Seibel: Do you still program a lot?

Peyton Jones: Oh yes. I write some code every day. It’s not actually everyday, but that’s my mantra. I think there’s this horrible danger that peoplewho are any good at anything get promoted or become more importantuntil they don’t get to do the thing they’re any good at anymore. So one ofthe things I like about working here and working in research generally isthat I can still work on the compiler that I’ve been working on since 1990.

It’s a big piece of code and there are large chunks of it that I’m really theperson who knows most about it.

How much code do I write? Some days I spend the whole day programming,actually staring at code. Other days, none. So maybe, on average, a couplehours a day, certainly. Programming is such fun. Why would you ever wantnot to do it? Furthermore it keeps you honest—it’s a good reality check touse your own compiler and to use the language that you advocate as well.

Seibel: And you still enjoy programming just as much as when you started?

Peyton Jones: Oh, yes, yes. That’s the most fun thing. I think mostprogrammers have the feeling that “there must be a good way to do this.”One of the nice things about working in research is that instead of somemanager standing over me saying, “This has to be done this week—just getit done,” I can sit and look at something and say, “There must be a right wayto do this.”

So I spend a lot of time refactoring and moving interfaces around andwriting new types or even just rewriting a whole blob to try to make itright. GHC is pretty large—it’s not large by industrial standards; it’s large byfunctional programming standards—it’s about 80,000 lines of Haskell, maybea bit more. And it’s long-lived—it’s 15 years old now. The fact that it’s stillactively developed is indicative that chunks have got rewritten. There are nountouchable bits. So it’s both challenging and good fun to look at somethingand think, “What is the right way to do this?” And often I’ll hold off forweeks on something but I just can’t think of a nice way to do it. But that’stantalizing. Because there has to be a nice way.

Seibel: In those weeks, what happens?

Peyton Jones: Oh, I’m thinking about it in the back of my mind. Andsometimes I’ll have a go at it—I sort of run up the hill. And then Iremember why it was so complicated and then usually some otherdisplacement activity takes place. So sometimes I run up this hill severaltimes. Sometimes I’m thinking about it in the background. And sometimes Ithink, “Well, time’s up—just got to do something now.” And maybe it’s notquite as beautiful as it could be.

Seibel: Is it the kind of thing that you wake up in the morning and you say,“Ah, I’ve got it!” Or is it that you decide to take another run at it and thistime you get to the top of the hill?

Peyton Jones: It’s more like that. It’s seldom that I just having a blindinginsight in the morning. Another thing that happens as a researcher is youhave the opportunity to reflect on what you’ve done and write it up. Soquite often if something interesting has happened I try to write a paperabout it. So an example of that is there’s a paper called “The Secrets of theGHC Inliner,” which is really a very implementation-oriented paper thatdescribes some implementation techniques that we developed for aparticular part of GHC’s innards which we thought might be reusable forothers. The chance that you have as an academic is to abstract from thecode that, the fourth time around, you’ve finally kicked into a shape thatfeels good, and write about it so other people can reuse that sametechnique.

Seibel: What is programming to you? Do you think of yourself as a scientistor an engineer or a craftsman? Or something else entirely?

Peyton Jones: Have you read Fred Brooks’s paper about this, the onecalled, “The Computer Scientist as Toolsmith”? I reread it recently. It’s verynice. I think it’s good to remember that we’re concerned with buildingthings. I think that’s why programming is so interesting.

At the same time I’m really keen on trying to extract principles of enduringvalue. I have a paper about how to write a good paper or give a goodresearch talk and one of the high-order bits is, don’t describe an artifact. Anartifact is an implementation of an idea. What is the idea, the reusable brainthingthat you’re trying to transfer into the minds of your listeners? There’ssomething that’s useful to them. It’s the business of academics, I think, toabstract reusable ideas from concrete artifacts. Now that’s still not sciencein the sense of discovering laws. But it is a kind of abstraction into reusablethought-stuff out of the morass of real life that I think is very important.

Seibel: So what about engineering vs. craft. Should we expect to be like theguys who build bridges where, for the most part, bridges don’t fall down?Or are we really more like the guys making pottery—except the pottery isjust incredibly complex—where all you can do is apprentice yourself tosomeone and learn from them how they do it?

Peyton Jones: It’s a bit of a false dichotomy. It’s not truly an either-orchoice. One thing that is hard, even for professional software engineers anddevelopers, is to viscerally grok the size of the artifacts on which we work.You’re looking at the Empire State Building through a 1-foot-squareporthole, so it’s difficult to have a real feel for how gigantic the structureyou’re looking at is. And how it’s interconnected.

How big is GHC? I don’t have a feel for that in the same sense I have a feelfor how big this building is. So I don’t think we’re anywhere near where theengineers are with building bridges. Their design patterns have now beenboiled down to where they can pretty much be sure that the bridge isn’tgoing to fall down. We’re nowhere near that with software. But I don’tthink that that’s a reason for saying we just shouldn’t worry about it at all.

In fact I think it’s somewhere where functional programming has a lot tooffer. Because I think fundamentally it enables you to build more robuststructures. Structures that are easier to comprehend and test and reasonabout. And here is something that I think functional programmers arelagging on: we talk about reasoning about functional programs but we don’tdo it very much. I’d like to see much more by way of tools that understandHaskell programs and formally reason about them and give you guaranteesbeyond their types. We stand on a higher platform and we should be able togo further.

So that’s about saying the material should become more robust. The morerobust your materials, the less you need to concentrate on the minutiainstead of the larger-scale structures. Of course that will just make us moreambitious to build larger structures until we get to the point where they fallapart again.

I think that’s sort of an invariant. As soon as you can do it, you stretch tothe point where you can’t do it anymore. I suppose I don’t really see it as, isit this or is it that? There will always be a strong crafty element, I think, justbecause we’ll stretch our ambition. In the case of engineering structures,there are physical limits on how far you can stretch. Nobody’s going tobuild a bridge that traverses the Atlantic any time soon. And that reallymight fall down if you built it. But that’s not the reason people won’t buildit—it’s just because it’d be too expensive. Whereas nowadays, withsoftware, once you can build bridges over the Channel pretty quickly andcheaply, well then, that becomes a done deal and we now think that’s prettycheap so we’ll now try the Atlantic. And now it falls apart again.

Seibel: Guy Steele was saying how Moore’s Law has been true for hiswhole career and he suspects it won’t be true for his son’s whole careerand was speculating a bit about what that’s going to do to programming. Iwonder will we eventually have to stop just saying, “If we can build a bridgeover the Channel, we can build one over the Atlantic”?