Co-Creator of Haskell: Functional Programming, Thinking in Types, Useless Languages | Simon Jones

Simon Peyton Jones is the co-creator of Haskell (pure functional programming language) and I interviewed him about functional programming, why it matters, and his thoughts on other programming languages. • My ergonomic keyboard project I mentioned, you can follow along here: https://read.compose.llc/ Podcast links: • YouTube: https://youtu.be/xcB_LF3cdqw • Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835 • Transcript: https://www.developing.dev/p/co-creator-of-haskell-functional Thank you to this episode's sponsor for supporting my work: • WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com/ Timestamps: (00:00) Intro (00:39) What functional programming is (09:18) Downsides of functional programming (10:53) Specialized hardware for functional programming (21:47) Haskell is useless (25:59) Rust vs C (28:26) Haskell vs OCaml (35:26) Side effects in Haskell (44:26) Type systems (57:30) How the Haskell compiler works (01:04:35) Why Haskell is talked about more than used (01:09:07) Avoiding success at all costs (01:11:12) LLMs and programming languages (01:13:57) New programming language design (01:15:59) Should students continue to learn programming (01:22:33) Why Excel is his 2nd favorite programming language (01:25:04) Advice for his younger self Where to find Simon: • LinkedIn: https://www.linkedin.com/in/simonpj/ • Wikipedia: https://en.wikipedia.org/wiki/Simon_Peyton_Jones • Personal Website: https://simon.peytonjones.org/ Where to find Ryan: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman • TikTok: https://www.tiktok.com/@ryanlpeterman Referenced in this episode: • Haskell is useless: https://www.youtube.com/watch?v=iSmkqocn0oQ • John Backus Turing Award lecture: https://worrydream.com/refs/Backus_1978_-_Can_Programming_Be_Liberated_from_the_von_Neumann_Style.pdf • Why functional programming matters: https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf • Excel is his 2nd favorite programming language: https://www.youtube.com/watch?v=_M4P5M85KO8

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  Why is the internet so insecure? Primarily because all of our software infrastructure is written in unsafe languages.

• 0:06Ryan Peterman?

  This is Simon Peyton Jones, co-creator of the functional programming language Haskell, and I asked them all about programming language design.

• 0:14Speaker 00

  If we rewrote all of our software infrastructure in Rust, things would be way, way better. I think that statically typed languages are a huge boon for LLMs. I do large-scale systematic refactoring fearlessly because the type system keeps me safe, in fact.

• 0:31Ryan Peterman?

  Would you recommend people learn how to program today?

• 0:35Speaker 00

  I think people are right to be worried in the sense that I think there's going to be considerable dislocation.

• 0:39Ryan Peterman?

  Here's the full episode.

• 0:45Ryan Peterman?

  I wanted to start by asking you, what is functional programming in your words? And why does it matter to people who might use the other languages, the imperative languages?

• 0:57Speaker 00

  Functional programming is about programming with values instead of mutation. So in a conventional imperative programming, computation proceeds by, like if I want to add up the numbers between 1 and 100, I have a mutable cell containing a running total. And then, as computation proceeds, I keep adding, you know, I keep adding to my running total. So there's a cell that changes its value over time. Computation proceeds step by step. There's a program counter. Now, that's very unlike mathematics. If I say 3 plus 4 times 7, you don't think of a mutable cell that changes its value over time. You think, well, 3 plus 4 is 7, 7 times 7 is 49, and just the answer is 49. So in a sense, it's more declarative than imperative.

• 1:42Speaker 00

  Another way to think of it is it's more like what a spreadsheet does. In a spreadsheet formula, if you put in a cell, you'd say, in A1, you put the formula equals A2 times A3 plus 7. Well, then, that's just the formula that is evaluated. And you expect to compute the values of A2 and A3 automatically before computing A1. It wouldn't make any sense to compute A1 from the old values of A2 and A3, right? So, and there's no notion of a program counter. There's no notion of do this and then do that. It wouldn't be sensible to say equals print x plus 3. Because who knows when or even whether that formula will ever be evaluated?

• 2:23Speaker 00

  Now, the surprise is that it is possible to do useful things in such a limited language. When I would learn programming, I learnt it by writing machine code in which the fundamental mode of computation is registers and program counters, and mutation of registers as you go along, and memory. Like, computation and mutation seem to be inextricably interwoven, right? That's how computation gets done. So it was a surprise to me when I learnt that, well, it is possible to do useful things with functional programs. I still remember that amazing revelation.

• 2:59Speaker 00

  Now, in fact, one way to look at it is this: right back in the late 1920s, early 1930s, Alan Turing was doing a PhD in Princeton under the supervision of Alonso Church. Now, Alan Turing, as we all know, invented the Turing machine, which is fundamentally about mutation, right? It has a little tape, and you can read things from the tape, and then you write back new things onto the tape, and it has an immutable program. Now, Alonso Church, at the very same time, was working on something he called the lambda calculus, in which there's no motion of mutation. This is, the lambda calculus is like the essence of functional programming.

• 3:42Speaker 00

  Programs execute just by reduction. Now, so these were two different models of computation. You might ask, what can you compute with a Turing machine, and what can compute with a lambda term? And the astonishing thing that turned out, which is completely non-obvious, is that anything you compute with a lambda term, you can compute with a Turing machine, and anything you compute with a Turing machine, you can compute with lambda calculus. So that means that the two are identical from the point of view of their computational power. Big surprise to me. Okay, so they're equally powerful, and then the question is, which might you want to choose? As I say, I started life from my baseline of imperative programming.

• 4:24Speaker 00

  Of course, that's the way you write programs, and functional programming is a kind of weird, anomalous, rather nerdy academic thing, but...

• 4:34Speaker 00

  I became hooked on the idea that by excluding side effects by default, that is imperative programming has side effects by default, by excluding side effects by default, we could make programs that are easier to write, easier to maintain, easier to reason about. And then the question is,

• 4:52Speaker 00

  what are the practical obstacles? Is it slower? Is it less convenient and so forth? So in effect, I've devoted my research life to exploring that hypothesis. The wonderful thing about being a researcher is you can take something which at the time, this is back in 1980, back in 1980, functional programming was very nerdy, geeky academic. But I was allowed to spend my professional life just saying, what would happen if you took that one idea, programming with values, and just ran with it? Where would you get? And I think we've got somebody somewhere pretty interesting. I don't want to say that it's better fundamentally, because after all, Haskell on that journey, started with functional programming, then we learnt how to mix functional imperative programming together

• 5:37Speaker 00

  in a way that we might talk about later, right? So it's not really an either or, it's more of a both and in the end. But my position now is, as I often say, when the limestone of imperative programming is worn away, the granite of functional programming will be revealed underneath.

• 5:57Ryan Peterman?

  And why do you say that?

• 5:59Speaker 00

  Well, functional programming is the language of mathematics. Right, that's how we fundamentally think about things when we want to be formal. Indeed, if we want to reason about and say, what does this imperative program do? We have to wheel out a lot of mathematics and, you know, whole triples and so forth. But that's all in the world of maths, which is just functional programming. Functional programming is just mathematics brought to life and made executable. So you might wonder, I suppose you may be saying, well, isn't imperative programming just enough? And I think that...

• 6:35Speaker 00

  There you have to have to

• 6:38Speaker 00

  just look at the broad sweep of things. I think what's happened is that from the world of functional programming, lots of ideas have got adopted into the imperative arena, right? So they grew up over here in functional programming. And then they have been adopted by the imperative programming thing. So you might think garbage collection, you might think lambda's, you might think language integrated query, you might think about lots about type systems, polymorphism and static typing, tons of that. So at least it has been an intellectually interesting experiment that has been a very fertile laboratory in which the grow up ideas that can infect the mainstream. Now, my instinct now is that we should start from functional programming and do imperative

• 7:22Speaker 00

  programming where necessary. I think probably the mainstream is we should start with imperative programming and sort of add bits of functional programming where possible. But and I'm not going to say that they're wrong to do that, just to say that I think there's a pretty interesting dialogue. Now, you have to do have to think very differently about the act of programming, right? You do have to rewire your brain quite a bit. But just let me, this is something we might want to come back to. I said easier to maintain. As programs get old, think of a 10-year-old program. If you have a piece of 10-year-old code written by somebody who's long since left your company that mutates some more or less global variables, then you might a little

• 8:04Speaker 00

  be a little bit afraid about, oh, and there's other bits of code scattered about that also read or write those those global variables, then you might be a little cautious about making modifications, right? Lest, oh, if I put these two things, if I do B and then A instead of A and then B, maybe, you know, the global variable that I read in read somewhere deep inside the code is now not have the value that it was expected to. So, reading and writing shared variables that are visible, you know, outside the scope, sort of somewhat global variables, is a form of coupling between bits of code that is very invisible, right? Very invisible. So functional programming forces that to become visible. It forces it into the open.

