Some reflections on Haskell

Now that I've written a few thousand lines of Haskell (mostly an astronomy application using the Snap web framework), I think that I can put up a few reflections on the language.

1. I'm more productive coding in Haskell than in any other language I know.

Until now, my most productive language was Python. I now find that I can code the same level of functionality in Haskell in the same time or less than Python, but the code is easier for me to understand a few days or weeks later.

2. The lack of a professional level IDE is a major barrier.

The full Haskell ecosystem including the thousands of Hackage libraries is huge. Haskell needs a sophisticated IDE to help navigate this ecosystem, incorporating wonderful tools like Hoogle and taking advantage of the many error checking possibilities available in a statically typed language.

I'm used to using sophisticated tools like Eclipse and Visual Studio. There is an EclipseFP plugin for Haskell but it is painfully slow even on my 8Gb quadcore 64 bit development machine. I suspect that it just can't keep up with larger Haskell programs. After much effort I succeeded in getting Leksah to compile under Ubuntu but it seems limited. A Visual Studio extension written a few years back has bitrotted and is not compatible with the latest versions of the GHC compiler.

3. Error messages could be improved.

A typical Haskell error message is a long and often incomprehensible type message. After some experience you can start to get useful information from these messages but it seems odd that such a high level language has such a rudimentary error reporting system.

As just one example, I sometimes make the mistake of returning different types from the if and then portions of an if expression.

A simple message like "If expressions must return the same type in if and then sections." would be very useful. However, instead Haskell seems to assume that the correct type belongs to the if section and returns a long type error for the value of the else section. If the error was actually in the if section type, this can cause you to spend too much time looking at the wrong code.

4. String conversions are painful

The Snap framework mostly uses ByteString. Much other library code uses Text and many Haskell functions expect [Char] values. With a few rare exceptions, Haskell does not do implicit conversions and so I spent a large amount of time tediously adding explicit conversion functions between the three types. I would say that about half the compiler errors I get are related to a missing string conversion function.

Haskell is a beautiful language. It is a shame that my code needs to be littered with these conversion functions. Perhaps Haskell should have a use-at-your-own-risk feature to turn on implicit string conversion? There is such a feature for string literals already.

Despite these warts, I think that it is clear that Haskell is a great language for coding large projects. I expect that the three issues I've mentioned will be addressed at some point soon and then Haskell should be destined for widespread use.
Shared publiclyView activity