Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		 Previous revision
armstrong_peyton_jones_interview [2009-09-28 12:10] – created 83.101.32.117armstrong_peyton_jones_interview [2009-09-28 12:16] (current) – 83.101.32.117
Line 1: Line 1:
  
-A reformatting of http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell+A reformatting for readability of http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell
  
 I'm Sadek Drobi. I'm here at Erlang Factory with Simon Peyton Jones and Joe Armstrong. Can you please tell us about yourselves and what you've been busy with lately?   I'm Sadek Drobi. I'm here at Erlang Factory with Simon Peyton Jones and Joe Armstrong. Can you please tell us about yourselves and what you've been busy with lately?  
Line 41: Line 41:
  
 JA: He left a little comment at the top, "Joe first wrote this", and then everything is completely different. We used to rewrite each others' code. JA: He left a little comment at the top, "Joe first wrote this", and then everything is completely different. We used to rewrite each others' code.
- Haskell and Erlang have 2 distinct models of concurrency, right? Haskell is going to side-effect free, Erlang is about messaging. Can you talk a bit about this in contrast to both models of concurrency?  + 
 +Haskell and Erlang have 2 distinct models of concurrency, right? Haskell is going to side-effect free, Erlang is about messaging. Can you talk a bit about this in contrast to both models of concurrency?   
 SPJ: I suppose Haskell initially wasn't a concurrent language at all. It was a purely functional language and we had the idea from the beginning that a purely functional language was a good substrate for doing concurrency on. But it turned out to be a lot harder to turn that into reality than I think we really expected because we thought "If you got e1+e2 then you can evaluate e1 at the same time as e2 and everything will be wonderful because they can't affect each other because it's pure."  SPJ: I suppose Haskell initially wasn't a concurrent language at all. It was a purely functional language and we had the idea from the beginning that a purely functional language was a good substrate for doing concurrency on. But it turned out to be a lot harder to turn that into reality than I think we really expected because we thought "If you got e1+e2 then you can evaluate e1 at the same time as e2 and everything will be wonderful because they can't affect each other because it's pure." 
  
Line 61: Line 63:
  
 JA: Phil Wadler saw it... You know, you can have two versions of the same model with all the same names, he didn't believe it was possible until we showed it to him. JA: Phil Wadler saw it... You know, you can have two versions of the same model with all the same names, he didn't believe it was possible until we showed it to him.
 +
  You mentioned some other language got inspired from Erlang and from Haskell, also about concurrency. For example, Scala. The dynamic part of Erlang actors in the same way that languages like F# and C# implement features coming from functional programming, more specifically Haskell. Can you talk a bit about this and how things get implemented in the mainstream or in other languages?    You mentioned some other language got inspired from Erlang and from Haskell, also about concurrency. For example, Scala. The dynamic part of Erlang actors in the same way that languages like F# and C# implement features coming from functional programming, more specifically Haskell. Can you talk a bit about this and how things get implemented in the mainstream or in other languages?  
 +
 JA: I don't know. People say "What will happen to Erlang?" and I have no idea. There are certain languages which are very influential, but don't get widely used, like Smalltalk, for example. Smalltalk is the ultimate object-oriented language and it has influenced Objective-C and all sorts of languages. It has this core band of pure Smalltalk programmers who don't believe in anything else, but it wasn't destined to take over the world. Erlang is probably... I don't know, maybe it's in that category, it influences other languages... It comes from a funny place, it comes from Ericsson, it comes from a telecoms company and that's really not our main business, to make languages.  JA: I don't know. People say "What will happen to Erlang?" and I have no idea. There are certain languages which are very influential, but don't get widely used, like Smalltalk, for example. Smalltalk is the ultimate object-oriented language and it has influenced Objective-C and all sorts of languages. It has this core band of pure Smalltalk programmers who don't believe in anything else, but it wasn't destined to take over the world. Erlang is probably... I don't know, maybe it's in that category, it influences other languages... It comes from a funny place, it comes from Ericsson, it comes from a telecoms company and that's really not our main business, to make languages. 
  