• 8:49Speaker 00

  And by the act of forcing it into the open, that strongly encourages a style of programming, which you don't have such interactions because they are painful to manage. So it encourages a style in which programs execute in modular boxes without interacting. Now, every imperative programmer would want to do that. But I want them to do that in a provably secure way. So you can know that these programs don't interact, rather than just say, I've done my best.

• 9:19Ryan Peterman?

  Then I guess on the flip side then, what are the downsides of functional programming language?

• 9:25Speaker 00

  Oh, well, it can be very tasking and inconvenient, right? So you're somewhere deep in the, you know, a subroutine of a subroutine of a subroutine of a software stack, and you want to reach out and, I don't know, grab the time of day.

• 9:40Speaker 00

  Oh dear, that's a side effect. But we're in a pure functional language, the time of, and indeed, there's a good reason because everybody higher in the stack is assuming that if I call this function apply to, you know, seven, it will give me the same answer if I call it again apply to seven. But if it could interrogate the time of day, suddenly it might give a different answer. Right? So as simple a thing as asking for the time of day invalidates a whole set of assumptions and so is not by default allowed at all. And that can be inconvenient because all you say, look, guys, all I want to do is get hold of the time of day, don't give me grief. And so every functional programming language, including Haskell, provides you with a little trapdoor. Haskell's is called unsafe perform I O.

• 10:25Speaker 00

  And it says, trust me, I'm going to do something that has side effects, but you can pretend there weren't any.

• 10:33Speaker 00

  All right? So, and it's called, it is literally spelt U N S A F E perform I O, the long name that has unsafe in the title so that you, the programmer, are taking on the obligation to make sure that what you're doing is okay. Whereas in imperative language, everything you do could be unsafe perform I O-ish.

• 10:53Ryan Peterman?

  I was watching one of your lectures and you did go over a little bit the history of functional programming languages and you mentioned somewhere that there was this idea of people building hardware for functional programming languages. This just made me curious because I didn't, I only know the von Neumann architecture. Do you have any idea what that might look like and some high level thoughts?

• 11:20Speaker 00

  Well, I did. And I think it's probably a bad idea. But back in 19, when was Bacchus' Turing Award lecture? I think it was 1978 or thereabout. What was it called?

• 11:34Ryan Peterman?

  Can programming be liberated from the von Neumann style?

• 11:38Speaker 00

  That's it. Now, he was saying two things. Firstly, he, the designer of FORTRAN, a quintessentially imperative language, the designer of FORTRAN was saying, guys, we should do functional programming. That was, that was what the talk was about. And he introduced a language called FP, the functional programming. It was a very particular, somewhat idiosyncratic functional programming language, but there it was. So that was rather amazing, right? This was 1977. He was saying, guys, give up on imperative programming. Just do functional programming. Here's how you do it. But he also said in the same lecture, we might imagine designing new hardware to execute this new kind of language. So if

• 12:23Speaker 00

  you like, we got Turing machines, they give rise to register machines and microprocessors and so forth, maybe lambda calculus. Perhaps if we designed a machine from the ground up to do lambda calculus, it would look different. So that was, of course, very exciting. And similar kind of thinking led to an actual commercial machine called a Lisp machine that was a piece of hardware that was designed by Symbolix to execute Lisp programs. Lisp is a mostly functional programming language. And so at the time, I was, you know, in my early twenties, we're thinking, oh, crumbs, what would a piece of hardware look like that could, was primarily designed to execute functional programs? Would it have a different kind of instruction set and architecture?

• 13:11Speaker 00

  The newest we got to it, actually, was, although there was a big strand of work then, there was the, called the MIT Dataflow Project. So dataflow languages, functional languages, they're definitely the same kind of category, right? And so the MIT had this great group led by Arvind, called the MIT Dataflow Group, and they designed, in the end, a machine called Monsoon, that was specifically designed to execute dataflow programs, that is, functional programs. It was based on, you know, a token store, and matching, and tokens flowing around, and getting matched up and executed. You can imagine data flowing through a graph. When three arrives at a plus node, and four arrives at the other input of the plus node, bam, you could fire that plus node, right? And the hardware did all of that.

• 13:56Speaker 00

  At a similar kind of time, in England, my colleagues, Thomas Clark, Joe Stoy, and others, built something called the SKI machine, SKIM. There's a paper about this in the FCA conference. And SKIM was designed to execute SK combinators. So, at the time, David Turner's written a lovely paper in which he described how to take lambda calculus programs and translate them into SK combinators. So you could read about that in my book. It's a very simple translation, like you can give the whole translation in half a dozen lines. But then you have this mess of Ss and Ks. And S and K reduction is very, very easy.

• 14:39Speaker 00

  So it's like the machine code of functional program, that one way to think of it.

• 14:44Ryan Peterman?

  What is a SK combinator, just for context?

• 14:49Speaker 00

  There are three combinator, S, K, and I. So, and they have simple reduction rules. Here they are. I of X equals X. K X Y equals X. S X Y Z is X of Z applied to Y of Z. End of story. That's all. So very simple, right? So now, all I've got to do is take my lambda, translate it into a giant tree of SK combinators, right? S applied to K, applied to I of three, and S of Z, just a huge tree of Ss and Ks, right? Now simply apply the rewrite rules I gave you. And that is program execution. It's rather astonishing that that can execute arbitrarily complicated programs, but it can. Do you think that's rather amazing?

• 15:33Speaker 00

  Now, then I can take an arbitrary Haskell program, I could translate it into lambda terms, and I could translate those lambda terms into S and K, very simple transformation, and I could just write those, run those three rules, and it'll produce the output of the Haskell program. That's pretty amazing. And indeed, there is an implementation of Haskell that uses exactly this. It's called MicroHS, and my colleague Leonard Augustin has built it. And its execution mechanism is SK combinator reduction. And if you sit in MicroHS, you can ask it to show you the Ss and Ks that it produces. If we had a, you know, shared screen, I could probably show you. So, long story short then, the SKI machine was designed to take SK trees,

• 16:17Speaker 00

  big trees of Ss and K combinators, and just execute them directly. So it was built in hardware, and it ran perfectly well, reasonably fast. Now, why didn't this catch on? Why don't we have functional programming machines? I mean, at the time, it was a big idea. We even had a conference called Functional Programming Computer Architecture, FPCA. It was right there in the title of the conference. But slowly, we became aware that what was really happening is we were doing at runtime what we could do instead at compile time. And that is always a bad idea. Imagine an interpreter for, I don't know, Pascal or something.

• 17:01Speaker 00

  Or for Java. Right, we can compile Java to bytecode, and we could interpret the bytecode. Right? So then we are, we were doing something at runtime. At runtime, the interpreter is looking at the bytecode, saying, dispatching to say which instruction, blah, blah, blah. Now, what does JIT do? It takes a sequence of bytecode and says, oh, no, no. I'm going to take that sequence of bytecode, compile it to a sequence of machine instructions that, when executed, will do the same thing. Right? Much faster. Because it can take advantage of bytecode sequences, for example, to say, you know, if you swap and then swap, it's a no-op or something like that.

• 17:43Speaker 00

  So what in fact it turned out is this whole SKI business, and any other, and indeed data flow machines also, was simply doing at runtime what you could do better at compile time. We were building an interpreter in hardware. So don't build the interpreter in hardware, instead build a compiler that translates your lambda term into a sequence of machine instructions that when executed will behave as if you had done this reduction business. And then you might think, well, machine instructions for what machine? Well, from a practical point of view, it was very hard to compete with Intel.

• 18:25Speaker 00

  Right? They were just spending bazillions of man years on making x86s go faster and ARM likewise for arms. So we can leverage all of that work by compiling into their instruction set. But even if you say you are God, you are the chief executive in Intel and can tell them to add new instructions or computation mechanisms to support functional programming, what would you add?

• 18:50Speaker 00

  Not very much.

• 18:53Speaker 00

  Little bits to do with garbage collection barriers, I think, and such like, but nothing major.

• 19:03Speaker 00

  So in other words, I think the whole build hardware to execute functional programming directly turned out to be a mistake. Inspiring mistake, fun mistake, I had a great time, but a mistake. It's better to build a compiler.

• 19:17Ryan Peterman?

  I would have thought there might be some unique opportunities for parallelism, given the immutability in these functional programming languages. So, yeah, you described that that graph or that SK combinator graph. I imagine you could, you know, execute that all in parallel, assuming there's no connections across the graph.

• 19:40Speaker 00

  And indeed, that was the data flow machine. The MIT data flow machine was all based on that idea. It's saying to throw the whole graph into the token store and just run all the nodes that are runnable. Right, but that's incredibly fine-grained. You've got to imagine this big tree of a million nodes and your processor is sort of wandering around over it, doing little things in parallel. There's a lot of memory traffic going on there and these little threads have to, you know, are operating on the same bit of tree, then there's synchronization costs. So very, very fine-grained parallel computation like this turns out to be impractical. Or not impractical, you could do it, but it's very slow.

