Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simon Peyton Jones interview

haskell.foundation

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Simon Peyton Jones interview

#41

Post by fho »

fprotthetarball wrote: post #7
wallscratch wrote: post #5

Earlier quoted context omitted.

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.

> 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.

Re: Simon Peyton Jones interview

#42

Post by jeofken »

wallscratch wrote: post #5
melling wrote: post #3

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 appealin…

Could someone explain why refactoring is so much easier in functional languages?

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.

Re: Simon Peyton Jones interview

#43

Post by renox »

massysett wrote: post #33
sterlind wrote: post #26

Earlier quoted context omitted.

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.

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.

Looks like the null-pointer mistake no?

Re: Simon Peyton Jones interview

#44

Post by nequo »

danielscrubs wrote: post #34

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…

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

[2] https://corecursive.com/015-dependant-types-in-haskell-with-...

Re: Simon Peyton Jones interview

#45

Post by tome »

doyougnu wrote: post #36
parminya wrote: post #15

Earlier quoted context omitted.

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 sh…

Hi coauthor here! Work has been steady the master project plan is tracked in this ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/17957 Almost all the recent work has been performed by Dominik Peteler (@mmhat) during Google summer of code, which John supervised. We've primarily been focused on landing !8341[0] which makes huge strides in Core w.r.t. modularity (see https://gitlab.haskell.org/ghc/ghc/-/issues/2187…

Thanks! This work is truly fantastic.

Re: Simon Peyton Jones interview

#46

Post by rurban »

melling wrote: post #3

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 appealin…

> 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.

Re: Simon Peyton Jones interview

#47

Post by foldr »

renox wrote: post #43
massysett wrote: post #33

Earlier quoted context omitted.

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.

Looks like the null-pointer mistake no?

Bottom has to be a member of every type because functions aren't guaranteed to terminate, so there's no really any way around that within the confines of a general purpose programming language.

That admittedly doesn't entail that Haskell ought to have special functions like 'error' that invite the programmer to explicitly introduce bottom values as a mechanism of signaling errors. However, in the real world, executing any function may raise an exceptional condition at any time (e.g. an out of memory error), regardless of programming language.

Re: Simon Peyton Jones interview

#48

Post by renox »

foldr wrote: post #47
renox wrote: post #43

Earlier quoted context omitted.

Looks like the null-pointer mistake no?

Bottom has to be a member of every type because functions aren't guaranteed to terminate, so there's no really any way around that within the confines of a general purpose programming language. That admittedly doesn't entail that Haskell ought to have special functions like 'error' that invite the programmer to explicitly introduce bottom values as a mechanism of signaling errors. However, in the real world, executin…

> Bottom has to be a member of every type because functions aren't guaranteed to terminate,

I don't understand: if the function you called doesn't terminate then you're blocked so I don't see why this should impact the types..

Re: Simon Peyton Jones interview

#49

Post by foldr »

renox wrote: post #48
foldr wrote: post #47

Earlier quoted context omitted.

Bottom has to be a member of every type because functions aren't guaranteed to terminate, so there's no really any way around that within the confines of a general purpose programming language. That admittedly doesn't entail that Haskell ought to have special functions like 'error' that invite the programmer to explicitly introduce bottom values as a mechanism of signaling errors. However, in the real world, executin…

> Bottom has to be a member of every type because functions aren't guaranteed to terminate, I don't understand: if the function you called doesn't terminate then you're blocked so I don't see why this should impact the types..

More info here: https://wiki.haskell.org/Bottom As bottom is the value of a non-terminating computation and a computation of any type may fail to terminate, bottom must inhabit all types. The same goes for 'error'. Although in real world Haskell code (using GHC) you can trap error values if you really want to, so 'error' isn't in fact indistinguishable from non-termination.
Post reply on HN