Interview with Simon Peyton Jones

JEREMY: Hey, so Simon, welcome back to Glasgow. How many years did you spend working here?

SIMON PEYTON JONES: It was about nine, but it felt much longer at the time. This is also the time my children were being born and it was a very important time of change for the department. So it was a very exciting time.

JEREMY: Well, as well as your children being born, the Haskell movement, I suppose, was born.

SIMON PEYTON JONES: It was. It slightly predated my children, actually. So they refer to Haskell as my first child.

JEREMY: Oh I see. Very good. Now I think in the past you’ve said Glasgow is a kind of spiritual home for Haskell. Are those your precise words?

SIMON PEYTON JONES: I don’t know, but I kind of feel that. Because Haskell was the fruit of an international committee of about 20 people. But it just so happened that several members of the committee were here at Glasgow. So it was John Hughes, Phil Wadler, myself, Kevin Hammond, who became an editor of the report. And Will Partain became involved a little later. So there was quite a few members of the Haskell Committee who were just here at Glasgow. So it was a sort of epicenter, if you like.

JEREMY: The epicenter, that’s a nice word. Very good, yes. Now you spoke about the committee. And I think in terms of programming languages, being designed by committee is not always a good thing.

SIMON PEYTON JONES: It’s not usually regarded as being an advantage. Because all of the languages that you hear about, Ruby, and Perl, and Python, and so forth, they all have quite clearly distinct individual closure. They have individual people who designed them. Or Pascal even longer ago. So Haskell’s very unusual in being, A, designed by a group, but B, nevertheless being quite successful over the long term.

JEREMY: There’s a wonderful quote from Tony Hoare– you were reminding me of it before– where he said he thought Haskell was doomed to succeed. Would you care to measure the success of Haskell? Do you think it’s exceeded your wildest dream?

SIMON PEYTON JONES: Oh, it certainly has. So I think what was in Tony’s mind is that Tony really likes very small, conceptually pure languages that are sort of stripped down to their essence. And Haskell, right from the beginning, it has a conceptual core that’s very small, but it has quite a lot of stuff around the outside. There’s more than one syntax for doing this. There’s lets as well as wheres. There’s pattern matching as well as case expressions. And we thought that was important. So I think he felt it was doomed to succeed because it was made by a larger group. But in fact no language is doomed to succeed.

I think my expectation was that Haskell would become a useful research vehicle for a number of research groups who were working on lazy functional programming at the time and maybe no more than that. But in fact, it’s been solidly influential over 2 and 1/2 decades. And it’s become a kind of thought leader in a way that has definitely exceeded my expectations.

JEREMY: You mentioned laziness there. And I think that’s one of the unusual things about Haskell compared to most mainstream programming languages. Can you give us a kind of Idiot’s Guide to Laziness, please?

SIMON PEYTON JONES: So laziness was, if you like, the thing that brought that particular group of people together, was the single war cry that sort of identified what Haskell was at the time. So lazy evaluation means, let’s procrastinate as much as possible. Let’s not do any work unless we absolutely have to. So if you call a function and you’re passing it an argument, well, let’s not evaluate the argument yet. Let’s pass to the function, the kind of recipe or suspension, which when the function needs the argument, it can evaluate it. And if you want to regard if, then, else as a function, that’s rather important. Because you don’t want to do both the then part and the else part.

Because you only want to do one in them. They’re kind of crucially important. But then it turned out to be more than just convenient. John Hughes wrote this very influential paper– John Hughes, also here at Glasgow– called Why Functional Programming Matters, in which he described how lazy evaluation allows you to compose programs together in a way that you couldn’t. You can write a program that generates all the possible moves in a game tree, sort of all the possible alternatives. That is an infinite tree. And then separately, you could write a program that walks over the tree and picks the right one. And in a eager language, you have to meld those two passes together into one.

But in a lazy language, you can separate them. So it’s a powerful modularity mechanism. And also it’s a powerful purity mechanism. It sort of forces you to be pure, which retrospectively I think was the most important thing about it.

JEREMY: Good. There are noises in the Haskell community about becoming more strict these days. Is that something you approve off?

SIMON PEYTON JONES: Oh yes, the whole strict-lazy dichotomy. So initially it was, well, there was Haskell, which was a lazy language, and there was Miranda, and SASL, and a few others, and there were strict languages. And these were very sort of different camps. But over time, Haskell has grown more strict, we have strictness annotations to allow the programmer more control over evaluation order. And indeed, the strict languages also usually have some kind of thunking mechanism to allow you to model lazy evaluation. So in fact I think people now see it more as a continuous spectrum. It’s more, what’s the default, rather than a sort of way of life doctrine.

