Simon Peyton Jones interview
haskell.foundation
Simon Peyton Jones interview
1–10 of 49 posts
Re: Simon Peyton Jones interview
#2> 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!
Re: Simon Peyton Jones interview
#3Around 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”
Re: Simon Peyton Jones interview
#4Around 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 appealin…
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.
Re: Simon Peyton Jones interview
#5Around 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 appealin…
Could someone explain why refactoring is so much easier in functional languages?
Re: Simon Peyton Jones interview
#6Around 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 appealin…
This is definitely my experience with the language, but mostly 'cause it's statically typed and compiled. I get a similar experience in Rust.
Re: Simon Peyton Jones interview
#7Around 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 appealin…
Could someone explain why refactoring is so much easier in functional languages?
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.
Re: Simon Peyton Jones interview
#8Around 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 appealin…
Could someone explain why refactoring is so much easier in functional languages?
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.
Re: Simon Peyton Jones interview
#9Around 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 appealin…
Could someone explain why refactoring is so much easier in functional languages?
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.
Re: Simon Peyton Jones interview
#10Around 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 appealin…
Could someone explain why refactoring is so much easier in functional languages?
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.