Impressions of Haskell

I finally found an online tutorial for Haskell that involves writing a non-trivial program:

• Write Yourself a Scheme in 48 Hours

It’s an excellent tutorial and has given me a good impression of Haskell for building a medium-sized non-trivial program: a LISP interpreter.

This impression, however, has been more negative than positive. I would consider Haskell for use for doing programs that do heavy computation with pure functions alone.¹ However if there’s any significant amount of I/O, error handling, or state, using Haskell is just bloody painful.

Monads are painful

• I/O must be done inside an I/O monad.²

• Error handling must be done inside an error monad.³

• Passing around shared state must be done inside a state monad.⁴

The preceding by itself would not be such a problem except that, in addition:

• Code that is pure uses a different syntax than code that is in a monad.

• Code that needs to be in multiple monads at the same time is a royal pain to write. It requires the use of monad transformers and explicit converting (or “lifting”) between individual monads and combined monads.

Having monadic code be in a different syntax than pure code requires the programmer to learn and use two different syntaxes. And these syntaxes aren’t even similar: they read in different directions. Mixing code that is both pure and monadic becomes confusing. Upgrading pure code to be monadic, which is not uncommon during development and maintenance, requires a lot of non-trivial syntactic transformations.

• Pure code - Reads inside-out, generally bottom-to-top and right-to-left.
• Monadic code - Reads top-to-bottom (with do-notation) and left-to-right (with bind operations).
• Pure + monadic code - Reads in multiple directions.

Using a pure value within monadic code requires you to “lift” the pure value into a monad value with an explicit conversion. Similarly using a monadic value in multi-monadic code (created by a monad transformer) requires you to lift the monadic value into a multi-monad value first. These explicit conversions pepper and obscure the main program logic. One has to do an annoying amount of gymnastics to make the type system happy.

Code golf erodes readability

Another factor complicating the readability of code is the Haskell community’s propensity for code golf: the tendancy to write code that is especially terse to the point of making it difficult to understand. There are many language and library features in Haskell that enable this:

• Overuse of operator overloading and custom operators:
  • The ability to mix custom infix and prefix operators in the same expression. Confusing.
  • The ability to treat an infix operator as prefix or visa-versa, when using certain syntax. Inconsistent.
  • The usage of custom operators in ambiguous fashion requiring knowledge of either the operator associativity or precedence to disambiguate. Requires non-local knowledge to parse expressions.

    • For example the $ operator appears to be a precedence hack to avoid the need to parenthesize an expression properly. I don’t think it worth introducing tricky syntax to avoid typing a single close paren.

• Implicit partial application of functions. Infix operator sections.

  • You must know the arity of a function to determine what an expression containing that function means.⁵ Requires non-local knowledge to parse expressions.

• Point-free style.
  • Discourages the use of explaining variables.

Terseness at the expense of readability was a hallmark of Perl. I don’t find it any more attractive in Haskell.

Here’s a short example containing monadic code, point-free style, and an operator section.

-- Parses the expression in the first argument to the program, evaluates it, and prints the result.
main :: IO ()
main = getArgs >>= putStrLn . show . eval . readExpr . (!! 0)

I argue that the preceding code is manifestly confusing for any newcomer to Haskell, yet this type of code I see frequently in Haskell written by others.

It is possible to rewrite the code to be more explicit:

main = do args <- getArgs
          putStrLn (show (eval (readExpr (args !! 0))))

Although I think the preceding would not be considered idiomatic Haskell.

The end?

Haskell’s strong type system and heavy restrictions on mutable state provide good assurance that the programs you write are correct, assuming you manage to write the program in the first place.

However I find Haskell difficult to write (due to monads and the type system) and difficult to read (due to code golf). I also do not require such a high assurance of correctness in the domains I work in. I typically find that a disciplined minimization of mutable state in other languages is sufficent to provide the necessary level of correctness I require, and with more flexibility during maintenance.