6 ms·

Simon Peyton Jones interview

166 points by gbrown_ 4y ago

xwowsersx 4y ago
> JB: So is it refreshing to to work on an implementation of a language from scratch after having worked on this 20-30 years old codebase in GHC and all this big beast where you can’t just redo everything from scratch? > SPJ: It’s a very different prospectus because in this case Verse is a pretty well-formed beast in Tim’s head. If we want to do something different we’re going to have to persuade him but I’m fine with that, right? But the dynamic is that he’s a sort of technical lead on the project – which is very unusual for the CEO of a multibillion dollar company and actually quite rewarding. Quite unusual and very cool!
melling 4y ago
Around 7:50 in Jones says this: “So, one of the great things about Haskell actually, that is spoken about and I think it’s the sort of killer app for Haskell, is that it’s so refactorable, right? You can do a heart or lung transplant on GHC and make truly major changes and the type checker just guides you to do all the right things.” Freely refactoring the code with worrying about unit tests, etc seems quite appealing. To summarize the killer app for Haskell is that “it’s so refactorable”
- WraithM 4y ago
  We use Haskell at Bitnomial, and I can confirm that this is in fact the case. We've been able to incorporate new complex knowledge quickly in a way that most other languages would have more trouble with. Refactoring is a secret weapon for Haskell.
- wallscratch 4y ago
  Could someone explain why refactoring is so much easier in functional languages?
  - fprotthetarball 4y ago
    Type systems of functional languages are generally capable of representing more. You can have the type system validate application state at compile time for you, for example. If it compiled before and worked and your refactored version also compiles, chances are you didn't break anything.
    - fho 4y ago
      > If it compiled before and worked and your refactored version also compiles, chances are you didn't break anything. And I would say that if somebody never worked with Haskell (or some other language with a strong type system like Idris) they can bit fantom what is possible to encode in the type system.
  - parenthesis 4y ago
    Because it is more difficult to make a change that affects other code without a change in types occurring, which will make compilation fail until all affected code is updated.
    - garethrowlands 4y ago
      Though Haskell has the option to defer type errors to runtime, making them just warnings at compile time. It means you can run your unit tests without having to change everything everywhere all at once. The flag is -fdefer-type-errors
  - tadfisher 4y ago
    I don't think it's a universal property of functional languages. Haskell is also strongly (excessively) typed, down to the level of modeling computation itself, and it's lazy. See, when you are defining a Haskell program, you are conceptually creating a tree of thunks that eventually get executed by the GHC runtime. Those thunks are typed, meaning they have typed inputs and outputs, and are either side-effect-free or are defined in a context that controls their side effects (e.g. the IO monad). So you can change the definition of types willy-nilly and either get a working compiled program or some error output that tells you exactly what is broken or doesn't make sense to GHC's model of your proposed computation. Because computation itself is typed, you have a stronger guarantee that it will work as expected when executed by the GHC runtime. Because side effects are controlled, you are forced by the type checker to handle runtime errors (or crash). At least that's how I understand it as someone who works with gifted Haskell engineers, but exists very much on the periphery of understanding.
    - foldr 4y ago
      > Because side effects are controlled, you are forced by the type checker to handle runtime errors (or crash). This is generally true in idiomatic Haskell code, but in fact even pure functions in Haskell can throw runtime exceptions, and you are not forced to handle these.
      - sterlind 4y ago
        correct me if I'm wrong, but can't you add a compiler flag to prohibit using functions that can panic like "error" and "head"? aside from that, you'd just need to worry about OOMs and faults in native code.
        massysett 4y ago
        I guess that would be nice, but no, I’ve never heard of anything like that. “error” is simply bottom. Bottom is an inhabitant of every Haskell type. There’s no straightforward way to just turn it off.
  - jim-jim-jim 4y ago
    One practical example: if you have a union of A|B, and you decide to add a third shape C to it, your program won't compile until logic for C is written in all the places where A and B are already being matched against. Refactoring often means changing data models, then letting the errors walk you through the actual implementation details.
    - garethrowlands 4y ago
      Yeah that's how it's supposed to work. Historically, Haskell didn't always make incomplete patterns an error, even now the checker isn't perfect, and even if it was people can still put wildcard patterns.
  - WastingMyTime89 4y ago
    It’s mostly the type system. Ocaml is the same. Static typing, type inference and the easiness of introducing complex types really help when it comes to fitting the code together. Beginners tend to think that "if it compiles it works" and it feels that way sometimes but you lose the hubris once you are bitten by a bug complicated enough to pass though.
  - sterlind 4y ago
    In addition to the type system, I'd also add purity. If you have a function f :: a -> b, there is literally no way for f to read anything besides a, or affect anything besides returning b (aside from unsafePerformIO, which you can ban from your code.) so if you want to refactor f, you know exactly from the call site everything that needs to be updated. all state is factored, so it can easily be refactored.
  - lmm 4y ago
    A functional language is fundamentally one where the same inputs always produce the same outputs. So you can e.g. change the order of two function calls and be confident that that's not going to change the behaviour, without even running it. In a language with pervasive state mutation, essentially any change you make to the code might change what the program does, so you have to test every little thing. https://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html https://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAb...
  - agumonkey 4y ago
    almost no, if at all, state you can unplug, replug stuff at will
  - goto11 4y ago
    Perhaps it is easier because Peyton Jones is a world class expert in Haskell and have 30 years experience refactoring it? In my experience the ease of refactoring is more depending on the quality of the code you are refactoring than the language. That said, a strong type system helps avoiding stupid mistakes and Haskell have a very strong type system.
    - fho 4y ago
      I guess it is a bit if both. You can of course write fast and loose Haskell code, but best practices will probably prevent you from doing that.
  - jeofken 4y ago
    With mutable state every function has an implicit dependency on other stuff. Without mutable state your function depends on its arguments, and produces only a return value. No moving parts or implicit dependencies = you can cut and paste stuff around the code base like there is no tomorrow.
