Simon Peyton Jones, graduated from Trinity College Cambridge in 1980. After two years in industry, he spent seven years as a lecturer at University College London, and nine years as a professor at Glasgow University, before moving to Microsoft Research (Cambridge) in 1998, which lately has been instrumental in introducing a new four-letter word to the English language – Microsoft Research is next door to the Cambridge University Computer Lab, and there Simon’s co-supervises a number of PhD students at the Computer Lab.

His main research interest is in functional programming languages, their implementation, and their application. He has led a succession of research projects focused around the design and implementation of production-quality functional-language systems for both uni-processors and parallel machines. He was a key contributor to the design of the now-standard functional language Haskell, and is the lead designer of the widely-used Glasgow Haskell Compiler (GHC).

He has written two textbooks about the implementation of functional languages and more generally, he is interested in language design, rich type systems, software component architectures, compiler technology, code generation, runtime systems, virtual machines, and garbage collection. He is particularly motivated by direct use of principled theory to practical language design and implementation – that’s one reason he loves functional programming so much.

“Success is great,
but it comes at a price.”

He says that he doesn’t want to ‘appear to claim that functional programmers have parallel programming wrapped up – far from it! It’s just that I think there’s a lot to offer and the world will be moving in that direction one way or another.  I don’t think we were that clairvoyant when we began Haskell twenty odd years ago- it was simply about doing one thing well

Simon is married to Dorothy, a priest in the Church of England and they have three children, Michael, Sarah, and Margaret.

RM:

Simon, an oft asked question for you I’m sure, can you remind me how Haskell was created?

SPJ:

In September 1987 a meeting was held at the Conference on Functional Programming Languages and Computer Architecture in Portland, Oregon, to discuss an unfortunate situation in the functional programming community: there had come into being more than a dozen non-strict, purely functional programming languages, all similar in expressive power and semantic underpinnings.

There was strong consensus at this meeting that more widespread us of this class of functional languages was being hampered by the lack of a common language. So we formed a committee to design such a language.

We thought a committee was the best answer to provide a faster communication of ideas, a stable foundation for real applications development and a vehicle through which others would be encouraged to use functional languages.

All the relevant researchers in the world were invited to contribute, as at that stage the project was purely academic. There were no companies using lazy functional programming, or at least not many of them. We invited all of the researchers we knew who were working on basic functional programming to join in.

RM:

Haskell is known as a lazy or delayed language, what advantage do these have over non-lazy languages?

SPJ:

Laziness has lots of advantages, including modularity.  These days, the strict/lazy decision isn’t a straight either/or choice.  For example, a lazy language has ways of stating ‘use call by value here’, and even if you were to say ‘oh, the language should be call by value strict’ – which is the opposite of lazy – you’d want ways to achieve laziness anyway.

Any successor language to Haskell will have support for both strict and lazy functions. So the question then is: what’s the default, and how easy is it to get to these things?

How do you mix them together? But on balance yes, I’m definitely very happy with using the lazy approach, as that’s what made Haskell what it is and kept it pure.

RM:

Tell me about Haskell’s unofficial slogan: avoid success at all costs. What’s the origin of it?

SPJ:

I mentioned this at a talk I gave about Haskell a few years back and it’s become quite widely quoted. When a language becomes too well known, or too widely used and too successful – certainly being adopted by Microsoft means such a thing – suddenly you can’t change anything anymore. You get caught and spend ages talking about things that have nothing to do with the research side of things. Success is great, but it comes at a price.

I’m primarily a programming language researcher, so the fact that Haskell has up to now been used for just university types has been ideal. Now it’s used a lot in industry but typically by people who are generally flexible, and they are a generally a self selected rather bright group. What that means is that we could change the language and they wouldn’t complain. Now, however, they’re starting to complain if their libraries don’t work, which means that we’re beginning to get caught in the trap of being too successful.

RM:

Ah, you mentioned Microsoft, what was it that attracted you to Microsoft Research and how has that affected your work with Haskell?

SPJ:

I’d been working in universities for about 17 years, and then I moved to Microsoft. I enjoyed working at universities a lot, but Microsoft was an opportunity to do something different. I think it’s a good idea to have a change in your life every now and again. It was clearly going to be a change of content, but I enjoyed that change.

Microsoft has a very open attitude to research, and that’s one of those things I got very clear before we moved. They hire good people and pretty much turn them loose. I don’t get told what to do, so as far as my work on Haskell or GHC or research generally is concerned, the main change with moving to Microsoft was that I could do more of it, as I wasn’t teaching or going to meetings etc. And of course all of those things were losses in a way and the teaching had its own rewards.

RM:

Is the recruitment by Microsoft of leading academic Computer Scientists a symptom of the inadequacy of Universities as environments for cutting edge research?

SPJ:

