.png "Review: Tern GSD S10 Electric Cargo Bike (3rd Gen)")
At the same time, I understood almost immediately why Haskell was—and still is—considered a language more admired than used. Even one of its most basic concepts, that of the “monad,” has spawned a cottage industry of explainers, analogies, and videos. A notoriously unhelpful explanation, famous enough to be autocompleted by Google, goes: “A monad is just a monoid in the category of endofunctors.”
The language is also more despised than explored. Steve Yegge, a popular curmudgeon blogger of yesteryear, once wrote a satirical post about how, at long last, the Haskell community had managed to find the one “industry programmer who gives a shit about Haskell.” For programmers like Yegge, Haskell is a byword for a kind of overintellectualized, impractical language with little industry applicability.
What Yegge didn’t understand, however, is that using Haskell is rarely a pragmatic decision. It is an intellectual, even aesthetic, one. In its essence, Haskell has more in common with the films of Charlie Kaufman than other programming languages: highly cerebral, charmingly offbeat, and oddly tasteful; appreciated by those in the know and judged by outsiders as pretentious. Haskell is, one might say, a cult classic.
That Haskell never gained widespread adoption exemplifies a paradoxical truth in software engineering: Great programming languages aren’t always great for programming.
Haskell is not inherently more difficult to learn than something like C, but the two languages pose different challenges. Writing in C is akin to precision engineering, requiring the kind of attention demanded of a skilled horologist. But Haskell code is, really, code-shaped mathematical expressions. C is a quintessential engineer’s language. Haskell is a pure mathematician’s.
A good engineer’s and a good mathematician’s aptitudes don’t always overlap. The industry’s not-so-well-kept secret is that most programmers aren’t as good at math or logic as you might think. This is mostly fine. After all, many doctors would make poor molecular biologists, few lawyers are legal philosophers, and the great majority of MBAs know zilch about econometrics. But this means few programmers can really master Haskell. This includes me, of course, whose legs weaken at the sight of such expressions as “F-coalgebra” and “typeclass metaprogramming.”
Still, when I think about Haskell, a line about Martin Amis’ prose comes to mind: “the primacy he gives to style over matter.” Haskell programmers are style supremacists, and it’s nothing to apologize for. In an industry often fixated on utility and expediency, the Haskell community should not feel obligated to summon evidence of its usefulness. Instead, it should simply retort: What’s the problem with useless intellectual exercises?
Because the thing about useless exercises is they don’t stay useless for long. Even when “industry programmers” shunned Haskell, language designers took note. In recent years, a Haskell-style paradigm has come into vogue because of the treasury of benefits it offers: rendering certain categories of bugs impossible by design, making a program’s correctness more provable, and enabling easy parallel computation. Some of the most anticipated updates featured in new versions of imperative languages are those inspired by functional programming. In the end, Backus’ anti–von Neumann plea was heard. Programming has been liberated.
