Simon Peyton Jones

So at least it has been an intellectually interesting experiment that has been a very fertile laboratory which to grow up ideas that can infect the mainstream.

My instinct now is that we should start from functional programming and do imperative programming where necessary.

I think probably the mainstream is we should start with imperative programming and sort of add bits of functional programming where possible.

And I'm not going to say that they're wrong to do that, just to say that I think there's a pretty interesting dialogue.

Now, you do have to think very differently about the act of programming.

You do have to rewire your brain quite a bit.

But just let me, this is something we might want to come back to.

I said easier to maintain.

As programs get old, think of a 10-year-old program.

If you have a piece of 10-year-old code written by somebody who's long since left your company that mutates some more or less global variables,

then you might be a little bit afraid about, oh, and there's other bits of code scattered about that also read or write those global variables.

Then you might be a little cautious about making modifications, right?

Lest, oh, if I put these two things, if I do B and then A instead of A and then B,

maybe the global variable that I read somewhere deep inside the code is now not have the value that it was expected to.

Reading and writing shared variables that are visible outside the scope, somewhat global variables, is a form of coupling between bits of code that is very invisible.

Functional programming forces that to become visible.

It forces it into the open.

And by the act of forcing it into the open, that strongly encourages a style of programming which you don't have such interactions because they are painful to manage.

So it encourages a style in which programs execute in modular box without interacting.

Now, every imperative programmer would want to do that.