Just Say ‘No!’
to Benefits-Only Analysis
Or, the perils of Awe-Inspired Advocacy.
Even I, as a pure functional programmer, grow weary of hearing about Haskell as if it were a language with no trade-offs. To talk about a language without mentioning its trade-offs is to advocate more than educate.
With Haskell, there are quite large tradeoffs with its laziness, quite non-trivial tradeoffs with its high level of strictness, and various bits of tradeoffs in nooks and crannies throughout the rest of it. Like any good language, there are great benefits packaged with considerable downsides. It is the nature of technology. But because so much Haskell advocacy is of a religious bent, providing a mere benefits-only analysis, a divisive confusion often prevails over educated clarity.
The problem is that there is a culture of indiscriminate advocacy in the Haskell community that has lived beyond its rightful lifespan. As soon as you learn Haskell, you are compelled to spread its gospel — talking to anyone who will listen (and some who won’t) about its unprecedented benefits. There are many reasons for such compulsion — the conceptual beauty of Haskell, the sheer amount of work you put into really understanding it, its culture of advocacy, or even as a small rebellion against the misery inflicted upon you by the ‘normal’ ways of doing software. These are mostly legitimate, but one can anticipate a lack of balance in the outcome.
The problem is that someone who has only newly learned about a technology is someone who has not yet run into its true limitations, nor experienced in its trade-offs across various domains. As it turns out, there are few less qualified to teach others about a technology than one who has not experienced the fullness of its implications. For an incredibly deep and thoughtful language like Haskell, this takes a very long, long time.
Fortunately, the solution, in principle, is easy enough — and applies far beyond just the Haskell community…
Just Say ‘No!’ to Benefits-Only Analysis
Recognize that every time you talk about the benefits of something, it is also your ethical obligation to talk about the trade-offs that enabled those benefits in the first place. Every hard-nosed engineer knows by reason and experience that every upside comes with a downside, and will (somewhat rightfully) dismiss those who refuse to divulge complete information about the latter, and especially those who do not seem to have that information in the first place.
Additionally, if you take it upon yourself to be a beacon of advocacy, it is also your responsibility to purposefully seek out and understand the trade-offs of what you advocate. Many trade-offs made by programming tools are initially quite hidden from view, especially to an eye not purposefully adjusted to see them… and especially in a conceptually deep language like Haskell.
But if you can’t think of any trade-offs, or automatically shrug them off as ‘too irrelevant to discuss’ — then it is time to check yourself for a religious mindset. We need much less of this in technology.
As both an advocate and a consumer, learn to just say ‘No!’ to benefits-only analysis.