Interesting read. Honestly, Scala looks like gibberish to me. I strongly distrust a language where I can't hold its conceptual model in my head all at once. This is true for C, true for JS, true for ML, and hell even true for Common Lisp (once you realize it's all macros over a simple core). It is not true for Scala or Haskell, at least for me.
> 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.
The power continuum isn't the same as the conceptual simplicity continuum. C++, for example, is less powerful than Common Lisp while being more complex as well.
At the same time, is Haskell more powerful? Common Lisp, relative to C++, buys me the ability to run arbitrary functions at compile-time and generate code. Haskell takes away that power, and as far as I can tell doesn't add anything to replace it. Indeed, it lets your code do strictly less thanks to the type system.
There's also the reliability/error-proneness continuum.
Haskell is probably less powerful than Common Lisp (Template Haskell technically yields the power, but it is less practical). The type system may also rule out some useful programs.
However, Haskell yields more reliable, less error-prone programs. The number of runtime bugs that get through the Haskell compiler is substantially lower than that of Common Lisp (I venture this is still true if you use CL's optional typing).
Haskell also has forms of power that as far as I know, Common Lisp does not have. Namely, type-classes allow expressing various forms of static-type-based polymorphism that's not expressible via Common Lisp (e.g: Return-type polymorphism).
In practice, having a smaller emphasis on macros pushed Haskell to abstract various repeated patterns using means other than macros. Some cases are covered by laziness. Others are covered by passing around simple functions. Some are covered by special wrapper types and combinators.
My personal opinion is that the extra composability of these alternatives is more beneficial than their weaker power is detrimental. The cases where alternatives to macros cannot be found are relatively rare, so the extra cost of Haskell's macro system (TH) rarely needs to be paid.