- ploppyploppy 4y ago
  This is definitely my experience with the language, but mostly 'cause it's statically typed and compiled. I get a similar experience in Rust.
- chrisseaton 4y ago
  > You can do a heart or lung transplant on GHC and make truly major changes and the type checker just guides you to do all the right things. I thought GHC was famously a nightmare to work in? > GHC is not exemplary of good large scale system design in a pure function language. Rather ironically, it violates the properties that draw people to functional programming in the first place: immutability, modularity, and composability > many new features have been force-fitted into the existing code without proper redesign > While the current design isn’t glorious, it works https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf
  - parminya 4y ago
    I guess that's two different things. One person says "You can give GHC a heart transplant" and the other says "GHC needs a heart transplant: Here is our proposal". In fact, the very text you quote as saying GHC was famously a nightmare says: > On the bright side, GHC is written in Haskell, and this language is particularly well suited to performing massive refactorings with confidence that nothing breaks. Thus, it should be possible to refactor the GHC library towards a more robust and versatile design and in fact Simon Peyton Jones continued by saying exactly that: > You can do a heart or lung transplant on GHC and make truly major changes and the type checker just guides you to do all the right things. The difficult stuff is envisioning and being very clear about what you’re trying to do. Actually doing it is often not that hard. So the two texts and the two opinions are completely in alignment. GHC is famously bad insofar as it has a poor design. But once a better design is designed, you can give it the heart transplant it needs without excess stress. I have no idea how the heart transplant proposed by Sylvain Henry, John Ericson and Jeffrey M. Young is going. I suppose at some point there should be something checked in and a report about how painful or painless it was (and, potentially, if it's really completely wrong, perhaps a series of bug reports in the next seven releases of GHC).
    - chrisseaton 4y ago
      I guess I wonder if it's easy to refactor then why haven't people done it when they added things in the past?
- rurban 4y ago
  > You can do a heart or lung transplant on GHC and make truly major changes and the type checker just guides you to do all the right things. This only tells that SPJ never had to work in hard realtime nor kernels. GHC code throws and doesn't help in violating latency bounds. Not at all. For such tasks we do have much better systems, without GC.
reikonomusha 4y ago
Why is Haskell, a comparatively obscure language (to Python, C++, etc.), so popular with topics in the orbit of "web3" (blockchain, crypto, metaverse, etc.)?
- nequo 4y ago
  The usual argument is that purity and the type system help you write correct code and finance is a domain where correctness is important. The applications I’ve heard for Idris also have to do with finance (although not blockchain stuff).
  - reikonomusha 4y ago
    Part of my confusion is also the social/community aspect, especially with Haskell hackers' frequent and negative attitude toward the enterprise, like Stephen Diehl who has become a sort of spokesperson for the "web3 is a farce (and worse)" narrative. It seems like such a stark juxtaposition, especially with SPJ and Lennart Augustsson, two research giants of the community, taking part in it in a serious capacity. (To be abundantly clear and uncontroversial, as it pertains to this comment, I'm not interested in discussing "is web3/metaverse {good,bad}", but rather in discussing the purely functional programming community-of-community's interests or anti-interests in it.)
    - eointierney 4y ago
      I reckon SPJ is sufficiently "researchy" that it doesn't really matter how it's applied, it's the research that matters. Also, he seems perpetually delighted that he gets to do what he does, and is paid to do so. He's one of my heroes, long may he lang
