In the last year, the Haskell language and associated technology have been seen developing into the most mature ecosystem we’ve seen to date, with innovation happening left and right across a variety of fronts. Editor tooling, for instance, is reaching levels of maturity we only dreamed about years ago. Simultaneously, there has been a fair bit of discussion about the economics of the Haskell ecosystem and the confounding factors that have led to its potential stagnation. Most recently, for instance, there have been discussions about “Simple Haskell” as a set of best practices to spur more successful industry projects.
At this point, the Haskell ecosystem sits on a knife-edge: it could easily fall apart and leave behind the remains of an advanced ecosystem with no practitioners left to maintain the bit-rotted pieces. Alternatively, it could thrive and evolve into a widely used and continuously researched technology that continues to refresh and reinvent itself in every new generation of programmers who join. I probably won’t be involved long enough myself to see what happens but I have a strong inclination to see it on the latter path.
However, the singular truth remains that unless Haskell sees more industrial use then there can never be any serious progress. Many people have written root-cause analyses on why this is the case, but most of them are very engineering-centric arguments about the technical minutiae of language extensions and advanced type systems. While there is some truth to the technical deficiencies, I would argue that these are not correlated with industrial success in any meaningful way.
The hard economic truth for engineers is that technical excellence is overwhelmingly irrelevant, and the history of our profession is full of cases that demonstrate this. Javascript as a language, for instance, largely came to dominate the browser ecosystem only due to the Netscape marketing department, who decided on a clever marketing ploy to circumvent Sun Microsystems and give their own new language cachet by hijacking existing name of Java. While we can’t attribute all of Javascript’s success to this naming, it is quite likely this trick was sufficient to convince enough non-technical stakeholders to make a significant difference in early adoption. These kinds of marketing tricks and positioning are likely the most fruitful path to reaching a large technical audience.
Years ago a friend gave me a wonderful book called “Christ Was an Ad Man” by Robert Pritikin (ISBN: 9780965906906). Offering a real-politik description of the world of advertising, the book is a funny read written from the perspective of a 1980s ad executive who gives an inside view behind consumer advertisements and persuasion, as well as the psychology of targeting. The thesis of the book is that the dichotomy between honest advertising and deceptive marketing is an illusion. Instead the world is divided into four quadrants of people across two axes. The first axis is people who are informed enough to make a decision versus those too uninformed to decide. The second axis is people who are looking to make a decision versus those who have already made a decision.
People who have already made a decision and are economically invested in that decision rarely change their minds about anything; this is readily apparent in high-investment “purchases” such as software. People who are uninformed and who haven’t made a decision will either choose randomly or require more information. However, conveying correct information to this group is time-consuming, so for marketers it doesn’t actually provide a good return on investment for their time. As a result, the only group that’s actually worth advertising to are people who are informed enough to make a decision but who haven’t made up their minds yet. Through hype and subterfuge, marketers should specifically target this group all while emphasizing four factors about their product:
If you look at comparative discussion about programming languages, you’ll realise that very little critical thinking is typically involved. Universities simply don’t give students the cognitive frameworks to perform comparative discussions of tools. Thus, instead of our discourse being about semantics, engineering quality, and implementation, we instead discuss our tools in terms of social factors and emotions (i.e. it “feels readable”, “feels usable”, “feels fast”).
Going back to marketing, we have to ask ourselves how exactly is Haskell perceived in the larger programming world? The official haskell.org site comes with this slogan:
An advanced, purely functional programming language
Unfortunately, this slogan is not optimal inside the above matrix because it’s addressing people who are already informed who have already decided. It isn’t memorable, it doesn’t include the key benefits of the tooling, and it doesn’t differentiate the language in any way. This isn’t great marketing.
Outside of the official site, one narrative overwhelmingly dominates all others: Haskell offers “correctness” and code written in Haskell is more correct than code written in other languages. Indeed, this viewpoint in and of itself would normally be a meaningful and succinct statement of value if it didn’t go completely against the grain of where software has been heading over the last 15 years.
This will be a bitter pill to swallow for many Haskellers but outside of very few domains, software correctness doesn’t matter. Software deals worth hundreds of millions of dollars are done based on little to no code and are sold as successes even if they’re failures. Around 66% of enterprise software projects fail or are vastly over budget1. Increasing labour costs means that the only thing that overwhelmingly matters is time-to-market. In other words, managing a software project isn’t about correctness or engineering anymore: it’s about running a risk portfolio of distressed assets. It’s true that if you’re managing a software project the choice of tools does matter, but this choice pales in comparison to the following simpler ways to mitigate risk:
The above factors overwhelmingly dominate decision-making for software projects and these feed back into the choice of tooling. If the talent pool is illiquid or geographically locked, that’s a non-starter. If there isn’t a large corporate vendor to go to to sign up for a support contract, then that’s a non-starter. If there isn’t a party to sue as an insurance policy against failure, then that’s a non-starter. These are existential problems for small, organic ecosystems that don’t have large corporate backing.
The bottom line is that rather than using more correct tools and engineering practices, it is simply far easier and more economical to hedge software risk with non-technical approaches. Moreover, if you throw enough bodies writing Java at a project for a long-enough period of time, it will produce a result or fail with a fairly predictable set of cashflows, which is itself a low quantifiable risk that’s very easy for a business to plan for. Thus, the economics of corporate software and a management culture that has fully embraced neo-Taylorism are in contradiction with the Haskell narrative that correctness through engineering excellence are the most important goals.
The “Simple Haskell” doctrine offers a new take on Haskell’s industrial stagnation, proscribing various fixes for the technical problems that prevent the language from seeing wide adoption. While I’ve read these arguments and there are some genuinely thoughtful critiques involved, I can’t help but feel it’s a bit backwards. What I see are manifestos from engineers writing about problems for other engineers, under the assumption that changing engineering practices will somehow change the situation that gave rise to these problems in the first place. Changing our engineering practices isn’t going to save us.
The fundamental question is: how will the community present the language in a way that gives it any industrial relevance in the 2020-2030 era? How will the next generation of engineers shape the Haskell narrative so that we don’t have to restrict ourselves from these advanced tools we have? We do have an advanced compiler and we have tools to build correct software, but these are not enough to foster adoption. We will also need some equally clever marketing beyond just “correctness”.
In Pritikin’s book there’s one advertising slogan that comes off as most applicable to Haskell:
There is a steak in every hot dog.
This statement is intrinsically deceptive but hints at a deeper truth. We could sell Simple Hot Dogs to the masses, but what is the “steak” for Haskell that will make you want to buy that brand over others? What is Haskell’s marketing slogan and key differentiation for the new decade?
https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf↩