Smug Erlang Weenie

Concurrency is trivial! It's bad implementations of concurrency in most languages and operating systems (i.e. shared-state threads) that make people think it's difficult.
All you have to do is figure out the natural concurrency in a problem and the code writes itself.
Look at how much faster Erlang is with 100,000 processes than Java!
Being able to have thousands of inexpensive processes opens up new solutions to problems.
You can't write reliable code unless it's distributed across multiple machines.
There's no need for defensive coding. Just LetItCrash.

So, the task is to populate this page with clever and piercing commentary on the outrageous and inflammatory claims typical of the SmugErlangWeenie. But alas! Though it's easy to find Erlang programmers praising their beloved language, they too seldom use it to smugly disparage other respectable languages.

Well, perhaps we can make a start at correcting this unfortunate oversight - how about a few provocative claims about writing concurrent programs. But whom should we provoke? It has to include those most likely to provide witty and incisive reactions, and that must surely include the SmugLispWeenies (after all, everybody else is already busy having a go at them). So let's build our inflammatory claims on top of PaulGraham's famous article, BeatingTheAverages (cf. BlubParadox):

: As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
: When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.
: By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.

The smug Erlang programmer can only respond to this with a smug smile, because he knows that LispIsaBlubToo?. The inductive step in this hypothetical proof of Lisp's ultimate superiority is totally bogus. After all, how can you get anything done with Lisp? It doesn't even have proper concurrency!

(The Lisp programmer may retort that Erlang has nothing to match Lisp's macros. And he'd be absolutely right. That just goes to show how silly the SmugLispWeenie's one-dimensional model of language power is!)

So what is "proper" concurrency? Having proper concurrency means that you can easily write a program that does a great many things at once, without using any "tricks", and the program is easy to understand. To have this property in a programming language requires the other language features to be chosen carefully. You mustn't have to fight the other parts the language to write concurrent programs. As they say, the forces must be balanced, and the language must be consistent within itself.

Java does not have proper concurrency, because concurrency doesn't fit in with the rest of its features. Adding concurrency adds complexity. Are my objects thread-safe? and which ones have to be?. These questions are difficult because you are fighting the paradigm. Most state and behaviour is encapsulated within objects, but concurrency is not. Each method call or state change in an object is a potential interaction between threads. To understand the program, you must understand all of these interactions. The tension between hiding behaviour within objects and exposing it to understand the concurrent interactions is not resolved by the language. In fact, only some parts of the language even support the concurrency they do have; see http://java.sun.com/products/jfc/tsc/articles/threads/update.html.

Thought experiment: can you imagine a horrible concurrency bug involving 'java.lang.Vector'?

CommonLisp does not have proper concurrency either, and you can't just add it with a few macros, or even a few special forms. Lisp has a lot of features that work against concurrency: data structures are frequently modified, functions are redefined, assignments are made to shared variables, and so on. The idea of making it easy to write concurrent programs isn't on the radars of Lisp programmers yet. When they implement concurrency, it's the low-level kind like C and Java, suitable only for writing hairy and complicated programs. These features introduce whole new classes of bug to large bodies of code that were previously correct. Like ThreeStarProgrammers of Blub, they ignore the "weird" alternatives, and just go with the macho low-level ways they know.

'Termite scheme implements proper concurency'

Thought experiment: what would be harder, adding Erlang's concurrency to Common Lisp, or Lisp's syntax and macros to Erlang? How would each turn out?

The latter has been done: see Robert Virding's LispFlavouredErlang?, a Lisp-2 at http://github.com/rvirding/lfe/

Well, as pointed out below - CommunicatingSequentialProcesses can be modelled in almost any programming language which supports threads. All you gotta do is refrain from sharing any mutable objects; and communicate solely via passing immutable ValueObjects around. Which can certainly be done in LispLanguage--SmugLispWeenie (You still lose bigtime for having to make all of your libraries "thread-safe.")

Yes, Common Lisp is powerful enough that you can do proper concurrency, in principle, but it seems to me any time you have to tell yourself "all you have to do is not do X and not include any code that does X, and only ever do Y," I'm not sure that it ever works out. You end up having to build the whole library around not-doing-X, at which point you might as well have your own language since you can't even import anyone's existing code without auditing it for X. Indeed Lisp with a library built around concurrency is the basic point of ClojureLanguage, though Clojure is focused on within-JVM concurrency and doesn't match Erlang's story for distributed processes.

Insert your smug assessment of any other language here.

Rule of thumb: if you ever hear yourself say, "We need to audit that code for thread-safety", then you are programming in the wrong language.

Erlang does have proper concurrency. An Erlang program is structured as a set of small CommunicatingSequentialProcesses. The needs of such processses are reflected in the other features of the language: data structures are immutable, so you cannot accidentally "communicate" by modifying them, even by accident (bug); interaction is by explicit message passing, so simple interactions are easy and complex interactions are possible (and easily recognised); most of the code does not require interaction and is purely functional, which completely separates it from concurrency concerns; the principle of supervisor processes handling recovery/restart/logging for other processes leads to very robust programs.

Some of these features may seem small, and others may seem inconvenient, but in combination they are marvellous. Erlang is an exceptional language because adding more of the real world's concurrency to a program doesn't add complexity and confusion, it makes the program simpler and more robust.

When are the rest of you going to get it?

Contributors: LukeGorrie (also a SmugLispWeenie)

Please flame below this line:

This is all quite silly. At no point does Erlang claim to be the end-all of languages; in fact, right in the list of advantages of the language in the beginning of the manual is that it's easy to interface to other languages for problems that are better solved in other languages, and at many points the language manual displays specific problems whose solutions in Erlang are cumbersome or inefficient. These language wars only come up around those who haven't actually read the manual, which goes to say a lot about the kinds of people who engage in this kind of vacuous diatribe. Erlang aims to do one thing and to do it well: soft realtime massive parallelism with an emphasis on fault tolerance. The weenies making the wars you're talking about are mostly coming from inflammatory pages like these. You, sir, are creating the people about whom you kvetch.

By the by: your smugness is off the charts. To point it out in others is an exercise in displaying ignorance of your own demeanor.

What's good about erlang is it is impossible to do it another way. Java/C++/etc can be structured as CSPs, but any programmer at any time can can make cross-thread calls.

I think the area of smugness that you are looking for is that erlang weenies realize that OO programmers are locked in a sad and confining mindset. And those few OO'ers who are deprogrammed and/or liberated by erlang feel a euphoria that often reduces/eliminates any desire to go back and taunt the less fortunate who remain shackled to lesser languages/environments.

That being said, how is the AspectOrientedProgramming thing going? - I love AOP because after you peel away all the pompous handwaving it is really just a way to legalize breaking encapsulation and since the BS is so deep people don't notice that it is really just adding global procedural subroutines to OO land - rather than a saving grace, I'd call it a deep crack in the dam... Maybe they should call it ProcedJ instead of AspectJ

As long as I moved into the realm of "things that cannot be said", I'd say that from where I stand OO seems to be like the Ptolemaic theory of the solar system, a complex system with lots of epicycles and when problems arise, a few more epicycles get chucked onto the pile. I have got to think that the successor to OO will have a more simple, elegant flair (Erlang?) not unlike how Kepler elegantly simplified astronomy. I think there are probably other of the same opinion, but they are shouted down by those who are making money from OO. How long do OO people think that OO will remain the best advertised, most profitable programming paradigm (I hesitate to say most popular since people tend not to choose their programming methodology, they just take what is on the bookshelf at the time)? I think AOP is a sign of the beginning of the end.

-- A Smug Erlang and otherwise non-OO Weenie who mistakenly ended up in OOz [I blame google!] :)

