| Quote: "You call 'Aversion to Extremes' a cognitive bias [... but] the more extreme a language pursues a theoretical concepts, the less used it typically ends up being in practice." Yes, people use languages with solid theoretical foundations less because they perceive them to be extreme. That was my point. Quote: "I can't imagine [... any measure that] makes these 'purity-oriented' languages appear to "work better in practice". How about SLOC required to implement a task? Take a look at this:
http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf
Its an old paper, but the findings are still perfectly valid. Quote: "each process is like an object, holding onto state". This is the actor model. Erlang is an uncompromisingly pure implementation of the actor model, which is why it is so effective. Again, I think you are making my case for me. Your use of the term "sacrificing flexibility" sets up a false dichotomy between purity and flexibility, as though there were programs that are difficult to write in Haskell. |
Measuring LOC required to implement a task is meaningless. If you implement a task in python in fewer LOCs than what I need in C, that doesn't necessarily mean anything, because my code might fit on an 8-bit microcontroller, run faster, ... or meet any other number of imaginary or real additional requirements I might think of (and people always have lots of those!) "Have 10% fewer lines of code" is pretty much never a given requirement, though.
Sure, erlang is a "uncompromisingly pure implementation of the actor model", but then python is an uncompromisingly pure implementation of the python model, and C is an uncompromisingly pure implementation of the C model, so that's hardly an interesting argument. Erlang is pretty much what popularized the actor model as we consider it nowadays in mainstream programming, so that's tautological.
The point (which you have not actually argued against) is that erlang is also a functional language, but not a pure one; it allows side-effects, it allows sending messages, it allows storing data in your (destructibly updatable) process dictionary, et cetera.
That means erlang benefits from the features it inherits from the functional languages, even though it doesn't go "full functional" in the sense some other languages do.
If you don't think there are programs that are difficult to write in haskell, agda, miranda, ML, ..., I have to doubt that you have done a substantial amount of them, and/or that you have applied it to any actual real-world task.