Tuesday, August 28, 2007

The Seven Deadly Sins of Erlang

More Erlang Related Articles

You want to know what I really think of Erlang? Erlang is crap. That’s what I think. Now don’t feel bad if you are an Erlang fanatic. And please don’t get mad. I always tell it like I see it. That’s my style. Besides, I think all programming languages are crap. Right now, I just have a specific bone to pick with the functional programming model and Erlang in particular. It is not the panacea that its supporters make it out to be. It is a false god, in my opinion. It has nothing really interesting or revolutionary to offer to a bug-haunted computing world that is suffering from a chronic productivity crisis and is currently undergoing a painful transition from sequential processing to massive parallelism. Without further ado, here are the seven deadly sins of Erlang:
  1. It has no mechanism for automatically enforcing deterministic timing at the operation level. In other words, operations in an Erlang program are neither reactive nor synchronous. This is an absolute must for rock-solid reliability. Note: Synchronous processing is not the same as synchronous messaging.
  2. It has no mechanism for automatically enforcing data and event dependencies. Bad for the same reason as above.
  3. It is implicitly sequential. Very bad when it comes to parallel programming.
  4. It is explicitly concurrent. Bad for the same reason.
  5. It is algorithmic. The algorithmic model of computing is a rampaging dinosaur at an amusement park. It is the primary cause of every ill that ails the computer industry. It is an insidious disease that came to life close to 150 years ago back when the first computer was built with gears, cogs and rotating shafts. It hides the true nature of computing. It should be put out of its misery and securely locked up in an antique museum, right next to the slide rule, the buggy whip and the typewriter.
  6. It is a computer language (based on English). Why English? Why not Mandarin, Swahili, Romansh or Latin for that matter? Programming a computer should have absolutely nothing to do with one’s mother tongue. Written code is notoriously hard to understand, even when it is your own code. Only programming nerds are enamored with cryptic code. It's a badge of honor to them. Truth is, the very fact that programming has to rely on a specific natural language is a sure sign that something is wrong with the linguistic approach. Not to mention the nasty little fact that languages are inherently sequential, which makes them ill-suited to parallel programming.
  7. Last but not least, Erlang does not have inherent support for plug-compatibility (drag and drop programming) and a searchable/browsable object repository. This is essential to effective and fast software composition and reusability. But then again, plug-compatible components make much better sense in a graphical environment. I happen to like Jeff Han's multi touch screen interface technology. I think it's probably going to play a vital role in our parallel programming future.

My question to Erlang supporters is this. If functional programming was all that it’s cracked up to be, how come Joe Armstrong (et al) felt it necessary to provide a method for failure localization? No need to answer. Joe alreeady did. He assumed that "large systems [written in a functional language or not] will probably always be delivered containing a number of errors in the software." By contrast, the COSA philosophy is that software should never fail, period.

See Also:
Parallel Programming, Math and the Curse of the Algorithm
The Age of Crappy Concurrency: Erlang, Tilera, Intel, AMD, IBM, Freescale, etc…
Half a Century of Crappy Computing
Parallel Computers and the Algorithm: Square Peg vs. Round Hole

11 comments:

Louis Savain said...

Ok, this being my blog, all comments from anonymous cowards get trashed. :-D If you don't like what I write, don't read it.

About trapexit: they have a bot that automatically grabs anything I post that has Erlang mentioned in it. Complain to them, not me. I don't care.

Sal Mangano said...

I enjoy your writing very much. It is very funny. It makes me feel like every day is April Fools day. Keep up the great work.

Louis Savain said...

Hey, Salvatore. Paisano! As they say in the deep American south, you come back soon, you hear. I'll play "Mambo Italiano" for you. And don't let the door hit your behind on the way out.

Konrad said...

Sorry for pointing it out, but it seems that erlang has only one deadly sin: that of not being COSA.

zbrown said...

It would seem your thoughts are nothing but a pipe dream. Not to mention your COSA model has no tangible, usable or viable output/product that can back up what you say. Not to mention you reinvent concepts in erlang and redefine words, such as algorithm. At the end of the day, you're just another nut.

David Hopwood said...

