Why not Haskell?

October 17, 2011

At one point, I think I qualified as a Haskell ninja — I understood and used monad transformers, I had a bunch of modules up on the module sharing system including C bindings, I was even credited for providing feedback on a Haskell paper.

But I haven't done any of that in months, maybe a year. And much like my post-mortem about why I stopped looking at O'Caml in 2005 (which I think in part is what drove me to Haskell), I figure Haskell deserves one too.

First, the good: Haskell is truly beautiful. I cannot think of another thing I've played with that has been so mentally rewarding over such an extended period of time. It's permanently changed the way I think about programming, from computation all the way through aesthetics.

That sort of statement may also be true about e.g. Lisp but I found that there wasn't a whole lot to get about Lisp (that's kind of the point of Lisp, after all), whereas each extra month with Haskell gave me an extra month of new perspective on what it means to compute from type classes to laziness to combinators to, yes, monads. (Man, I feel like someone trying to explain what an acid trip is like.)

But despite all that experience, I conclude that writing Haskell code is hard. I don't mean that in the "math is hard, let's give up", sense, but that getting from an empty page to a program that does the job is a harder process than it is with e.g. Perl. A resulting correct Haskell program is likely more reliable, maintainable, and perhaps faster, but getting to that point (framing your problem the right way, knowing how to profile or deal with space leaks, understanding when unsafePerformIO is actually the right thing) is just too much effort.

Here's a diagram summarizing the problem:

If you've written a Haskell program that runs, it's highly likely to be a correct solution; but the set of runnable Haskell programs is much smaller than the space of programs that get the job done, and frequently I'm more interested in being done.

I find myself digging up Haskell sometimes for when I want sketch something out mathematically: writing a program to answer a question like "how many different ways can I seat n people at m tables given these extra constraints?" is a delight in Haskell. But for the sorts of code I write, those parts are the small ones; the bigger ones are parsing file formats when the input language is not well specified or interacting with some grungy library.

(That point is the only point I wanted to make, but since there's nowhere else to shove it in, I'll add: I also recently dug up some old Haskell code I'd written in the past and found I was unable to compile it due to the "DLL hell" that is package versioning of Hackage. It made me grumpy.)

So, Haskell, I conclude: it was definitely worth my time, even if it had only been so I can understand PL research papers. I can wholeheartedly endorse you learning it as well. But I'm sad to say I don't imagine myself basing a new major project (or company) around it.

Strangely lately I've been writing a lot of code in Go, which seems to have attracted a lot of other people I know. I think of the Go language as sort of the anti-Haskell: visually ugly, semantically warty, written with apparently little regard for the state of the art in research — but on the other hand, incredibly pragmatic throughout. A shining example of worse is better.