So the culture of the programming-language community is much more,“prove that your type system is sound and complete,” kind of stuff. Wedodge, probably, the more important but much harder to answer questionsabout whether, in practice, they make people more productive. But they arequestions that are really hard to give convincing answers to. Are you moreproductive writing a functional program or an object-oriented program todo the same thing? Even if you could spend a lot of money on doing seriousexperiments, I’m not sure you’d come up with results which people wouldactually buy.

Seibel: Do you guys do any, even small-scale experiments? You’re workingfor Microsoft, who has plenty of cash, so why not get a team of experiencedHaskellites and a team of experienced C# people and give them the sametask and see what happens? That’s the kind of test you would need, right?

Peyton Jones: Yeah, yeah, that’s right. It’s partly a question of money. Butit’s not just a question of money. It’s also sort of time and attention. To dothat kind of experiment your whole methodology is different. And you needto shift culturally as well. And, while Microsoft, from the outside, appears tohave plenty of cash, in fact the story here is largely one researcher and hisworkstation. We can’t just turn on money for any particular thing. Be nice ifwe could. Nearer the coalface, as it were, there are big usability labs inRedmond where they do perform experiments on things that are protoproducts. New versions of Visual Studio are extensively usability tested.

Seibel: Presumably that’s more for the total user interaction, rather thanfor programming language issues.

Peyton Jones: Well, they also do some interesting work on testing APIs.Steven Clarke and his colleagues at Redmond have made systematicattempts to watch programmers, given a new API, talk through what they’retrying to do. And they get the people who designed the API to sit behind aglass screen and watch them.

And the guys sitting there behind the glass screen say, “No, no, don’t dothat! That’s not the right way!” But it’s soundproof. That turns out often tobe very instructive. They go and change their API. To be honest,programming language research is weak on that score. But it is partlybecause these are difficult questions to answer. And culturally we’re notwell adapted to do it. I regard it as a weakness. But not one that I personallyfeel terribly well equipped to address.

Seibel: So if researchers are coming up with interesting ideas about how toimprove programming, are the best of those good ideas from research labsand universities percolating into practice fast enough?

Peyton Jones: Well, fast enough. I don’t know. Whenever I talk to peoplewho are actually involved in building products that customers want and aretherefore prepared to pay for, I’m very conscious that many of the thingsthat bother me just aren’t on their radar at all.

They have to do something this week that their customers are going tovalue; they just don’t have time to mess about with something that mightwork or that might even work in some ways but in total isn’t yet ready forprime time.

There’s a bit of a disconnect—it’s sort of a chicken-and-egg problem there.Sometimes the ideas that are developed in research need quite a bit ofengineering effort around the edges that isn’t fundamental research in orderto be directly useful.

I wouldn’t like to imply that developers on the ground are being dopeyabout this, just not taking up good ideas that would benefit their lives.They’re doing what they’re doing for quite good reasons. There issometimes a bit of a gap between research prototypes and stuff that youcan build in reality. And I think that Microsoft is actually doing quite wellhere because Microsoft Research does fill that gap a bit and does have quitea bit of mechanism—incubation groups and so forth—whose aim is to putresearchers and developers in closer touch with each other and perhaps tohelp provide some extra effort to lift things across the boundary. So MSR iskind of as good as it gets, I think, as far as crossing that boundary isconcerned.

There are layers to this kind of onion. For a mainstream developer shopthat’s stuffed with Java, not only is functional programming a radicallydifferent way of thinking about programming but also there are lots ofinterop questions. And have you got enough books and are there enoughlibraries? So there’s this whole ecosystem that goes with programming,people and skills and libraries and frameworks and tools and so forth.

If you have enough of those blockers you get sort of stuck. So I thinkdifferent pieces of research technology in programming language live ondifferent points on a spectrum. Some are more evolutionary from where weare. You can say, “It just plugs right into your existing framework, it workson unmodified Java, it’s a static analysis that points you to bugs in your codeand yipee!” That’s much easier to absorb than, “Here’s a whole new way ofthinking about programming.”

That said, I think that if we’re specifically discussing functional programmingthen I do think that we have seen a qualitative sea change in people’sattitude. Many more people have heard about functional programming thanever used to. Suddenly rather than always having to explain what Haskell is,sometimes people say, “Oh, I’ve heard about that. In fact I was readingabout it on Slashdot the other week and I gather it’s rather cool.” That justdidn’t happen a few years ago.

But what’s underlying that? Is it just a random popularity thing? Or maybepart of it is that more students have been taught about functionalprogramming in university and are now in managerial or seniorish positions.Perhaps. But perhaps it’s also to do with as we scale up software dealingwith the bad consequences of unrestricted side effects and as we want todeal with more verification and parallelism, all those issues become morepressing. I think that leads to this greater level of interest. I think graduallythe needle is moving across this cost/benefit tradeoff.

Seibel: When did you get introduced to functional programming?

Peyton Jones: I didn’t learn about functional programming until somethinglike my final year at Cambridge when I went to a short course given byArthur Norman. Arthur Norman was a brilliant and slightly eccentriclecturer in the department. Wonderful guy, interested in symbolic algebraso he was big into Lisp as well. He gave a short course on functionalprogramming in which he showed us how to build doubly linked listswithout using any side effects at all. I vividly remember this because this wasmy first notion that you could do something that weird—you’d think if youbuild a doubly-linked list you have to allocate the cells and then you have tofill them in to make them point to each other. It looks as if you just have touse side effects somehow.

But he showed how, in a purely functional language, you could actually writeit without using any side effects. So that opened my eyes to the fact thatfunctional programming, which at that stage I knew very little about, was amedium you could really write quite interesting programs in rather than justlittle toy ones.

Seibel: I think a lot of people might look at that demonstration and say,“Oh, isn’t that interesting,” and then still go back to hacking BCPL. Why doyou think you were able to take the leap so much farther, spending most ofyour career trying to show how folks can really use this stuff?

Peyton Jones: There was one other component, which was DavidTurner’s papers on S-K combinators. S-K combinators are a way oftranslating and then executing the lambda calculus. I’d learned a little bitabout the lambda calculus, probably by osmosis at the time. What Turner’spapers showed was how to translate lambda calculus into the threecombinators, S, K, and I. S, K, and I are all just closed lambda terms. So ineffect it says, “You can translate these arbitrary complicated lambda termsinto just these three.” In fact, you can get rid of I as well because I equalsSKK.