Firstly, congratulations on your smugness. You have penned a rant that would make PaulGraham proud; if you keep working on your technique you might find yourself in the august company of ErikNaggum. Well done, Sir.

Of course, a few facts may require correction:

Encapsulation, especially the bondage-and-discipline style of encapsulation found in such languages as CeePlusPlus and JavaLanguage, where the programmer has to do extra work to tear down the firewalls the language designers think are proper, is not really a fundamental property of OO - the mantra of PolymorphismEncapsulationInheritance nonwithstanding. PythonLanguage, CommonLispObjectSystem, and several other OO systems will let you frob whatever object internals you like; encapsulation in these environments is voluntary and by convention. (OTOH, there are many non-OO systems which do feature encapsulation; though they aren't widely used these days). If Erlang's main selling point were that it didn't have "private", that wouldn't be a convincing argument.
To me, AspectOrientedProgramming isn't all that terribly new and exciting, though perhaps I don't grok it much. CommonLisp programmers have been doing similar with MetaObjectProtocol hacking for years; indeed, I've done quite a bit of pseudo-aspect stuff in C++ just using MixIn inheritance. The interesting part of AOP is the research in how compilers can automatically "meld" crosscutting concerns together, without troubling the poor programmer. To claim that AOP is all about bypsassing the encapsulation of OO, however, seems to me to be rather dubious. Unless you're stuck coding in Java, you don't need AOP or any other new paradigm to do things beyond what the class designer thought proper.
Your references to Ptolemy and epicycles (I will note that the AddingEpicycles page has spent a lot of time in RecentChanges of late), while interesting, really doesn't say anything. At least not anything verifiable or falsifiable. It's really just a high-falutin' way of saying "I think OO is too complicated". To which I must ask: Complicated in what way?
Finally, I should note that nowhere did you mention the one advantage that usually is claimed for Erlang; CommunicatingSequentialProcesses. While CSP is nice, and it's well known that MessagePassingConcurrency scales much better and is easier to test/debug/verify than SharedStateConcurrency - this issue is also orthogonal to OO. One could have a fully polymorphic language, complete with inheritance/delegation and a robust type system (static or dynamic), and still require that threads only communicate via messages (and cross-thread pointers aren't allowed). Indeed, many OO languages, including CommonLispObjectSystem and C++, say utterly nothing about concurrency whatsoever. Both languages have been extended numerous times with various concurrency models (including numerous shared-state models), but neither require any particular technique. Of course, the SeaOfObjects? approach is endemic in Smalltalk and Java, but it's not a feature of all OO systems.

"To which I must ask: Complicated in what way?"

Sorry, you cannot have an answer. I invoke Date’s Incoherence Principle — It’s not possible to treat coherently that which is incoherent. First, define coherently what is OO. After that we can discuss, coherently, in what way it is too complicated. Until then the right answer is "'I think OO is too complicated'". The burden is on OO, not the people who recognize that it is unformalized.

OO is polymorphism, and the calling of methods in objects. That's the minimum set of features every languages that calls itself OO has. There are other features that many OO langauges have but those two are the main ones. But from your rant I think what you're really trying to say is not that OO is too complicated but that Java is too complicated, and on that I would agree.

Erlang is a pretty language, especially the concurrency. Hopefully it will be the next big language.

Erlang does have macros. How are they different from CommonLisp or SchemeLanguage macros? they are like CeeLanguage macros

It's possible to hook into the compiler to perform syntactic transformations (I believe the bit-field syntax was implemented this way) but, by all accounts, rather hairy.

Smug they may be, but they have something to be smug about. I wouldn't be so sure my language is good if I were a VB programmer, but with Erlang ...

CategoryWeenie