[HN Gopher] Simon Peyton Jones interview
___________________________________________________________________
Simon Peyton Jones interview
Author : gbrown_
Score : 132 points
Date : 2022-10-16 12:12 UTC (10 hours ago)
(HTM) web link (haskell.foundation)
(TXT) w3m dump (haskell.foundation)
| reikonomusha wrote:
| Why is Haskell, a comparatively obscure language (to Python, C++,
| etc.), so popular with topics in the orbit of "web3" (blockchain,
| crypto, metaverse, etc.)?
| Zababa wrote:
| 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.
| [deleted]
| nequo wrote:
| 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 wrote:
| 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 wrote:
| 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
| Mikeb85 wrote:
| Functional programming lends itself well to finance through
| correctness and also the fact everything you do is basically
| data in -> data out. Versus other domains where using stateful
| objects to model things is easier.
| yodsanklai wrote:
| 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.
| nextos wrote:
| 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.
| xwowsersx wrote:
| > 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 wrote:
| 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"
| ploppyploppy wrote:
| 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 wrote:
| > 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
| parminya wrote:
| 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 wrote:
| I guess I wonder if it's easy to refactor then why haven't
| people done it when they added things in the past?
| parminya wrote:
| I don't know. But - and this is my interpretation, not
| some summary of another talk - it sounds like Simon
| Peyton Jones, who is one of the people who are
| responsible for the poor state of the code, already
| answered that: "The difficult stuff is envisioning and
| being very clear about what you're trying to do."
| Presumably, wherever his skills lie, they don't lie in
| envisioning a better state and refactoring the code
| towards that goal (to him, it was "difficult stuff", and
| left aside as he implemented changes that had a greater
| impact on its users). Afaik, for a long time GHC was
| maintained by the same two or three people so it probably
| shows the imprint of individual developers much more than
| your average compiler of similar size. Now development is
| much more open and this kind of technical debt is getting
| paid off.
| WraithM wrote:
| 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 wrote:
| Could someone explain why refactoring is so much easier in
| functional languages?
| jim-jim-jim wrote:
| 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 wrote:
| 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.
| lmm wrote:
| 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. htt
| ps://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAb...
| fprotthetarball wrote:
| 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.
| parenthesis wrote:
| 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 wrote:
| 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
| agumonkey wrote:
| almost no, if at all, state
|
| you can unplug, replug stuff at will
| tadfisher wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| WastingMyTime89 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2022-10-16 23:00 UTC)