I see it as, when the limestone of imperative programming is worn away, the granite of functional programming will be observed.
Simon Peyton Jones
(I’m still not quite sure why I wrote this. You should just go and buy the book. But maybe someone will be interested.)
I got my copy of Peter Seibel’s new book Coders At Work yesterday, and the first chapter I turned to was, naturally, the interview with Simon Peyton Jones. I found it to be excellent and informative; of course, as anyone who’s seen him in action can testify, SPJ’s a careful and entertaining communicator of ideas, so that’s no surprise — if the other chapters are as good as this one, well, it’s a winner of a book.
Here’s a summary of the interview. Hopefully it contains enough to tantalise/encourage purchase, but not enough to give away the farm. :-) (And remember, this is just one chapter of the book.)
Seibel starts as he seems to start every chapter (modulo small variations), by asking “When did you learn to program?”. SPJ tells us about his school days, and his time as an undergraduate at Cambridge, through into industry and back to academia at UCL, and then on to a Professorship at Glasgow. Along the way we hear about some of the machines he programmed, and impressive things he did on them — such as “a program to extract 24-digit square roots” on his school’s computer with 100 8-digit memory locations, entered directly in machine code, because that’s all it had. Hearing about heroic stuff like this always makes me feel a bit bad, for having merely human levels of curiousity and drive as a schoolchild, and for a while I was worried the interview would be dominated by this historical stuff, since it went on for a few pages. Then I realised quite how long the chapter is (35 pages), and felt better. :-)
One thing I didn’t know was that SPJ doesn’t have a PhD. (Another thing I didn’t know was that neither does Robin Milner, apparently. Wow.) He discusses how that happened, and why one does a PhD, what its value is, etc., and also some personal philosophy of his approach to research. As someone who enrolled on a PhD just last week, I found this bit quite inspirational:
He [John Washbrook] said, “Just start something, no matter how humble.” This is not really about programming, this is about research. But no matter how humble and unoriginal and unimportant it may seem, start something and wroite a paper about it. So that’s what I did. It turned out to be a very significant piece of advice.
I’ve told that to every research student I’ve ever had since. Because it’s how you get started. Once you start the mill turning then computer science is very fractal — almost everything turns out to be interesting, because the subject grows ahead of you. It’s not like a fixed thing that’s there that you’ve got to discover. It just expands.
This leads into a few pages about functional programming in general, its popularity in the research community, its practicality, and the ways this research is feeding ideas back into the mainstream. There’s a bit of discussion of the vexed question of how to do experiments on programmer productivity/experience: how do you verify, other than anecdotally, that such-and-such a language (or feature) actually benefits the programmer or program? He mentions some interesting sounding work at Microsoft (“Steve Clarke and his colleagues at Redmond”) on this, at the API level. Then it’s back to how SPJ got into FP; he says he was influenced by being taught by Arthur Norman at Cambridge, where seeing a doubly-linked list implemented without side-effects was an ‘aha’ moment, and that David Turner‘s work on S-K combinators was also really inspiring and exciting to him — and says a bit about what that means for FP implementation.
Then laziness comes up: it was another interesting thing which motivated him, and has turned out to be a big idea, not least because it kept the focus on purity, which is the Big Win, he now realises. He talks about the old embarassing I/O situation, and the stream-based approach to ‘solving’ this, and just mentions monads here before being steered elsewhere by Seibel, never to return… :-)
He discusses his work on compiler writing (and GHC in particular of course), and the pros and cons of type-checking and static checks, including the problems of generic programming in a statically-typed world. This leads to a discussion of how he thinks about and designs software (unsurprisingly, its driven by types), and his “terribly primitive” programming environment (about the same as mine, except I’m one of the people he mentions that “just live their whole lives in ghci”), and his approaches to debugging. (Here he mentions some work Pepe Iborra did on debugging for Haskell — could he mean this? Pepe’s blog mentions that in 2006, but SPJ says he did the work “earlier this year”. So has Pepe done something more recent, or did the interview take place in 2006/7? I suspect the latter?)
On the subject of writing correct software, Seibel asks what he thinks about formal proofs, and his replies are as sensible as you’d expect — skeptical about ‘big up front’ specification/proof for (now) well-rehearsed reasons, but hopeful about “partial specifications” of program properties, e.g. in the style of QuickCheck.
Then we get six pages about STM. :-) Seibel starts by passing on a question from Guy Steele: “Is STM going to save the world?”. The typically sensible answer is of course not: No Silver Bullet, there are various ways to skin the concurrency cat, but that compared to locks & variables STM is a clear win every time. He talks about problems of starvation, and why that’s particularly problematic with optimistic approaches to concurrency, and comes back to the partial specification idea, discussing how STM lets you think more compositionally in terms of pre- and post-conditions than some other approaches. The STM discussion ends with him telling how he came to it via a talk by Tim Harris about STM in Java, and the realisation that STM could be made to fly so much more easily in Haskell than Java — leaving implementor brainspace free to invent mechanisms such as orElse which the Java guys hadn’t spotted (and example of FP research feeding back into the mainstream). “There was less crap, basically, so the cool idea stood out in high relief.”
Seibel then asks, “What’s your desert-island list of books for programmers?” I don’t want to give it away here (buy the book! It’s great!), but I’m sad to say I only own one of the books mentioned.
For the last six pages of the interview, discussion turns to SPJ’s everyday programming practice (he still loves it), programming as craft vs engineering (a false dichotomy, to SPJ), programming in the large, what it means for code to be beautiful, and code longevity. SPJ discusses how working in research allows you to put more time and energy into keeping things beautiful, and the tensions in industry that lead to ‘big systems full of goop’, and broad (rather than beautiful) APIs. It’s all insightful stuff, and his preferences, likes and dislikes echo my own so strongly that I’m glad I’m still working in research too, at least for now.
Overall, as I said, I really enjoyed it. I learnt a lot about the man, and a few things about programming I didn’t know (I haven’t really looked at STM yet, in particular). Cool.
Oh, and for a nice perspective on the relative longevities of limestone and granite alluded to in the quote I opened this with, check out this 1986 documentary taking a 30-minute tour round the entire British coastline: Round Britain Whizz. :-)
(Also, if you haven’t seen it yet, this is good, too.