• 20:20Speaker 00

  Right, so the Dataflow people, their history, if you look at the history of the MIT Dataflow project, they started with micro-parallelism. Every individual instruction was a separate parallel computation that might take place and the token store would match it up, right? And then they built more and more compiler technology that grouped these things together into larger units. So they expanded from micro threads of single instruction threads into 10 instruction threads or 100 instruction threads, right? But even that never really caught on. So you're right though, that if I say in a Haskell program, e1 plus e2, then I can do e1 and e2 in parallel.

• 21:01Speaker 00

  And GAC does support you in doing that, but you nowadays, rather than expecting the compiler to do that automatically for every sub-expression, you can spark a computation. You say e1 par e2 and that says, "Do e1 and e2 in parallel." There's a project at Carnegie Mellon for a strict language called ML that has a very good variety of parallel ML going in similar way. So essentially we've moved away from the dream of automatically getting parallel at very, very fine-grain to program a, we give programmer clues about where it's a good idea to do parallelism, but still the compiler will try not to fork to tiny grains.

• 21:47Ryan Peterman?

  I was searching on YouTube and I've searched your name and this video came up and it said Haskell is useless, Simon Peyton Jones. And it's a video from a long time ago and someone's got a low quality handheld camera. There's a group of researchers that are all talking. Butler Lampson is across the table and it's a fun little video. And in the video, you lay out this two dimensional graph where on one dimension, there is the useful versus useless axis. And then on the other dimension, there is the safe versus dangerous. And then you're placing programming languages on this two dimensional graph.

• 22:31Ryan Peterman?

  And I think you started by putting C as it's very useful, but it's incredibly dangerous. And then you put Haskell on the polar opposite side. You said it's useless, but it's very safe. What are the least safe and most useful languages and why do you place them there? Like C, for instance?

• 22:52Speaker 00

  Well, yeah, so let's see. In C, you program by mutation. So it's unsafe in the sense that any function can mutate any variables at any time. It has a lot, you pass pointers around a lot and functions mutate the memory pointed to by those pointers. And moreover, typically, they can mutate it anywhere. There's no array batch checks or anything. So it's kind of like super unsafe. And in fact, and this is demonstrated by that. Can you imagine that like all of these exploits that we get every day, right? That Mythos is discovering in huge numbers, but we've had, you know, why is the internet so insecure? Primarily because all of our software infrastructure is written in unsafe languages.

• 23:32Speaker 00

  If we, I mean, if we'd written all of our, you know, internet software and operating systems in Haskell or maybe in OCaml or ML, 99% of all these exploits would be removed by construction.

• 23:47Speaker 00

  Like, it's like, we've built a boat out of paper clips and we're surprised that it's leaky. I mean, you shouldn't build boats out of paper clips, right? Because they have holes in them. You should build it out of a secure substance, right? But then it's too late. So we spend incredible amounts of human ingenuity and effort patching the holes in our boat built of paper clips. It's tragic. It's tragic how much effort and ingenuity and money has been lost and waste of resources just because we wrote our, you know, computational infrastructure for the world in an insecure language. That's what I mean by unsafe.

• 24:27Ryan Peterman?

  I mean, are there not vulnerabilities? Like, if I wrote something in Haskell, I mean, there's gotta be some new type of...

• 24:34Speaker 00

  Of course there are vulnerabilities. I just said 99%. I didn't say 100%. If I write a Haskell program that says, "Receive message", if the message says, "Tell me everything", then spit out my entire database in reply. No language can stop you doing that, right? But if you look at the program and it doesn't have any such things, right?

• 24:58Speaker 00

  So, I mean, so, you know, nothing can prevent you against high-level attacks to insecure programs. Or, I mean, another example might be deadlock, right? Two services, no matter how securely written, if A waits for B and B waits for A, deadlock. Sorry.

• 25:15Speaker 00

  No, and no language is going to stop you doing that. You might hope for some high-level verification tools. But it's like, surely if you're trying to do something hard, like prove that that doesn't happen, you want to have a foundation that is, you know, in which you've got some bedrock to stand on. If you're standing on sand and trying to prove some advanced property, it's very, very difficult. But, good point. I'm not talking about 100% security, absolutely not. But how many, how many, how many exploits are based on buffer overruns? Or, you know, pointer manipulation that's gone wrong? If you couldn't have a buffer overrun, you couldn't do pointer manipulation that's gone wrong, those, those just wouldn't exist.

• 25:58Ryan Peterman?

  So I mean, C is maybe half a century old now. What about more modern versions of those lower-level languages like Rust?

• 26:09Speaker 00

  Much, much better, much, much, much better, right? If we rewrote all of our software infrastructure in Rust, things would be way, way better. I'm not actually even sure whether Rust has array bounds checks built in, but it must have the ability to promise that you're not indexing out of bound. I don't quite know, but if you compile all your code with that switched on, you're way better situation, way better.

• 26:37Speaker 00

  So yes, this is not just functional programming, but you did ask about why I thought C was an insecure, unsafe language.

• 26:44Ryan Peterman?

  If we imagine that graph, there's that, the upper right quadrant, which is useful and safe. And you described that as nirvana in the video. And I guess maybe over time, I mean, C is somewhere really unsafe, really useful.

• 27:01Speaker 00

  Yes, so C, I mean Rust has moved along the axis from useful but very unsafe to stay useful and become safer. Now Haskell started off as being very safe but useless. So it's worth just rehearsing that because in the first version of Haskell, there was no I/O. The only, a Haskell program was a function of trying to string to string. It's functional programming after all. It could do no I/O. All it could do was take a string and produce a string. So obviously, that's not very useful. It's a little bit more useful. A language that is very, very safe and completely useless is no-op, that does nothing ever. Very safe, but very useless. Haskell was a bit better, right?

• 27:46Speaker 00

  At least it lets you apply a function to a string and get back another string.

• 27:52Speaker 00

  So of course, we then worked on how could we do I/O in Haskell in a safe way? And that will lead to, you know, monads and stuff. But, but so just as the, you know, we're moving from C horizontally to go safer and safer, but, but staying useful. So from Haskell, we're moving sort of vertically to get more and more useful without stopping being safe. And Nirvana is when we sort of meet up, right? So, but the point is not to say one is better than the other, but just to say that we both seek things that are useful and safe.

• 28:24Ryan Peterman?

  And when I think of functional languages in, I guess, in the mainstream or, you know, what people are kind of thinking about, I hear Haskell, I also hear OCaml. How do these two programming languages compare if someone was trying to pick a functional language to work with?

• 28:41Speaker 00

  So OCaml is a strict language that is called by value. So when you say F apply to 3 plus 4, it'll add 3 plus 4 and then call F to get something right. In Haskell, if you say F of 3 plus 4, it'll build a little suspension that says, well, if you ever need this 3 plus 4, you can evaluate it, but maybe you'll never need it, and then it calls F. That's a lazy language, right? Now, so because OCaml is strict, it has a defined order of evaluation. So if you say F of 3 plus 4 and a second parameter 8 plus 9, it'll evaluate 3 plus 4 and then 8 plus 9 in that order, right?

• 29:20Speaker 00

  So it makes sense to say, you can say F of print hello, comma, print goodbye, right? Because you get hello and then goodbye printed. So once you have a defined order of evaluation, then it's pretty easy to incorporate I/O, right? Even though it quotes a functional language, OCaml allows you to do I/O without, you know, without saying unsafe perform I/O or anything. In fact, it has a defined order of evaluation and it's perfectly kosher to do that. As a sort of unintended consequence of being called by value, it was also by default impure. Now, good Haskell, good OCaml programmers won't use many side effects, but...

• 30:04Speaker 00

  OhCamel doesn't prevent you.

• 30:07Speaker 00

  Haskell prevents you. Why does it prevent you? Because if we'd allowed you to say f of print hello, comma, print goodbye, those would be thugs, like not yet evaluated. Right? So if f happened to evaluate its first argument and then its second, we'd print hello and then goodbye. If it evaluated its second and then its first, we'd print goodbye and then hello. If it didn't evaluate either, we wouldn't print either of them. That doesn't sound very good from a, if you want to control what I/O is happening. Right? Laziness forced Haskell to stay pure. Strickness allowed OCaml, which grew out of the ML tradition, by the way. ML is another functional language that predated Haskell. It was always strict and it always had I/O by default.

• 30:52Speaker 00

  Um, it wasn't a goal, but that's just the way it worked out. At the time, nobody thought about it. It was just obvious.

• 31:00Speaker 00

  So that's a big difference between OCaml and Haskell, right? Is that, um, now then, since then, they've both grown up. Haskell's gained sort of monads, OCaml's gained lots of fancy type systems. Some of them look, Haskell and OCaml have learnt from each other. OCaml has grown an interesting effect system recently and a whole lot of new extensions. It's an absolute hotbed of innovation at the moment, OCaml. So I view OCaml and Haskell as kind of siblings, brothers and sisters. Right? We love each other. We learn from each other. We compete with each other. All of the things that siblings do, but they're not the same, right? So siblings don't say, I'm just better than you. You shouldn't exist. We say, let's, let's enjoy our life together. And that's what, that's the way it is.

