Simon Peyton-Jones: Towards a Programming Language Nirvana

Download this episode

Download Video


While in Cambridge, England recently for the
MSR Cambridge 
10 year anniversary and
MSR Cambridge PhD Summer School
(stay tuned for coverage on this on Channel 8...) I caught up with
Simon Peyton-Jones,
Erik Meijer
and, very briefly (too briefly),
Butler Lampson
to talk about what's going on inside Simon's head right now with respect to general purpose programming language evolution.

Trust me, it's most interesting and programmers should be excited about the thoughts in Simon's head these days. Join us for a really brief conversation (I think this is my shortest interview in the 3+ years I've been taking part in conversations here on Channel
9) with some of programming language design's best and brightest. Here, Simon clues us in to the nirvana of programming languages: Safe and Useful (effectful). Better just to listen in to Simon's excellent and succinct explanation of the holy grail
of general purpose programming languages.


PS I will be interviewing Butler Lampson sometime in the future (when he's in Redmond). He's a rather prominent computer scientist with a rich history in making
systems that many of us rely on for a number of things...



Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      Thanks for this video.
      I love listening to programming language gurus.  Smiley
    • User profile image
      awesome Smiley

      Heh, coincidentally just two days ago I became interested in Haskell - and GHC (Glasgow Haskell Compiler) in particular. I think I'm going to learn it someday when I have more free time.
      It's great to see the man behind GHC that has made a lot of work for it. Wish you luck. 

      Big Smile
    • User profile image
      Wonderful video Charles, but no fair, it's way to short! Smiley Can we please get Simon back on C9 soon. I read his "Beautiful Concurrency" paper again recently and was struck again by what a great brain / communicator he is (as well as possessing a very sly sense of humour). More Simon...
    • User profile image
      Wow, thats very cool. Just way too short! I wanted to hear more Sad

      Good interview.
    • User profile image
      Great Teaser!

      More please.

    • User profile image
      Yes, more SPJ please!
    • User profile image
      This conversation really just "happened" in the sense that it was entirely unplanned... This is why we got cut off - the geniuses were only gathered there because they happened to be getting ready to walk around a poster session and evaluate the content and delivery of the students standing next to their posters for a "competition" of sorts.

      I will try to get more time with Simon. Since he's in Cambridge most of the time, it probably won't be soon, though I do know he's going to a conference not too far from Seattle sometime soon.... I will need to look into this.

      Short though this interview is, it's in fact crammed with very valuable insights and information.

    • User profile image

      Brilliant! More of this please. Interesting perspectives, not just bla bla bla. Smiley

    • User profile image
      Charles wrote:

      I will try to get more time with Simon. Since he's in Cambridge most of the time, it probably won't be soon, though I do know he's going to a conference not too far from Seattle sometime soon.... I will need to look into this.

      Yes, he's going to have a few tutorials and talks at OSCON in Portland which takes place July 23-27, so you best hurry if you want to make arrangements for anything related to that!
      According to their website his last talk is on the 25th. Maybe you could invite him up to Seattle after that? Or arrange a road trip Smiley

      I'd love to hear more talk on general programming languages trends and theory, but also more on the concurrency problem that we face in the future.
    • User profile image
      Great video!
    • User profile image
      When will Nirvana.NET be relased?
    • User profile image
      I listened to the audio version of this video...maybe that was a mistake.

      It is interesting to see what they consider "safe" and "unsafe", but wouldn't the scope and type of a variable inherently limit the extent of its "side effects"? And the same with functions? Perhaps a better definition of "safe" is in order.

      I should note I have never programmed in Haskell, but it looks intriguing.
    • User profile image
      If you are interedted in Haskell (or anybody), the first step is to read:

      warning: reading YAHT can cause catharsis, haha Smiley
    • User profile image
      pepper wrote:

      It is interesting to see what they consider "safe" and "unsafe", but wouldn't the scope and type of a variable inherently limit the extent of its "side effects"? And the same with functions? Perhaps a better definition of "safe" is in order.

      Well yes, maybe. Depends on what you mean. E.g. in C you can include IO functions and call them anywhere you want (the hard disk, network drives etc. are all "mutable variables" in a sense) so in order to be safe you must have a language which separates "IO actions" from "pure computations" (otherwise you could in principle make several calls to "sin" or something and get different results for the same input values, if "sin" reads from disk or a network socket or whatever).

      Also scope of variables can change dynamically. E.g. what if a function returns a mutable reference? Then this mutable reference can be accessed from outside the function it was created in. So in order to be safe the language must statically ensure that no such "leaking" of side effects can occur.

      So Haskell does all of this. You have an "IO monad" where you define "IO actions". A monad is pretty simple actually, but it's such a general concept that it can be difficult to get a handle on it. Essentially you have a data type representing your monad, and two functions on it. One of them takes "something" and makes it into a "monadic something". And the other takes two "monadic somethings" and combines them into one "monadic somehting". Monads can be used to model lots of things, such as collections (e.g. that LINQ stuff is heavily based on this), but in this case the monad is used to model "IO actions". In other words "actions which, if performed, will do some IO". Note that you're not actually doing any IO when using the two monadic functions described above, you're only building actions which represent the IO you want to do.

      Anyway, the point is that there is no way of actually performing this IO "outside" of this IO monad. The only way of doing IO is to take smaller IO actions and combining them into larger IO actions (using the function mentioned above). But there is no way to "run" an IO action from within Haskell (you effectively give the IO action representing your program to the compiler, which will produce the necessary code to run it, but you the programmer has no way of running IO actions). This means that IO actions "infect" anything that uses them; the only way to use an IO action is within another IO action.
      So "sin" must be pure and completely free from side effects because its type doesn't say that it's an IO action.
      Of course IO actions are perfectly free to call pure functions to do computations, but the opposite is statically ensured to never happen.

      That's one part of the puzzle.

      The other cool thing is that if you only want to do mutable state (and not, e.g. read from a network socket or do any other IO) then you can use the "ST" monad. This is like the IO monad except it only allows you to read and write to mutable variables (and arrays etc.), and it also gives you a function called "runST" which runs and ST action. This means that you can actually call such an ST action from pure code (unlike IO). The key thing here is that runST has a type which prevents side effects from "leaking" (so you can't e.g. call runST on an ST action which returns a mutable reference). So while you may have lots of ST actions which read and write to lots of mutable references in scope, there is no way that any such side effects can "leak" through "runST". This means you can write algorithms with mutable state (and there are algorithms where this is requried) but then once you're done you wrap it in a pure interface (same input => same output) and call "runST" on it to convert it into a pure function that can be called from any pure function.

      This way we still get purity (the compiler can do all sorts of cool stuff; but perhaps more importantly the programs are much easier to understand and usually contain far fewer errors -- not to mention the benefits to concurrent programming this gives), but we also have the pragmatics of being able to do low-level mutable state programming where needed.

      So while pure functionaly programming used to mean "no mutable state ever" (and as SPJ said, this was the cause of prolonged embarassement before they figured out the monad stuff!), now days it just means "safe mutable state that can be encapsulated in a pure functional environment", which is much more useful!
    • User profile image

      Not only was it nice, informative and too short, but it was just funny!! Big Smile Big Smile I laughed a lot... More like this one.

    • User profile image
      Hehe. I remember back when I was in college. I gave the computing department a great deal of grief for using haskell for "not being a useful language". Hehe. It's really nicely put together tho.
    • User profile image


      What a great name for a programming language!

    • User profile image
      Ion Todirel
      i don't quite understood what comprehensiveness term means in the context used by Mr Simon, anyone?
      DamienMorton wrote:
      When will Nirvana.NET be relased?
    • User profile image
      quango wrote:


      What a great name for a programming language!

      Nirvana was used as a concept. You know, nirvana... It is NOT the name of a programming language being worked on... That said, yeah, it would be an interesting name.

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.