Peyton Jones: No, no. Software’s different I think. Because if you writesoftware that’s ten times as big that doesn’t mean you have to run it on acomputer that’s ten times as fast. The program counter spends its time in asmall portion of the code. Ninety percent of its time is spent in ten percentof the code or something. So the parts that are performance critical may bea relatively small part of the program.

It’s true that what tends to happen is you slap abstraction on abstraction onabstraction and before you know it pressing a single button on the screen agreat number of things happen all the way down the chain before you finallyget to some registers being moved.

So we may have to work on ways of collapsing out those layers bysophisticated compiler transformations so not so much happens. Theabstraction boundary may be useful for people but machines don’t care. So Idon’t think just because we may reach the boundaries of what computerscan do that necessarily software will immediately halt from getting morecomplicated. Because by that time they’ll be pretty fast anyway. I think theprimary limitation on software is not the speed of computers but our abilityto get our heads around what it’s supposed to do.

Seibel: What do you enjoy about programming?

Peyton Jones: For me, part of what makes programming fun is trying towrite programs that have an intellectual integrity to them. You can go onslapping mud on the side of a program and it just kind of makes it work fora long time but it’s not very satisfying. So I think a good attribute of a goodprogrammer, is they try to find a beautiful solution. Not everybody has theluxury of being able to not get the job done today because they can’t thinkof a beautiful way to do it.

But I really think it’s a funny medium because it’s so malleable. You can dovirtually anything with it. But that means you can build ugly things as well asbeautiful things and things that will be completely unmaintainable and undurable.I sometimes feel a bit afraid about the commercial world with, onthe one hand, the imperatives of getting it done because the customerneeds it next week and, on the other hand, the sheer breadth rather thandepth of the systems that we build.

Systems are filled with so much goop—in order to build an ASP.NET webservice-y thing you need to know about this API and this tool and you needto write in three different languages and you need to know about Silverlightand LINQ and you can go on doing acronyms forever. And each of them hasa fat book that describes it.

This is a tension I don’t know how to resolve. These are useful systems—they’renot designed by accident. Each of them is there for a reason and each of themhas a smart person who’s thinking hard about how this thing should bearchitected. But nevertheless, each, individually, has a broad interface. Itmay or may not be deep but it’s certainly broad. There’s a lot of stuff youneed to just have in your head. It’s like learning a language—a humanlanguage—there’s a large vocabulary.

For me, that’s no fun. I never learned my multiplication tables. I alwaysworked them out from first principles every time and I just developedenough tricks that I could do it quickly enough. When you do seven nines Istill have to go, oh, seven nines, oh, seven tens and subtract, so it’s sixtythree.Whereas other people just learnt them. And that’s a relatively smallthing. So I hate things were you just have to learn these big things. Soinstinctively I back away from these big goopy things. But at the same time Iacknowledge that they’re useful and important in practice. The question inmy mind is, if you were able to take a bit longer to design some of thesethings, could they be designed with smaller, less complicated, and less adhoc interfaces?

Seibel: Sometimes it seems that it’s exactly because each of these blobs hassome smart person or people working on it and each smart person wantstheir own little playground to play in, that things get so complicated.

Peyton Jones: I’m sure there’s an element of that. But to put a morepositive construction on it, if you like, it’s a big, complicated world andthere’s a lot to get done. If you had a grand Olympian vision—if you had avery large brain and enormous throughput—you might be able to dosomething with less overlap and more overall coherence.

But in practice we have to factor these problems into little chunks. Andthen the little chunks each have somebody who looks after it and who’sconditioned by the things they’ve done before and their heritage. So maybethey design something within that space that may not be as good as it couldpossibly be—they’re pressed for time. And certainly by the time you look atthe combination of everything it’s maybe quite a lot less good than it couldpossibly be. And then before you know it you’re locked into a legacyproblem—that’s another reason that things are not as good as they couldpossibly be.

So there’s a tremendous legacy ball and chain that’s being dragged around.It’s one of the nice things about Haskell. When I gave a retrospective onHaskell at, I think it was POPL 2004 or something, I put up a slide that saidone of the things we’ve learned to do in Haskell is to “avoid success at allcosts.” This is clearly a sort of meme because people remember that phraseand they quote it back to me.

It has a grain of truth in it because it means by not being too successful, tooearly, we’ve been able to morph Haskell quite a lot during its life. And partof the reason that I’m feeling a bit manic at the moment is because Haskellhas become more successful and so I get more bug reports, more featurerequests. And more people saying, “Don’t break my program please.” Thatdidn’t use to happen.

Seibel: You’ve mentioned writing beautiful code a couple of times. Whatare the characteristics of beautiful code?

Peyton Jones: Tony Hoare has this wonderful turn of phrase in which hesays your code should obviously have no bugs rather than having no obviousbugs. So for me I suppose beautiful code is code that is obviously right. It’skind of limpidly transparent.

Seibel: What about those little jewels of code that you almost have topuzzle out how they work but once you do, it’s amazing. Are those alsobeautiful?

Peyton Jones: Sometimes to say that it’s obviously right doesn’t mean thatyou can see that it’s right without any mental scaffolding. It may be that youneed to be told an insight to figure out why it’s right. If you look at the codefor an AVL tree, if you didn’t know what it was trying to achieve, you reallywouldn’t have a clue why those rotations were taking place. But once youknow the invariant that it’s maintaining, you can see, ah, if we maintain thatinvariant then we’ll get log lookup time. And then you look at each line ofcode and you say, “Ah, yes, it maintains the invariant.” So the invariant is thething that gave you the insight to say, “Oh, it’s obviously right.”

I agree completely that just looking at the bare code may not be enough.And it’s not a characteristic, I think, of beautiful code, that you should beable to just look at the bare code and see why it’s right. You may need tobe told why. But after you have that, now with that viewpoint, thatinvariant, that understanding of what’s going on, you can see, oh yeah, that’sright.

Seibel: Does that put an upper bound on how big a piece of software canbe and still be beautiful?

Peyton Jones: I don’t know if it’s a bound on its size. The insights that youneed in order to reassure yourself that it’s right, or at least right-ish, arealong the lines of being more confident that it’s correct. Any really, really bigpiece of software is bound to have shortcomings or indeed outright thingsthat you just know are wrong with it. But it’s not economic to fix them atthe moment. It’s certainly true of GHC and it’s definitely true of Microsoft’ssoftware.