• 31:44Ryan Peterman?

  You described the laziness and the strict and as a programmer, I, my initial thought is, I would like to control the order of execution. And when I say, print x, I, and then print y, I wanted to have that order. Otherwise, it would be a little unintuitive. What is the main benefit of laziness?

• 32:05Speaker 00

  Why is laziness good? Well, um, John Hughes did this rather well, way ago, 1980 something. He wrote a program called Why Functional Programming Matters.

• 32:17Speaker 00

  And one of its main theses was that lazy evaluation lets you.

• 32:22Speaker 00

  Compose programs in a particularly modular way. So imagine a program that is, I mean, his classic example is a program that plays chess. Right? So one thing you could do is you could imagine building a tree of all possible moves, starting from the position we're at. It would be a very, very big tree. In OCaml, it would be too big. Because first of all, I compute the tree, and then I'd start deciding what move to do. I couldn't possibly do that. Because the tree of all possible moves, you know, has more nodes in it than the number of protons in the universe. So let's not do that. Now, if instead you could build the tree, oh, having got this tree, supposing you had it, you could then walk over the tree, saying, "Oh, let me do some minimaxing," and saying, "Oh, this is, it looks like a good position. Let me go this way."

• 33:07Speaker 00

  I could explore the tree, right? Now then, so if you, in OCaml then, you would have to put the tree generation and the tree exploration in one function.

• 33:19Speaker 00

  Right? In Haskell, with lazy evaluation, you can generate an infinite tree, and then the explorer that prunes the tree and explores just the bits of it that is necessary is completely modularly separated. Right? I can build a different generator and a different pruner. They're just completely separate programs. So lazy evaluation is very powerful glue that lets you glue together two programs that you'd like to be distinct. Strict evaluation forces you to merge them together.

• 33:53Ryan Peterman?

  Yeah, this reminds me, I mean, so in Python, for instance, they have the idea of a generator where you could lazily retrieve things.

• 34:01Speaker 00

  Every strict language, every, you know, serious strict language, has lazy evaluation in it. They're called iterators or generators. And so does OCaml. Right? But in Haskell, that's the default. Now instead, in Haskell, so this is a bit like, again, the two are converging on the middle, right? Haskell lazy by default, but you can make things strict. You can put in exclamation marks to say, "Please evaluate this before the call." Right? Or the IOMO now to say evaluate, but that's a more brutal, strict, strict abbreviation. So in Haskell, you can make things stricter. In OCaml, you can make things lazier.

• 34:40Speaker 00

  Right, so it really boils down to is what's the default? We both want to have a mixture of the two. And then it becomes a bit cultural as to which you prefer. I don't know. Some people sometimes ask me, they say, well, if you were designing Haskell again, would you make it strict by default with really good support for laziness? And I often say, well, I might. Yeah, that does seem attractive because frequently I found myself cursing laziness as an implementer. But I strongly suspect that 10 years after that, I'd be thinking, man, if only it was lazy by default. Oh, when I said strict by default, I would definitely mean strict but pure.

• 35:24Speaker 00

  Right, no side effects.

• 35:26Ryan Peterman?

  A few times in our conversation, you've mentioned the word monad. And it seems like it allows us to do the side effects. What is a monad? And yeah, how does it help us do side effects and preserve ordering?

• 35:41Speaker 00

  One way to think about it that's very easy to understand and use is just to imagine that the do notation is somehow built into Haskell. So you can say do print x, semicolon, print y. And that has type I O unit. So a value of type I O unit means I do some input output and return a value of type unit. An expression of type I O int is an expression that when you run it will do some I O and return an int. Okay, so do lets you combine I O performing computations together.

• 36:23Speaker 00

  So print three has type I O unit. It does some I O, namely printing three. Get char has type I O char. It does some I O, namely reading a character from standard input and returns a character. All right. Notice that's different from just char. So, you know, quotes X quote, that has type char. It's just a character pure, right? Getchar, the I/O performing operation, has type I/O char. It does some input-output and returns a character. Okay.

• 37:05Speaker 00

  The do notation lets you combine together I/O performing computations.

• 37:12Speaker 00

  So if you say do and then you say x-left arrow getchar, semicolon, putchar x, then that x-left arrow getchar, that says, "Run the getchar computation and get me the character. Call it x." The putchar x says, "Run the putchar computation to put x." And we combine them together with the do notation, that combines two computations to make one I/O performing computation. All right?

• 37:45Speaker 00

  So, but these things are completely first-class. That's what's new about monads compared to just make it into C. x-left arrow getchar, semicolon, putchar x. That's a computation whose type is I/O unit. Right? Let me give it a name, so I can say, "Let foo with type I/O unit equals that do." Now I can pass foo as an argument to something. I could put foo in a data structure. I could return foo as a result. It's a value, just as much as 3 or plus.

• 38:21Speaker 00

  In particular, for example, I could say, "do foo, semicolon, foo."

• 38:27Speaker 00

  That takes foo, uses it twice. Each time, oh, do foo, semicolon, foo says, "do foo and then do foo again." Right? So I'll read a character and put it, and then read a character and put it again.

• 38:40Speaker 00

  So these values of type I/O T, for some type T, are first-class values.

• 38:48Speaker 00

  Right? In C, I can't take x colon equals 3, semicolon, you know, y plus 4, and pass that as an argument to something and expect it to happen wherever it's used, right? It's not a first-class value.

• 39:03Ryan Peterman?

  When I first was learning this monad idea, it seems like you've said in a few places, "It's a way to do the side effects, but keeps the language pure." But when I saw it, my first thought was, "It's almost like this little, you know, place where we segregate the dirty things we want to do, I guess." But then, how does that keep the language pure?

• 39:26Speaker 00

  Oh, because, because, I mean, well, yeah, we are lying, but look, if your function has type int or int, can it do any I/O?

• 39:34Ryan Peterman?

  No.

• 39:35Speaker 00

  No. If it has type int to I/O int, it could do arbitrary I/O. So yes, so it's nice, pure int to int function or dirty int to int function.

• 39:49Speaker 00

  So you may say, perhaps you're about to say, "That's a bit of a blunt instrument." Either completely pure or completely dirty, right?

• 39:59Speaker 00

  It gets you an awfully long way.

• 40:03Speaker 00

  But nevertheless, it would be cool if you could say, "Oh, I am an int to effectful doing reading of files only int." Right? So you'd like to, in the type, you'd like to say, "What kind of effects can it have?

• 40:25Speaker 00

  Can it throw exceptions? Can it, you know, spawn new threads?"

• 40:31Speaker 00

  So you'd like to enumerate the effects this computation could have, right? That would be cool. That's called an effect system. And there's, you know, bazillion programming language papers about effect systems. And it turns out that you can indeed, in the type system of Haskell, and indeed, OCaml is rapidly becoming sane, you can express just not just "all or nothing, does it do I/O, game over", but rather, "Which particular effects does it do?", including no effects at all, that's pure, right?

• 41:07Speaker 00

  A good place to start is a library called Bluefin, which my colleague Tom Ellis has designed. It's a very nice take on how to do effect systems in Haskell.

• 41:17Ryan Peterman?

  I guess the purity comes from that this is, this dirty stuff is signaled through the type system.

• 41:25Speaker 00

  Correct.

• 41:26Ryan Peterman?

  Okay, so we can do it, but here it is, and be aware.

• 41:31Speaker 00

  Yep, and because you have to thread, you know, because the type system gets in your face, you know, you were trying to,

• 41:39Speaker 00

  like map, say, no, map says I apply a function to every element of the list. Well, so it has type A to B, to list of A to list of B. If you want to apply an I/O performing function, so the function you're applying has type like int to I/O of char.

• 41:57Speaker 00

  You could map that over a list, but you just get a list of I/O of chars. That hasn't done any I/O yet, right? You want something that says, take a list of I/O chars and perform those actions one at a time. So I want a function that goes from type list of I/O char to I/O of list of char. Right, and you might want to perform all those actions top to bottom, or maybe bottoms top. Who knows? That's what this function of type, you know, so yes, so you could do it in various ways. So sometimes it gets in the way, right? You say, oh shit, you know, can't I just use map? Well, in Haskell, no, sorry. You're going to have to do a little bit more work to tell me in what sequence you want your effects to happen.

• 42:43Speaker 00

  Because by default, Haskell does not specify sequence. So the, you know, adding monads to control effects does get in your face a bit. And that's a, that's the tax we pay. In effect, that's part of the big experiment that Haskell is doing is to say, suppose we upfront, say, we can, we're willing to pay that tax. You know, how many followers can we get?

• 43:09Speaker 00

  And the more, but I will note that monads have infected quite a lot of other languages. Like F sharp is definitely a call by value in pure language. And yet F sharp had these workflows that were definitely monads, right? And monads have, you know, appeared in Scala and in many, many other languages. So something that's very monad like has appeared lots elsewhere. It's been a very unifying concept.