- Zababa 4y ago
  OCaml also has some of that, with Tezos, and Rust with Solana. I think it's because functional languages are thought as producing safer code, which is important in this industry.
- Mikeb85 4y ago
nextos 4y ago
It's interesting he discusses Liquid Haskell (proofs via refinement types) extensively: "So, for me, that’s as far as increasing our ability to give you statically guaranteed theorems about Haskell programs. My money’s on Liquid Haskell at the moment and I hope that we the Haskell community" My experience is that other refinement type systems are way less complex. See: https://github.com/hwayne/lets-prove-leftpad https://github.com/hwayne/lets-prove-leftpad In particular, compare https://github.com/hwayne/lets-prove-leftpad/blob/master/liquidhaskell/LeftPad.hs https://github.com/hwayne/lets-prove-leftpad/blob/master/liq... to https://github.com/hwayne/lets-prove-leftpad/blob/master/dafny/Leftpad.dfy https://github.com/hwayne/lets-prove-leftpad/blob/master/daf... For me this has been a bit of a disappointment.
danielscrubs 4y ago
Any tips on other professors like SPJ? He seems like a super human even after the 10 years Ive followed him. Never angry, always happy, always engaged, always teaching things with depth, not dumbing things down to make it easier, not pandering…
- nequo 4y ago
  Most academics don’t have as many interviews and talks uploaded with them as SPJ but check out Stephanie Weirich’s Strange Loop talk[1] and interview on Corecursive.[2] [1] https://youtube.com/watch?v=wNa3MMbhwS4 https://youtube.com/watch?v=wNa3MMbhwS4 [2] https://corecursive.com/015-dependant-types-in-haskell-with-stephanie-weirich/ https://corecursive.com/015-dependant-types-in-haskell-with-...

166 points by gbrown_ 4y ago

> JB: So is it refreshing to to work on an implementation of a language from scratch after having worked on this 20-30 years old codebase in GHC and all this big beast where you can’t just redo everything from scratch? > SPJ: It’s a very different prospectus because in this case Verse is a pretty well-formed beast in Tim’s head. If we want to do something different we’re going to have to persuade him but I’m fine with that, right? But the dynamic is that he’s a sort of technical lead on the project – which is very unusual for the CEO of a multibillion dollar company and actually quite rewarding. Quite unusual and very cool!

melling 4y ago

Around 7:50 in Jones says this: “So, one of the great things about Haskell actually, that is spoken about and I think it’s the sort of killer app for Haskell, is that it’s so refactorable, right? You can do a heart or lung transplant on GHC and make truly major changes and the type checker just guides you to do all the right things.” Freely refactoring the code with worrying about unit tests, etc seems quite appealing. To summarize the killer app for Haskell is that “it’s so refactorable”

WraithM 4y ago
We use Haskell at Bitnomial, and I can confirm that this is in fact the case. We've been able to incorporate new complex knowledge quickly in a way that most other languages would have more trouble with. Refactoring is a secret weapon for Haskell.
wallscratch 4y ago
Could someone explain why refactoring is so much easier in functional languages?
- fprotthetarball 4y ago
  Type systems of functional languages are generally capable of representing more. You can have the type system validate application state at compile time for you, for example. If it compiled before and worked and your refactored version also compiles, chances are you didn't break anything.
  - fho 4y ago
    > If it compiled before and worked and your refactored version also compiles, chances are you didn't break anything. And I would say that if somebody never worked with Haskell (or some other language with a strong type system like Idris) they can bit fantom what is possible to encode in the type system.
- parenthesis 4y ago
  Because it is more difficult to make a change that affects other code without a change in types occurring, which will make compilation fail until all affected code is updated.
  - garethrowlands 4y ago
    Though Haskell has the option to defer type errors to runtime, making them just warnings at compile time. It means you can run your unit tests without having to change everything everywhere all at once. The flag is -fdefer-type-errors
