Simon Peyton Jones

Back in 1980, functional program was very nerdy, geeky, academic.

But I was allowed to spend my professional life just saying, what would happen if you took that one idea, programming with values,

and just ran with it, where would you get?

And I think we've got somebody somewhere pretty interesting.

I don't want to say that it's better fundamentally because after all Haskell on that journey started with functional programming, then we learned how to mix functional imperative programming together in a way that we might talk about later, right?

So it's not really an either or, it's more of a both and in the end.

But my position now is, as I often say, when the limestone of imperative programming is worn away, the granite of functional programming will be revealed underneath.

And why do you say that?

Well, functional programming is the language of mathematics.

That's how we fundamentally think about things when we want to be formal.

Indeed, if we want to reason about and say, what does this imperative program do?

We have to wheel out a lot of mathematics and, you know, whole triples and so forth.

But that's all in the world of maths, which is just functional programming.

Functional programming is just mathematics brought to life and made executable.

So you might wonder, I suppose, you may be saying, well, isn't imperative programming just enough?

And I think that there you have to look at the broad sweep of things.

I think what's happened is that from the world of functional programming, lots of ideas have got adopted into the imperative arena.

So they grew up over here in functional programming.

and then they have been adopted by the imperative programming thing.

So you might think garbage collection, you might think lambdas, you might think language integrated query, you might think about lots about type systems, polymorphism and static typing, tons of that.