Line 71: Line 75:
  
 SPJ: In principle I could. I don't think it's going to any time soon. I suppose Microsoft could turn around and tell me "Please don't work on Haskell any more." SPJ: In principle I could. I don't think it's going to any time soon. I suppose Microsoft could turn around and tell me "Please don't work on Haskell any more."
 +
  Like they did with Erik Meijer, right?    Like they did with Erik Meijer, right?  
 +
 SPJ: Erik is a whole different ball of wax. Erik works in the developer division in Microsoft and that's much more product focused, but amazingly Erik has brilliantly found a way to meld ideas from functional programming in quite a product-focused kind of way and build a little research bubble in the developer division that they perceive as being actively valuable to them. I think that's amazing! Whereas I'm a mere parasite. I'm a researcher who isn't required on a month-by-month basis in the way that Erik is to produce immediate value to the company. SPJ: Erik is a whole different ball of wax. Erik works in the developer division in Microsoft and that's much more product focused, but amazingly Erik has brilliantly found a way to meld ideas from functional programming in quite a product-focused kind of way and build a little research bubble in the developer division that they perceive as being actively valuable to them. I think that's amazing! Whereas I'm a mere parasite. I'm a researcher who isn't required on a month-by-month basis in the way that Erik is to produce immediate value to the company.
  
Line 107: Line 113:
  
 SPJ: You are misrepresenting me! I never said that types guarantee your program is correct, but you were talking about segregating events and types are a very good way to segregate things. SPJ: You are misrepresenting me! I never said that types guarantee your program is correct, but you were talking about segregating events and types are a very good way to segregate things.
 +
  In the same topic, in Scala, which we say got inspired by Erlang, for the actor model, actually they don't copy memory, they don't copy data structure, but they rather share them and there are no constraints on the data structure, so it could be mutable and it could be shared. Martin Odersky, father of Scala wrote a paper about using types, be it inferred or not, type annotations for guaranteeing that the reference is not consumed concurrently. So, you can use mutable data structure, which is very nice for performance reasons, yet you get some guarantees of not having race conditions. Can you talk a little bit about that from the two perspectives?    In the same topic, in Scala, which we say got inspired by Erlang, for the actor model, actually they don't copy memory, they don't copy data structure, but they rather share them and there are no constraints on the data structure, so it could be mutable and it could be shared. Martin Odersky, father of Scala wrote a paper about using types, be it inferred or not, type annotations for guaranteeing that the reference is not consumed concurrently. So, you can use mutable data structure, which is very nice for performance reasons, yet you get some guarantees of not having race conditions. Can you talk a little bit about that from the two perspectives?  
 +
 SPJ: First thing to say, Scala is not just a knock-off of Erlang. It's a whole sophisticated language which rather elegantly combines functional and object oriented systems, in a rather innovative and unusual way. But I think you are right - one thing you can do with Scala is implement an Erlang-like model. Once you've got an imperative system, in which you can mutate things, it is possible to use type systems to constrain exactly how you mutate them so that, for example, ownership types in object oriented languages are an example of doing this.  SPJ: First thing to say, Scala is not just a knock-off of Erlang. It's a whole sophisticated language which rather elegantly combines functional and object oriented systems, in a rather innovative and unusual way. But I think you are right - one thing you can do with Scala is implement an Erlang-like model. Once you've got an imperative system, in which you can mutate things, it is possible to use type systems to constrain exactly how you mutate them so that, for example, ownership types in object oriented languages are an example of doing this. 
  
