Why Haskell Isn't Ready for the Enterprise

After a lot of analysis, we decided not to bring Haskell into our toolbox where I work. There's a number of reasons for this, but my big ones are below. I also tried to leave out some of the areas where it's widely known there are issues and people are already working to address them (package dependency hell).

I'm basically leaving this here because I love Haskell - and if you're reading this I hope you do too - and would love nothing more than for these to be wrong in the near future.

No XSD Support

I'd like to believe I'm just ignorant, but after tons of searching, I can't find a Haskell library that let's me validate an XML file against a single or set of XSD files. Are you kidding me? Is this 1997?

As much as I'd love to do JSON everywhere, there's just no way right now you are doing enterprise integration and never touching XML without having to validate it against a schema.

No entry-level killer app

Haskell is missing is a showpiece which demonstrates the incredible power of the language and how quickly it can make you productive at a given task.

Remember the first time you saw a Rails example:

1. "There's no way that little code implements a whole HTTP request/response"
2. "Wait wut? A little extra code now saves the data to a db?"
3. ....mind boggles at productivity gains....

You were on board right away, and you didn't even know Ruby yet!

It's not that Haskell doesn't have it's share of killer apps or libraries - but that it's missing the combination of the perfect app, the best example - and yes, even a little evangelism by the community - that creates that magic moment that sells you. That makes you want to learn more about the language.

My first real program in Haskell was a production project for parsing EDI (electronic data interchange) format files. Between the Conduit library and Haskell's raw speed and existing parser libraries it was not only a cinch - it was correct and fast as hell. But the only reason I even used Haskell was because I had already decided hell or high water I was going to learn it, and that it was the only language fast enough (I could have used C, but I don't hate myself enough).

What we need to do is invert that experience. We need to sell Haskell based on the wins it gives you, without having to learn the language to appreciate them. Remember, the programmer isn't the only one we have to sell on using Haskell.

The learning materials suck.

I love Haskell. After a long time I think I finally (kinda) get the more advanced concepts like Monads and Applicatives. I might even have some idea why you might use them in certain situations.

The issue here is that the more advanced concepts are frequently what makes Haskell so powerful. They are what helps enforce the lack of side effects, and removes even the possiblity of certain kinds of logical error.

But the tutorials do a really crappy job of exposing these concepts, and are loaded down with enough technical mumbo-jumbo that detracts from the learning experience rather than explaining what is to be gained.

I don't give a damn what the technical definition of a monad is. I only care:

1. When should I use it?
2. What do I win for doing so?

The same can easily be said for most advanced Haskell concepts, which happen to be the same ones that make the language so powerful.

No amount of community evangelism is going to get us out of the fact that a manager doesn't want to use a language that is hard to learn without easily demonstrable gains. The beginner learning experience is the first place to dispel this perception - and the current learning materials fail miserably.

Summary

So that's my complaints about the current state of Haskell. If I'm wrong in certain areas or just not aware of awesome resources that exist, I'd love to be corrected.