Whenever I decide to learn a new language, the first small program I try to write is a JSON parser, which converts a commonly used data format for web applications into a structure that can be manipulated by the computer . While the parser I remembered writing in C had resulted in a programmatic grotesquerie spanning over a thousand lines, I felt a thrill of pleasure when Haskell allowed me to achieve this in less than a hundred.
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 fundamental concepts, that of the “monad,” has given rise to a cottage industry of explanations, analogies, and videos. A notoriously useless explanation, famous enough to be autocompleted by Google, says: “A monad is just a monoid in the category of endofunctors. »
Language is also more looked down upon than explored. Steve Yegge, a popular curmudgeonly blogger from yesteryear, once wrote a satirical article about how, finally, the Haskell community had managed to find the one “industrial programmer who doesn’t give a damn about Haskell.” For programmers like Yegge, Haskell is synonymous with a kind of overintellectualized and impractical language with little industrial applicability.
What Yegge failed to understand, however, was that resorting to Haskell is rarely a pragmatic decision. It is an intellectual, even aesthetic, question. At its core, Haskell has more in common with the films of Charlie Kaufman than with other programming languages: highly cerebral, delightfully quirky, and strangely tasteful; appreciated by connoisseurs and considered pretentious by foreigners. Haskell is, one might say, a cult classic.
This Haskell has never Widespread adoption illustrates a paradoxical truth in software engineering: good programming languages are not always good 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 required by a skilled watchmaker. But Haskell code is actually a mathematical expression in code form. It is the language par excellence of the engineer. Haskell is a pure mathematician.
The skills of a good engineer and a good mathematician do not 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. It’s generally good. After all, many doctors would make poor molecular biologists, few lawyers are legal philosophers, and the vast majority of MBAs know nothing about econometrics. But this means that few programmers can actually master Haskell. That of course includes me, whose legs weaken at the sight of phrases like “F-coalgebra” and “type class metaprogramming.”
Yet, when I think of Haskell, a phrase about Martin Amis’ prose comes to mind: “the primacy he gives to style over matter.” Haskell programmers are style supremacists, and there is nothing to apologize for. In an industry often obsessed with usefulness and desirability, the Haskell community should not feel obligated to gather evidence of its usefulness. Instead, he should simply retort: What’s wrong with pointless intellectual exercises?
Because the problem with pointless exercise is that it doesn’t stay that way for long. Even when “industrial programmers” avoided Haskell, language designers took note. In recent years, a Haskell-style paradigm has become fashionable because of the many advantages it offers: making certain categories of bugs impossible by design, making the correctness of a program more provable, and allowing parallel calculations easy. Some of the most anticipated updates in new versions of imperative languages are those inspired by functional programming. Ultimately, Backus’s anti-von Neumann plea was heard. The programming has been released.
