Haskell Programming – Downsides and Problems

haskell

I'm looking at diving into Haskell for my next (relatively trivial) personal project. The reasons that I'm tackling Haskell are:

  1. Get my head into a purely functional language
  2. Speed. While I'm sure this can be argued, profiling that I've seen nails Haskell close to C++ (and seems to be quite a bit faster than Erlang).
  3. Speed. The Warp web server seems to be crazy fast in comparison to virtually everything else.

So, given this, what I'm looking for are the downsides or problems that come along with Haskell. The web has a tremendous amount of information about why Haskell is a Good Thing, but I haven't found many topics about its ugly side (apart from gripes about its syntax which I don't care about at all).

An example of what I'm looking for could be like Python's GIL. Something that didn't rear its head until I really started looking at using concurrency in a CPython environment.

Best Answer

A few downsides I can think of:

  • Due to the language's nature and its firm roots in the academic world, the community is very math-minded; if you're a pragmatic person, this can be overwhelming at times, and if you don't speak the jargon, you'll have a harder time than with many other languages.
  • While there is an incredible wealth of libraries, documentation is often terse.
  • Gentle entry-level tutorials are few and hard to find, so the initial learning curve is pretty steep.
  • A few language features are unnecessarily clumsy; a prominent example is how record syntax does not introduce a naming scope, so there is no way to have the same record field name in two different types within the same module namespace.
  • Haskell defaults to lazy evaluation, and while this is often a great thing, it can bite you in nasty ways sometimes. Using lazy evaluation naively in non-trivial situations can lead to unnecessary performance bottlenecks, and understanding what's going on under the hood isn't exactly straightforward.
  • Lazy evaluation (especially combined with purity and an aggressively optimizing compiler) also means you can't easily reason about execution order; in fact, you don't even know whether a certain piece of code actually gets evaluated in a given situation. Consequently, debugging Haskell code requires a different mindset, if only because stepping through your code is less useful and less meaningful.
  • Because of Haskell's purity, you can't use side effects to do things like I/O; you have to use a monad and 'abuse' lazy evaluation to achieve interactivity, and you have to drag the monadic context around anywhere you might want to do I/O. (This is actually a good feature in many ways, but it makes pragmatic coding impossible at times.)
Related Topic