donald stewart on haskell in the large

Last October Don Stewart gave a very interesting talk at CodeNode on his experience using Haskell at a large scale. And by large, he means millions of lines of code. Although he wasn't allowed to talk about the very specifics of the code, his talk is full of interesting remarks that i found resonate with my experience. They actually convinced me that the next language i should try in production should be OCaml.

The first thing that drew my attention in this talk was the sheer amount of code they've written: 3.4 millions of lines of code. Taking into account Haskell's conciseness, that's quite a lot. I've got experience with very substantial projects written in functional languages such as Clojure with two orders of magnitude less code! Althouth it's true that running on top of the JVM lets you reuse hundreds of libraries, and that might be closing the gap a bit.

A second interesting point was the fact that Don's team is using interpreted code (via their own Haskell compiler): virtual machines have many advantages, yes.

And i wasn't surprised at all to learn that their code is strict by default: my experience with the limited laziness of Clojure has been bad enough to reinforce my exasperation with space leaks in my hobbyist Haskell. Laziness is pretty cool, but also the source of the most difficult to track down bugs i've encountered in the latest years. More difficult in fact than any memory leak i can remember in those dreadful C++ years: there at least i had a very clear, fool-proof methodology to avoid those problems (unlike the case of mutable state: the peace of mind bought by immutability is priceless).

I also found myself nodding enthusiastically at Don's plea for sticking to basic, simple constructs and to avoid as much as possible the line noise of excessive infix operators. One can write Perl in any language. And, for an old lisper, his advocacy of a programming style based on writing interpreters for little languages, sounded right on the money.

The thing he mentions over and over that i haven't experienced first-hand in a real-life, sizeable project is the power of a real type system (no, Java's or C++'s aren't), and that's something i'd really like to try.

Then at some point he mentions they have their own module system, not as good as ML's, but… and i realised that there's a language out there that has all the good things the talk mentions and needs none of the workarounds they use. It's called OCaml, and i've been meaning to use it in earnest for some years now. Maybe it's finally time i dust that part of my bookshelf, if only to compare real-world development in a properly typed language with my experience with dynamic languages such as Clojure (which has not been by any means as bad as static typists seem to fear).

At any rate, there's lots more in this talk that is surely more interesting than my ramblings: recommended!