- tadfisher 4y ago
  I don't think it's a universal property of functional languages. Haskell is also strongly (excessively) typed, down to the level of modeling computation itself, and it's lazy. See, when you are defining a Haskell program, you are conceptually creating a tree of thunks that eventually get executed by the GHC runtime. Those thunks are typed, meaning they have typed inputs and outputs, and are either side-effect-free or are defined in a context that controls their side effects (e.g. the IO monad). So you can change the definition of types willy-nilly and either get a working compiled program or some error output that tells you exactly what is broken or doesn't make sense to GHC's model of your proposed computation. Because computation itself is typed, you have a stronger guarantee that it will work as expected when executed by the GHC runtime. Because side effects are controlled, you are forced by the type checker to handle runtime errors (or crash). At least that's how I understand it as someone who works with gifted Haskell engineers, but exists very much on the periphery of understanding.
  - foldr 4y ago
    > Because side effects are controlled, you are forced by the type checker to handle runtime errors (or crash). This is generally true in idiomatic Haskell code, but in fact even pure functions in Haskell can throw runtime exceptions, and you are not forced to handle these.
    - sterlind 4y ago
      correct me if I'm wrong, but can't you add a compiler flag to prohibit using functions that can panic like "error" and "head"? aside from that, you'd just need to worry about OOMs and faults in native code.
      - massysett 4y ago
        I guess that would be nice, but no, I’ve never heard of anything like that. “error” is simply bottom. Bottom is an inhabitant of every Haskell type. There’s no straightforward way to just turn it off.
- jim-jim-jim 4y ago
  One practical example: if you have a union of A|B, and you decide to add a third shape C to it, your program won't compile until logic for C is written in all the places where A and B are already being matched against. Refactoring often means changing data models, then letting the errors walk you through the actual implementation details.
  - garethrowlands 4y ago
    Yeah that's how it's supposed to work. Historically, Haskell didn't always make incomplete patterns an error, even now the checker isn't perfect, and even if it was people can still put wildcard patterns.
- WastingMyTime89 4y ago
  It’s mostly the type system. Ocaml is the same. Static typing, type inference and the easiness of introducing complex types really help when it comes to fitting the code together. Beginners tend to think that "if it compiles it works" and it feels that way sometimes but you lose the hubris once you are bitten by a bug complicated enough to pass though.
- sterlind 4y ago
  In addition to the type system, I'd also add purity. If you have a function f :: a -> b, there is literally no way for f to read anything besides a, or affect anything besides returning b (aside from unsafePerformIO, which you can ban from your code.) so if you want to refactor f, you know exactly from the call site everything that needs to be updated. all state is factored, so it can easily be refactored.
- lmm 4y ago
  A functional language is fundamentally one where the same inputs always produce the same outputs. So you can e.g. change the order of two function calls and be confident that that's not going to change the behaviour, without even running it. In a language with pervasive state mutation, essentially any change you make to the code might change what the program does, so you have to test every little thing. https://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html https://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAb...
- agumonkey 4y ago
  almost no, if at all, state you can unplug, replug stuff at will
- goto11 4y ago
  Perhaps it is easier because Peyton Jones is a world class expert in Haskell and have 30 years experience refactoring it? In my experience the ease of refactoring is more depending on the quality of the code you are refactoring than the language. That said, a strong type system helps avoiding stupid mistakes and Haskell have a very strong type system.
  - fho 4y ago
    I guess it is a bit if both. You can of course write fast and loose Haskell code, but best practices will probably prevent you from doing that.
- jeofken 4y ago
  With mutable state every function has an implicit dependency on other stuff. Without mutable state your function depends on its arguments, and produces only a return value. No moving parts or implicit dependencies = you can cut and paste stuff around the code base like there is no tomorrow.
