Caging the Effects Monster

Simon Peyton Jones gave an outstanding keynote on functional programming at ACCU 2008. A language researcher at Microsoft in Cambridge, he’s perhaps best known as the man behind the Haskell programming language and GHC, the leading Haskell compiler. He also happens to be a superb presenter who positively exudes enthusiasm. Not many compiler writers connect so well with an audience.

I’m a huge fan of a functional programming style, by which I mean I like first class functions, higher order functions, anonymous functions, list comprehensions, closures and so on. In the languages I use most often, C++, Python and Shell, functional programming is a central paradigm — every bit as useful and important as object-oriented and procedural programming.

For Haskell and other pure functional languages it’s not just about style. Simon Peyton Jones’ central argument was that programming will increasingly be about the control of side-effects: to write correct programs, side-effects must be contained. A pure function has no side-effects. Thus you can be sure what it does. You can even prove it correct. A pure program built entirely from pure functions is equally correct but, sadly, of limited use. Haskell’s type system distinguishes pure functions from impure ones — the ones which change the world. If you minimise and contain impurity, you’re winning!

It’s certainly a compelling argument. In the languages I use from day to day, as already mentioned, I favour a functional style. I also adopt value-based programming (sometimes known as single assignment programming — once you’ve set something, you don’t change it) as far as possible: it’s easier to figure out what a program does, and you can avoid a whole class of defects. Simon Peyton Jones describes my approach as “Plan A”, the mainstream route towards writing programs which are both useful and safe. He promotes “Plan B”, a more radical approach, where “useless” languages like Haskell find ways to change the world.

Strong Static Typing

Static type checking is central to Haskell and the language comes with a rich type system allowing static analysis and compile-time checking. It’s the type system which determines, rigorously, which parts of a program have side-effects. Unlike C++, the type system doesn’t seem to get in the way. A lot more is inferred. In fact, some type declarations are unnecessary since the compiler could deduce them from the code — but in Haskell type declarations, at least for module exports, are seen as a good thing.

I found this interesting. Although I like dynamic languages I also like strong typing (yes, you can have both). In theory, static strong typing would be best of all; you eliminate the bug before you run the code. My experience with languages like C++ and Java have caused me to kick against this theory. The C++ type system just seems to get in your way: by the time you’ve wrestled the compiler into submission and got a program you can actually run you’ve worked so hard you feel like it must be good, when actually you’d have been better off running, testing, revising the code in an iterative manner. You’d certainly have had more fun! Haskell, though, may cause me to revise my opinion once again. It may indeed offer the benefits of strong static typing without the baggage.

A Taste of Haskell

In the afternoon I attended Simon Peyton Jones’ “Taste of Haskell” tutorial, which went into Haskell in more depth. The room was packed and people had to be turned away. Although I have written and read some Haskell I know very little about it, and three hours training with the world expert on the subject haven’t really altered that. Nonetheless, I’d like to record my first impressions here. They may all turn out to be wrong!