ML for the Working Programmer

31 Dec 2014

In 1996, I arrived in Cambridge and, like countless other fresh university students, went about acquiring the prescribed stack of wincingly expensive textbooks. One - the key one for the Computer Science part of the course - bore the title ML for the Working Programmer.

At the time, I thought nothing of this, but as my classmates and I learnt ML - the primary teaching language for undergraduates at the Computer Lab - we began to regard it as ironic overstatement, or perhaps protesting too much. Surely no working programmer would use this fussy, academic language? Unlike real languages such as C (or even BASIC), there was no way to access memory directly. You couldn’t circumvent the type system to get things done. You couldn’t even do something as simple as a for or while loop; you had to tie yourself in knots with “tail recursion”, and hope that the compiler makes it efficient1.

By the time I’d graduated, I’d come to appreciate the elegance, expressiveness and power of ML, but still regarded it as a language for academics; something to influence other, more practical, languages perhaps, but not something I expected to see being used in the “real” world. But then, strange things started to happen.

The first hint that something was changing came from, of all places, Microsoft. In 2005, they adopted F# as an official language for their .NET platform. This new language2 was essentially a dialect of ML3.

A little while later, over on the open source side of the fence, there was an increase in interest in ML’s lazy compatriot Haskell at Red Hat and others. Interestingly, this wasn’t for solving hard problems with complex algorithms, where you might expect a more expressive language to be useful. Instead, it was for things like scripting and build automation, the most pragmatic of practical tasks. Academic languages were definitely getting their hands dirty.

In the past few years, things have picked up even more. The first time I looked at Rust, the closest thing to a viable C++ replacement I’ve yet to see, it was pleasantly familiar. More recently, Apple’s Swift has a distinctly ML-like flavour.

It’s not just shiny new languages, either. C++ 11 added ML-like features such as lambdas and type inference to its already stuffed arsenal4. Even JavaScript, while not changing in terms of the language spec, is becoming noticeably more ML-like5 in actual use, as people stop trying to make it look like Java and adopt a more functional style.

All of this is, in my opinion, very good news. Programming isn’t easy, and you need some kind of intellectual framework to navigate the near-infinite space of possibilities. The core ideas behind ML and friends have been polished in the river of academia for decades, and have become smooth and beautiful as a result. ML has a lot for the working programmer.

  1. Spoiler: it does. [back]

  2. Perhaps not coincidentally F# was developed at Microsoft Research Cambridge, at the time next door to the Computer Lab. [back]

  3. Not the Standard ML I’d learnt as an undergraduate, but its close relative OCaml. Perhaps it’s just early exposure, but I’ve never been keen on the latter’s syntactic quirks. Semicolons as list separators? Sacré bleu! [back]

  4. In fact, C++ has had at least one feature taken directly from ML almost since its inception. Don’t like exceptions? Blame ML. [back]

  5. Arguably LISP-like, but I’d say that that would imply macros. Perhaps Scheme-like, but Scheme and ML are very similar in many respects. [back]

This site is maintained by me, Rob Hague. The opinions here are my own, and not those of my employer or anyone else. You can mail me at, and I'm robhague on Twitter. The site has a full-text RSS feed if you're so inclined.

Body text is set in Georgia or the nearest equivalent. Headings and other non-body text is set in Cooper Hewitt Light. The latter is © 2014 Cooper Hewitt Smithsonian Design Museum, and used under the SIL Open Font License.

All content © Rob Hague 2002-2015, except where otherwise noted.