I don’t think so.  Universities are rich communities stuffed with interesting and diverse people, and lots of bright students.  An industrial research lab allows you to be more single-minded, to be sure, but many people actively enjoy teaching students and participating in the diversity of a university environment. And it’s very important that students are taught by leading researchers.

RM:

Okay let’s get back to Haskell. The language has a basic module system but it’s not a state of the art module system, is it? Was it a conscious decision to avoid tackling that?

SPJ:

Yes it was a conscious decision.  We wanted to solve one problem well, rather than three problems badly. We thought for the bits that weren’t the main focus, such as the module system, we’d do something straightforward that was known to work, even if it wasn’t as sophisticated as it could get. You only have so much brain capacity when you’re designing a language, and you have to use it – you only have so much oxygen to get to the top of the mountain. If you spend it on too many things, you don’t get to the top!

RM:

Were the modules the only main elements you decided not to tackle?

SPJ:

Another minor thing was records. Haskell has a very simple record system, and there are lots of more complicated record systems about. It’s a rather complicated design space. Record systems are a place where there’s a lot of variation and it’s hard to know which is best. So again, we chose something simple.

People sometimes complain and say ‘I want to do this obviously sensible thing, and Haskell doesn’t let me do it.’ And we have to say, well, that was a place we chose not to invest effort in. It’s usually not fundamental however, in that you can get around it in some other way. So I’m not unhappy with that. It was the economic choice that we made.

RM:

Have you thought of adding an ML style module to Haskell?

SPJ:

Oh yes, often!  But it’s a hard thing to retro-fit.

RM:

The latest version of Haskell is Haskell Prime, is this a priority for you and how is it developing?

SPJ:

Haskell Prime is the name for a process rather than a language.  Although many people would welcome a well-written standard incorporating many of the advances that we have made since Haskell 98, there seems little appetite for actually doing the work that would entail. So the Haskell Prime process has evolved into something more incremental, modelled on open-source software development.  Each year, people will specify and advocate some feature that they’d like to see in the language.  We’ll argue about it (in an open forum), and then make a ‘release’ that incorporates the agreed set of features, whatever they are.  If the case isn’t made, it doesn’t go in that year.

RM:

Speaking of the evolution of Haskell, what do you think of variants such as? What influence has Haskell has on newer languages such as F#?

SPJ:

I see Haskell as an ideas factory, where people can evolve and study type systems, programming techniques, or implementation technology.  Then the best of those ideas may migrate into the mainstream.  That has certainly happened with F#, which consciously borrows ideas from Haskell such as monads, re-titled as ‘workflows’.

This traffic of ideas is not straightforward; for example, Don had to tastefully and creatively adapt the monad idea for the F# setting.  Nor is it uni-directional; for example, software transactional memory (STM) in Haskell was born out of my attending a talk by Tim Harris on STM in Java.

RM:

The Haskell community seems a very friendly one. What makes it that do you think?

SPJ:

Haskell has an extremely friendly sort of ecosystem growing up around it. There’s a mailing list that people are extremely helpful on, it has a wiki that is maintained by the community and it has an IRC channel that hundreds of people are on being helpful. People often say that it seems to be an unusually friendly place, compared to other experiences they’ve had elsewhere.  I don’t know why this is, but I’m very pleased that the Haskell community has this reputation as being a friendly and welcoming place that’s helpful too. It’s an unusually healthy community and I really like that.

RM:

How difficult is it for a new language to break another language’s strangle-hold? I’m thinking particularly how Java broke through C++. Can you ever predict the next big thing?

SPJ:

It’s difficult to have mainstream impact you need to be both smart and lucky. Neither is enough by itself.  And that makes mainstream impact very hard to predict.

RM:

Can you see mainstream programming becoming more careful about effect, or rather side effects over the next few years?

SPJ:

Yes, that’s the main prediction I am prepared to make!  The cost of unrestricted side effects is climbing, as we write more complex software, and as we try to use more parallel processors.  The languages of the future may or may not be recognisably functional, but I’m convinced that the languages of the future will have robust mechanisms for controlling effects.

RM:

What would be your advice to ambitious programmers?

SPJ:

Learn a wide range of programming languages, and in particular learn a functional language. Make sure that your education includes not just reading a book, but actually writing some functional programs, as it changes the way you think about the whole enterprise of programming. It’s like if you can ski but you’ve never snowboarded: you hop on a snowboard and you fall off immediately. You initially think humans can’t do this, but once you learn to snowboard it’s a different way of doing the same thing. It’s the same with programming languages, and that radically shifted perspective will make you a better programmer, no matter what style of programming you spend most of your time doing. It’s no good just reading a book, you’ve got to write a purely functional program. It’s not good reading a book about snow boarding – you have to do it and fall off a lot before you train your body to understand what’s going on.