ploppyploppy 4y ago
This is definitely my experience with the language, but mostly 'cause it's statically typed and compiled. I get a similar experience in Rust.
chrisseaton 4y ago
> You can do a heart or lung transplant on GHC and make truly major changes and the type checker just guides you to do all the right things. I thought GHC was famously a nightmare to work in? > GHC is not exemplary of good large scale system design in a pure function language. Rather ironically, it violates the properties that draw people to functional programming in the first place: immutability, modularity, and composability > many new features have been force-fitted into the existing code without proper redesign > While the current design isn’t glorious, it works https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf
- parminya 4y ago
  I guess that's two different things. One person says "You can give GHC a heart transplant" and the other says "GHC needs a heart transplant: Here is our proposal". In fact, the very text you quote as saying GHC was famously a nightmare says: > On the bright side, GHC is written in Haskell, and this language is particularly well suited to performing massive refactorings with confidence that nothing breaks. Thus, it should be possible to refactor the GHC library towards a more robust and versatile design and in fact Simon Peyton Jones continued by saying exactly that: > You can do a heart or lung transplant on GHC and make truly major changes and the type checker just guides you to do all the right things. The difficult stuff is envisioning and being very clear about what you’re trying to do. Actually doing it is often not that hard. So the two texts and the two opinions are completely in alignment. GHC is famously bad insofar as it has a poor design. But once a better design is designed, you can give it the heart transplant it needs without excess stress. I have no idea how the heart transplant proposed by Sylvain Henry, John Ericson and Jeffrey M. Young is going. I suppose at some point there should be something checked in and a report about how painful or painless it was (and, potentially, if it's really completely wrong, perhaps a series of bug reports in the next seven releases of GHC).
  - chrisseaton 4y ago
    I guess I wonder if it's easy to refactor then why haven't people done it when they added things in the past?
rurban 4y ago
> You can do a heart or lung transplant on GHC and make truly major changes and the type checker just guides you to do all the right things. This only tells that SPJ never had to work in hard realtime nor kernels. GHC code throws and doesn't help in violating latency bounds. Not at all. For such tasks we do have much better systems, without GC.

reikonomusha 4y ago

Why is Haskell, a comparatively obscure language (to Python, C++, etc.), so popular with topics in the orbit of "web3" (blockchain, crypto, metaverse, etc.)?

nequo 4y ago
The usual argument is that purity and the type system help you write correct code and finance is a domain where correctness is important. The applications I’ve heard for Idris also have to do with finance (although not blockchain stuff).
- reikonomusha 4y ago
  Part of my confusion is also the social/community aspect, especially with Haskell hackers' frequent and negative attitude toward the enterprise, like Stephen Diehl who has become a sort of spokesperson for the "web3 is a farce (and worse)" narrative. It seems like such a stark juxtaposition, especially with SPJ and Lennart Augustsson, two research giants of the community, taking part in it in a serious capacity. (To be abundantly clear and uncontroversial, as it pertains to this comment, I'm not interested in discussing "is web3/metaverse {good,bad}", but rather in discussing the purely functional programming community-of-community's interests or anti-interests in it.)
  - eointierney 4y ago
    I reckon SPJ is sufficiently "researchy" that it doesn't really matter how it's applied, it's the research that matters. Also, he seems perpetually delighted that he gets to do what he does, and is paid to do so. He's one of my heroes, long may he lang
Zababa 4y ago
OCaml also has some of that, with Tezos, and Rust with Solana. I think it's because functional languages are thought as producing safer code, which is important in this industry.
Mikeb85 4y ago

nextos 4y ago

It's interesting he discusses Liquid Haskell (proofs via refinement types) extensively: "So, for me, that’s as far as increasing our ability to give you statically guaranteed theorems about Haskell programs. My money’s on Liquid Haskell at the moment and I hope that we the Haskell community" My experience is that other refinement type systems are way less complex. See: https://github.com/hwayne/lets-prove-leftpad https://github.com/hwayne/lets-prove-leftpad In particular, compare https://github.com/hwayne/lets-prove-leftpad/blob/master/liquidhaskell/LeftPad.hs https://github.com/hwayne/lets-prove-leftpad/blob/master/liq... to https://github.com/hwayne/lets-prove-leftpad/blob/master/dafny/Leftpad.dfy https://github.com/hwayne/lets-prove-leftpad/blob/master/daf... For me this has been a bit of a disappointment.

danielscrubs 4y ago

Any tips on other professors like SPJ? He seems like a super human even after the 10 years Ive followed him. Never angry, always happy, always engaged, always teaching things with depth, not dumbing things down to make it easier, not pandering…

nequo 4y ago
Most academics don’t have as many interviews and talks uploaded with them as SPJ but check out Stephanie Weirich’s Strange Loop talk[1] and interview on Corecursive.[2] [1] https://youtube.com/watch?v=wNa3MMbhwS4 https://youtube.com/watch?v=wNa3MMbhwS4 [2] https://corecursive.com/015-dependant-types-in-haskell-with-stephanie-weirich/ https://corecursive.com/015-dependant-types-in-haskell-with-...