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:
- 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.
- It has no mechanism for automatically enforcing data and event dependencies. Bad for the same reason as above.
- It is implicitly sequential. Very bad when it comes to parallel programming.
- It is explicitly concurrent. Bad for the same reason.
- 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.
- 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.
- 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.
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