Erlang Criticism Not Unwarranted

Eric's post on the recent Erlang criticism and his take on the subsequent trail of mail list discussions is fairly accurate in my opinion. I posted a long response on his blog and midway realized it's a blog post of its own. Here.

I'm not going to argue too strongly for "sequential Erlang" because it's really "concurrent Erlang" that stands out. The Erlang syntax is ok by me, but then I still prefer Lisp syntax to anything else I've seen anywhere. Simple.

And I can say nothing for the erlang list, except I've been skimming it too, with not so different reactions as yours.

Anyway...

"in development, the behavior of that existing function often changes thereby affecting all the calling functions"

As with all dynamic languages (especially those unlike Lisp and Smalltalk that do no have good refactoring editors), you need good unit test coverage. Which you are doing, right?

"defining dozens of one-line functions has made flow control difficult to follow in some circumstances."

This is pretty much the same for all functional languages, and even Smalltalk, which tends to have many small methods, where other OO language programmers tend to write overlong methods.

Good tools, which again Lisp and Smalltalk tend to have, and others don't, are indispensable. Otherwise the only thing that tends to help IMHE are again many good tests to read, "Oh, so this is the thing to call, and how to call it."

I still think that's better than really long methods Java or other languages that tend not to be reusable without a good deal of pain. (For one thing, they tend not to be really well tested.)

"It shouldn't take a committee to help you write good file handling code."

I don't disagree completely except that Wide Finder pushed Erlang and its community into a new I/O situation. So most of what happened by the end of it was a core Erlang member adding some new core capabilities to the language. Then also what happened was the exposure of a development process for how to evolve concurrent algorithms generally in Erlang or maybe any concurrent system. I would think both, especially the new core I/O capabilities, will help down the road without requirement the full committee.

"the language is a DSL for networking gear."

Which essentially what it is. CouchDB, Yaws, ErlyWeb, etc. will help, but mostly Erlang and its surrounding code is not much more than what the telecom programmers were using in the mid-1990's. that is its upside and its downside.

"I can write a Scala function to make an HTTP POST in four lines of code and have it run screamingly fast"

Two points:

• Yeah, *but* then you also have to deal with all of Scala's type system. "Oh, you need an existential type here because a mere parameterized type gets the type system all confused, even though it's fairly obvious what you are trying to do."
• Yeah, *and* what the rest of the world should learn from Erlang is "concurrent Erlang" and how to apply *those* lessons in a distributed, multi-language way. You shouldn't need to use Erlang to get the benefits of things like OTP. OTP and basic message passing with pattern matching is missing from pretty much every system but Erlang. Scala and Java do not have an OTP although Scala addresses the latter.

(And now you see why I thought so highly of Jini and Javaspaces, because it also attempts to bring these to Java. It's the closest thing Java has to Erlang/OTP. But now, where did that go again? Dang it.)

Like you wrote...

"actors are so important, it will be amazing when the programming public realizes why we all need to do this"

You could also try Gambit Scheme, which I think is better as a sequential language (Lisp) but also has pretty much Erlang-scale thread/mailbox performance on a single CPU. Not much in the way of distributed or multi-core support yet. You get more of those, "shared nothing" threads, and functional data structures if you use the Termite package on top of Gambit. Multi-core is bubbling to the top of Gambit now that a decent package system has been released.