Churchill College, University of Cambridge
5 HN recommenders · recommended in 8 months, 2017–2024
1:04:16 · 170K views · Apr 25, 2017
Simon Peyton Jones gives Churchill College's annual computer science lecture on Haskell's birth and evolution. He covers the most influential ideas, from laziness to monads and type system evolution, plus current developments and guesses about the future.
Recommended as a funny, accessible history of Haskell that is valuable even for people interested in language design in general.
9 comments from Hacker News
Yes, I didn't include the papers below in my parent response because, “just read these dense academic papers to understand what monads are and why Haskell has them” doesn't tend to be good advice for Haskell beginners. But learning why monads came to be included in Haskell is useful if you want to dive deeper into this stuff: Philip Wadler's original paper on Comprehending Monads [PDF]: [LINK] Philip Wadler and Simon Peyton-Jones' paper on Imperative Functional Programming [PDF]: [LINK] Simon Peyton-Jones mentions both papers and talks about why monads came to be part of Haskell in his talk on the history of Haskell here, with examples that are a little more accessible than the above papers: this video [introduction to purity and then monads starts around 30:07] It's a funny talk and it's worth watching in full, but here's a nice soundbite: “So what did we do for IO? Well, we just didn't have any. [audience laughs] So the joy of being an academic, right, is you can design a language — in 1990, I beg to inform you — that had no input/output. A Haskell program was simply a function from string to string. That was what it was. … But this was a bit embarrassing…” He goes on to talk about other ideas they explored to create effects, why they settled on monads, and why he wishes now they had called them something like “workflows” (as F# later did[1]) to make them sound less intimidating. (Simon and Philip will both be at Haskell Exchange 2019 in London this coming week if anyone else,
Unsound typesystems are not necessarily a problem, but consider the problem the other way around: given a sound typesystem, how do we improve this in such a way that a) the average Joe will understand it b) it decreases the overhead of writing the types c) the type system helps the programmer write better programs Haskells approach to this keeps the constraint of soundness: this video The whole video is very interesting even if you know nothing about Haskell, but are just interested in language design in general. To summarize the part of the video I just linked: Their approach so far has been to try and design the type system in such a way that you reduce programmer pain while not sacrificing soundness at all. It is a painful constraint for language designers, but it allows you to gradually add functionality to the type system from observing real world examples. The goal can be described as: Design a typesystem such that every working program can be typed in both a sound and correct way, while minimizing the amount of programs that can be typed, but are not working as intended.
SPJ also noted that the original success of haskell was due to their pursuit of laziness. Because laziness has no place in a system with side effects, their pursuit of laziness and functional programming is what led them to discover the usefulness of monads for describing it in the first place. If they were pursuing a strict language instead, then they were allowed to take shortcuts, because sneaking in side effects is a lot easier. YEs maybe the next haskell will be strict, but getting to the point to make that decision required laziness. SPJ made a great lecture about this. It is very easy to follow and a fun insight into the academic history of modern functional languages this video
> I'm from Microsoft and when you see Microsoft documentation it often says, you know, x y or z is a rich something, right. In this case Haskell - or ghc's version of haskell is a rich language. What does this mean? Sounds good, doesn't it? But it always means this, right. That it's a large, complex, poorly understood, ill documented thing that nobody understands completely. From a great talk by Simon Peyton Jones this video
Also, it's worth watching a bit of this talk (link at a particularly relevant time to start) because while Haskell is an "ivory-tower language," it is not _just_ an ivory tower language, and the people working on it are very much not just "a merry bunch of category theorists who had little interest in software engineering." this video This talk is seven years old btw. Caring about industry users in Haskell is not new.