• 43:31Ryan Peterman?

  OpenAI, Anthropic, Cursor and Vercel all use this product to make their lives better. And the problem it solves is when you're building SaaS or an AI product and you want to sell to other companies. There's all these requirements you need to meet. There's SSO, there's SCIM, there's RBAC, there's audit logs. These are all things that take time to integrate, but aren't the main focus of your app. WorkOS is an API layer that lets you meet all of these requirements in just a few lines of code. So let's say you have a new SaaS product and you want to sell to other companies. WorkOS will solve all of these critical feature gaps for you. You can check them out at workos.com to learn more and get started.

• 44:13Ryan Peterman?

  And I appreciate them for supporting my work and sponsoring this podcast. When I read about Haskell and people's perception of Haskell, one thing that keeps coming up is that the type system is really powerful. And so I kind of wanted to ask you, maybe just even on the highest level, what is a type system in your words?

• 44:35Speaker 00

  Okay, so what does a type system do? It lets you reject silly programs upfront.

• 44:43Speaker 00

  So if I have a function that adds one to things and I apply it to a character or to an I/O computation,

• 44:54Speaker 00

  I'd like to, that's going to fail at one time.

• 44:58Speaker 00

  Right? Because I can't add one to a character. Or maybe you overload plus, maybe reverse a list or something. If I give, if I've got a list reverse function, I give it something that just isn't a list.

• 45:09Speaker 00

  Then it's a bit silly to allow that and only fail at runtime.

• 45:13Speaker 00

  So fundamentally, type systems are about rejecting at compile time, programs that you do not want to run because they will fail at runtime. Okay, now. We've had static type systems for a long time. Like, you know, going back to Pascal and earlier. But simple type systems are annoying because they get in the way. Imagine a function that reverses a list. In Pascal, you could write a function that reverses a list of integers. But if you wanted to reverse a list of characters. Sorry.

• 45:52Speaker 00

  You can't let that function that reverses a list of integers, it has type list of int to list of int, so you can't apply it to a list of characters. Game over.

• 46:03Speaker 00

  You have to write another copy of the code with a different type. That's a bit annoying. So what are we going to do? We need polymorphism, we need a more powerful type system. We want to give reverse the type for all a, list of a to list of a. So that upfront says, I work for any type A. You give me a list of integers, fine, I'll produce a list of integers. You give me a list of characters, fine, I'll produce a list of characters. Notice that's much better than just list to list. I want to keep the fact there's a list of integers, so I know if I apply, you know, when I look inside the list, I know I've got an integer. But also, if I just list the list, I might get back a list of some completely different type, but I know that reverse returns a list with the same type of things.

• 46:48Speaker 00

  So parametric polymorphism, super valuable. Right, if you want a static type system, it must have parametric polymorphism. The message is. If your type system is too simple, it gets in the way. Very important lesson, because it means that we cannot really say is a type system useful or not unless we say which one, because we know that weak type systems are very inconvenient. It must at least have parametric polymorphism. And that is another idea that was born in the world of functional programming. It was born in ML, incidentally, Robin Milner's famous dictum, well, type programs don't go wrong. ML was the first, I think, the first parametrically polymorphic functional programming language.

• 47:33Speaker 00

  But generics in Java and object-oriented programming more generally is exactly the same idea, right? So there's an idea that was born in functional programming and made its way into the mainstream.

• 47:44Ryan Peterman?

  And you mentioned polymorphism. And so there's this parametric polymorphism in the type system. But in the example you mentioned, where maybe you want to do an operation on a list and then the type of the input changes, I was just thinking, what about when people do polymorphism in the classes?

• 48:04Speaker 00

  Yeah, okay. But so now you're into a whole more complicated world, right? So as soon as you say class, you're talking static type system again, right? So object-oriented programming is another approach to polymorphism. So in an object-oriented language, we say if we have a Ford that is a car and a car is a vehicle, then anything that works on vehicles should also work on cars and should also work on Fords. So the code that we write for cars works unchanged for vehicles and for Fords. Okay?

• 48:43Speaker 00

  Now, that's a form of polymorphism, not parametric polymorphism. That's what you might call object-oriented polymorphism or subtype polymorphism. Okay. So now we, but polymorphism in the sense that the same code, the same executable code, actually the same machine instructions work on values of different types. Okay, in both cases. Both reverse a list, same machine instructions. Code that works on vehicles, works on things and forwards, same machine instructions, right? Okay. That's what polymorphism in general means. Parametric polymorphism means this full A list of A to A stuff. Subtype polymorphism means if it works on vehicles, it works on any subtype of vehicles. Okay?

• 49:26Speaker 00

  Now, the interaction of the two, which you get by adding generics to an object oriented language, is pretty complicated. Oh, and by the way, adding side effects as well. And that's why you're, and so your question involving classes and subclasses and so forth is smack in that complicated world. And I'm not sure it'll be very fruitful for us to, you know, we'd have to get a lot more details of the type system sorted out to know what to say. But at this very high level overview, my, my sort of, the big point I'm trying to make is weak type systems get in the way. Type systems are meant to reject programs that will go wrong, but my function that

• 50:08Speaker 00

  reverses a list of integers, it will also reverse the list of characters. So it's tiresome to be told, no, that is a bad program. Right? I want to be able to write the static full A list of A to A. So the idea of making a type system more complicated is to say, programs that you want to run, you can still write in your static type system. Now, you might say, well, blimey, if that's all, if that's all, why don't we just get rid of the static type system altogether? Now we could run all of those programs. But the trouble is you can run too many programs now. You can run programs that will crash at runtime. And that's very, very, very bad. And we all know the costs of programs that crash in deployment, that you could have

• 50:50Speaker 00

  crashed before you even started to run them, let alone before you even ran your first test. Right? Before you even linked it into an executable? That's really good. But the biggest benefit of a static type system, in my humble opinion, is maintainability. If you have a program written in, I don't know, Perl or Ruby, or Lisp in its, in a basic form, and it was written 15 years ago, and the original author has left, and all of the people who were involved at the time it was written have left, then that program is very difficult to maintain.

• 51:29Speaker 00

  And it becomes almost immutable. Nobody dares change it anymore. What they do is it's an immutable piece of software and you do that stuff around the edges to impedance match what you really want to do to this now immutable blob. So of course you have lots of tests. So test your development, I'm totally with it. I'll develop all of that. But still, G H C, for example, is itself written in Haskell. It's thirty five years old and yet I do large scale systematic refactorings of it, you know, fearlessly, because the type system keeps me safe. In fact, often what I'll do is I'll change a few types and then start compiling. And then a sort of wave of changes propagate through, forced by, you know, I just get type errors. So I know what to do.

• 52:13Speaker 00

  Whereas the thought that I've changed the representation of this data structure a little bit, I've added a field to this data structure, where in the entire compiler might that field be read, written, or freshly allocated? I can't imagine how anybody maintains thirty year old software and makes large scale changes like that without a type system. It's unimaginable. So for me, the benefit of type systems is maintainability. Oh, and designability, right? So a type, I often write the types of my programs upfront. I write the type, you know, the data types are super conspicuous. Now, if I say, it's a bit like writing the classes of an arbitrary language, right? But if you have no types, no classes, nothing, just,

• 52:58Speaker 00

  I don't know, S expressions. Types are my design language. They're the way that I start writing my designs.

• 53:07Ryan Peterman?

  I'm trying to understand the other mindset, like, let's say, C, for instance, where I remember a lot of stuff when I was learning it in college, for instance, many times where I'd add a character to a pointer or something and it just works because it interprets the character as a number. So is there any value to having that kind of type system or is that just strictly unredeemable?

• 53:34Speaker 00

  Just use stronger.

• 53:37Speaker 00

  I think there's no benefit to weaker.

• 53:39Ryan Peterman?

  Just off the top of my head, one thing I think of is there is a set of programs that will work but don't satisfy the type system.

• 53:49Speaker 00

  Oh yeah, that's right.

• 53:50Ryan Peterman?

  That and but those are, I mean, I don't know if they're good, that's subjective.

• 53:54Speaker 00

  Oh no, they may be good. So, so, so, so, uh, that like us, like we started, if you have Pascal and you write a function to reverse a list of integers, then if you apply it to a list of characters, the same machine instructions would work, but it is rejected, right? So we have rejected a perfectly decent program, bad, right? Our goal is to expand the collection of programs that satisfy the type system, to include as many as possible of the programs we want to run without including any of the bad programs that we don't want to run.

• 54:32Speaker 00

  Okay? Parametric polymorphism is a big step in that direction.

• 54:38Speaker 00

  Other, you know, type system innovations are a big step in that direction, but there will always be some programs that would run perfectly well that the type system rejects.

• 54:53Speaker 00

  Imagine a tree that is, uh, contains integers at every node, but if you are 17 deep in the tree, or 34, or 51, if you're in a multiple of 17 deep, the integers can be characters instead, or the integers all turn out to be characters, right?

• 55:17Speaker 00

  Now, you could write a program that generated such trees, and you could write a program that consumed such trees, knowing that every 17th layer, we switch to characters, but most static type systems would make it pretty hard for you to accept that program, and yet it will run.