1. It has no mechanism for automatically enforcing deterministic timing at the operation level. In other words, operations in an Erlang program are neither reactive nor synchronous. This is an absolute must for rock-solid reliability.

You haven't given a concrete argument why you think this is necessary for reliability. Certainly, there is a strong argument for limiting nondeterminism, but not for eliminating it entirely. In most asynchronous messaging models (including Erlang with some minor caveats), processes are internally deterministic, and only the message arrival ordering introduces nondeterminism. Since nondeterministic ordering of input events is usually inherent to the problem specification, I don't see this as a problem.

2. It has no mechanism for automatically enforcing data and event dependencies. Bad for the same reason as above.

I'll grant you this one. Such a mechanism would not be incompatible with the rest of Erlang's semantics.

3. It is implicitly sequential. Very bad when it comes to parallel programming.

Current processors can't make effective use of very fine-grained parallelism, so it's not surprising that current language specifications are not optimized for that. Build a massively parallel processor, and the languages to exploit it will be available in very short order.

4. It is explicitly concurrent. Bad for the same reason.

Implicitly concurrent languages have been tried (e.g. Act, Oz 1), and their designers eventually gave up on that approach. For example, the designers of Oz 2 say that "We changed to sequential composition because it makes programming and debugging substantially easier."

5. It is algorithmic. The algorithmic model of computing is a rampaging dinosaur at an amusement park. It is the primary cause of every ill that ails the computer industry. It is an insidious disease that came to life close to 150 years ago back when the first computer was built with gears, cogs and rotating shafts. It hides the true nature of computing. It should be put out of its misery and securely locked up in an antique museum, right next to the slide rule, the buggy whip and the typewriter.

This is a rant, not a technical argument.

6. It is a computer language (based on English). Why English? Why not Mandarin, Swahili, Romansh or Latin for that matter?

More to the point, why not Swedish? Because English is a lingua franca in the programming community. Even with a graphical language, you'd still end up with the primary documentation in English.

Programming a computer should have absolutely nothing to do with one’s mother tongue. Written code is notoriously hard to understand, even when it is your own code.

See my comments on graphical vs textual languages here.

7. Last but not least, Erlang does not have inherent support for plug-compatibility (drag and drop programming) and a searchable/browsable object repository.

This is mainly an issue of tools and library support, not of language or programming model. Smalltalk and Self demonstrate what can be done here, so it's not as though this would be entirely new technology.

I happen to like Jeff Han's multi touch screen interface technology.

Thanks for the reference (more information here). That is indeed quite neat, although a programming language environment had better not be entirely dependent on it, in order to achieve widespread adoption.

Scott Fleckenstein said...

I'm curious,

You assert that a "mechanism for automatically enforcing deterministic timing at the operation level..is an absolute must for rock-solid reliability".

The motorola phone switch written in erlang has acheived "9 nine's" uptime without this feature. Are they lying, or are you wrong?

Louis Savain said...

Scott wrote, The motorola phone switch written in erlang has acheived "9 nine's" uptime without this feature. Are they lying, or are you wrong?

No. You are deceiving yourself and others by equating uptime with reliability. Uptime is the result of the fault tolerance characteristic of Erlang, which is not in dispute. It does not mean a lack of failures. There are many situations (e.g., avionics, financial systems, power generation, etc...) where failure is not an option, period. Erlang does not solve the software unreliability problem, it assumes it. Joe Armstrong said so himself at the beginning of his thesis. Sorry.

Scott Fleckenstein said...

deceiving? It was an honest question. I think maybe you've had a little too much caffeine.

Louis Savain said...

Scott wrote: "deceiving? It was an honest question. I think maybe you've had a little too much caffeine."

You're obviously a hostile Erlang fanatic who took offense. Now that I think about it again, I should have said "lying" instead of "deceiving". You were just plain lying and you know it. As I wrote elsewhere to Salvatore Mangano (il paisano), don't let the door hit your behind on your way out. :-D

Louis Savain said...

Hey, Hopwood. You bore me, man. I'll leave your comments on my blog for historical purposes only. But then again, I may trash them later just for the hell of it. :-D