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

21–30 of 49 posts

Re: Simon Peyton Jones interview

#21

Post by garethrowlands »

jim-jim-jim wrote: post #10
wallscratch wrote: post #5

Earlier quoted context omitted.

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.

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.

Re: Simon Peyton Jones interview

#22

Post by garethrowlands »

parenthesis wrote: post #8
wallscratch wrote: post #5

Earlier quoted context omitted.

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.

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

Re: Simon Peyton Jones interview

#23

Post by WastingMyTime89 »

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?

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.

Re: Simon Peyton Jones interview

#24

Post by yodsanklai »

reikonomusha wrote: post #11

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

First, I'm not sure if Haskell is that popular in that space. But I'd say there's a combination of factors.

Python/C++ come with their issues and when starting a project from scratch (e.g. a blockchain), there's more flexibility in the choice of language. In the blockchain field, throwing buzzwords has proven useful to gather money and make some projects stand out (functional programming, formal verification...). Also academics love these language, so starting a project in Haskell/OCaml can get you contributions from academia, possibly some big names joining your team. And of course, strongly typed languages with a clean semantics give you more safety which is important in some fields.

Re: Simon Peyton Jones interview

#25

Post by sterlind »

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?

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.

Re: Simon Peyton Jones interview

#26

Post by sterlind »

foldr wrote: post #18
tadfisher wrote: post #9

Earlier quoted context omitted.

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…

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

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.

Re: Simon Peyton Jones interview

#27

Post by lmm »

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?

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

Re: Simon Peyton Jones interview

#29

Post by nextos »

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

In particular, compare https://github.com/hwayne/lets-prove-leftpad/blob/master/liq... to https://github.com/hwayne/lets-prove-leftpad/blob/master/daf...

For me this has been a bit of a disappointment.

Re: Simon Peyton Jones interview

#30

Post by agumonkey »

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?

almost no, if at all, state

you can unplug, replug stuff at will

Post reply on HN