Sure, Haskell is a research language. Simon Peyton Jones has called it “a laboratory for types”. And for the people who really want to stretch their brains, to use those “more generalized abstractions”, that’s great. Use Haskell. Go make crazy new stuff and write papers about it.
But, we’ve just repudiated Wadler’s point even further. Haskell is not some perfect, discovered language. It’s not what aliens are using. It is not some higher form of multi-universal discourse. (Wadler: “So we may conclude it would be a mistake to characterise lambda calculus as a universal language, because calling it universal would be too limiting.”) Haskell is an invented language — or several invented languages, dialects differing by GHC version and extension.
Second, there’s nothing inherently superior about a research language. Indeed if you’re trying to build something today, you need a factory, not a laboratory. If Haskell is R&D, Elm is the product design team that needs to bring something to market. And perhaps surprisingly, Elm has found virtue in simplicity. In particular, it’s found that gratuitous abstraction and generics are harmful.
On more than one occasion, I’ve found myself reading Haskell code with return or do-notation, and had no idea what the concrete type was. Yes I know it’s a monad, I know it’s type correct, but in order to understand what this program is doing I need to know the type. Does return mean Just? Does it mean place into a singleton list? Does it mean perform an IO action? Does it mean a constant PRNG? I have no idea what this code does. For all the claimed guarantees, I might as well be reading JavaScript!
To a people building web applications, generic code is a vague hinderance, not an enlightened truth. For this sort of person, nouns like “monoid” are a trap. They’re interested in the verb: append. There’s nothing special about monads in Elm; it’s just that some types happen to have a function called andThen. Without do notation, and without the special IO type, a monad is just an interface. And without type classes, it’s just a convention.
It’s been pointed out that Haskell’s ladder of abstraction is backwards. They want you to grasp the abstract essence of a monad, and only then can you use the parser library. But most programmers just want to use the library already, and if it happens to give them intuition about a pattern they can apply elsewhere, so much the better. There’s no reason to point it out; just let it happen naturally. Let andThen be… discovered.