• 55:36Speaker 00

  Now, you might say, "Oh, but I really want to write that program, guys. You know, don't get in my way." Well, then, um, uh, then we should provide a way for you to bail out into dynamic typing. Right? What I'd like to do is to say, "Okay, so if all else fails, then at least you can, as it were, pair up a value with its type representation." There's one reason we don't want to interpret an integer as a double precision float, for example, is that, you know, they don't even have the same representation, which is just nonsense, right? One possible way, which untyped languages let you do, is to tag every integer and every double precision float with the fact, "I'm an integer, I'm a double precision float." But that has a lot of overhead.

• 56:19Speaker 00

  So, one merit, and it's not, I think it's not the biggest single merit, but it is a major merit of static type systems, is you have no tags. You know that if it says it's an integer, it's going to be an integer. You know that if it's a double precision float, it's going to be a double precision float. Right? But if you're not sure, um, maybe we could make a way to make a pair of a type representation and this value. The type representation is now like a runtime tag. It's like a little runtime data structure that describes the type. And then in your program, you could say, "Now I want to say, oh, I've got this type dynamic. We'll call this pair a value of type dynamic." Now, when I want to take a value of type dynamic and treat it as a character, I want to say, "Ah, look, look at the type dynamic.

• 57:04Speaker 00

  See if it says it's a character. If it is, return the character. If not, crash, like runtime failure." That's fine, you can do that. So, um, and Haskell has good support for dynamic typing where necessary. So, my, uh, my, my story would be, static typing should expand, carry as much as possible, and where you absolutely cannot do it, sorry, then use dynamic typing, and we provide facilities to support that.

• 57:30Ryan Peterman?

  One thing I wanted to, to talk with you about is the compiler. How does the GHC work on a, on a high level?

• 57:37Speaker 00

  So, GHC takes a string, like, like any other compiler, the, the source code of the program, parses it,

• 57:45Speaker 00

  and then it, um, uh, type checks it, because, "Is this a type correct program?" Then it converts it to lambda calculus.

• 57:58Speaker 00

  Now Haskell, the Haskell AST, the original source tree, has fifty different data types, fifty different kinds of nodes, some of which have thirty or forty different variants. So it's a really big, diverse, complicated data structure, the AST. Lambda calculus has, this variant of the Lambda calculus has eight. One or two or three data sets with eight constructors. So it's like taking a gigantic language and squeezing it down into a tiny one. And that tiny one, we can then optimize, right? That's the optimizer works on that.

• 58:40Speaker 00

  So the front end does parse, rename, type check, de-sugar into Lambda calculus. That's the front end. The Lambda calculus particular language is called GHC's core language. I'm quite proud of it because it's been very, very stable. It's thirty-five years old and it has barely changed since birth. That's amazing, right? Because Haskell has changed a lot, a lot, right? So almost all of the innovation in Haskell has been in the front end. Very little in core. Now, the back end, the core optimizer, has changed a lot too. But all of the changes that were useful there would have been useful thirty years ago,

• 59:25Speaker 00

  right? So it's two completely separable things. So I'm quite proud about that. Core, then we do a lot of core to core passes that simply take core programs, which is core programs, right? Lots and lots, long pipeline. Then we convert it to C minus minus, which is a prototypical imperative language. Think of it as a portable assembly code, right? So that bit is meant to be platform independent. So it's simply, that's the compiler that take, do you remember I said if you take Lambda calculus and compile it? That's that step, right? I want to compile the Lambda calculus into, you know, machine instructions, really. But I don't really mean machine instruction, I mean portable machine instructions. That's called C minus minus.

• 1:00:09Speaker 00

  Then I want to convert C minus minus into actual machine instructions for various platforms. And there we could either do that directly with an Azure Code backend or go via L L V M.

• 1:00:18Ryan Peterman?

  Interesting. I've never heard of C minus minus. Why not just go directly to, I would have thought, maybe Assembly or something like that?

• 1:00:25Speaker 00

  Well, because what happens in Assembly in which, for which processor, please?

• 1:00:30Ryan Peterman?

  Oh, I see. I guess it's the, I would have thought the lambda calculus part was already portable. So you just.

• 1:00:37Speaker 00

  It is, yeah. You could go straight, but, but, but, so there's work to go from lambda calculus. You could go all the way to x86. Then throw all that away and now go from lambda calculus to Power PC. Oh dear, I've just duplicated a lot of work.

• 1:00:53Speaker 00

  By going from lambda calculus to C minus minus and then from C minus minus to x86, C minus minus, we've said, we've, we've avoided duplicating the work that went from lambda calculus to C minus minus, right? Well, you see, that is pretty obvious, isn't it? Right? You got to, you want to make the platform specific bit as small as possible. You would like to have, as it were, like a generic architecture, one that can do addition and has a program counter and a stack and so forth. That's all C minus minus is. It's just a portable assembly language. And then you say, oh, the nitty gritty of, you know, whether you have double precision add and set the floating point bit here and there, that, well, that's platform specific.

• 1:01:33Speaker 00

  The call is itself statically typed, you know, but in some ways it's surprising because no other compiler has this property, no other production compiler. By call is statically typed, I don't just mean that the initial, the initial program was type correct. I mean that a call program, you could run a type checker on that. I might say, why do you need to? Because after all, if G H C is correct, it started with a type correct call program. Because it came from a type correct Haskell program, assuming the de-sugarer was right. And all the optimizations, if they're right, will generate a type correct call program. So why do you need a type checker? Answer, to discover bugs in G H C. Now, these are serious bugs, right? If you ever take a type correct call program and an optimization pass produces a type incorrect call program.

• 1:02:19Speaker 00

  What will happen if we don't have the type checker for call? We'll generate machine code and we'll run it and we'll get a seg fault.

• 1:02:28Speaker 00

  Now we have to backtrack from a particular test program that now crashes

• 1:02:34Speaker 00

  all the way to back up the pipeline, up the pipeline, up the pipeline, up the pipeline. Oh, it was this pass of GHC that was faulty. That's super hard to do because you know, you're getting out GDB on some runtime failure. There is an indirect and perhaps distant consequence of the fact you just generated a type, you know, you just made a, you had a bug in the optimizer. So it is amazing to have a type checker for Core.

• 1:03:04Speaker 00

  Now, why does nobody else do this? Well, it's because their intermediate language typically, and this, I really am talking typically because I know of no other compiler that has this property, none, production compiler. Typically then, they're, you know, complex syntax trees decorated with all sorts of Pragma information and things hanging on it, onto it here and there and

• 1:03:26Speaker 00

  um, you know, there's no, there's no type checker for it at all.

• 1:03:31Speaker 00

  And there's no hope of one. So I'm very proud of the fact that Core is statically typed. And I'm also, also think it's a the most delightful thing is that the way that it is statically typed, it is, it's an implementation of something called System F. So System F, when I said Lambda calculus, Lambda calculus as Alonso Church had it was untyped, had no type system at all. But Girard defined something called System F, which is a statically typed Lambda calculus, a rather powerful one. And Core is essentially System F. So we literally adopted something from the nerdy theoretical computer science, you know, logic community,

• 1:04:13Speaker 00

  logic of mathematics community and adopted it directly in a, in a production implementation. So I'm very proud of that. I think Core is, and the fact that we can do, we have 35 years worth of development that has been not just not impeding, but actively aided by a statically typed intermediate language is really a big marker in the ground.

• 1:04:35Ryan Peterman?

  You know, watching all your talks, reading everything. One of the interesting data points that you brought up was that Haskell is talked about more than used. When you compared Stack Overflow volume and, you know, actually GitHub volume, like who's actually using the programming language? Why do you think that is?

• 1:04:55Speaker 00

  So Haskell embodies one key idea. Immutable changes everything. There's a quote from Pat Helen's talk that I think you also, a paper which I think you also looked at already. So it says, "Programming with values changes everything about the way you think about programming. It's just mind changing. It's not necessarily better, but it is different." And so Haskell takes that idea and runs with it. Everything is driven by that one idea. Everything else is incidental. In the early days, that meant we just said, "Well, guys, suck it up. We'll keep changing the language and if it breaks your program, it's too bad." So it is a bit peculiar and therefore also it felt a bit academic because initially it was really not very powerful.

• 1:05:40Speaker 00

  It was taking the key idea, but you couldn't do very much with it. We talked about that, right? So over time, GHC and Haskell in general has become more and more powerful. The type system has become less and less in your way and more and more useful. The, you know, all the obstacles that make functional programming hard have become better. The compiler generates faster code, it can browse faster and so forth. So it has become less, if you like, peculiar. So we've become more and more taking into account the needs of our users. But in a way, the sort of cultural heritage is we never give up on the one core principle. We're just not going to give you unrestricted side effects. Sorry. You want to say unforfeited perform by O and put up with the consequences.

