TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

A response to "Erlang - overhyped or underestimated"

74 点作者 cannedprimates超过 14 年前

10 条评论

nivertech超过 14 年前
I used to all kinds of syntax or absence of it, like in Lisp or Forth. So I have no problem with Erlang syntax itself, but with its verbosity and inconsistency.<p>1. Versbosity<p>Sorted by code verbosity level, Erlang is somewhere in between Java/C++/C# (more verbose) and Ruby/Python (less verbose). But closer to dynamic languages, since you don't need to specify the types.<p>OTP code is significantly more verbose than plain Erlang and adds some boilerplate code (which can be generated for you by tools, like emacs or rebar, but you still need to read it and maintain it).<p>When you adding dialyzer specs, code become even more verbose. Since you need to duplicate function and argument names in the specs. Even worse - you need to duplicate dialyzer specs in edoc specs, since edoc uses it's own specs.<p>You can write your own macros and parse-transforms to reduce verbosity, but they aren't 1st class citizens and will not work from shell.<p>Given said all that, you still can expect up to 1:10 SLOCs reduction, comparing to C++ or Java, for large real life distributed applications.<p>2. Inconsistency<p>Example of inconsistency:<p><pre><code> proplists:get_value(Key,Proplist) dict:fetch(Key, Dict) dict:find(Key, Dict) gb_trees:get(Key, Tree) gb_trees:lookup(Key, Tree) ets:lookup(Tab, Key) dets:lookup(Tab, Key) element(Index,Tuple) lists:nth(Index,List) array:get(Index,Array) </code></pre> All this can be written in modern languages as:<p><pre><code> Data[Key] Data[Index]</code></pre>
评论 #2039381 未加载
评论 #2040011 未加载
评论 #2039487 未加载
swannodette超过 14 年前
Excellent post.<p>As I broaden (and continue to deepen) my knowledge of programming languages - Ruby, Python, Objective-C, C, C++, Java, JavaScript, Prolog, Scheme, Racket, Common Lisp, Io, Haskell, Clojure, Smalltalk ...<p>... I've become very, <i>very</i>, <i>VERY</i> wary of programmers who are overly concerned about syntax.<p>I've also become wary of programmers who care too much about regex and string manipulation facilities.<p>This post does a great job of concretely explaining why I have misgivings about people who express these kinds of opinions.
评论 #2039329 未加载
评论 #2039408 未加载
philwelch超过 14 年前
<i>Remember this: “In OO-languages state is kept in objects; in Erlang, state is kept in processes”.</i><p>If you think of OOP as "objects holding state and passing messages to each other", it's not difficult to map that idea to the Erlang world.
评论 #2039842 未加载
gaiusparx超过 14 年前
Strange to see there are people concerning about different syntax in different languages. Kind of like expecting Chinese language to have the same grammar as English.
ph0rque超过 14 年前
As someone who has been learning Erlang for a few months now, I mostly agree with the article. The only statement that rubbed me the wrong way was:<p><i>Many Erlang programs are running in companies with no open-source policy as well - don’t expect the programmers of those systems to even be able to talk about what they do. It is a competitive advantage to keep the mouth shut.</i><p>In fact, I see the shut mouths as a disadvantage in some cases: coming from the Ruby/Rails world, it was a shock for me to not find an open-source library, yet find a request for it back in 2000. Further investigation revealed some well-known authors having worked with the closed-source version. What we'll probably do is take the equivalent Ruby library, and make it work through Erlectricity.
allertonm超过 14 年前
I've no horse in this race, but the comment..<p>"I have written production level code in Erlang, namely a BitTorrent client good enough for everyday use"<p>...seems to be going some way towards proving the Acharya's point #4 for the following reasons:<p>1) No reference to any actual users of the code apart from the author himself.<p>2) No link to where the code is available.<p>3) Code is a single-user client, when Erlang's strength is usually considered to be in multi-user servers.<p>It's not obvious that the author understands what is meant by "production level", since the project mentioned does not even appear to meet the most liberal possible interpretation of this term, which would be "shipped".
评论 #2039356 未加载
Aloisius超过 14 年前
What matters to me is that code never relies on one person or a small group of people to maintain/improve it.<p>If a senior Python/C++/Java developer can open up the source code to some Erlang program that is having problems and fix a bug, then awesome. I can hire them by the boatload.<p>If I have to spend 2 months searching for a replacement for an Erlang developer that quit, well, that's not good at all.<p>My feeling is that senior Erlang people aren't exactly abundant. I have a friend who is flown around the world for Erlang contracting jobs simply because he's a well known senior Erlang guy. That makes me nervous as an employer.
评论 #2040471 未加载
评论 #2047354 未加载
mfukar超过 14 年前
Great post! Let me just say that for a person like me, who hasn't really used Erlang in large projects (mostly on small projects for fun), this post (as a retort to the previous one) was a really insightful introduction to the mentality behind/in Erlang.<p>One comment I've wanted to make about the initial post by Sudarshan Acharya and his point about Erlang's syntax is the following: before delving into functional languages, I had mostly experienced imperative &#38; OO programming. The syntax of any language doesn't really bother me: it's already unintuitive enough that I have to learn <i>a new language</i>, based on typed text, to tell the computer what to do, that worrying about it / contemplating its reason for existence isn't gonna help me in any way.
akkartik超过 14 年前
I get pissed when noobs diss lisp for its parens, and yet I complain about erlang's syntax. Mea culpa.<p>When I complain about its syntax I'm really thinking about its error messages. Leave out a comma, or replace a period with a semicolon, and prepare to be confounded. They take some getting used to, and I've never managed to get past them in several attempts.
评论 #2040021 未加载
joe_the_user超过 14 年前
<i>The trick of OO-languages is “abstraction is had by introducing another object”.</i> ... <i>In Erlang, the mantra is “abstraction is had by introducing another process”.</i><p>OK, it is hard for me to imagine that creating another process wouldn't have a larger conceptual overhead than introducing another object. Perhaps I just haven't seen the magic yet.<p>--<p>For me OO is far from a panacea. But does get some jobs done.<p>A big thing is the ability to construct multiple entities that can all be treated effectively the same way because they all implement the same interface. Your function happens to take Y structure. Suppose X inherits from Y but does something differently - Voilà, you have abstracted away your dependence from X. What would the Erlang equivalent to this be?
评论 #2039750 未加载
评论 #2039704 未加载