Conciseness as a language feature is ill defined and probably not uniform. Different languages could be more or less concise depending on the problem.
Erlang as a functional language can be very concise, beyond Ruby or Python. Specifically pattern matching often replaces if statements and recursion and list comprehensions can replace loops.
For example Java would have something like this:
String foobar(int number){
if (number == 0) {
return "foo";
} else if (number == 1) {
return "bar";
}
throw new Exception();
}
while Erlang code would look like:
foobar(0) -> "foo";
foobar(1) -> "bar".
With the exception being inherent because there is no clause for input other then 0 or 1. This is of cause a problem that lends itself well to Erlang style development.
In general anything you could define as a transformation will match a functional language particularly well and can be written very concise. Of cause many functional language zealots state that any problem in programming is a transformation.
Erlang allows you to realize functionallity in very few lines of code, compared to my experiences in Java and Python. Only Smalltalk or Scheme came near for me in the past. You've get only little overhead, but you typically tend to speaking identifiers for modules, functions, variables, and atoms. They make the code more readable. And you've got lot's of normal, curly, and square braces. So it depends on your keyboard layout how comfortable it will be. You should give it a try.
You have to spend some time, write code, to understand erlang's sweet spot, vs. all the other emerging tools, DHT, doc stores, mapreduce frameworks, hadoop, GPU, scala, ... If you try to do, say SIMD type apps outside the sweet spot, you'll probably end up fighting the paradigm and writing verbose code, whereas if you hit problems that need to scale servers and middleware seamlessly up and down, it flows naturally. (And the rise of scala in its sweet spot is inevitable, too, I think)
A good thing to look up would be the Tim Bray Wide Finder experiment (distilling big apache log files) from a couple years ago, and how he was disappointed with erlang.
I generally don't recommend putting much store in the Alioth shootout, given you inevitably end up comparing really good and bad code, but if you need to put numbers of LOC, erlang vs. C, ruby, whatever
发布评论
评论（4）
作为一种语言特征，简洁性的定义不明确，而且可能不统一。 根据问题的不同，不同的语言可能或多或少简洁。
Erlang 作为一种函数式语言可以非常简洁，超越 Ruby 或 Python。 具体来说，模式匹配通常会取代 if 语句，而递归和列表推导式可以取代循环。
例如，Java 会有这样的东西：
而 Erlang 代码看起来像：
例外是固有的，因为除了 0 或 1 之外没有输入子句。这自然是一个非常适合 Erlang 风格开发的问题。
一般来说，您可以定义为转换的任何内容都将与函数式语言特别匹配，并且可以写得非常简洁。 当然，许多函数式语言狂热者表示，编程中的任何问题都是转换。
Conciseness as a language feature is ill defined and probably not uniform. Different languages could be more or less concise depending on the problem.
Erlang as a functional language can be very concise, beyond Ruby or Python. Specifically pattern matching often replaces if statements and recursion and list comprehensions can replace loops.
For example Java would have something like this:
while Erlang code would look like:
With the exception being inherent because there is no clause for input other then 0 or 1. This is of cause a problem that lends itself well to Erlang style development.
In general anything you could define as a transformation will match a functional language particularly well and can be written very concise. Of cause many functional language zealots state that any problem in programming is a transformation.
与我在 Java 和 Python 中的经验相比，Erlang 允许您用很少的代码行实现功能。 过去只有Smalltalk 或Scheme 能接近我。 您只需要很少的开销，但您通常倾向于说出模块、函数、变量和原子的标识符。 它们使代码更具可读性。 并且有很多普通的大括号、大括号和方括号。 因此，这取决于您的键盘布局，它的舒适程度。 你应该尝试一下。
穆埃
Erlang allows you to realize functionallity in very few lines of code, compared to my experiences in Java and Python. Only Smalltalk or Scheme came near for me in the past. You've get only little overhead, but you typically tend to speaking identifiers for modules, functions, variables, and atoms. They make the code more readable. And you've got lot's of normal, curly, and square braces. So it depends on your keyboard layout how comfortable it will be. You should give it a try.
mue
Erlang 非常简洁，尤其是当您想要实现性能和可靠性时。
即使与 Haskell 相比，Erlang 也很简洁：
即使与 C++ 相比，速度也快得惊人（而且可靠）：
（SLOC 减少 18 倍并不奇怪）。
无论如何，这始终取决于您的喜好和您想要实现的目标。
Erlang is surprisingly concise especially when you want achieve performance and reliability.
Erlang is concise even when compared to Haskell:
And is surprisingly fast (and reliable) even when compared to C++:
(18x less SLOC is not surprise).
Anyway it always depends of your preferences and goal what you want achieve.
你必须花一些时间，编写代码，了解 erlang 的最佳点，与所有其他新兴工具，DHT，文档存储，mapreduce 框架，hadoop，GPU，scala，...如果你尝试这样做，说 SIMD 类型如果您的应用程序超出了最佳点，您可能最终会与范式作斗争并编写冗长的代码，而如果您遇到需要无缝地上下扩展服务器和中间件的问题，它会自然而然地进行。 （我认为 scala 在其最佳位置的崛起也是不可避免的）
值得一看的是几年前的 Tim Bray Wide Finder 实验（提取大的 apache 日志文件），以及他是如何失望的与二郎。
我一般不建议在 Alioth 枪战中投入太多精力，因为你不可避免地最终会比较真正好的和坏的代码，但如果你需要投入 LOC、erlang 与 C、ruby 的数量，无论什么
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/erlang.html< /a>
You have to spend some time, write code, to understand erlang's sweet spot, vs. all the other emerging tools, DHT, doc stores, mapreduce frameworks, hadoop, GPU, scala, ... If you try to do, say SIMD type apps outside the sweet spot, you'll probably end up fighting the paradigm and writing verbose code, whereas if you hit problems that need to scale servers and middleware seamlessly up and down, it flows naturally. (And the rise of scala in its sweet spot is inevitable, too, I think)
A good thing to look up would be the Tim Bray Wide Finder experiment (distilling big apache log files) from a couple years ago, and how he was disappointed with erlang.
I generally don't recommend putting much store in the Alioth shootout, given you inevitably end up comparing really good and bad code, but if you need to put numbers of LOC, erlang vs. C, ruby, whatever
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/erlang.html