• 1:06:24Speaker 00

  So we're going to stick to one core principle and then we'll do lots of work around the effort to make that better. Right, so that does limit our community somewhat, right? It does mean you have to, you really have to think in a different way. Immutable changes everything. That means you'd have to think a different way about programming. Maybe you don't want to think in a different way. That's fine, then don't use Haskell, right? So in a way, we've, we started from a very small user community, a very sort of pure and nerdy one, and growing, growing larger and larger, but all slowly, slowly, but all the time maintaining faithfulness to this core principle.

• 1:06:57Ryan Peterman?

  I thought that was very unique about Haskell because I feel a lot of the other programming languages are user-centric. I mean, if people want something, they work on it, they add it, whereas Haskell feels more principled or it's, it's all starting from these ideas and if you don't...

• 1:07:19Ryan Peterman?

  Satisfy these ideas as a user, yeah, well, we, you know, that's, that's fine. For instance, in one of your talks, you mentioned somewhere that there was a release of the compiler, where if a file wasn't type correct, then the compiler would delete the file.

• 1:07:37Speaker 00

  Oh, it reported the error message first.

• 1:07:39Ryan Peterman?

  Yeah, reports there, but I thought that was, that was absurd. I mean, very hostile, I guess to the, I mean, well, it's, if you're type safe, no problems, but.

• 1:07:50Speaker 00

  Oh, it was a mistake, right? It was a bug. It wasn't deliberate.

• 1:07:55Speaker 00

  And it only happened, you know, how did the bug get, you know, get out? Because of course, if it always did that, we'd have noticed. How did it get into a release? Well, it was supposed to be only on Windows and only when you compile a module that was not in the current directory. But at that stage, our, our users were very forgiving and, you know, somebody wrote to us and said, well, by the way, Simon, you might like to know that, you know, GAC does this, but hey, don't worry about it. You know, I just copy all my files somewhere else before I compile and then I copy them back.

• 1:08:21Speaker 00

  So of course, those days are long gone. We pay a lot more attention to our users and have much more rigorous CI testing than ever we did. Right? So that's a, that's a story from a long time ago, but it's a good cultural story, but it suggests that we care about our users very much, but we know, we, we care about users who want, in their, in their hearts, want to be principled. We're trying to appeal to, one, one of the things I like best about Haskell is people often say, I just enjoy writing Haskell. Right? It's fun, right? My boss doesn't allow me to because, you know,

• 1:08:55Speaker 00

  somehow it doesn't fit with my production shop and I, but, but for me, I would go for, I love writing this stuff every time, every time. That's, that's very rewarding to me.

• 1:09:07Ryan Peterman?

  There's also this interesting, I don't know if it's a cultural value, but it's a statement that you say often in the context of these older talks, that you say that you avoid success at all costs. Could, could you explain what you mean by that phrase?

• 1:09:21Speaker 00

  Oh yeah, this was just a little, a little play on words. It was in a retrospective on Haskell, I gave an invited talk at Popple in, how long time ago? Probably 20 years ago. So it's a, it's a little play on words because you can read it as either avoid success at all costs. And that's what we've been discussing. Success at all costs means compromise your principles in order to satisfy your users, or think that you're satisfying users. You know, give them what they say they want, where, or if we build it, they will come, kind of deal, right? So, avoid success at all costs. Or if you parenthesize it the other way, it says, avoid success at all costs.

• 1:10:05Speaker 00

  Or, at all costs, avoid success. And that's saying, that's a little joke, because it says, if you're too successful and have too many users, it becomes more difficult to make changes.

• 1:10:17Speaker 00

  And we experience that right now. So, I devote many, many more of my personal cycles to backward compatibility issues than ever I did. I have devoted hundreds of hours, you know, hours and hours, well, days and days, weeks and weeks in the last year or two, to the following, what seems to be a very simple property. If, if you can compile a program, a package, in a whole program, with GAC 10.0, and we release GAC 10.2, you should be able to compile that same package unchanged with GAC 10.2.

• 1:10:53Speaker 00

  Seems reasonable, right? After all, 10.2 should just be better. But no, GAC has never had that property. And making it have that property has turned out to be very, very time consuming. Previously, we just never cared. Then we started to care, but thought it was a lot of work, and now we're investing the work.

• 1:11:13Ryan Peterman?

  I guess that was from a long time ago. I think nowadays, software engineering, there's been a major shift in the last year, where a lot of code is being generated by these models or these LLMs. How do you see programming language design shifting to accommodate a world where a lot of the code is no longer written by humans?

• 1:11:34Speaker 00

  I think it may be the best thing that's happened to statically typed languages for a long time.

• 1:11:40Speaker 00

  Because, as we've been discussing, with a static type system, you cut down the space of programs that the LLM can generate.

• 1:11:50Speaker 00

  Because it is perfectly capable of running the compiler and saying, oh, darn, that was a bad program, better fix it.

• 1:11:56Speaker 00

  Right? So, a zillion iterations get done behind the scenes.

• 1:12:01Speaker 00

  Whereas in an untyped language, the first one it coughed up, you'd have had to run or run against its test suite or who knows what, but it's it gradually tightens up that cycle. Right? So I think that statically typed languages are a huge boon for L L M's. Because it's too easy to and programs are just strings, right? We could um. It could just generate the next plausible word. Uh, and you want you want to make any implausible programs, programs that really shouldn't run. You want to make them not run right away.

• 1:12:32Ryan Peterman?

  If there's a slider on, I guess, the strength of a type system and, you know, the other sides of the week. What what do you see as the absolute strongest type systems among programming languages?

• 1:12:43Speaker 00

  Oh, Haskell, I think. Haskell is exploring the bleeding edge. There is an exception, which is that module systems are a um. And in particular, sort of a functo style module systems are explored much more deeply in um the M L O camel world.

• 1:13:04Speaker 00

  And in the Haskell world, we've essentially never gone there. But otherwise, I think Haskell's right up there. Now, of course, a language like Scala um is also, as so Scala has almost everything Haskell has. I think not quite, um, but it also has subtyping and object orientation. So that's a lot more complicated, a lot more complicated, I think.

• 1:13:30Speaker 00

  And they pay a price for it. I think Martin O'Desky would agree that they pay a price for it. So uh in complexity, it's probably more complicated than Haskell's.

• 1:13:44Speaker 00

  Uh, and maybe in terms of power, so maybe I should have said Haskell and Scala are the two leading. Haskell, Scala, O camel. Perhaps I'll just put them in an equivalence class for now. They're not strictly comparable. They all have things that which they're more powerful than the other, probably.

• 1:13:57Ryan Peterman?

  What do you think are the important problems to solve in the future of programming languages today? Maybe, you know, what are the unsolved problems in the domain that are top of mind for you?

• 1:14:07Speaker 00

  I think it's actually hard to identify, you know, to say, here's a problem we want to solve, let's try to solve it. But I think another way to tackle it is to say, what are interesting, you know, new languages out there that are exploring very different parts of the design space? And there, I think I do have a candidate. So the language that is my day job, I work for Epic, and we're designing a programming language called Verse. Now Verse is a very exotic language. It's really a functional logic language, so it's yet more expressive than Haskell. It has appetitive type system, but a very different one to Haskell's. So if you like, the way I think of it is like this, if you look at C and Fortran, they look pretty different if you're an imperative programmer.

• 1:14:52Speaker 00

  But if you look at them, if you zoom out, still you can see functional languages, then C and Fortran are pretty close together, you know, along with object-oriented languages, they're all in a clump, right? And then there's some functional languages, you know, Haskell and ML and OCaml and Scala out here. If you zoom out still further, then the imperative languages and functional languages are all together, and Verse is way out here, right? So Verse is exploring a very new point in the design space. But just like functional programming back in 1980, it seems sufficiently interesting and cool and unusual and weird that it's worth exploring, right? So back in 1980, nobody would have said, we're definitely going to do functional programming, and it's going to be useful for practical applications.

• 1:15:35Speaker 00

  They said, that's pretty weird, you know, by all means, give it a try, guys. And that's kind of what I had with Verse. One difference is that back in 1980, we were purely academics, and now, but Verse is being developed by, well, Epic Games. So we've got some, you know, much more muscle behind it than, you know, was behind functional programming to begin with. So we'll see. It's a very interesting intellectual endeavor, adventure, I should say.

• 1:16:00Ryan Peterman?

  Yeah, I think a lot of people, like students, they may be worried about AI or studying computer science. Would you recommend people learn how to program today, given that AI is starting to write reasonable code now?

• 1:16:13Speaker 00

  Oh, yeah, yeah. So I think people are right to be worried in the sense that I think there's going to be considerable dislocation. Right? It's like, if you were in the Industrial Revolution, then lots of people lost their jobs as spinners and weavers.

• 1:16:29Speaker 00

  And it wasn't easy for them to get a new job in the new economy. Now, the new economy had, in the end, had more jobs. But if you were one of the people who just lost their job, that was not a happy place to be. From our perspective, Olympian perspective, a few hundred years later, we think, well, it's just a blip. Right? If you're part of the blip, problem. So I think the right to be worried.