JEREMY: Yes, I’d like to ask you about Haskell applications out in the real world. Can you think of any examples of perhaps very exotic deployments of Haskell programs?

SIMON PEYTON JONES: Oh well, so Haskell is kind of strange, because it’s been quite a niche language. So it’s been difficult for large companies to start using Haskell in a major way, because they’re always worried about how many Haskell programmers there’ll be and will the Haskell compiler continue to be supported? So I think that Haskell as kind of like a fungus or a mushroom. You know the way that fungi have these very long tendrils under the ground. So they’re quite widespread, but you can’t see them?

JEREMY: Yeah. So Haskell is quite widely used, particularly in small startup companies with the chief technology officer– Like there’s a company called SchedMe in New York doing some kind of scheduling system. And they’re entirely built in Haskell. And their CEO is telling me how they threw away their Ruby code, and it was just so much better in Haskell. So it’s used in small companies quite a bit. It’s also used in some big companies, particularly banks. Every bank appears to have a secret functional programming group. And quite often, that functional programming group is using Haskell. So Standard Chartered, for example, has quite a big Haskell group. In fact, they’re continually hiring people.

And they don’t get their quants, their traders, to write Haskell directly, but a lot of their infrastructure is written in Haskell. And when their quants say, we want some new kind of spreadsheet-oriented tool, they’ll write spreadsheets that invoke functions written in Mu, which is essentially a reimplementation of Haskell. So Haskell has become quite important in a number of financial settings. And then Galois, founded by John Launchbury, who is also a graduate of this department. So is now quite a successful company in the northwest United States. And I was talking to Alice Miller earlier on today. They do a lot of safety critical things using Haskell.

One example was they have a domain-specific language for writing the control systems for cool quad copters. So they write in this very high-level language, which is essentially Haskell, and then they compile that down to C, which runs on the quad copter.

JEREMY: Here’s a slightly cheeky question, Simon. What’s your second favorite programming language after Haskell presumably is your first?

SIMON PEYTON JONES: Difficult question, yes, because they’re a long way behind. I think I’d have to say Excel.

JEREMY: Right? That’s interesting.

SIMON PEYTON JONES: Most people don’t think of Excel as a programming language at all. But it is, right? And moreover, it’s a functional programming language, which everybody believes should be fun– They don’t even think of it as func– They don’t even think they’re programming. They’re modeling. So what I would like to do is to get Excel to be more up front about being a functional programming language, and particularly to support user-defined functions and rich data structures, records and arrays ways and so forth. And then in my grand vision, we would teach Excel as our first programming language. Because anything you can do in Haskell, ultimately you could do in Excel if you could do all of this.

That would be pretty exciting. So my second favorite programming language is not Excel as it is today, but Excel as I hope it might be one day.

JEREMY: Good. This is my last question now, Simon. You’ve written an article about how Haskell is like wearing a hair shirt. Now I want you to give some encouraging words to novice Haskell programmers, people who are learning about Haskell in our course and maybe finding it quite difficult. What would you say to encourage them to pursue functional programming?

SIMON PEYTON JONES: Functional programming, particularly if you’re used to writing in imperative programs, does feel a bit like rewiring your brain, which can feel a little bit painful at first. But the experience is once you come through that pain, you look at the entire– functional programming is kind of like a radical and eloquent attack on the entire enterprise of writing programs. It’s not like, well, I’m just going to switch syntax. It’s just C# instead of Java. It’s a whole different way of thinking about the problem. And if you think about complex problems, and programs are the most complex artifacts that human beings have ever built.

If you think about complex problems in a new way, that could shed really new light on it. So I think one of the interesting things about Haskell in particular, is it sticks remorselessly purely to one central idea, which is a programming with values and functions rather than programming with mutation and side effects. And most other functional programming languages sort of dice with the devil a bit and do quite a lot of side effects. Haskell is pretty remorselessly pure about that. And that kind of educates you continually into this new way of thinking. I’ll just give one tiny example. Sometimes you do want to do mutating things, and we do that using monads.

When you want concurrent threads that are doing I/O in the world, so they must be concurrent, they must interact with each other in some stateful way, a good way to make them interact is using transactional memory. So transactional memory is something that’s quite hard to do in imperative languages, because in principle, every mutation of every memory location must be tracked. But in Haskell, because the mutation of mutable locations are so carefully partitioned in the type system– and a little bit awkward to get at as a programmer– then there are very few of them. So transactional memory systems are efficient and effective. And indeed they come out of the box with GHC.

JEREMY: Simon, thank you very much.

SIMON PEYTON JONES: It’s been great talking to you. It’s really nice to be back in Glasgow actually.