Previous Posts

I've decided to relocate my blog. Blogthing has been unreliable, so I'll try here instead.

Haskell for Alphas and Betas

A few times now I've seen or heard an argument that goes like this:

Haskell is fine for people with the Hacker Nature, but there is no way that the average Code Monkey is ever going to grok recursion, let alone monads. Therefore Haskell is doomed for use in the Real World, and will forever remain a plaything of academics and over-enthusiastic start-up companies.

Lets call the people who can define new monads "Alphas" and the rest of the developers "Betas". First of all, its worth noting that most, if not all the people who make this assertion are in fact Alphas, and they might be surprised at how much some other people can understand. But I can accept that there are people out there who generate software, but for whom software is not a primary skill. For example a physicist who writes a numerical simulation of particle interaction in Fortran, or a financial trader who's understanding of how to price a swaption is embedded in Excel. And of course the favourite example: people who's primary job is the design of dynamic web applications and who know just enough to query a SQL database and convert the results into HTML. Some of these people are capable of groking the monad laws, but they are not interested in theoretical computer science. So how will they do in Haskell?

I think a clue comes from an experience report on Eiffel. The application was for financial derivatives back in the 90s. The developers used Eiffel to create a library of classes (which would now be called an embedded domain specific language) for derivative construction. It sounds not unlike the one proposed by Simon Peyton Jones in Haskell. Once the developers had generated a library of Eiffel classes, the people who understood derivatives could use the existing library to describe esoteric financial contracts and define the pricing algorithms associated with them.

This is the way that Haskell should go in the future. The Alphas can formalise the problem domain in a way that saves the Betas from having to understand any advanced stuff like GUIs, database access, and all the other stuff that makes our lives so interesting.

Excel is very much a case in point here. It has been called "the most popular functional programming language in the world", although of course it is not Turing Complete. But it shows that many people can get their heads around a system of linked equations, and even simple recursion where necessary.

But the real beauty of Haskell is that it doesn't have any built-in concept of flow of control. This may sound like an odd advantage, but it allows an embedded DSL to have a monad embodying its own domain-specific notion of control flow in which the cause-and-effect model follows the model of the domain experts rather than the rest of the language. Parsec (the recursive descent parser library for Haskell) is a good example: a parsing action can have side effects, but anything that happened in a failed parse is guaranteed to be invisible. Coming up with Parsec took some Alpha brains, but now any Beta can write a parser in Haskell without worrying about the interaction of side effects and backtracking.

Environments such as Vital may help to push this even further by providing an intuitive spreadsheet-like front end, but many of the Betas don't actually need it: they are happy with expressing their knowledge in source code; they just want a language that thinks the same way they do.

So I really don't think that Haskell has to be a closed world to the Betas. The Alphas will interpret the domain as a library of monad combinators, and the Betas can just use the library without worrying about details like the exact flow of control. Over time some of the Betas will come to understand and be promoted to Alphas, and the rest will continue to code unabated.