• 1:16:52Speaker 00

  We don't know how things will shake out. I'm actually optimistic that in the medium term, if we don't destroy ourselves with some truly existential thing, but from an employment market point of view, I'm optimistic that in the end, we'll just be in a higher place, that AIs will just be a bigger power tool. I mean, everyone, we like using compilers, right? We don't like machine code anymore. Compilers make us more productive. Maybe LLMs can make us more productive. That's what I hope. I sort of believe modulo dislocation effect. Now,

• 1:17:25Speaker 00

  should we teach children or even undergraduates how to program? So I think still, yes.

• 1:17:34Speaker 00

  The reason is because,

• 1:17:38Speaker 00

  like, one way to say it is co-pilots need pilots.

• 1:17:42Speaker 00

  Right? I think co-pilot is quite a good title that Microsoft gave their tools. Right? Because it encourages you to believe it's your partner, not your boss.

• 1:17:51Speaker 00

  If L L M spit out a pile of goop and we literally do not understand what it does, but we just try it and it kind of works, that might be okay if we're just throwing up a quick visualization. It might be less okay if the quick visualization is going to drive our policy choices about as a nation, whether to go into lockdown because of Covid, or if this program is going to run my aeroplane or train signalling system.

• 1:18:15Speaker 00

  So now those are extreme ends of the spectrum, you know, from quick and dirty things, it really doesn't matter if it doesn't work, when it kind of does a lot of the time, absolutely fine. Two, this is a thirty year code base, it's going to last a long time. I really want to make sure that it's like putting new stuff into G H C. If somebody sends me a pile of A I generated code to put into G H C, I'm not going to put it in unless I've reviewed it, or somebody's reviewed it, because in ten years' time, I'm going to want to change that code. How do I even know what it does? If it's simply a magic incantation that somebody's done that kind of worked on the test they did, but maybe won't work in deployment, that's no good. So I really want long-lived, maintainable code to be well reviewed. Sorry. So and to

• 1:18:58Speaker 00

  do that, I need reviewers who can write code, who know. Let me mention one other perspective. If you think about what every child should know, when I think about whatever a child should know about computing, I would include binary and bits. Not, oh, just as for physics, I would include atoms and molecules. Now, it's not that in real life, anybody manipulates atoms or molecules, or takes decisions which are based directly on the knowledge of atoms, knowledge, but somehow, knowledge that all matter is made up of atoms, you know, constituted of a finite number of elements, that atoms, that knowledge underpins everything we understand

• 1:19:41Speaker 00

  about the natural world. If you literally had never been told that, you are sort of emasculated, as a, even as a citizen, let alone as a scientist. So if you literally do not know that everything is composed to bits, that words and music and text and L L M's and everything is all just bits, I think you're coupled. So I want every child to learn, you know, it's like I want you to learn the bottom, that it's all bits, nothing else, it's all just bits. I even have a talk, the talk is called Bits with Soul.

• 1:20:17Speaker 00

  So easy to grab for, the talk I gave to an audience that was not a computer science audience at all, it was a completely lay audience ranging from fourteen year olds to professors of quantum mechanics, pretty difficult audience to address, and it was meant to be about, all about codes and coding and bits, so, and so it tries to get at the essence of why, why do I think it's important that every, every child, every person, every human being should understand something about the computational universe that surrounds them, and that is founded in bits. Now, just to divulge the analogy a bit further, I would then say, and it also, I think, I want them to also know about programming, programs. I want them to know that computers fundamentally execute by following machine instructions blindly,

• 1:21:00Speaker 00

  right, that is not magic, it's not hocus pocus, it's just remorseless and very dumb, right, it's incredibly empowering then, and also to learn the basics about how neural networks work. In the same talk, I explain how a one neuron neural network works, and that's enough, then it's actually true to say, not distorting the facts, to say, ChatGPT is just a trillion of those wired together, and astonishingly, that very simple, so, all ChatGPT is, is a trillion floating point numbers and a lot of floating point arithmetic,

• 1:21:38Speaker 00

  that helps you to make sense of a question like, can ChatGPT have feelings? Well, it gives you, of course, that's a philosophical question, but informs your, you know, your discussion about if you know that all it is is trillion floats and a lot of floating point arithmetic, that's all, nothing more. Anyway, sorry, long answer to your question, but, so I, so yes, basic programming, absolutely, yeah, becoming very skilled in how to use, you know, web Django framework two point seven, maybe not so much.

• 1:22:17Speaker 00

  Maybe. I think one thing that LLMs are very good at is knowing the arcane and complicated APIs that many of these frameworks present. When there's just, you know, 10,000 functions you've got to know. And if an LLM is really good at knowing that, I don't want to learn them.

• 1:22:34Ryan Peterman?

  You mentioned somewhere, someone asked you, you know, what's your favorite programming language? And obviously Haskell's got to be number one.

• 1:22:40Speaker 00

  Yeah.

• 1:22:40Ryan Peterman?

  But for your second favorite programming language, you said it was Excel. At that time, why was Excel your favorite programming language?

• 1:22:49Speaker 00

  Oh, because it's the world's most widely used functional programming language. The formula language is a functional language, isn't it? Doesn't have any side effects. You program entirely with values. So the formula language of Excel is a functional programming language. A very weak one. It doesn't even let you define new functions. And it has a very limited collection of data types. Namely, just, you know, flat arrays and numbers and strings. So when I was working for Microsoft, I took it as my, what's the word? Walkie to say, let's take that idea.

• 1:23:27Speaker 00

  Excel is the world's most widely used functional language by three orders of magnitude. And, oh, not is the world's most widely used programming language by three orders of magnitude. Not just functional language. Excel is used by many, many more programmers, users, domain experts than any imperative language. Right? Imperative language is a few million users. Excel, hundreds of millions of users. Right? Even if you just restricted users who are using formulae. So how can we delight those users? Answer, take ideas from functional programming and use them to make Excel's formula language more powerful.

• 1:24:13Speaker 00

  It took me 20 years, but Excel did finally add lambda to Excel. Look it up. There are blog posts about it and many YouTube videos about it. So you can now program in Excel using full lambda as Alonso Church originally defined it.

• 1:24:32Speaker 00

  You can write anything, like because lambda is computationally complete. You can write any computation in Excel now. It would be a bit slow, but you can. And much more practically, you can take formulae that previously you just copy pasted here and there. And you wanted to make reusable, wrap them up in a lambda, and now you can just call the lambda. And now it is a proper grown-up functional language that is too incomplete. Just search for lambda Excel. Those two keywords will get you lots of raw material.

• 1:25:04Ryan Peterman?

  Last question for you is, knowing everything that you know now from your career, if you could go back to when you just graduated from college and give yourself some advice, what would you say?

• 1:25:15Speaker 00

  All of these people who you see very successful, wandering around, looking as if they've made it. I guess you might class me among them now. They are, all of them, just making it up as they go along. They feel insecure, uncertain, not sure what to do next. Not sure what their next steps are, not sure what next big problem they're going to tackle. Unsure about whether what they're doing is going to be successful or not. And so all of their confidences, I mean, they project confidence maybe. That's partly a life skill, but often they're not. And so the fact that, you know, in my, in those days, of course, I felt very not confident. I would say, you know, since all of these successful people are making it up as they go along,

• 1:26:00Speaker 00

  it's fine for you to be as well.

• 1:26:03Speaker 00

  And they've been lucky, moreover. They've been lucky. They've had.

• 1:26:09Speaker 00

  But if you want to be lucky, you do need to put yourself in a position where accidents can happen to you.

• 1:26:18Speaker 00

  And that means taking risks. So if you want to be lucky, you need to be in a put yourself in positions where lucky things could happen, right? And that means taking some kind of risks. If you're very conservative, you never take any risks, it's very unlikely that the accident that is life transforming will happen. That's a balance, of course. But it means accidents are not so bad. And of course, dying is bad, but lots of accidents may change your life in a way that might be surprising to you, but turns out to be not so bad in retrospect.

• 1:26:50Ryan Peterman?

  Awesome. Well, yeah, thank you so much for your time. I really appreciate it, Professor Jones.

• 1:26:54Speaker 00

  We will. Nice talking to you. Thanks, Brian.

• 1:26:56Ryan Peterman?

  Hey, thank you for watching this podcast. If you liked it and you want to see the show grow, please support with a comment or a like. Also, if you have any recommendations for people you want me to bring on, please drop a comment. Guests like Barbara Lizkoff, Mike Stonebreaker, Mark Booker, these were all people that I brought on because someone left a comment. On another note, aside from the podcast, I'm working on building the ergonomic keyboard that I wish existed. Here's a glance at the prototype. It's a split keyboard, so there's two sides. This is in the case. But yeah, we launched on Kickstarter and we hit our goal within eight hours of launching. I really appreciate it if you were one of the people who grabbed one of the early units. We're now working on the long journey of building the tooling now. And so if

• 1:27:40Ryan Peterman?

  you still want to pick one up, I've left the late pledges open on Kickstarter. So you can grab one there. I'll put a link in the description. Thank you again for watching the podcast and I'll see you in the next episode.