Line 141: Line 149:
  
 SPJ: We are tackling the awkward spots. There are very detailed operational semantics given that explains that I/O happens as you go. It's no good if you've got to print the message and then read the response and then print something else. You can't save that up to the end! SPJ: We are tackling the awkward spots. There are very detailed operational semantics given that explains that I/O happens as you go. It's no good if you've got to print the message and then read the response and then print something else. You can't save that up to the end!
 +
  That takes us to a discussion about user's model. For me, as a user of Haskell, I have a mental model that everything is happening by the end. That's what the type system tells me - that everything is saved until the end.    That takes us to a discussion about user's model. For me, as a user of Haskell, I have a mental model that everything is happening by the end. That's what the type system tells me - that everything is saved until the end.  
 +
 SPJ: When you mean the user model, you mean the programmer? Not the user user? SPJ: When you mean the user model, you mean the programmer? Not the user user?
 +
  Yes. This is in sync with how things happen, but sometimes it gets out of sync. It's the same thing with when you are dealing with processors. You are sending messages, but sometimes it's maybe not that cheap to send a message and also it hits barriers of using this mental model that you established. What do you think of this problem?    Yes. This is in sync with how things happen, but sometimes it gets out of sync. It's the same thing with when you are dealing with processors. You are sending messages, but sometimes it's maybe not that cheap to send a message and also it hits barriers of using this mental model that you established. What do you think of this problem?  
 +
 SPJ: I don't think I understood the question. SPJ: I don't think I understood the question.
 +
  With any feature of the language, you define a mental model for the programmer, so that the programmer can reason about this feature. The implementation tries to get in sync with this mental model, but it's not always true. In some cases, it gets far from it. It's the same thing with processors, when you are sending messages. It's not exactly the same thing, because you need to copy or you don't need to copy. Sometimes it's not performant to do it that way, you do it another way. What do you think of this problem? The same thing with I/O, that as a programmer I think that is happening by the end, but it is actually happening on the fly, it's happening right away.    With any feature of the language, you define a mental model for the programmer, so that the programmer can reason about this feature. The implementation tries to get in sync with this mental model, but it's not always true. In some cases, it gets far from it. It's the same thing with processors, when you are sending messages. It's not exactly the same thing, because you need to copy or you don't need to copy. Sometimes it's not performant to do it that way, you do it another way. What do you think of this problem? The same thing with I/O, that as a programmer I think that is happening by the end, but it is actually happening on the fly, it's happening right away.  
 +
 SPJ: It is happening right away and by design. I think the presentation that I gave today which said the main program is an I/O action, which is gotten by stitching together other things, that's a first approximation. I've taken quite a lot of trouble to add a tutorial that explains in rather more explicit details. I mean, that model doesn't work at all for a concurrent program, for example, when you are spawning threads that have got to talk to each other, of course you aren't going to save all that up to the end.  SPJ: It is happening right away and by design. I think the presentation that I gave today which said the main program is an I/O action, which is gotten by stitching together other things, that's a first approximation. I've taken quite a lot of trouble to add a tutorial that explains in rather more explicit details. I mean, that model doesn't work at all for a concurrent program, for example, when you are spawning threads that have got to talk to each other, of course you aren't going to save all that up to the end. 
  
Line 175: Line 189:
  
 SPJ: No. But we are not talking about the cost model, right? Whereas you were talking about the understanding of what semantics of the program is. SPJ: No. But we are not talking about the cost model, right? Whereas you were talking about the understanding of what semantics of the program is.
 +
  Yes. When performance is a question, you need to think about performance. In the same sense, how much should the programmer know about what's actually happening with processors or processes? What we saw in your presentation is that you started with a quite transparent system where the programmer doesn't know on which thread things are executing, and you ended up with something very explicit saying "Your processor executed this, the other processor executed something that is similar to Erlang". What do you think?    Yes. When performance is a question, you need to think about performance. In the same sense, how much should the programmer know about what's actually happening with processors or processes? What we saw in your presentation is that you started with a quite transparent system where the programmer doesn't know on which thread things are executing, and you ended up with something very explicit saying "Your processor executed this, the other processor executed something that is similar to Erlang". What do you think?  
 +
 JA: I think when you are saying the programmer needs to think about performance, I wouldnt' say that - I'd say the programmer needs to measure the performance of the programs, because the one area where my intuition is really wrong is in guessing performance, apart from the fact that I know the input. Parsing stuff is usually the big bottleneck apart from that. When you put these, when you have virtual machines running on top of multicores with core affinities and you put virtual machines inside the virtual machines, your intuition about performance goes out of the window. JA: I think when you are saying the programmer needs to think about performance, I wouldnt' say that - I'd say the programmer needs to measure the performance of the programs, because the one area where my intuition is really wrong is in guessing performance, apart from the fact that I know the input. Parsing stuff is usually the big bottleneck apart from that. When you put these, when you have virtual machines running on top of multicores with core affinities and you put virtual machines inside the virtual machines, your intuition about performance goes out of the window.
 +
  Sometimes you give some hints to the compiler like "This is a future, this is delay" or whatever it is and sometimes you are really explicit and say "I need a process to execute this". Or, the same thing with data parallelism - I say "I want this list to be executed in several processors", so I'm very explicit about this.    Sometimes you give some hints to the compiler like "This is a future, this is delay" or whatever it is and sometimes you are really explicit and say "I need a process to execute this". Or, the same thing with data parallelism - I say "I want this list to be executed in several processors", so I'm very explicit about this.  
 +
 JA: I think that annotating your program with parallel things is very very difficult. Your intuition would probably be wrong.  JA: I think that annotating your program with parallel things is very very difficult. Your intuition would probably be wrong. 
  
  • armstrong_peyton_jones_interview.1254139809.txt.gz
  • Last modified: 2009-09-28 12:10
  • (external edit)