Haskell Sorcery

Software engineers are irrepressibly creative. For generations, they have devised programming languages to boldly explore new ways of expressing ideas.

But does it matter? Do the new languages help us? While I grew to appreciate certain innovations, I found I profited most from ignoring trends and following well-worn paths established by Lisp programmers decades ago. Weary and wary, I tend to dismiss the latest programming paradigm as a passing fad.

I was therefore pleasantly surprised to find an exception: Haskell.

Mind Your Language

What do I look for in a programming language? First of all:

  1. Programs should be easy to express.

Writing code should be comparable to writing prose. A plain text editor with 80-character columns should suffice. Coding should feel like writing an email or a novel. If instead it feels like filling out a tax return, then the language is poorly designed.

I have encountered languages that flaunt this law, none of which I will utter here. I have seen languages that practically force the programmer to run a heavyweight specialized IDE, and that require 14 words to print 2 words.

Haskell adheres to the zeroth law. Programs are so easy to express that interactive Haskell interpreters are practical. For example, to print "Hello, World!" in a Haskell session (online even!), just type:

> putStrLn "Hello, World!"

To turn this into a complete program that can be compiled:

main = putStrLn "Hello, World!"

Though really, a short "Hello, World!" program is unimpressive; it’s merely a basic requirement of a well-designed language.

Let us now dispel a common misconception, one which I once believed:

In other words, I used to think functional programming languages were only of theoretical interest because they frowned upon side effects. Rob Pike notes that they have a “problem with I/O”. Even Simon Peyton Jones himself jokingly derides earlier incarnations of the language as “useless”.

But times have changed. Modern Haskell handles side effects beautifully. Our “Hello, World!” program above proves this, and we shall see many other examples.

Moreover, it has become clear that:

  1. Side effects are important and therefore should be easy to express.

  2. Pure functions are important and therefore should be easy to express.

  3. Indicating when a function is pure is important and therefore should be easy to express.

Most programming languages respect the first two laws; the third is the tricky one. Haskell is the first widespread language to follow all three laws.

In other words, Haskell’s greatest contribution is not that it does away with side effects (such a language is indeed useless), but rather that it constitutionally separates pure and impure functions without encumbering the syntax of either.

are we not pure? no sir! p…

Haskell gently forces us to distinguish between pure and impure code through its unobtrusive yet uncompromising type system. For example:

-- pal.hs
main = do
  putStrLn "Enter just over half of a palindrome:"
  s <- getLine
  putStrLn (s ++ tail (reverse s))

Without knowing Haskell, we might guess it behaves as follows when run:

$ ghc pal.hs
$ ./pal
Enter just over half of a palindrome:
murderforaj
murderforajarofredrum
$ ./pal
Enter just over half of a palindrome:
gohangasalami.
gohangasalami.imalasagnahog

The code resembles what one might write in a dynamically typed scripting language. Like such languages, Haskell has a refreshing lack of boilerplate.

However, looks are deceiving: Haskell is in fact statically typed. As we might expect, the compiler knows that s is a string so it can prevent us from, say, accidentally using s as a number.

More incredibly, the compiler also knows exactly which functions are impure (putStrLn, getLine) and which are pure ((++), tail, reverse), so it can prevent us from, say, accidentally mutating global state in a pure list-reversing function. The compiler simply refuses to build a program which incorrectly mixes pure and impure functions.

We’ve barely scratched the surface. When we tackle less trivial tasks we shall see Haskell possesses many other charms.


Ben Lynn blynn@cs.stanford.edu