James Dabbs

Why Haskell

07 Mar 2015

I’m an unabashed fan of Haskell. When I mention that (as I am wont to do), people tend to dismiss it: “oh he’s one of those academic types, he would like Haskell.” And I’ll admit – I wrote my master’s on monads, and stumbled in to Haskell when someone told me that you could actually use monads to do things (pun very much intended). Yes, that’s how I got to Haskell – but I’ve stayed because I believe it’s a great step in solving several of the software industry’s hard problems.

For Building

If I were launching a startup today, I’d absolutely be willing to bet it on Haskell1. Here’s why:

Leveraging the Type System

Far and away, the most exciting thing about Haskell is its advanced type system and runtime:

Hiring and Onboarding

Admittedly, with Haskell’s comparatively small userbase, it’ll be hard to find the right hire with the right experience. If you’re running a Haskell startup, you’re going to have to invest in training your new hires in the language. But:

For Learning

I’m very interested in the idea of Haskell as a first language. I’m 100% sold on it as a second. Learning Haskell was the best thing I ever did for my Ruby skills. But there are upsides even for first time students:

Constraints, Creativity, and Experimentation

Writing Haskell is a tightly-constrained activity. I take that as a positive. Certainly, it stops you from making many kinds of mistakes. But as someone who’s taught a lot of Ruby, the “you can do anything you want” wide-open solution space can be completely overwhelming to a beginner. It’s nice to have a language with a strong opinion of what’s right. In general, constraints breed creativity.

Moreover, the compiler having your back is a huge boon to learning. You are free to experiment, confident that if it compiles, it’s probably correct. No hidden bugs popping up later or far away – if your code has a problem, you’ll get an explicit (if initially opaque) message telling you where and why. Refactoring in Haskell is as fun to me now as playing with Legos was twenty years ago, with much the same feel. It takes surprisingly little mental energy – you can often switch your brain off and let the compiler do all the hard work.

Foundational Concepts

I’ll be the first to admit that Haskell has a reputation of being hard to learn. Some people wear this as a badge of honor – “oh, you want to print something? Ok, first let me tell you about the monad laws …”. While I understand that reflex, I think it’s harmful to the Haskell community. You can absolutely be productive in Haskell without really grokking monads. For many years, the language didn’t even have monads! But people realized they were repeating several common patterns, and eventually – as good engineers do – found the right tool to abstract the solution.

Category theory is a well-studied discipline that provides a very rich vocabulary for talking about functions and how they compose. Vocabulary has an interesting relationship with thought, and while it’s not at all necessary to learn category theory before Haskell, I do like that it exposes you to foundational concepts that will shape the way you think about all of the code you write. Once you recognize a monoid or a monad, once you’ve internalized ideas about functional purity, it changes the code you write in other languages. Writing modular programs well is very much about understanding composability – why remain willfully ignorant of the vast body of work done studying how functions compose?

Why Not Haskell?

Haskell is exciting and promising, but it’d be unfair to pretend that it’s perfect. The runtime is incredibly sophisticated, but that makes it hard to reason about at times. There are certainly situations where I’d reach for C or Rust instead for low-level, performance critical code. But I think the more significant problems for Haskell to address are around the ecosystem and tooling. Cabal hell is certainly a problem and tooling is spotty, but improving (though Hoogle is amazing).

As I see it, the biggest problem is that you can’t “just jump in” to Haskell. I’m coming from the Ruby world where a potential learner can have a blog running in 15 minutes. This makes it much easier to experiment with the platform, and invariably some of the folks that try it out end up liking it and using it. Again, Yesod seems to be making some great strides in that direction.

Similarly, while Haskell is great for building a product that’s going to be around for a long time, startups often need to prove an idea quickly before committing to that kind of investment of time and money. In the Rails world, you can pull in a functional auth layer, background worker system, or payment module with a dozen lines of code. Working in Haskell, it too often feels like you’re forced to re-invent the wheel and spend time working on things that aren’t your core business concern.

What Next?

Most of those problems are a matter of adoption, and would be resolved if more people built with or learned about Haskell. That’s largely why I’m writing this. But as the problem is one of community engagement, I’m very interested to hear what you think:

If you run a business, would you consider building on Haskell? If not, what’s stopping you? How do you feel about bringing on new devs that need language training? Would you hire a junior dev that only knows Haskell?

If you don’t know Haskell, would you consider learning it? If you have considered learning it, what stopped you? Lack of support materials? Of time? Of interest? Of employers?

If you have learned Haskell, what do you wish you knew earlier? What do you feel is lacking or painful? What would you think of presenting it as a first language? Is it hard because it’s so different from other languages? Is it that people insist on presenting the hard parts? Or is it honestly just intrinsically hard?

If you have answers or questions or are just interested in this discussion, please tweet, retweet, or email me.

And try Haskell.

1) Of course, no tool is right for every job. Evaluate it yourself, considering the specific and unique needs of your business.