I had Casey Muratori on who is a video game developer and programming creator also known for several talks (ex1, ex2) on the history of computing. In putting together those talks he dug deep into computing history. Enough where he had interesting stories and tidbits to share.

For instance, Dijkstra wrote about his depression and there were also several famous flame wars that happened between legends in the industry. They didn’t have social media back then so they wrote letters to each other calling each other out which we discussed.

Lastly, we talked about his career and the video game industry. I was curious to compare it with big tech and hear more about his career path. He’s a great story teller so I hope you enjoy the episode!

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

01:08 - Digging into computer science history

04:08 - What shocked him

16:23 - Dijkstra was depressed

26:17 - The personal side of goto considered harmful

35:09 - The anatomy of a 35 year mistake

50:12 - Clean code horrible performance

58:33 - How to write high performance code

01:01:18 - Where bad code comes from

01:06:37 - Why design docs before code is a bad idea

01:09:20 - The only unbreakable law in software engineering

01:15:57 - How he got into programming

01:21:16 - Why he didnt work in big tech

01:30:44 - Should you work at a startup early on

01:34:52 - What video game engineering is like

01:39:57 - Why preventing recursion is reasonable

01:43:24 - Is vibe coding bad for the industry

01:50:17 - Technical reading recommendation

01:54:27 - Advice for his younger self

Transcript

01:08 — Digging into computer science history

Ryan:

[01:08] There’s this famous quote by Donald Knuth. The big part of it is, “Premature optimization is the root of all evil.” And I remember, I’ve heard that before, but I don’t think I know the full history behind it. And why is that significant?

Casey:

[01:26] So I guess we can split that into two parts. What’s the history behind it and why is this significant? The significant part is probably the easiest to answer because, for whatever accident of history, it’s something that people really remembered. It stuck. And so the reason that it ended up being significant is people keep repeating it, and they keep interpreting it or reinterpreting it. So the effects of that phrase are far beyond what anyone may have done with it in context at the time or what they meant or any of those things, or the history. The effects of it are still felt to this day.

[02:02] Some people, I think probably correctly, you might say, interpret the term with a fair bit of nuance and say, oh, well, it can mean a number of different things or it’s trying to capture something subtle or whatever. Other people are very blunt about it and just think, oh, it just means I don’t have to think about the performance of my code to the end of the project. “Premature” just means any consideration of performance is not worth it.

[02:28] Eventually, we’ll see where the code is slow and we’ll fix it or something. It’s a significant phrase for that reason, at least to me. You still hear it to this day, and it’s at least, depending on how you want to account for it, it’s at least something that’s 50 years old now. And so that’s an incredibly lasting impact for a rule of thumb, or however you want to look at it. So on the history side, this was really.

[02:57] When I decided to do a talk on this, I knew I wanted to do another computer history talk because I had given one before. This is at something called the Better Software Conference. There’s been two of them so far. At the first one, I did a history talk, and I wanted to do another history talk. And this was going to be like, I’m probably only going to do two of these, and this is the second one. I wanted to do it on the history of this phrase because when I started looking into the history of this phrase a while back, I found that there was just a lot of stuff there that I didn’t know.

[03:27] And this is true. I mean, I guess I would say every time I’ve ever looked at computer history, every time I go, I refer to it as dumpster diving. But it’s not like that makes it sound derogatory. But I think of that as kind of what I’m doing. But it’s not really like, it’s actually a very enjoyable experience to go back through history and try to pick through what happened. So to do this talk, I basically went and tried to do a pretty detailed analysis of how did this phrase end up being put in print?

[03:58] What were the worked examples at the time? What were they thinking about? Why might it have been said?

Ryan:

[04:02] What did you learn in doing all that research about these famous computer science phrases?

04:08 — What shocked him

Casey:

[04:08] The thing that shocks me both times, even though I’ve now done it twice, is the amount of stuff that you learn about what was going on at that time that you just had no idea about. It’s just mind boggling. And I would point out that this is for a talk. I’m not a historian, I don’t do this for a living. I’m not at a university somewhere doing computer history research. So what I think of as a pretty thorough read for the history that I did for the talk is actually somewhat shallow.

[04:39] If you had time and the resources, you could go access some of these people’s personal papers, make appointments to see things that are not really in the public record so much, and so on. So even just with publicly available things that you can get, the amount of stuff that I found was just really kind of intriguing to me. And so I’ll give kind of a brief overview of sort of what I thought was the story of this kind of phrase. In a way, I think there are kind of two.

[05:10] I guess I would say there are sort of two threads that are good to understand that come together. And this is what I tried to portray in the talk as well. The first thread is this idea of a thing, and we didn’t really do an intro to this podcast, but I’ll say it now. I’m a big fan of your show. When you said, do you want to be on the podcast? You didn’t have to tell me what the show was. I’ve already watched it.

[05:34] I love it. And one of the people you had on, for example, was Barbara Liskov. And in that interview, she actually refers to something called the software crisis, right? And I think you prompted her a question about this as well, right? So a lot of people don’t really know about the software crisis. They don’t know that that was a term. They don’t know. This is something that happened because it’s kind of ancient history now.

[05:58] It was in the sort of late 60s, early 70s. This was the thing. What this was is originally computer hardware, in a sense that you or I can’t really conceive of it in practice because it was so far before our time that basically computer hardware originally was very simplistic. And so the things that you were going to do with it could be described very easily. And really all you were trying to do when you programmed a computer was just translate a fairly straightforward definition of some computation into machine instructions.

[06:36] The kind of thing that we would think about today as hand optimizing assembly code was really just all computer programming was. It was just like, okay, we’re going to take this problem description and translate it in. But during the 60s, computing power was advancing to the point where people could consider doing much more significant things with it. They could run payroll systems, they could do analysis of data sets, and they would want to be able to be flexible and change the sorts of computations they were doing and all these other sorts of things.

[07:06] They were starting to have graphical displays. Ivan Sutherland’s Sketchpad is in the early 1960s. What they found was that at that time, programmers were not really ready to make that transition. They didn’t think about things the way we all now take for granted, where it’s like, oh, yeah, I built this library for loading JPEG images, and now when I want to load a JPEG, I just call load JPEG and it’s done.

[07:32] All of these things that we take for granted all had to be a cultural shift. The idea that there were going to be these abstractions and these ways of sort of breaking down a much more complex system into parts that we could manage, that actually was a transition that had to happen. And so the software crisis was kind of this period where people were starting to say, the methods that we’re using for programming will not scale to these larger problems that we want to do.

[07:59] We’ve got to figure out something to do about it. So that’s one thread of history that’s coming. Another thread of history that’s coming. It’s a little bit more specific to Donald Knuth, who was the first person to really put this into a worked example. He’s kind of who I would credit with the origin of this phrase, even if there are people who might debate that fact. And to me, it doesn’t really matter who said the phrase.

[08:23] The phrase lives on its own. So I wouldn’t even argue with someone if they wanted to sort of make other claims about it. But just in general, he was going, like, at Stanford at this time, he was sort of learning about the fact that you could do these profiles, like taking actual execution profiles, figuring out where time was spent in the execution of a program and using that to guide your decision-making about where you’re going to spend time developing the software.

[08:55] Again, something that even today, performance is maybe not as much of an emphasis as it maybe should be in software. But even today, with that in mind, most people understand the concept of an execution profile. They understand that you could go into Chrome and see a network profile of how that’s working. You could see a flame graph of where time is being spent, or all these sorts of things. Again, you have to remember, if you rewind the clock back far enough, these were all brand new concepts, right?

[09:24] A sampling profiler, a block-based profiler, a binary instrumentation profiler. All these sorts of things were not just tools that everyone assumed that they could just go have and had seen at some point. Some people may never have even realized that was a thing. So that’s another thread that’s happening. And those two things converge effectively in 1974, right? Roughly. To get us this statement, Knuth is very much into this idea of structured programming, which is sort of a proposed solution to the software crisis.

[10:02] Maybe a proposed solution is the wrong way to say it. It’s a certain set of ideas that are trying to be employed to improve the situation. Let’s say he’s very much into this. We can talk about what that is as sort of a separate tangent if we want to later. He’s very much into that. He’s thinking about that. He’s thinking about this idea that programmers can’t just be about writing all of this very tightly optimized assembly language code.

[10:31] And that’s all we’re going to spend all our time doing. We have to be thinking bigger picture. We have to be picking and choosing our battles. We have to make concessions to maintainability. If this particular routine is not really accounting for hardly any of our runtime, we should not be obfuscating it with all of these hand-unrolling the loops and all these things. Remember again, underlying all this, they don’t have massive optimizing compiler passes like we have with LLVM now.

[10:57] They don’t have all of this extra stuff. So if you wanted something unrolled, you were going to unroll it yourself. If you wanted some kind of loop, hoist a loop invariant out, you probably had to do that yourself. A lot of that stuff that we take for granted today, again, not in there. So that sort of. He’s very unstructured programming. He’s starting to see these execution time profiles. They do a thing at Stanford in 1970, actually he does it with some students where they take a look at FORTRAN programs and they instrument them to see where the time is being spent.

[11:26] Not in exactly the most rigorous way that you might imagine. That’s another thing from my talk that I kind of go into. But he’s sort of saying, look, we as programmers need to start taking the decision about what to optimize more seriously. And he kind of has a fairly nuanced take on it. If you actually read the section of his 1974 paper Structured Programming with go to Statements where kind of the first time this was really put to print that I know of.

[11:54] He does say it in an ACM Turing Lecture a little earlier, but he would have submitted the manuscript for this publication prior to the lecture. So it was the first time that I know of that he actually committed it to paper. It would have been there. But he may have said this a lot in lectures. He kind of obliquely refers to that in the Turing Lecture that maybe he had said this around town, so to speak.

[12:20] So where this was first uttered, I don’t think anyone knows. But the point being, when he says that phrase, it’s in this context of saying, look, we need to be very concerned about efficiency. We shouldn’t be leaving performance on the table when it matters, but at the same time, we need to know that it matters. If we don’t know that it matters, then we’re going to apply this optimization. That’s a premature optimization, and it has real cost.

[12:48] It’s going to make our maintenance and debugging of this program worse for all the same reasons that it would make it worse today. If we go into something and we start applying these optimizations to it that are above and beyond the kind of structural things that we might be doing to that code otherwise, that’s creating a cognitive burden that other people are now going to have to deal with, and you’re going to have to deal with in the future.

[13:10] So I don’t want to put too many words in Knuth’s mouth, certainly, but in general, that’s sort of the way that this comes together is those two things, this idea that we need to be doing things to solve the software crisis. How have a more structured approach to programming, care about maintainability and debugability, composability, abstraction, all that stuff. But also at the same time, we do care about optimization.

[13:33] So how do you dovetail those things? “Premature optimization is the root of all evil” is kind of like this phrase he uses, I would say, if I had to imagine his way of sort of reminding himself, think about all this before you make a decision. Right. That would be kind of my take on it. Right. And where it comes from. So hopefully, I don’t know, that’s very long, but it’s a very expansive question. So hopefully I’ve kind of wrangled most of the stuff into there.

Ryan:

[14:00] It sounds like this is really an engineering tradeoff, where the software crisis is about the maintainability and the complexity for people to actually write and handle their code, and then the tradeoff between performance and, I guess, code that is maintainable. And it sounds like this Knuth quote is, be mindful of where you pay that cost.

Casey:

[14:29] Yes. And it’s always important to understand the context in which this was said historically. So I want it to be a historical talk, because who your audience is is a large determiner of what the root of all evil is. If you’re talking to a bunch of people who don’t think about optimization at all, then you don’t really need to say this phrase to them. If you fast forward to today, when a lot of people don’t really take optimization into account at all during their programming, or very, very little, this phrase doesn’t make very much sense to someone who does care about performance, because it’s like why would you ever say that?

[15:08] It just seems like it encourages people to not be mindful of the performance of their program. But if you rewind to that time and you understand that, well, a lot of the programs, you know, they had the opposite problem. A lot of the programs at that time, what programming was, was coming up with all these crazy little assembly tricks to shave a cycle off here or there, right? And if you’re talking to an auditorium full of people who are really into that sort of thing, then it really can be the root of all evil, right?

[15:41] It’s like you guys are spending all your time on this, but we have this really big other problem. And that is not the right tradeoff, right? That is, you’ve swung, you know, like calling it tradeoffs is a great way to say it. You’ve swung the pendulum way too far in one of those directions at some point. And so to some degree, while I would highly dispute the description “root of all evil” today as a good thing to say to somebody, or that it leaves a good impression, when we rewind to that time period, I think it makes a lot more sense.

[16:12] Because when you look at what people were actually spending their time doing, where their priorities were, I think that maybe that wasn’t so much of an exaggeration. I mean, obviously it’s hyperbole, but it’s less of one.

16:23 — Dijkstra was depressed

Ryan:

[16:23] In your slides, there were so many quotes and snippets of really kind of digging into the true history. Was there anything you found that surprised you when you were doing the research?

Casey:

[16:33] I mean, constantly, absolutely constantly. And first of all, I’ll just say that there’s, as a meta point, I’ll give you a specific thing that surprised me that’s kind of funny. That’s more about a technical thing. But first I want to talk about a broader picture, which is one of the things that really hits home for me whenever I do these, is the personal aspects of it. These people were friends and competitors and all these sorts of things.

[17:08] And it’s all kind of lost to us in a way when we think about computing history in a sterile way. When I read up on what Edsger W. Dijkstra wrote, Dijkstra was the person who kind of kicked off structured programming. No, I’ll call it a revolution. That’s a bit too probably grandiose, but he kicked off that train of thought. He wrote a thing called Notes on Structured Programming. It was a manuscript or a monograph, I don’t remember what they called it.

[17:39] Got a typewritten thing. It looks exactly like a typewritten thing. Right. When he wrote that, he was very depressed, like he was having a lot of trouble in his life at that time. He had gone through this situation where they had done what people today now recognize as pioneering work in distributed computing. He and these other people at Eindhoven University of Technology.

[18:07] I apologize, I can’t say the proper name for it; it’s well beyond my pronunciation capabilities. But point being, he had done this really foundational work in distributed computing and published it, and people today now recognize it as that. It is undisputedly a massive contribution to distributed computing. He did it with a part-time team of people at the university, who—this wasn’t their job; it was a mathematics department they were in.

[18:34] And as a result of that, basically they sort of just got dissolved, like the Department of Mathematics. I guess he wasn’t really specific about it, but in his notes the Department of Mathematics was just like, they disbanded the team. It was like, this isn’t math or whatever, I don’t know, they just had a pessimistic view of it. And he was really depressed about that, and he wasn’t sure what he should do with his life and, what’s the deal here, right?

[18:57] And he was having this sort of, I don’t want to call it an existential crisis because I don’t want to again put words in his mouth. These are historical figures and, you know, I can only. That’s why I try to use quotes to try to show you like what they said. But that’s, it’s just so relatable when you go through the history this way. It’s not just some random guy who wrote some math down in a paper.

[19:17] It’s like people were really struggling with this, and some of the most important aspects of computer history come out of these amazing human stories. And I found that absolutely fascinating. So I’ll just put that out there as one of the biggest rewarding things about looking into this history, if you ever do it, is if you can go find the actual writings of the people, like things outside of just their technical papers.

[19:41] It’s just fascinating. And it’s so much more relatable and fascinating because you feel the story. It’s not just this abstract computer science thing that happened. So that’s one thing. But the other thing I was going to say is when you read through this stuff, I just go through piles of documents and I’m just reading them and seeing, does this fit into this story? Should it be part of what I’m telling, or is it extraneous?

[20:07] Is it something that is interesting, perhaps, but not actually part of it. And one thing that I found, when the VOD of this lecture or talk goes up, I’m going to include this in the notes because I thought it was so fun, didn’t make it into the talk. I found a thing, like a thing from Tony Hoare. So C. A. R. Hoare, who again is another massive figure in computer science. Hoare, Dijkstra, and Knuth are like the three amigos.

[20:38] And they all write to each other. They’re very important people in computer science history. So I found a thing by him that was like a thing he did not decide to pursue. It’s like this note where he’s talking about—he’s talking about this thing that he’s thinking of doing, and there’s just a handwritten thing on him from later on in his life, when he was, I guess, categorizing these documents, and he just writes down, like, I decided not to pursue this because I talked about it at this conference that I was at.

[21:10] And Peter Naur, who’s again another famous figure in computer science history, if you’ve ever looked at context-free grammars and parsing, you’ve probably heard Backus–Naur Form. He’s the Naur in Backus–Naur Form. If you’ve ever heard of the language ALGOL, he was a major figure in standardizing that and writing up the standard and all this stuff. Anyway, Hoare. Yeah, I proposed this thing, I went through and said it, and Peter Naur was like, making multipass compilers is easy.

[21:40] I just wrote a nine-pass one. So I decided not to pursue this. So what’s the thing? I read through the thing and maybe I’m just overreading it with the benefit of hindsight, but he pretty much describes static single-assignment form, like SSA, which is a very standard compiler technique developed in the ‘80s. But this note is from the ‘60s. So it’s like, in my head, I’m like, did Peter Naur accidentally set back compiler science by 20 years by telling Tony Hoare?

[22:18] Well, 15, let’s say, by telling Tony Hoare this is not important, when actually it would have been very, very important. You find stuff like that all the time where you’re like, whoa, what is this? I saw another one too. Just one more I’ll mention. I can’t remember now, I’m sorry again. Your brain kind of turns to mush when you try to dump this many documents into it for a talk. But there was a pretty interesting thing, I thought, where Margaret Hamilton, so the person who managed the Apollo Guidance Computer, she was one of the core programmers originally on the project and then was the manager of the whole OS, like the whole real-time software that ran the Apollo 11.

[23:03] Well, all the Apollo Guidance Computer stuff, right? Which I mean, most people today herald as a very, very significant real-time systems achievement in that era, right? Everyone pretty much agrees with that. She had to write a defense. I think it was in Communications of the ACM, maybe it was in Datamation. They say—apologize. I can’t remember the venue because it had been pointed out as a failure because people didn’t understand the context that the reason that the Apollo computer had to trip those alarms was because that had been used improperly.

[23:40] It was used in a configuration that wasn’t supposed to. And it actually, rather than crashing, went into backup modes and successfully landed. It worked. It actually was a triumph of fault-tolerant engineering. And she had to write a defense of this because people at the time were saying, “Oh, they screwed up. This is an example of why you wouldn’t want to do engineering this way, or don’t write the code this way.”

[24:03] And so again, stuff like that always makes me think, the more things change, the more they say the same. That’s exactly what would happen on Twitter now, right? Some very successful thing that people did, right? They would just get slandered and say that it was done wrong, and there would be a flame war, and then they’d have to come out and have a thing. So anyway, those are just some examples.

[24:23] But there’s so much great stuff in there. I highly recommend it to anyone who likes this kind of thing. You won’t be disappointed if you go dumpster diving, as they call it.

Ryan:

[24:32] When you said that you saw the human stories and that Dijkstra was depressed at that time, what did you see that made you realize that?

Casey:

[24:42] One of the nice things about Dijkstra is that he’s kind of a pretty straight shooter. And so I didn’t actually have to do any interpretation. He literally talks about being depressed. There’s a paper, not a paper, like a thing that he did that’s like a retrospective that’s handwritten by him later on in life. And he literally says, in this period I was very depressed because of these reasons.

[25:12] Now, he could be wrong about the source of his depression. Right. So I don’t want to claim that just because he said it, it’s necessarily true or something like that. But one of the amazing things, I think one of the really cool things about academics, especially that era, is they just produced a voluminous amount of material, and so we don’t have to guess that much. In the private sector, I think it’d be a lot harder, like if you wanted to know what people at maybe Lockheed or something were thinking or doing at that time.

[25:47] I imagine it’s much more difficult just because things are classified or they’re not academic, so they’re not necessarily going to write them all up. So a lot of the internal stuff when you write them, academics don’t really have that. They don’t have an incentive or a prohibition on writing up everything they do. So they don’t just have to have a public-facing statement of what they did or a public-facing paper of what they did.

[26:07] And then, oh, there’s this extra secret stuff. The academics don’t have that restriction. They’re sort of... They benefit from being as forthcoming as possible about what they’ve accomplished, usually.

26:17 — The personal side of goto considered harmful

Ryan:

[26:17] I saw in the slides that you looked at Go To Statement Considered Harmful. That email, do you have any sense of the personal or people side of that?

Casey:

[26:28] So you’re talking about the original Dijkstra letter to the editor. That’s like Edsger W. Dijkstra’s Go To Statement Considered Harmful. The complete story is actually relatively simple according to him. He was at a conference in Tennessee where he was talking to Brian Randell, who’s another computer science guy. He doesn’t quite get the same level of name recognition as a Knuth or something like that, but he has a lot of papers at that time.

[27:04] You can go find him. He’s not obscure. He’s not an obscure figure. I wouldn’t say to anyone who reads the history. You’ll see him come up. He’s talking to Brian Randell and some other people outside. This is exactly like the same thing that happens at modern conferences. There’s the talks and then there’s all the stuff that goes down at the bar. Right. It’s very much that. They’re outside, they’re talking.

[27:25] And according to him, he’s basically giving the same sort of example of a problem with the Goto that he gives in the paper. Right. This idea of enumeration, we can talk about that later. But sort of a side note, he’s sort of saying, like, this is kind of a problem with Goto. And one of the reasons that maybe it’s not such a good idea. And the people who were listening to him were like, Brian Randell and the others were like, you should publish that.

[27:56] That would be helpful because there’s these arguments going on about whether GOTO is good or bad. That was kind of happening at the time already, since around 1959 even, I think there’d kind of been a little bit of that, had been kind of growing, this idea that maybe Go To Statement Considered Harmful wasn’t the best idea as a way to structure your programs. And so he does. He goes back to Eindhoven University of Technology and he writes up this same thing he was saying, basically, and he sends it to Communications of the ACM for publication.

[28:29] Niklaus Wirth, who is the creator of Pascal, a very prominent figure, also was very heavily involved in ALGOL and all this sort of stuff. Language designer guy, he is the editor who is in charge of getting this thing published. I guess I’m not exactly sure how things work at Communications of the ACM. He doesn’t want to wait to have it published. He doesn’t want to take the time to go through the referee process or whatever.

[28:58] I don’t know at that time what the requirements were for publishing an article in Communications of the ACM, but I’m sure that it involved a lot of procedure. It wasn’t just like, oh, hey, I’m the creator of Pascal at that time. He wouldn’t have been the creator of Pascal yet, because Pascal comes later, I think. But either way, he’s like, hey, I’m this important guy. I’m just going to put this whatever I want.

[29:19] Communications. That’s not how it worked. And so he decides that in order to get it published more quickly, he’s just going to publish it as a letter to the editor. Because then there’s no anything goes there. As long as the editors are fine with the content. I assume it doesn’t have to be refereed, it doesn’t have to have any kind of review. It doesn’t have to be, et cetera, et cetera. So he turns it into a letter to the editor and he takes the name of the thing that Dijkstra sent, which was A Case against the GO TO Statement.

[29:47] That was what Dijkstra wrote at the top of the thing as the title. He changes it for letters to the editor to Go To Statement Considered Harmful. Right. So it wasn’t even Dijkstra’s plan to have it maybe be that confrontational. But that’s what happens now. This is not well received, to say the least. According to Knuth, again, I’m just trying to say who said what here. According to Knuth, Dijkstra said he got letters, angry threatening letters, in much the same way you would today.

[30:34] Got people who were very abusive, telling him off. I’m sure part of that is because by all accounts, Dijkstra himself was also somebody who liked to push people’s buttons. That’s well acknowledged. I think Alan Kay is probably the best source for this. He talks about this. He liked Dijkstra, and they apparently got along well. But he’s often said that Dijkstra was someone who kind of leaned into being sort of brash about stating things about programming and kind of relished that position.

[31:07] So it probably didn’t help that he was already sort of known a little bit in that way. But in general, that’s how it went down. And, like I said, that wasn’t the initial foray against Go To Statement Considered Harmful by any stretch of the imagination. But it just kind of maybe, you call it the straw that broke the camel’s back. It was like a flashpoint, might be the way to say it. And then the title, of course, that Niklaus Wirth picked is quite the doozy and kind of clickbaited everyone, as I call it, into that soap.

Ryan:

[31:43] It’s funny because, I mean, social media, it’s similar patterns. People have very explosive first lines, and then the comments are full of all this hate and stuff. In their case, I’m guessing this is all papers. So you submit a letter to that. It’s a physical thing, and people are reading maybe a newspaper or something. I don’t know.

Casey:

[32:05] Yeah, it’s like a periodical. It comes as a bound. I mean, I guess there’s. All the things around us here are hardbound, but it’s like usually with soft. It was a maybe a perfect binding kind of bound thing that has you open it up, table of contents and letter to editor. Right. And yeah, like you can go find. There are a few. If you go look at people’s personal papers, which, like I said, if I did this full time, I’m sure I could find out way more stuff than I did.

[32:34] Right. But some people have gone and looked at the personal papers, and occasionally some of them have been able to digitize some of those and put them online that we can look at. And you can find, for example, online right now, if you search for it, there’s a back-and-forth letters, personal letters between Edsger W. Dijkstra and a guy who is kind of into functional programming and promoting that. And you can look at the correspondence, and it’s kind of.

[33:02] It’s a little, it’s a little flame war. Like, really, like that’s what they did. They didn’t have the ability to do, like, pithy Twitter replies, so it was just on paper. And Knuth did something similar. It wasn’t really a flame because he had, at least when reading comes through, a tremendous amount of respect for the authors of the book Structured Programming, which is Dijkstra, Hoare, and Dahl.

[33:32] One of the things that he published was a series of open letters to them reviewing the book and talking about the things that he didn’t find compelling in it. Very respectful. So it wasn’t. That one wasn’t a flame war. But that’s what they had to do because they didn’t have social media. So Edsger W. Dijkstra wrote all these things called EWD with a number. It was his initials, basically, and then a number.

[34:00] And that’s like this serialized list of all the things he wrote. And he labels them this way. It’s not like some historian characterizes it after the fact. It’s like, oh, I’m doing. He’s like, I’m doing EWD 937 now or whatever. Right. It’s hilarious. But anyway, several of those have been put online that are not necessarily technical. For example, his trip reports. You can go read those and you can read about, oh, I went and stayed at, like, such and such’s house and we went to dinner or whatever, right.

[34:31] So you can find some nice personal anecdotes in even the publicly available stuff. But in terms of a real heart-to-heart conversation, I didn’t have access to anything like that that wouldn’t have just been in a paper, more or less, normally. So it’s a shame. One of the problems with this stuff is it’s so interesting, but it’s not a job to do. If somehow it was a job, I probably would almost take that job.

[34:58] Being the person who crawls through and tries to redocument this whole thing. But, no, computer historian, no one’s hiring, no one’s interested in paying for that.

35:09 — The anatomy of a 35 year mistake

Ryan:

[35:09] You have this other talk, and the title was just so catchy. It was “The Big Oops: Anatomy of a 35-Year Mistake.” What is that? 35-year mistake.

Casey:

[35:21] So this was a kind of funny thing that happened to me that I then did a historical lecture on. I had worked on systems in the past that were basically like editors. You have 3D graphics editors. You have to multi-select things and move them around. There’s a bunch of architecture things you have to learn to be able to write that kind of code and certain kinds of problems you have to solve. A very basic one that I would point out that hopefully most people can relate to would be if I have a bunch of things on the screen, some of which have a color.

[36:00] So maybe this is a drawing program and I’ve got some text and I’ve got some shapes and I’ve got some strokes, some hand-drawn stuff, whatever, and I want to be able to select a bunch of them, and I want the user interface to present to me which things I could edit on these shapes. So I want to be able to edit the color, and I want it to apply to all of them. Right. This is just a basic architecture problem that you have to solve if you’re going to write one of these programs and you want it to be any good.

[36:26] Now, oftentimes, you will see programs where the person didn’t solve this problem, and you can’t do that. It’s very frustrating, right? So a good program, someone has solved that architectural problem in some way. And I was watching, I just happened to be watching because sometimes I do like to watch old videos of computer science pioneer stuff. And I was watching a demo of Sketchpad. I’d seen it before, but I was watching a demo of Ivan Sutherland’s Sketchpad.

[36:53] And Sketchpad, for those who don’t know, is a groundbreaking computer graphics program. It’s done with a light pen, and it was done in the early 60s. And you could draw things like you do in a modern CAD program, and you could do stuff that even a lot of modern CAD programs don’t really offer or only offered recently. I think in the talk I said in 2007 was the first time that AutoCAD got some of these features.

[37:19] You could do stuff like say these two shapes, this line has to be perpendicular to that line, constrain it, and you could just do whatever you want with the drawing and it would resolve for making that happen. And these are very rare in programs even to this day. That’s just not a common operation you would see in a drawing package today. I was looking at this and I was like, how the heck did he solve this architectural problem?

[37:46] How did he do this stuff in the early 1960s in assembly language, with no editing tools, no debugging tools? I mean, this would have been like either punch cards or one step away from punch cards. It would have been hard to develop this stuff. And when I went back and I went through his thesis and I looked at the code, it’s actually documented how he did it. And I realized, like, oh crap, this is actually like an entity-component system.

[38:18] Basically what we would now consider sort of state of the art of real-time architecture for doing these kinds of operations, meaning cross-cutting, operating on this kind of property across many things at once that are all kind of different. And this was something that object-oriented programming — I’m editorializing now, a bunch of people will complain that I’m saying this, but this is just my opinion.

[38:47] Object-oriented programming and the pedagogy around it really struggled with that problem for a long time because they were teaching, despite people who will now claim otherwise. I document it very completely in the talk, so I don’t think they have any leg to stand on. But the pedagogy at the time was all about build a domain model. The domain model looks like your hierarchy. Basically, like I’ve got employees and employees, I’ve got contractors and I’ve got derived, like is this a full-time employee or a part-time employee?

[39:15] That was how they suggested these things should be implemented. That kind of architecture doesn’t work for these kinds of operations that I’m talking about. Entity-component systems do. And generally, that kind of rotated architecture, I might call it, does work for these. What I call the 35-year mistake is the fact that I very ironically, in my opinion, Sketchpad sort of showed in its architecture how you could solve this problem and how you could solve it in arguably an object-oriented way.

[39:52] I think if you squint at it, a person who does object-oriented programming could easily make an argument that you can do an object-oriented version of this. You don’t have to violate any particular principles to do it. It’s just not the hierarchy domain model way that people were conceptualizing it through a lot of the 80s and 90s, let’s say, and even unfortunately to this day. But I think a lot of object-oriented programs don’t do that anymore.

[40:17] Ironically, that was in Sketchpad. The DNA was there, and we could have had it right away because Ivan Sutherland figured it out. But weirdly enough, the whole idea of this sort of inheritance hierarchy with lots of encapsulation around it grew in part out of Sketchpad because Alan Kay looked at it and said the interesting part of this is the fact that you could take a shape and not know what it was and just have this draw circle call on it or something.

[40:49] That was the part they took away from it, which is much less interesting in my opinion and not that architecturally useful in most cases. So in kind of this amusing way, Sketchpad contained, if I’m editorializing, it contained what I consider to be a good architectural idea, but the takeaway from it was a bad architectural idea, is how I would say it. And saying bad architectural idea is a little bit strong because, as I say in the talk, I think there are times when you do want to think very high level.

[41:17] You might want to think about things in kind of the way that Smalltalk thinks about them. So I don’t want to say bad idea in the absolute sense, but bad in the way it ended up being applied, let’s say.

Ryan:

[41:29] Why does that class hierarchy not work for this problem?

Casey:

[41:33] It’s pretty easy to understand, actually. So when you think through an inheritance hierarchy that’s based on sort of what you see in the real world or what you’re trying to model. So you say, the typical example, and it’s brought up tons of times by people who wrote the OOP literature, like Bjarne Stroustrup, like the Smalltalk people, the idea is keeping it with a Sketchpad example, I’m going to have a shape.

[41:58] From the shape, I’m going to derive triangle or circle. And the encapsulation is around that thing. So a circle has a radius, but shapes don’t have radiuses. Shapes don’t necessarily know what that is, right? So it tends to get deferred down and the encapsulation boundary is drawn around that sort of derived class. That’s, like, the most derived version of whatever this thing is.

[42:25] The problem is that creates a lot of headaches when now something that wants to work across a lot of shapes needs to actually do something intelligent with modifying, say, the scale of something or wanting to change its color because it doesn’t really have a way to know what’s going on in these highly encapsulated things. So typically what you end up having to do in those situations is you then have to take this inheritance hierarchy and kind of, in a sense, throw away the benefits of it.

[42:57] You end up having to make at the top all of these accessor iterator things that allow you to probe into that lower class and say, tell me all of the colors that you might be using and a name for them. In a sense, what you end up having to do when you want the architecture to work is you have to rebuild the Sketchpad version on top of the inheritance hierarchy version, which doesn’t really do anything for you.

[43:24] And it’s not to say that there isn’t some benefit that you can derive from having derived is kind of a pun here, I guess, that you can derive from having this idea of saying this thing is like this other thing. Please give me some of the implementation of it. That’s not necessarily a bad thing in practice. The problem is when you teach people that this is how it’s going to work, like you just make this hierarchy and then your architecture is just supposed to work, it really ill-prepares them for the reality that that’s actually not going to solve most of the problems that you have are not going to be solved that way.

[43:56] And again, it just comes from this fact that typically when we’re working with computer programs, most of the time what we need to do is create cross-cutting operations that work with a lot of the data that’s inside these derived classes. That’s actually the thing that we want to do. And it’s really cumbersome and typically a bad fit for the problem space to put that into some virtual functions that are sitting at the top of this very sort of tall hierarchy.

[44:23] It’s usually much better to do. Again, even if you’re doing object-oriented programming, you don’t have to stop doing object-oriented programming. You just have to think about it differently. You have to think about what the objects are differently, where you’re drawing the encapsulation boundaries. It just helps to think about it differently and say, actually, the more important things to model are what are the things that stuff is built out of?

[44:44] How do I build a circle out of objects, right? What are those things? A radius property, a center property. Those maybe should be the objects that I’m thinking of as more first-class citizens. And this inheritance hierarchy stuff about what the objects are that I see on the screen, like triangle and circle, that’s a distraction. That’s not the proper way to model the problem. And again, I don’t think I would be pissing off any object-oriented programmers by saying that today because I think a lot of them use architectures that do think about objects in that sort of rotated sense and not in the domain model hierarchy sense.

[45:20] Not that there aren’t still people who are doing that. But it’s not the only way to go nowadays. It’s not the only way that’s promulgated.

Ryan:

[45:28] because I guess my immediate thought would have been in that case, the base class has the notion of a color or some shared thing, and we just operate. If you’re a shape, then we assume you have a color. But you’re saying refactoring and putting up in there is suboptimal and you want all these subclasses to have some handle to some radius property or something like that.

Casey:

[45:54] Is that what you just described is what tends to happen in systems that are architected this way? You end up with your derived class not really being very much of anything because in order to edit stuff, you had to migrate it all up to the top. And there was actually terms for this in the old days. I don’t still use, like, fat base classes, right? Or things like that. It just ends up your base class has every type of property that any derived class might ever have.

[46:18] You have get primary color, get secondary color, get tertiary color, right? Because something needed three different colors or whatever. And most things don’t use those colors and all these other sorts of things, right? There’s certainly nothing wrong with running a program that way. It’s just, again, why did you bother with the hierarchy? You’re not getting any actual encapsulation benefits from it because you just forced everything in the base class anyway.

[46:41] So why didn’t you just make that be your thing? Just make one class called Shape and be done in terms of the ECS style of implementation. I don’t necessarily want to advocate for it or not because I don’t actually personally use ECS or anything like that, but they are very common. Now the idea there is to just turn it on its side and say, look, typically what we want to do is do things like, okay, there’s stuff that has physics on it.

[47:09] I’m doing this thing, and I want to have physical simulation of entities. Well, the physics system is the thing that probably knows how that should be stored. So rather than having that be data in my derived class that’s encapsulated around the derived class, instead, why don’t I just have the physics system know what physics is, and then if you want to make something that participates in physics, you just have a handle for whatever this thing is, like a handle for my shape.

[47:36] That handle is valid in all the systems. So I can look up the physics properties of the shape and gather it when I want to actually do something with it. But generally speaking, the encapsulation stays around the system. So physics properties are defined by the physics system because, hey, that’s who knows how physics should work. And I just ask about my physics when I need to do something with it.

[47:59] And this kind of gets you out of that problem. And then now you can just compose things. Oh, I want to make something that has several physics elements in it. Fine. I can just have multiple physics handles if that’s what I need, or something like this. I can very flexibly merge these things together. I want something to not have physics. I just don’t ever insert the. I don’t ever ask the physics system to have a valid piece of data for this handle in it.

[48:21] And it won’t simulate any physics for it. Right. Whether that’s the world’s best architecture or not, I’m not going to argue for it or against it. It’s just a lot better than domain model hierarchies, that I will say, right?

Ryan:

[49:31] Earlier we talked about the tradeoff between, I guess, performance code and maintainable code. And I saw you had this one video. It said in quotes, “Clean Code, Horrible Performance.”

[50:03] I feel like this is on the same topic. What’s your take on that? Because you also put Clean Code in quotes. What does that mean?

50:12 — Clean code horrible performance

Casey:

[50:12] So it’s a fairly subtle topic, right? And that’s why the quotes are there. Because the first thing that you have to point out is that clean code is clean code. Object-oriented programming. A lot of these phrases, they mean different things to different people. And so if you’re going to say that this code is clean, it’s pretty hard to find two programmers who will agree on exactly whether it is or not.

[50:39] They all have different ideas about what is clean and what is not. The reason I put that in quotes is I was talking about a very specific thing, which is literally the book Clean Code. The thing where there’s, here are the things that we would recommend that you do in that particular case. What I was talking about is there’s a certain set of ideas that is advocated in Clean Code as these are the things you should do.

[51:04] And they are like you should have everything should be kind of, I guess I would say dynamic dispatch, or at least code shouldn’t know the types it’s operating on, right? Saying it’s dynamic dispatch is maybe it depends on the language whether that’s going to be true or not. But when I write code, I don’t know what types I have. It’s just, I don’t know. Some base classes is what I’m operating on, and they could be anything.

[51:28] That’s thing one. Thing two is functions should be very small. In fact, the numbers are kind of weird. They’re like four lines or five lines. When you go look at the actual things that are claimed in some of this literature, it’s really strange. You’re just like, gosh, that’s very small, right? And I go through some of those things and I say, look, if we were to actually follow these, we get into a really bad state because a lot of the languages that people are going to be using to implement this stuff, like C, for example, which even would be a fairly good case in a lot of cases.

[52:01] At least it’s a compiled language and so on. In a lot of cases, these things are kind of a recipe for disaster. If you’re handing out types where you can’t know the type at compile time, or you can’t know the type, or it’s going to be in a different module, so unless you have really aggressive link-time code generation, it’s not going to be likely that you could figure this out. And you’re saying all the functions should be very small.

[52:24] And of course they’re going to be virtual because they’re on these sort of types that you don’t know what they are. This creates a really toxic combination for the compiler. Normally you can have— I mean, you can have small functions if you want them only four lines long. If the compiler can know that, it can just inline that, right? If it can see clearly what you’re doing, it can just merge those things in. We don’t have a problem if they’re behind a virtual function.

[52:50] So it doesn’t know, it can’t guarantee that it is that type. It can’t do that. And so when you talk about all this stuff, what you’re giving up... People, I think, also because the video—I mean, the video was a very short video as part of a series—I think people sometimes get the wrong idea that I think that virtual function calls cost a lot. They do cost something, but depending on how you want to look at it, they actually don’t cost that much because it depends on whether it’s predicted correctly or not.

[53:19] But in general, the cost of a virtual function is less than you would think a lot of times. The actual reason that it slows things down is because the compiler cannot merge the code together. It can’t inline stuff and remove and reduce the waste. That’s the actual problem. So if you just want to call a virtual function, yeah, if it was a really, really hardcore optimization scenario, then you don’t want anything, probably calling a virtual function in general, because there is some cost to that.

[53:45] Just calling a function has cost. But that wasn’t the really bad part of it, right? So it’s that. Plus there’s an additional thing, which is that it can’t unroll and go wide on things. If the compiler can see everything you’re doing, it can use SIMD, it can widen loops to operate on multiple things at once. It can unroll those loops. There’s all these things it can do. If it’s got these virtual functions, it’s just like, that’s it.

[54:08] I don’t know. I can’t make decisions about that. I have no idea what this thing on the other end is doing. That was my point on that. And again, it’s not meant to be assailing the idea that your code should be easy to read or easy to maintain. It’s just more like these guidelines seem really bad. And also, I don’t think we need them for code to be maintainable. I don’t have trouble maintaining functions that are 30 lines long or 50 lines long.

[54:33] I don’t find that five is a magic number or something, or that it has to be really short. And also I find that it’s usually pretty easy to write code where I know what the types are, that those can be determined at compile time. I don’t think that results in code that’s particularly hard to read.

Ryan:

[54:48] When I was in college and very early, I remember people would recommend that book, “Oh, you should read Clean Code.” So my understanding is that you wouldn’t recommend that to people who are software engineers to read that. I guess the way I would categorize it is a mixed bag.

Casey:

[55:00] So I wouldn’t actually say that I disagree with all of the things in the book, though. I mean, some of the things are things that I definitely do myself. Like giving variables easy-to-understand names is something that I think is good advice, and that’s in that book. Right. And so kind of more, I wouldn’t necessarily say do or don’t read the book. What I would say is, like, I think there’s some things in this book that don’t.

[55:31] That aren’t addressed properly. Like, I don’t think you want to tell people these rules of thumb and not tell them about these other problems. That was exactly what I was pointing out there. And so usually it’s more that it’s like I find that oftentimes there is this tendency, I guess I’ll say, to pretend that we don’t have to talk about performance and we can just say, in fact, premature optimization is the root of all evil.

[56:01] Bringing it back to there, I feel like there’s this temptation and very prevalent practice of sort of taking that idea to mean we don’t have to talk about performance when we’re teaching people things at all. Or like when you write the book Clean Code, you don’t have to talk about performance at all. You can just include a thing that’s basically like, hey, there’s performance issues, but most of the time it’s not a problem or something like that, which is, or if you look at Refactoring, the book Refactoring, very popular, it literally says exactly that in like the OOP thing.

[56:34] It’s like there might be performance concerns, but they’re usually okay or something, right? And that is not true. I just think that’s fundamentally not true. I think these books should include detailed discussions of the actual performance problems that you are very likely to hit if you take some of their advice, because it’s not that it means you can’t do those things.

[56:57] But I’ll quote you back to you. It’s about trade-offs. There is always a trade-off that you’re making, and sometimes if you understand the trade-off, you will make it. You’ll say, I know this is going to cost. This may be a serious performance problem for us, but I think that’s okay. I think it’s not like our performance won’t suffer to the point where it’s a problem for the product. I understand what that is.

[57:23] There’s a huge difference between that and just going like, eh, we don’t worry about performance till the end. It’s completely different. Those are two different engineering approaches. And so what I try to do is encourage people to put that analysis back in, understand the performance trade-offs you’re making, understand how much it might cost in the future to make these fixes. And I don’t really do any AI stuff, but my sort of feeling is more so now than ever.

[57:53] I feel like that’s got to be pretty important because you’re instructing these AIs to do what they’re going to do. And I feel like it would be a bad idea not to know about performance trade-offs because, especially if an AI is going to be doing your bidding and structuring the code the way you want to structure it or doing whatever, it seems like a fairly straightforward part of the process to include performance stuff in those instructions.

[58:17] Right? That would be a natural thing that we would want to understand and do. So I feel like really I’ve been just trying to get that more into the conversation, and I feel like it’s as relevant now as it ever was and arguably maybe more so. I don’t know, but I could be wrong about that.

58:33 — How to write high performance code

Ryan:

[58:33] What are some things that are in your mind? They’re those high-value performance things to consider that don’t cost a whole lot to think about.

Casey:

[58:43] So to me, awareness is the number one thing, right? Understanding roughly the performance characteristics of the hardware that you’re working on, which includes things like if there’s a network, what does that look like? And so on. It’s really about awareness more than anything else. Because a little bit of awareness can go a very long way if you understand the basic concept that network latency versus network throughput are different things.

[59:15] You can make upfront decisions about structuring code such that you batch things properly and so on and so forth. If you don’t understand those things, you could get very far down a project only to realize that everything you designed and the way it works is all very serial and really just cannot be accelerated over a network at all. It’s never going to run reasonably or something like that.

[59:36] Right. And so I think the lowest hanging fruit is just to get some education in performance, get some education in how to think about the way a machine works and what makes it fast or slow, what it struggles with and what it doesn’t. And just to keep that in the back of your head, because at the end of the day, if you have that knowledge, I think you’re very unlikely to make the kinds of architectural decisions that will be hard to undo later.

[01:00:06] Right. And so that’s really the majority of it, I think. And that is by far the highest impact, lowest cost thing you can do is just do that training once, because once you have it, it’s with you forever. Once you understand how to think about performance, it can always be there. And at any time you can sort of have that alarm bell of like, “I don’t see...” You’re always kind of looking like, “I don’t see the path towards this running well,” then that’s your cue to stop.

[01:00:38] Maybe we need to rethink how we were making some of these decisions. As long as you can see that path, you can delay most optimization work. As long as you can see the path, like here is how we will optimize this, you’re in pretty good shape because if you’re making those trade-offs correctly, you’re not going to paint yourself into a corner where there’s nothing that you can do other than scrap and rewrite.

Ryan:

[01:01:05] You had this one video title. It said, “Where does bad code come from?” I guess, yeah. My question to you is: what’s the answer to that? Where does bad code come from?

01:01:18 — Where bad code comes from

Casey:

[01:01:18] Yeah, that’s a good question. My feeling on where bad code comes from is that, for everything that I’ve seen on projects in the past, the bad code all seems to come from roughly the same source. And that is not dealing with the actual thing that’s happening. Right. There’s a lot of ideas in computer science about sort of doing upfront design and making a lot of decisions without ever really implementing anything.

[01:01:54] And I have found that universally that leads to the worst kind of code. And the reason for that is, I hate to be pessimistic, and I hate to be pessimistic about my own ability, but I’ll just say, for me personally, I am not able to correctly hold all of the details for most complex software in my head at once. There’s just a lot of stuff going on at, like when the actual instructions hit the CPU, there’s a lot going on down there that’s very hard to keep all in your head.

[01:02:34] And so when you approach an upfront design, typically, unless the problem is very stupidly simple, right? When you approach something with upfront design and you think you’re going to get all of this architecture worked out ahead of time, you forget some important things. You make decisions without realizing, oh, wait, there’s this thing that has to happen there that means that this isn’t really the right way for these pieces of code to interoperate.

[01:03:03] Then you end up seeing these hilarious APIs or something where it’s like you’re just like, how did this end up being the way that you do this? I have to create all these objects and I have to connect them together with these things and I have to create this weird filter graph thing and then I have to call compile on it. But only you end up with these insane things. And you’re like, all I wanted to do was call this one thing that said, like low pass filter this buffer.

[01:03:26] It could have been one function call, right? It’s like, how did you get there? And the answer is because you weren’t actually dealing with the actual problem and looking at what the actual code looks like when you actually want to solve the problem in practice. And so my idea where bad code comes from is usually just that. It’s that. It’s this failure to engage with the actual reality of the situation.

[01:03:52] Maybe there are people out there. I certainly have never met any, but maybe there are people out there whose brains are so expansive that they can actually hold all that in there and they can therefore just do it upfront. But other than for various sort of constrained problem spaces, I’ve never seen that work. And there are some times when that’s the case with, if you’re just doing, I’m trying to do this particular mathematical operation, that might be a case where you can work it all out on paper because it’s very specific what it is.

[01:04:21] It takes these N inputs, produces this output. And I can work, right? But when you’re talking about architecture, like, hey, it’s a web browser, right? Some complicated thing, the details are all that matter to me, right? It’s like, it’s where all the complexity lies. And if you try to do the design without reckoning with them, it just leads to bad results in my experience.

Ryan:

[01:04:41] So how do you avoid writing bad code in that case?

Casey:

[01:04:45] I try to start with the actual solutions to the problems and work up from there. So one way to say it would be instead of top-down programming, bottom-up programming as much as possible. And top-down programming isn’t really the same as designing up front. But I’m just saying as a contrast there, try to start with the things that you know you need. It’s like, okay, if I’m building this thing, it’s gotta have a rasterizer.

[01:05:10] All right, I’m gonna start making a rasterizer. I’m gonna see what kinds of stuff that does and how I would like, what’s the most straightforward way to call this and use it. Okay, let’s make an API out of that, right? Build it out of steps where the abstraction comes from actual working code that gets abstracted rather than pushing the abstraction down from the top, where I say, this is how I will abstract the rasterizer.

[01:05:36] And now I go write the rasterizer and the thing that uses the rasterizer, only to find that that is not a very good way to use a rasterizer. So to me, starting with that and working upwards is the best way to ensure that you will get an architecture that is at least good for one thing. Now, if you want it to be good for multiple things, you probably need a couple different. I want a few different varied things that would use this rasterizer that I will kind of work on together, and I’ll make abstraction decisions that work across all three of them.

[01:06:07] That’s a good way to make a more reusable API that works for a lot of things. But I never want to just sit down and say, “How will I design an API for lots of people to use a rasterizer without actually writing any of it?” It’s like, no, no, no. And I definitely can’t do it. And I would question someone who says that they can. Unless one caveat: they’ve written a lot of them before, right? If you’ve written tons before, then you’ve sort of done the thing that I’m talking about already.

[01:06:33] And you might remember, oh, it’s this way, right?

01:06:37 — Why design docs before code is a bad idea

Ryan:

[01:06:37] I think there’s a lot of common advice, especially at these larger companies where there’s this process to write a design doc and put together everything in advance, present it before you write any code. And it sounds like you’re saying that that’s a terrible idea.

Casey:

[01:06:57] I think that’s an absolutely terrible idea. Now, that doesn’t mean that I wouldn’t be okay with that process with a slight modification.

[01:07:05] If what you’re doing during that time is writing test code in the way that I’m saying. So we’re going to write a little experimental rasterizer. We’re going to do those things. We’re going to start, and then our document that we’re producing is, here is what we have determined is a good API based on these experiments. I have no problem with that. That’s following my procedure pretty much to a T. And I don’t tend to produce documentation because I work on smaller teams.

[01:07:32] I don’t have to have a 1,000-person org know exactly what I’m doing there or whatever. So I wouldn’t produce upfront documentation normally in a case like that. But if you wanted to, that seems totally reasonable. Right. And that is communicating our research into how this should be structured out to a wider audience. But we still did the due diligence of determining that it really does work in practice.

[01:07:55] It’s not just our guess about what it will be.

Ryan:

[01:07:59] I see. Okay, so you’re saying kind of this pair design, pair prototype, just build as you go, but it’s just so you get a sense of the reality of the design.

Casey:

[01:08:10] Yeah. And I think I would be very comfortable with the team that wanted to work that way. If they’re like, look, we want to produce, we want to document this thing before we start developing. That’s just how we feel more comfortable with how we’re going to do it. Maybe it’s a very large org, maybe we have some very good reasons for that. Then I would say totally fine. It’s just, I want to hear if I’m going to be comfortable.

[01:08:31] I want to hear that that process is not, we’re just typing on paper. We are actually testing these API design decisions, and they come from looking at actual usage code that we have made and that we have implemented at least experimental versions of, so that we know they really do account for all the details that we’re likely to encounter in practice. That’s what I want to hear. Right. I don’t want to hear, we thought it through.

[01:08:57] I’m like, did you think it all the way through? Because I’ve seen a lot of times where people thought they did and they didn’t, including myself. That is not. That is not. I always think it all the way. So it’s like, no, this comes from a personal place of I forgot the thing. I forgot this important thing and I made a really stupid design, right?

Ryan:

[01:09:14] There’s another video you had. It was titled The Only Unbreakable Law.

Casey:

[01:09:19] Oh, yeah.

01:09:20 — The only unbreakable law in software engineering

Ryan:

[01:09:20] What is the only unbreakable law in software engineering?

Casey:

[01:09:24] So, yeah, that was a lecture I did where I was trying to think of, if I was going to say one thing about architecture to people, right? If I was going to say one thing about architecture, what could I say that isn’t probably wrong? Because you think about a lot of our ideas about architecture, it’s like even the stuff I just said to you, who knows what we’re going to be thinking 10 years from now.

[01:09:47] It’s like, they’re not really laws, they’re just observations that we’ve had that maybe this is a good way to do things, but it’s not really a law, right? So the only thing I’ve seen that feels like a real law to me is the thing I cover in this lecture, which is Conway’s Law. And this is a. It’s not a real law in the sense of like the laws of gravity or so, like, it’s not a physics law.

[01:10:14] Like a physicist would laugh at calling it a law. It’s probably not even a theory; it’s more like a hypothesis at this point, right? But in terms of things that I would place money on being validated as a law at some point, if we ever had the means to do so, this would be one of the only software engineering things that I think would qualify. And it is that if you would like to organize a series, like a set of people to work on something, or in the modern parlance, let’s say agents.

[01:10:56] So it could be. It doesn’t have to be human. It’s any system that has sort of its own internal processing, like a human brain does or like a computer does. If you need to partition a problem into a set of workers in this way, where the communication between those workers is slower than their own internal computation ability, which we would all agree is true about humans, it’s true about two computers running an AI model as well, right.

[01:11:25] The amount of time it takes to send information back and forth to them is significantly slower than what the GPU can be processing directly on its own, right? In systems that look like that, when you start to tackle a problem, in order to get the benefits of that parallelization, you will have to make decisions about who is working on what, at least some decision. For example, if we are making a car and you and I are the two people who are going to make the car, I’m going to design the body of the car, you’re going to design the wheels.

[01:11:54] Right. Just a decision someone could make. Once you’ve made that decision, you have now locked in the fact that the iteration on the design will be slower across that boundary than it is interior to either of the two parts. So, for example, your ability to improve the design of the wheels on their own and my ability to design the body of the car and improve that on its own will be much faster than our ability to design the interface between the wheels and the tire.

[01:12:32] Or it’s not even just the interface, the degree of harmony between the designs. So the degree to which your wheels complement my body design and my body design complements your wheels, that they all are considering the trade-offs together. Right. And Melvin Conway’s paper, which lays this out, this is a very early paper. It’s in the 60s at least. Was it in the 50s? It’s way back. When that lays this out, points out the consequence of this is that products or any.

[01:13:06] And when I say product, I mean anything that comes out of one of these design processes or development processes. Products will have a similar structure to the organization that produced them. You will be able to see in the product evidence of this because the degree to which things are able to harmonize is restricted across that boundary. So when you look at the object, it will have that boundary visible in some way.

[01:13:33] Right. It won’t be quite as good at the interface between these two things or in the way that they work together as the things are themselves to themselves. It gets sort of flattened, like one way. The rule is pithily stated is products look like the org chart, but that’s not exactly what it says. But that’s kind of a downstream consequence, and boy, do you ever see it in the real world.

Ryan:

[01:14:03] So, I’ve heard that in the context of these big tech companies, like, almost like it’s a bad thing to quote unquote ship your org chart, or basically the product you put out there has these inorganic, yes, things. So it sounds similar to what you’re saying.

Casey:

[01:14:24] Yeah, it’s. And I think part of the reason I think it is kind of an unbreakable law is I think it’s somewhat unavoidable. It’s more something that you just have to be aware of and mitigate to the degree that you can. Like, you just have to understand, look, that lower communication time, whether it’s humans or computers or whoever is doing this work, that lower communication bandwidth is whatever.

[01:14:54] That just means that where we draw these lines has consequences for what we ship. And so we really want to try, over time, to align those boundary drawings to places where it will have the least bad impact on the result of the product. And that’s true for org charts, like I said. I suspect it will also become true for AIs and things like that, where it’s like, you will want to partition these problems in ways that respect that line drawing, because that will be less good than the thing that can be wholly solved by one unit, whatever that unit is.

[01:15:36] And so to me, it’s a very helpful construct for thinking about things. It’s also a very good explanation for why you see something somewhere. You’re like, why doesn’t this just integrate this? It’s like, because there were two different teams. It’s like, I’m sorry, that’s just the answer. And it costs a lot more for those two teams to have integrated this. That’s not how we work. Right.

01:15:57 — How he got into programming

Ryan:

[01:15:57] I’d love to hear more about your career and how you got into programming.

Casey:

[01:16:04] I started programming when I was really little because my father worked at Digital Equipment Corporation, which is actually a very important company in that era. No longer exists. Right. They would be sort of like almost like a case study in how not adapting to a change in technology leads to your demise. They were one of the most important companies in the world for computing. If you ever heard of a PDP-11 or a VAX in computing history, that’s them.

[01:16:35] Right. They made these things that were foundational computers in computing history, gone today. Right. Part of them got absorbed by Intel, part of them got absorbed by Compaq, but they don’t exist. So he worked for that company. And so we always had computers in the home, and I learned to program when I was little, and that’s just sort of always what I wanted to do. I really enjoyed it.

[01:16:59] And so I ended up getting an internship at Microsoft when I was pretty young, and I met some people there. I came out to — I should say, I grew up on the East Coast, so nowhere near Microsoft. I met some people there. I ended up coming out to the West Coast really early on. This would be in, like, ’95. So it didn’t feel early at the time. It felt late in computer history. But nowadays, like, oh, wait, ’95.

[01:17:26] Oh, my God. Before everything was on the web, right? There was a web, though it was nascent. I ended up coming out and working sort of in the game industry, and that’s what I did ever since. And I’ve mostly always worked on game technology. I’m famously absolutely terrible at understanding game design. People who watch my stuff know this about me. I’m very, very bad at it.

[01:17:54] I’ve tried to make games a couple times and I just cannot do the design side. I’m awful at it. But I really enjoy the engine stuff, and I feel like I’m okay at it, and I’ve been able to contribute to projects. So in general, most of the time, if you’ve used code that was written by me, you probably used it in the context of a video game that was using technology that I wrote. And an example would be I worked at RAD Game Tools on a character animation system.

[01:18:23] I wrote the entire thing myself. That is used. Well, that’s not entirely true. I wrote the entire thing myself, except for the texture compressor, which Jeff Roberts wrote. There was this texture compressor that you could use as part of the pipeline for the exporting and stuff like that. It was a pretty cool project at the time. I’m really proud of it. The first version was awful because I was pretty new at the time.

[01:18:44] The second version, I thought we did a really nice job. And it was made at a time when people didn’t think you could do licensable game technology of that kind because it was too hard to integrate into things, like you couldn’t get the performance or whatever. And we did a lot of things that I think were pretty innovative at the time. And we were able to make something that was very successful. And it’s.

[01:19:04] I mean, we released the first version of that in ‘99. It’s still in use today, largely unchanged from the architecture that I guess was the second version I did in 2001 or something. There are a few changes to the architecture that people have made over time, but it’s largely unchanged. I found out recently Baldur’s Gate 3, which was a big game from Larian, came out. I had no idea. It turns out they use it.

[01:19:30] It’s in their engine or whatever. So I’m very proud of that product because I think it was in tons of games and was a very hard problem to solve. And I think we solved it pretty well. It’s largely irrelevant today. I would say it’s still in some people’s engines over time, but it’s not the kind of product you would make today because nowadays engines are monolithic and you license them as a whole. Typically, you wouldn’t be getting a character animation library.

[01:19:57] It’s going to be something that’s built into Unreal Engine or built into Unity. It’s not the kind of product you would probably consider making today. That was mostly, in terms of things that I’ve done that people might actually have experienced or used, like folks at home. If you’ve played games, you may have played something that I had a hand in at some point, but only the technology, not the design.

[01:20:20] I also worked a little bit on The Witness, which was a game by Jonathan Blow and team that I thought was absolutely fantastic. And I did some work on the walk system there that I was pretty proud of. I thought it came out pretty well. There’s some parts of it that are really janky. I don’t think I did a very good job of the actual implementation of it, but the design was pretty good, let’s put it that way.

Ryan:

[01:20:43] Early in your career. So you worked at Microsoft and then went to go.

Casey:

[01:20:48] I was only ever an intern. I never actually, I mean, I guess that’s technically working there, but I didn’t ever work there as an employee. Employee, right.

Ryan:

[01:20:55] As someone who’s writing code, I mean, there’s a lot of different paths, but there’s one path I imagine: you go and you work at one of these big tech companies and create their tech products, I guess. And then video gaming seems like another path. And I think there’s other paths as well, of course.

01:21:16 — Why he didnt work in big tech

[01:21:16] What drew you to going towards video gaming and not continuing down the Microsoft path or something like that?

Casey:

[01:21:25] I think that there’s a bunch of things I could say about that, but they’re probably all BS. The truth is probably that I’m probably more affected by the people around me than I would like to admit. I mean, I guess I don’t have a problem admitting it now, but at the time I probably wouldn’t have said that, right. I could envision an alternate past where I did stay at Microsoft and try to get a job there and work there instead of being just an intern and then going off and working at a different place.

[01:22:00] The reason that didn’t happen was because of the people who I worked with there when I was an intern. I fundamentally really like. Nowadays I fundamentally really love doing things like analyzing assembly code or looking at exactly how a microarchitecture is working and these sorts of things. If I had gone to Microsoft and had just happened to be under some people who were doing that kind of work and had taught me how to write device drivers in assembly language or something like that.

[01:22:33] I might still be there today, right? That’s not what happened. The capsule summary is the group that I was supposed to be in, the way that they did internships at that time was that a set of interns, say three or four of them, would be underneath a particular manager who was going to be managing those interns. So there were a couple of us who were supposed to be reporting to this guy whose name I won’t mention, just in case for some reason it’s ancient history.

[01:23:02] He probably wouldn’t care at this point, but we were supposed to be reporting to this particular person. And literally the week before we arrived, he has this massive flame-out with upper management. Leaves, just walks out of the building, and has not been heard from since. So we show up, and there was me, a guy named Rudy, a guy named Rajeev, and we’re just interns. We show up, we’re like, hey, how’s it going?

[01:23:39] And we report to this test guy, this SDET guy named Scott Latham, really nice guy. And we’re like, we’re supposed to be reporting to a program, like a software, or what’s going on? This is one of the guys in the test org. He’s like, yeah, that guy’s gone, he’s out of here. And me and this other guy, Bruce Johnson, are going to take care of the interns because, eh. Right. We don’t really know what you’re going to do.

[01:24:13] The first thing I think Bruce had me do was like an ANI cursor loader. There’s this format, I don’t know, ancient history now, but there’s this format for animated cursors on Windows. If you ever see the stupid little walking dinosaur or the, like, no one uses these anymore, I don’t think. But they were this thing that was in there. He had me write a parser for loading ANI files, right? Like it’s just meaningless stuff.

[01:24:36] So my experience there was pretty lame. I was like, this is kind of dumb. I don’t really want to work here. But it could have been totally different if I had been on some team that had really inspired me to learn the stuff that I didn’t know. I didn’t know assembly language at that time, really, at all. I think the only thing I’d ever written assembly language was a joystick polling routine for DOS because it was the only way you could poll the joystick in DOS.

[01:25:00] I think that’s really it, if I’m honest about it. I think most of it is that I think even if you’re a very brash youngster, which I was, and even if you think that you’re very independent, I think you definitely gravitate toward people who you see doing things you think are impressive or technologically interesting. And that is just not the experience I had at Microsoft. Now, there were some people who I like, the people I went out to go work with were people in other parts of Microsoft who were leaving Microsoft to do a startup company.

[01:25:34] And those were the people that I was really impressed with. Those are the people that I wanted to hang out with. So, if I just look at it in arrears, if those people had just been staying at Microsoft and doing something, maybe I would have gone.

[01:25:47] And I think that’s the truth of it, as best I can determine at this point anyway.

Ryan:

[01:25:51] So you moved across the country to go work with those people at a startup?

Casey:

[01:25:56] Yes.

Ryan:

[01:25:56] That feels pretty risky to do.

Casey:

[01:26:00] It was especially because at that time, a startup is not really what you think of as a startup today. Like, a startup was just some scrappy people in a crappy office doing stuff. Nowadays, you think startup, it’s like, well, we’ve got $10 million in VC funding and we have free sodas and whatever, like in the break room, and a masseuse comes in periodically or something like this.

[01:26:22] Right. I don’t know what the now version of a startup is, but it’s very different, right? So, yeah, it was pretty risky. And I don’t really know why I did it. It was mostly just because I hadn’t had really good experiences with education. I didn’t really want to do college, or I didn’t want to do any more education. I wanted to actually work, for whatever reason. And this seemed like a.

[01:26:52] But this was just the easiest way to do that. And I don’t really regret it, honestly. I’ve been able to learn most of the things that I would have needed to, if I was gonna go do a PhD or something. I’ve ended up doing work that is the sorts of stuff, like I’ve been lucky enough to be in positions where I could go spend a few months writing this particular linear least squares solver or something like that.

[01:27:19] The kinds of things you might have done as a thesis or something, or that walks on somebody done The Witness. Those sorts of things are the kinds of things you would have done had you decided to get a master’s degree or something like that. So I’m fortunate enough that I’ve kind of been able to have that part of the education because not everyone gets that opportunity. You may never get, if you don’t do a master’s thesis or you don’t do a PhD thesis, you may never really get the chance to really do deep work on one problem and learn a lot about it, read a lot of papers, maybe make some novel contribution in some very small way usually.

[01:27:59] Right. And so I was just lucky enough to do that. So I don’t really regret not doing something like that, but I think had I not had those opportunities subsequently, I could see being regretful about that because that is something that I do enjoy doing. And if I’d never had the chance, I would have been sad.

Ryan:

[01:28:18] So you went and you traveled to this startup because there’s no funding, it sounds like.

Casey:

[01:28:25] So, yeah.

Ryan:

[01:28:26] What, you? It’s just a group of guys. Was there pay or...

Casey:

[01:28:30] It’s just not really. No, it was. It was pretty rough, and it didn’t last very long. Right. I ended up going to work at an actual game company shortly after that called Gas Powered Games. And then shortly after that I started working at RAD Game Tools, which I stayed at for quite some time and where I did that character animation system and stuff. So it was pretty quick into not doing that, but it was still a pretty educational experience for me.

[01:28:53] And also what I will say is at the time, I worked with a guy named Chris Hecker, who I have to give basically complete credit for teaching me basically about reading technical papers. Before that time, I just thought math was kind of stupid and an annoying thing you had to do in class. Right. And I definitely didn’t know anything about reading a SIGGRAPH proceedings, really.

[01:29:26] And I may have been aware. I mean, I was aware of SIGGRAPH. I knew what it was. But I don’t think if you’d handed me that binder, I would have known what that was or what to do with it. I think the biggest takeaway that I got from that, other than startups are hard and maybe don’t do them unless you have a lot of people and a lot of funding and aren’t really that much on the line, maybe.

[01:29:51] But the biggest takeaway that I got from that that was positive was just a much deeper appreciation for math, a much deeper appreciation for research, how to read it. That’s where I learned to use CiteSeer, which would be kind of the precursor to Google Scholar or whatever. Crawling references and all that stuff. In a lot of ways you could say if I hadn’t had that experience, I bet I wouldn’t have given the two talks that we’ve talked about for most of the interview.

[01:30:17] Because what are those talks? They’re me crawling every reference. They’re just me going back and back and back and looking at everything that I can find. And that’s something that if no one ever conveys to you the importance of reading, the scholarship and being aware of what’s being done, and also teaches you how to read a tech paper and how to parse through it, I don’t know that you get that.

[01:30:42] I don’t know that you get that.

01:30:44 — Should you work at a startup early on

Ryan:

[01:30:44] I remember early in my career, I think there’s this common path of these big companies, and then there’s this thought of, oh, me and a couple buddies, let’s go build something. Now, with your experience looking back, if someone out there is young and thinking about starting, would you say go that common path or would you say take the chance?

Casey:

[01:31:10] It’s a really tough question. And I think the advice is that you have to think about what it is that you want to do every day. So in my mind, the things I regret are the times when I’ve had to do things or chosen to do things that I wasn’t really that happy doing every day. Right? And so I think you just have to optimize for the experience you want to have. Because a startup might work out, it might not.

[01:31:45] It’s always a risk, right? You may go to the big company and it may be cool. There may be interesting things there, or there might not be. You don’t really know. You’re making a kind of blind decision. And so I think you kind of have to optimize for what do you want your day to day to be? What do you want the experience to be? And you want to keep a running talent, you want to be aware of it.

[01:32:12] If you make a decision and six months in, you are not liking what you’re doing every day, then you need to get out of that, right? That’s my opinion. So I don’t know. I think most people probably, if they sit down and actually clear their mind and aren’t engaging in too motivated a reasoning just for themselves, go, what do I envision working at the startup will be like? What will I actually be doing every day?

[01:32:40] Am I gonna like that? Is this gonna be thrilling? Trying to make this thing work and being kind of on the edge, and do I want the kind of war stories of the things we had to do to pull off the demo or whatever? Right. If all that sounds exciting to you and you wanna have that experience, then you should do that thing. And I would say, really, I really mean that.

[01:33:05] I don’t even think you should take into account, even, like, let’s say, the startup’s gonna fail. If you want to have that experience, then you need to do it, right? It’s just like anything else. It’s like going and backpacking across Europe or playing guitar at a nightclub. It’s like, you may know that these things are not profitable. Is that the experience you want to have?

[01:33:26] Are you going to look back on that six months or a year or five years or whatever, the amount of time you’re thinking of committing to it? Are you going to look back and say, I’m glad I did that, or are you gonna be like, that was time that I would have rather spent some other way? Right. And so I think most people can probably, if they’re honest with themselves, at least make a pretty good guess.

[01:33:45] And that guess, if they’re honest with themselves, is gonna be better than any advice I’m gonna give them. My guess about what you should do is gonna be worse than yours. So you should just make that determination. Because another way to look at it is, you know, the big company side, maybe you just wanna have some security. Maybe when you’re starting out, I mean, I’ll just give some examples.

[01:34:04] Maybe you want to spend a lot of time dating. You want to find a partner, and you want to have a relationship, and you want to have a family. Maybe that’s more important to you. Maybe the startup, yeah, it might be fun. Maybe it would be more money if it worked out or whatever. But maybe the stability is actually going to be something that you would really benefit from because the sorts of things that you imagine being fulfilling in your life are not all around what you’re going to be doing in computing.

[01:34:34] I think you can have some guess about those things if you just let yourself have some space to think about it and don’t engage in too much motivated reasoning about it. And I think that would be the best way to make a decision, if you’re going to make one. That’s my feeling about it. Anyway.

01:34:52 — What video game engineering is like

Ryan:

[01:34:52] We talked a lot about video game engineering, and I have no idea what goes into video games. If you were to just boil it down to the big pieces that you need for a video game, what are those software components?

Casey:

[01:35:07] So the biggest thing that’s different about a video game is that the sort of original mental model that you’re taught in programming, which is the standard I O, is not how it works, right? So the biggest mental shift is just like, oh. The way that a video game or a simulation of any kind works is I need to have some world state.

[01:35:37] And I’m constantly updating that world state on a regular interval. Everything is always happening. There’s no “I wait for input and then I do something,” right? Everything is always going because it is real time. The time is going forward. So the components tend to be built around this idea, and it depends on what level of sophistication you end up getting into. But in general, you need a way of storing that world state.

[01:36:03] So some kind of. We usually call these entities, like the things that make up a world.

[01:36:08] So some way of modeling what is in the world. Where are things in the world, what is their state, what are they doing right now? So you need something that does that, something that is in charge of advancing that state. This is a mixture of several things. It could involve physical simulation, it could involve AI, not necessarily large language model like the modern notion of AI, but pathfinding, making a decision between whether I should attack the player or not, that sort of AI.

[01:36:42] So we have the world. Some way of showing the world state, some way of advancing the world state, like an update step that may involve lots of things like that. Then some way of presenting the world state. So a renderer. Right. And this is something that typically has, I guess I would say it’s traditionally been a very important part of a game because the visuals are often something that is a selling point for games.

[01:37:12] People produce trailers, certainly in the AAA space. We’re trying to show you how cool the new lighting looks and the whatever. So that is a pretty big component of games. Oftentimes you go look at an indie pixel art game, it might be much smaller because that’s a much smaller part of the problem. Now that’s generally what the shape looks like. There’s a lot of little pieces there. Typically nowadays we would have some way of asset streaming. The renderer needs to have things like textures loaded, models loaded, things like that.

[01:37:45] We need world data, physics, collision models, these sorts of things. They might be too big to fit in memory, or we don’t want to spend a lot of load time to load them up front. We want to stream them in as they’re necessary. So there’s typically this thing that’s sitting there constantly grabbing things off of disk, caching things, pulling them in and out of a cache that’s being used by the renderer, by the physics, and so on.

[01:38:04] So that’s another common component that’s new, didn’t used to be there. There’s going to be an audio and music system. Obviously, that’s in charge of when sounds are triggered in the world, ambient sound effects that are happening in the world, music that’s playing, continuity. Again, all of that’s interacting with the world state to know which ones of those things are happening. The update step, which will be triggering things in that sound system.

[01:38:28] And of course, the asset streaming to load what sounds are being played or load the music. So we typically have that. And then I’m trying to think, I’m trying not to leave out any major components. In a modern context, there’s often networking. So we want to have a way for multiple of these game clients to communicate with a server. So typically what that means is that world, that state of the world might be provisional. It might be sort of a predicted model of the world that’s not the real model of the world.

[01:39:01] The simulator is actually running. The authoritative simulator is actually running on a server somewhere. And I am merely communicating with it to find out what the world state is. And then, because I don’t want to wait, I don’t want the latency of going all the way around, I am predicting the motion of things forward in time based on the last information I have. So that’s another kind of way that things tie in.

[01:39:27] If you want to start doing things like competitive multiplayer and all these sorts of things. Right.

Ryan:

[01:39:31] That makes a lot of sense because I used to play video games, and then these MMO online games, when I start to lag, everyone continues forward.

Casey:

[01:39:43] Yes.

Ryan:

[01:39:44] And then my Internet catches up, and then everyone jumps to where they’re actually supposed to be. Okay, that makes a lot of sense. I pulled some of your top tweets. I thought that might be interesting to discuss.

Casey:

[01:39:57] I’m sorry.

01:39:57 — Why preventing recursion is reasonable

Ryan:

[01:39:57] So someone said, NASA does not allow recursion in their code. How crazy is that? And then you said, not even slightly crazy, and it went really viral. Can you explain why that’s not even slightly crazy?

Casey:

[01:40:12] When you’re writing functions in a procedural programming language like we have, and that NASA is probably using, you are able to use the program stack for storage. I mean, that’s what it’s there for. It’s what local variables are. I call a function, I get some storage space on the stack. The compiler did that for me. It also saves the return address when I make a function call. That program stack is keeping track of where in my code I was, so that when the thing that I called is finished, I get back there, not some other point.

[01:40:50] Neither of those two things are things you couldn’t implement yourself. They’re both things you could do. You could break the thing up into pieces. You could have ways of remembering what they were, like a state machine. You can have your own stack that you put data on and access it. Right? So the only thing recursion really does is it allows you to leverage the fact that someone already wrote that code for you and maybe more convenient to use because it’s built into the language.

[01:41:18] Now, there are some things, if you really want to get super technical about it, there are some things that happen at a CPU level when functions are called, but we can put those aside for now if you want to talk about them after we wrote the code. So the reason that I don’t think it’s crazy to go, we’re not going to use recursion to implement an algorithm, is because if you’re doing that, you’re kind of just YOLO swagging that there’s room on the stack for whatever it was that you were doing, right?

[01:41:44] And you can’t even really check unless you’re going to do some kind of weird thing. We could sort of do a thing where we go like, okay, let’s try to determine how many more iterations, how many more recursion depths we have before we hit the end of our stack. We can do those calculations, but it’s like, eh. And also if the compiler changed something about the layout, it wouldn’t be true anymore, and so on and so forth.

[01:42:07] So it’s like, so if I’m NASA and I’m like, hey, I don’t want my astronauts to crash into the moon, it seems much more logical to say, don’t use recursion. Just figure out whatever this thing was you’re going to do, turn it into a loop, keep a stack, and make a state machine for it. We can reason about that much more clearly. We know exactly how far it’s going to take. It doesn’t matter what compiler, it’s going to work the same way every time, and it will know the bounds.

[01:42:31] Precisely.

[01:42:33] Very sensible to me.

[01:42:35] And again, you assume at NASA that they’re not doing it for their health. They’re doing it because they have hard constraints on the problem domain where someone’s life is at risk, or at a minimum, many millions of dollars in equipment is at risk. If you screw up, if your stack falls, if you get something where you’d recurse too many times and hit the end of the stack, that is not just a, oh, I rebooted the computer or restarted the software.

[01:43:08] So I don’t know. Hopefully that makes sense.

Ryan:

[01:43:11] Andrej Karpathy had this famous tweet that kind of coined the phrase vibe coding.

Casey:

[01:43:16] Yes.

Ryan:

[01:43:17] And then you said, if you thought software was bad today, buckle up, because it’s about to get a whole lot worse.

Casey:

[01:43:23] Yes.

01:43:24 — Is vibe coding bad for the industry

Ryan:

[01:43:24] It’s been about a year and a half since that tweet came out. The tweet came out in February of 2025. Would you say that that was an accurate prediction?

Casey:

[01:43:35] To be clear, I think the whole lot worse part is predicated on something that may not happen. And that is that the idea that we just kind of type some stuff into a computer and ship it to prod, right? Basically like, hey, could you make me a thing and then publish it, becomes a common way of doing things, right? For example, also done by people who maybe don’t have a computer science background. I think it’s fair to say, and that I wouldn’t be being sort of overly dismissive of AI at this point, to say that a person who is well trained in computer science using an AI to make code right now can make substantially better code than someone who doesn’t know anything about computer science, who is just given Fable and types some stuff in.

[01:44:27] The difference is rather dramatic, I would say, from everything that I’ve seen. So part of my concern that I was trying to express in that tweet was like, if the idea is like, we’re just going to type stuff in and we’re not going to really be checking the code, someone who knows computer science is not really going to be looking at it. Worst-case scenario, it’s literally just like some random person in marketing somewhere who has no idea what programming is, just types of stuff in and crosses their fingers.

[01:44:57] Right. I think we’re in for a world of hurt right now. It’s a race, so it’s hard to say because it’s basically a race of how good can you make the AI versus how much adoption does it get? It’s a curve. If you can make the AI good enough that the people who are adopting it at a particular rate are always using an AI that’s good enough for what they’re adopting it for, we wouldn’t expect software to get significantly worse.

[01:45:24] If those curves go the other way, we’re in a lot of trouble. Right. So I feel like right now we’re almost kind of teetering on this knife’s edge. It’s really, to me, it feels like a footrace of improving AI so it can be more autonomous and make better decisions without you needing to make them for it, versus the capability level of people who are using it and the degree to which they’re paying attention to its output.

[01:45:49] It’s like these two curves that are just, what’s going to happen? I don’t have a prediction. I don’t know where we’ll be in a year. Obviously, for all of our sake, I’m hoping that the AI curve wins because I agree. I understand certainly the perspective of people who maybe just don’t like AI and don’t want there to be AI. I can understand wanting it to fail. I understand that.

[01:46:21] Right. And I’m no fan of AI myself, so it’s not like I’m going to criticize someone for taking that position, but at the end of the day, if you’re talking about something that tons of people are using, you’re going to kind of want it to be good. I think at this point, given the level of adoption of AI, I really don’t think it would be great if it stopped getting any better right now.

[01:46:46] Like, if this was as good as it was going to get, I think that might be bad. Certainly six months ago, I think that was true, and I think it’s probably still true today. So I think ideally, if you want software to not be terrible, you have to kind of still be hoping that six months from now the AIs are again significantly better than they were. Right. Like, that is the only way out of the current situation, as I see it.

[01:47:15] Right. I don’t know if that’s fair, but that’s my sort of feeling on that.

Ryan:

[01:47:21] One of your other top tweets, it was Shopify put out this internal memo and you just replied, Slopify.

Casey:

[01:47:30] Yes.

Ryan:

[01:47:30] So I guess it’s because in this tweet it’s leadership pushing the adoption curve, maybe harder than the capabilities of the AI in this case.

Casey:

[01:47:39] Yeah. Although I also just like the pun. One of the things that I think is most unfortunate about the AI adoption, as I’ve seen it, is just the, because people think that it’s going to be this major. I guess if I had to categorize the way it appears that companies are reasoning about it, they’re assuming that if they don’t get in early it will be a big disaster for them, right? Like there’s a tremendous.

[01:48:07] They don’t just think, “Oh, well, we can just wait until the AI does what we need it to do and then start using it.” They’re like, “No, we have to do it now. Even before we know whether it can really do the thing that we want it to do or whether we know whether the outcomes are good, everyone has to do it right now. Let’s do this, right?” And I understand why they want, why they’re going about it that way, because they think that that’s critical, right?

[01:48:27] They obviously believe that’s very important. And to me, that’s just kind of terrifying because, as with any technology, the sane way to do it is to measure its capabilities, see how well it is able to solve problems that you have, see if it solves them faster than the way that you were doing it, and put it into a workflow at such a time as you’ve determined that it is a net positive. That’s just the same; that’s what you would do with any technology.

[01:48:57] And you’d probably have your team of people whose job it is to assess this thing, and they’re out there YOLO swagging it. They’ve got 3,000 agents working on this cluster, talking to each other and doing God knows what, right? So there’s going to be that, and someone’s going to do that. But that should not be every org. You wouldn’t just be like, everyone needs to use a ton of tokens, right? So yeah, I do have concerns about that.

[01:49:24] I don’t think that the way AI adoption was done was the best way for quality in software. But I would temper that statement with just the obvious fact that we were not exactly a five nines industry to start out with. Software quality was really pretty low rolling into the AI era. So I always try to just also caveat most of the things that I have to say that might be critical of a particular thing happening with AI with just the fact that, look, it wasn’t particularly great beforehand either.

[01:50:01] A lot of this software was pretty low quality, and so you can’t. Some AI things may make things worse, but it’s not like software was amazing and the AI showed up and ruined everything. That is a completely ridiculous narrative. That is not true at all.

01:50:17 — Technical reading recommendation

Ryan:

[01:50:17] Do you have any top technical book recommendations for engineers that might be listening?

Casey:

[01:50:25] No. I would probably use this opportunity to try to pitch reading technical papers. I think something that really the industry could use more of is people being more aware of what’s happening, both the historical papers, but also just current papers. It’s daunting at first, to be sure. If you don’t tend to read technical papers in your field, you will probably find it confusing. You won’t know where to find them, you won’t know how to approach them.

[01:51:00] It will seem to take too long to read them because you don’t know how to skim them properly and determine whether it’s worth your time to investigate a particular section of a paper and all that stuff. But if you’re willing to spend a few months just, at night I look at a paper, or on my lunch break I look at a paper, if you’re willing to spend a few months just doing that, you will get your bearings and you will start to know where the good papers are in your field.

[01:51:25] You’ll know how to find them, you’ll know where they tend to be published. You’ll be able to read them much more effectively, you’ll be able to know how to spend your time on them. And I think in all but probably a few small fields that probably exist somewhere that maybe people don’t tend to write many papers in or something like that, it’s tremendously valuable, and I think it’s so valuable that I read papers in disciplines I don’t even do.

[01:51:50] And I find it extremely rewarding. I read security research papers all the time. I don’t even work in a field where there are security research implications. Games don’t really do much of that. They tend to be run very sandboxed, and they don’t. Sometimes there are. But they’re not that kind of thing. They’re not like a web server authentication protocol or something like this. And I just find it incredibly rewarding because there’s just so much good stuff out there that you can learn.

[01:52:18] So I would say that would be it. Instead of a book rec, I would say find a paper, try reading a paper.

Ryan:

[01:52:24] How do I go and find that first paper or someplace to get started?

Casey:

[01:52:29] That will be valuable for most people who are watching because they might be generalists or working in web dev or in just a general tech org at a big tech company or something like that. I would say pull up the proceedings of USENIX, look through it for a paper that sounds interesting to you and try reading that paper. Or oftentimes there’s awards. I think USENIX has them where it’s like best paper of the conference.

[01:53:00] Try reading the best paper of the conference, see what you think, because that’s a collection of papers that’s usually about operating system stuff and systems design stuff. So it’s going to be something that most people can relate to. It’s not going to be really esoteric. If you were to open up the proceedings of SIGGRAPH, for example, it’d be like, oh, neural networks for cloth simulation or something, and you’re like, okay, this is not.

[01:53:28] I can’t relate to this because I don’t do graphics or whatever. Right. So USENIX might be a good place to start. But in general, yeah, if you had another option would be to go to scholar.google.com, which is their search that just specializes in papers, and type in a topic description that you find interesting. So if you wanted to learn, maybe you were very interested in consensus algorithm Paxos or something, and I don’t know what that is, or it came up at work and I haven’t really ever looked at it.

[01:54:02] You can just type that in, Paxos, and they’ll just be a list of papers, and they’ll say a thing like cited by. You can see how many citations they have. That’s usually how influential that paper was, to a certain extent. So those are some ways you could get started and find something that might interest you. It won’t be for everyone. You may bounce off it, but that’d be my recommendation. It’s something to try. You might find it interesting.

01:54:27 — Advice for his younger self

Ryan:

[01:54:27] And then, yeah, last question for you is if you could go back to the beginning of your career, when you just entered the industry, and give yourself some advice, what would you say?

Casey:

[01:54:38] I think the advice I would have given to myself was to get into low-level programming earlier. I didn’t really learn how to properly analyze and even really write assembly language code until probably 2010 or 2015 or something. I mean, it’s recent because I’m pretty old, and it’s like the last 10 years or so. Right. And I feel like I always wanted to know how to do it and just never seemed to.

[01:55:21] And the advice I would have given to myself was, just go down the hall. What I was interested in, go down the hall and be like, grab somebody. Show me. How the heck do you write this? Just show it to me. I think one of the problems is a lot of people, especially when they’re young, they are afraid of appearing like they don’t know things. And I think that can be a real impediment to learning.

[01:55:48] I’m sure it was for me. And I probably just didn’t want to literally say, “I don’t understand any of this stuff. Can you explain it to me?”

Ryan:

[01:55:55] To me?

Casey:

[01:55:58] And I think that’s one of the most useful things you can do. I don’t understand this. Please explain it to me. It’s very useful, and most people will be very happy to do that, if they’re not a dick. Most people will be like, oh, sure. Now, they might not be good at explaining it. There are plenty of engineers who are really good at something and suck at telling you how they do what they do. So you won’t always get a great explanation, but sometimes you will.

[01:56:26] Sometimes you’ll find the type of person who can explain very clearly how it is they do what they do. So if you just keep asking, you’ll get the good explanation. Nowadays, I wouldn’t really need to give myself exactly that advice because the Internet has so much great information on it. I could have taught myself that did not exist at the time.

Ryan:

[01:56:46] Awesome. Well, thank you so much for your time, Casey. I really appreciate it.

Casey:

[01:56:49] Thank you so much for having me. I love the show. It was an honor to be invited on, so thank you very much.

In this conversation, I asked Thariq Shihipar who is an engineer on Anthropic’s Claude Code team how Anthropic makes the most out of the models for engineering and how the industry will change soon.

For instance, we discussed:

• How Anthropic maintains their code given so much more code is landing now

• What has worked in preventing AI-written breakages

• How internal software engineering practices have changed (e.g. onboarding, glue work, etc)

• How engineers within the company typically leverage the models

• What percent of Anthropic’s work is fully autonomous

Hope the conversation is helpful for giving you some insight in how the models are and will change software engineering more in the near future.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:29 - Onboarding at Anthropic

02:53 - Internal capabilities vs external perception

06:16 - Model vs Harness

08:55 - What percent of Anthropics changes are fully autonomous

14:51 - Computer use

17:42 - How to make the most out of your compute

20:45 - Loop engineering

22:47 - Where the industry will go soon

26:02 - Which model do Anthropic engineers use

27:38 - Is learning a particular model worth it

30:56 - Prompting tips for todays models

35:04 - How to get the models to do tasteful work

39:00 - How much of writing is done by AI at Anthropic

45:36 - Code ownership and maintenance at Anthropic

52:04 - How Anthropic prevents breakages

55:24 - Visibility and sharing your work

58:42 - Luck surface area example

01:00:57 - Should people still learn to code

01:07:42 - Advice for his younger self

Transcript

00:29 — Onboarding at Anthropic

Ryan:

[00:29] My goal with this conversation is to ask you as much as I can about how you can get the most out of the models specifically for software engineering, so that people in the industry can learn from the best practices where Anthropic‘s having success. And so to start the conversation off, I’d like to ask you, let’s say I was coming from a company that’s maybe less AI-pilled, and I was onboarding onto your team.

[01:01] What are the most impactful things that you tell me to start doing to successfully onboard?

Thariq:

[01:08] I think the number one tip we have for both people inside and outside Anthropic is that if you treat Claude like a thought partner and give it the context that you need, then you can usually figure out the next steps. And so I think that starting with, okay, can Claude do it? If not, why not? And using that as the starting place, I think is really important. And I think just always thinking about, okay, reflecting on, can you move up a higher abstraction level?

[01:42] Can you set up a system? Can you build the system that builds a system instead of just building the product itself?

Ryan:

[01:52] I remember when we used to onboard people, you would get assigned an onboarding buddy, someone who really knows the code base. And you can ask all of your trivial setup questions too. It sounds like Claude fills in a lot of those gaps. And in practice, is it 100% you don’t need an onboarding buddy and you can just ask the model for everything?

Thariq:

[02:14] You do need an onboarding buddy, but more from a social and cultural perspective than a technical perspective. I think, from a technical perspective, you can basically just work with Claude and, if you’re good at it, you can get what you need to onboard. But I think just having the context of how to work with the team, and also how to get buy-in on what you’re building, or understand how the team works together, or just even have a friend to work with, is really important.

[02:46] So, yeah, we still have onboarding buddies, but it’s not nearly as much technical lift as it used to be.

02:53 — Internal capabilities vs external perception

Ryan:

[02:53] There’s a big difference between the external perception of the AI capabilities and the internal Anthropic usage. Because I’ll talk to friends and say, yeah, what Boris is saying is the reality. And so my question is, why is there such a big difference between that internal perception and that external perception?

Thariq:

[03:15] I think we have a good track record when we make these claims. You’re like, oh, it turns out to be true on a large enough timescale. I think a lot of engineers are not really in the IDE anymore. The code being written is like, I talked to large enterprise customers where they haven’t typed a line of code themselves in six months. We think of it part of our jobs to figure out how to work at a higher abstraction level.

[03:45] And if I spend a day trying to figure out how to get Claude to do this autonomously and I fail, that’s fine, maybe even good. Because now I can be like, oh, hey, Claude is not good at this. How do we make it better? But I think if you’re working an average job, your job is to produce the output. And I think automation always has a cost because it’s an investment. And if it works, then great, you’ll make a return on your investment over time.

[04:14] But if it doesn’t, now you’ve wasted all this time. And so I think the nice thing about the models is that generally the chance of the investment working out is higher and higher because the models are getting smarter and smarter. But you still have to take that leap as an individual. Your boss is not going to be super happy with you if you’re like, you know, if you’ve been working on your harness setup the entire time and not shipping code.

[04:40] But yeah, I think it’s mostly just culture and thinking of it as our job to sort of live in the future. And then we try and build it into the product and our harness as well so that you don’t have to do as much manual step. Yeah.

Ryan:

[04:53] Are there examples that come to mind when you think of things you don’t see people doing at Anthropic that are really making a big difference and you’d kind of recommend?

Thariq:

[05:06] Using Claude Code for knowledge work I think is really valuable. The way a technical person does knowledge work, I think, is very different than the way a non-technical person does knowledge work these days because you can get the models to do it. And so I think increasingly, if you can figure out, like, hey, this is a task, the task is made up of code-like things, how do I tell the model the code steps to take in order to do it right?

[05:36] You can do a lot more, right. So I think I do a lot of accounting with Claude Code on the personal side, using scripts and Python instead of Excel. I do video editing using FFmpeg and these libraries to render visuals and things like that. And so I think most knowledge work is reducible to code and coding agents, if you think about it well.

[06:07] And I think that that’s one big difference that I see, other people doing less of.

06:16 — Model vs Harness

Ryan:

[06:16] I think we talked a little bit about the model and the harness, and I want to ask you, what’s the relationship between the model and the harness in terms of getting the best end results? Obviously the model is important, so how important is the harness, and are there any examples you could share?

Thariq:

[06:36] Yeah, I mean, the harness is super important. I think that sometimes there’s this idea that the harness doesn’t matter because the models will get better and better. And if the model just does everything perfectly, then why do you need a harness at all? I think that in practice, what we see is the models get better and better, and so the harness needs to become more and more complicated to allow the model to do more things.

[07:04] An example of this is Auto mode. And so Auto mode is a classifier that runs after every task that you normally have to ask a permission prompt for Claude. And back when we were on Claude Opus 4 or even Claude Opus 4.5, maybe it was not so bad to hit Enter on the permission prompts because the turns would only last a few minutes anyway. Now Claude can run for hours, and so you really need that ability for it to do work safely.

[07:38] Stick to your instructions. And Auto mode is really complicated software. Sandboxing is really complicated software. And then you also think about things like, okay, Claude can do so much more work. Now, how does it represent the work that it’s done? It’s worked for eight hours and you want to know what’s done in eight hours. This is what we use Artifacts for. And Artifacts themselves are a form of prompting, because how does Claude represent that in a useful way?

[08:06] There’s a lot of different ways that it could represent that information. And so I think roughly what we see is the harness. Harness engineering is definitely this mix of science and art. I think it’s very unintuitive in a lot of different ways, but I think it has just big abilities to unlock new parts of model behavior. And I just see the harnesses get more and more complicated, and it’s kind of harder and harder to actually vibe code to your own, which is a little bit unintuitive to me because of how good the models have gotten.

[08:45] But yeah, things like Auto mode and workflows and things like that, which are actually quite complicated pieces of software, become really load-bearing.

08:55 — What percent of Anthropics changes are fully autonomous

Ryan:

[08:55] I think as LLMs have advanced, more and more of the human part can be taken out of the loop. At Anthropic, what percent of your or your team’s changes are fully autonomously made versus actually pairing with a model? People were doing more of that around a year ago.

Thariq:

[09:18] I think it’s very dependent on what you consider autonomously made or what team or what function you’re working on as well. For example, a designer might give you a Figma file, and then you pass the Figma file to Claude Code. Claude Code is great at using the Figma MCP, but the designers put a lot of work in there. I think roughly our goal is to sort of get Claude being able to do all of the glue work that ties everything together, right?

[09:55] So, okay, you’ve got a Figma file. Do I really need to rewrite that in React or something? Probably not.

[10:00] I think that work has been done once, right? And so the way I think about it is, what’s the unique work that I need to do every day, right? And the more I’m doing that unique work, the better. And I think there’s just a ton of demand for unique work and thinking. And the more I’m doing something I’ve done before, I’m like, okay, can Claude do this?

[10:24] Or if I’m just translating what someone else has done, I’m like, oh, can Claude do this as well? It’s really blurring the lines of what does it mean? Even if Claude has fully generated his PR, you’ve probably made a lot of decisions and added a lot of context along the way.

Ryan:

[10:42] How close are we to a world where someone just says, “Hey, Claude, here’s the ticket. Just don’t tell me until you’re done”?

Thariq:

[10:50] Yeah, so I mean, it depends on how good the ticket is. If someone has perfectly written out essentially a software spec for this ticket, then yeah, actually Claude can probably do that, right? But I think that to start, let’s say that we get a GitHub issue. Is this worth fixing? Oftentimes issues are also feature requests or something, or there might be multiple things happening that maybe you combine together in a different way.

[11:18] And so I think that a lot of that work is, okay, what’s the vision for the product? Where do we want to go?

[11:27] How do we make sure what we’re building is cohesive? And so I think for a specific spec, a specific enough spec, Claude can do it. In practice, people haven’t figured out what they really want and haven’t figured out the unknowns or the shape of the problem and things like that. And maybe the way you would have done it before is you start writing the code and you’re like, oh, what am I supposed to do now?

[11:55] Or you figure it out that way. Now I think you need new ways of figuring out what you don’t know yet. And I think you can still chat to Claude, really. But I think that’s the hard part. And I think definitely a failure mode is like, you tag Claude, tag. And you’re like, hey, please do this one sentence or less description, no previous context or memory. And then it does it. And you’re like, oh, no, I don’t like it.

[12:22] And then you’re like, just iterating forever on that, right? Versus figuring out what you actually want, really quickly.

Ryan:

[12:30] When I was working at Meta, the ambiguity of the task really ranges, oftentimes proportional to people’s—I mean, levels aren’t everything in software engineering, but roughly, senior engineers kind of take that ambiguous business need and convert it into something that’s a lot more concrete. And then people who are maybe newer in their careers kind of do the implementation work, and intern projects were kind of almost line by line specified.

[13:02] If I was still working at Meta and I had an intern, I was like, just kind of give the intern back. Give Claude my intern’s work back, and it would kind of do it. What kind of work does an intern do then at Anthropic, if Claude can kind of handle it? What we see in practice is that there are just so many new types of work that no one has ever done before, right?

Thariq:

[13:55] And I think that we all have to figure that out. And so, for example, how do you do an eval against these new coding behaviors, right? How do you make sure that Claude‘s performance across millions and millions of users doing all sorts of tasks? Sometimes these tasks might have tradeoffs, you know. So I think there’s a lot of new work to be done, especially on the research side of things.

[13:19] And I think that it’s harder and harder to write those specs, but there’s also less and less experience that is relevant, you know what I mean? And so I think that, yes, having some experience means that you can sort of, you know, you know how to get work done and you know how to learn. But I think you also get those skills out of college. And now I think as an intern trying to figure out, okay, what are the things that people have not done before?

[14:25] And doing that, I think, is really exciting. And I think that there’s, yeah, I think internships are less “write the React code,” you know what I mean? And there’s so many new problems to solve. We need people to solve them. It’s helpful if you have a fresh set of eyes on it. But it is definitely more proactive and opportunistic, maybe than before, where it was maybe more of like a pipeline.

14:51 — Computer use

Ryan:

[14:51] We talked a little bit about knowledge work, and that makes me think of computer use and browser use. And I wanted to ask you, how far away is that from being widely adopted in the industry and impactful? Maybe you can talk about how Anthropic uses it, since it feels like you’re always far ahead.

Thariq:

[15:11] I think computer and browser use, the models have gotten a lot better. Opus 5, I think, is a really good computer use model. But there are these weird edge cases where, for example, it can’t type a password on my behalf because my passwords are in 1Password or something, and it can’t access that. And so it gets stuck. I think there are still those edge cases, which are kind of UX edge cases. And then I think also, obviously, computer use is also the more and more people turn APIs and MCPs into new ways to use Claude. I think that can also take a lot of the use cases that you’re using computers for.

[15:51] And so going back to, oh yeah, knowledge work, everything is code. I think there are some things where there’s no API, there is no way to execute in code other than just opening up your browser. But I think increasingly there are more and more ways. And I think, yeah, Claude Code is a great example of we’ve just sort of tried to roll up all these things into APIs that it can use. And so it feels like it can do a lot of work on your behalf, even though it’s not literally running a virtual computer and clicking things.

Ryan:

[16:24] I have noticed that whenever I use any kind of computer use tooling, it feels painfully slow. I look at the cursor, and it’s sitting there for 10 seconds, moves over, goes there for 10 seconds. Where is all that latency coming from? Do you have a sense?

Thariq:

[16:41] I think it’s hard to make a small model that’s really, really good at it. I think just because there’s a lot of knowledge that you need to have about this task and how these things work together and stuff. And so you want a smart model, and smart models take a little bit longer time. I think a lot of people thought we’d get here sooner, but I think it’s just been a harder task than we expected.

[17:03] I think one thing someone’s told me about computers before is that it’s a state machine where you don’t control the entire state. If you are on the DoorDash website or something, you want to add something to the cart, and you add it incorrectly. Now you have this new flow to undo it. Now you need to go click, and now you need to go delete it, and you can make a mistake along that side as well.

[17:25] Whereas in code, you can sort of undo, Git, whatever. You control all of the state. But for computer use, each action is, if not irreversible, it’s much harder to reverse than others.

17:42 — How to make the most out of your compute

Ryan:

[17:42] At Anthropic, I get the sense that employees have a lot of budget in terms of the compute to speed up whatever it is they need to do. And so if we were to spur the imagination of people who use the models to make them more productive, assuming they had infinite compute, what type of workflows would you start telling someone to do if they had infinite compute?

Thariq:

[18:10] I think this difference is slightly more exaggerated than you think. I think that, for example, I use my Max subscription on the weekends, and I have almost never hit a five-hour limit. I think the models are really smart, and I think that a lot of times when we’re spending a lot of compute, we’re just trying to find capabilities or we’re trying a bunch of different things, and it’s more about us figuring out model possibilities than getting a lot of work done.

[18:43] When we’re testing for math, for example, we’re trying to understand how smart the model is. And that is useful to us, that’s useful output to work. And it can also sometimes solve the Riemann Hypothesis or something, or not make progress, you know what I mean? People can replicate what we do at home just by thinking at a higher level of abstraction. For example, I’m trying to get Claude to draft feedback for you.

[19:07] And so I want the funnel for, like, Claude has drafted some feedback to the user, has submitted feedback, to be really good, right? And so I monitor that funnel. And then I asked Claude. I had some ideas, but then I was also like, oh, what if I ask Claude to try and improve the funnel? And it’d be like, here are some ideas, can you come up with some as well? Let’s figure it out. All of those things you can kind of do yourself right now.

[19:33] If you’re like, okay, when I’m making a feature, let me annotate it with events. Let me make sure that Claude has access to those events. Let me run a loop in the morning every day to check what events have fired and what changes were made. Maybe even let me proactively suggest some ideas. This can all happen, I think, within a fairly reasonable amount of compute, actually. What I see more often is people running into limits where they’ve actually done the opposite.

[20:04] They’ve started with a small mid-scope task. It’s like, oh, hey, refactor this function in this way, and then Claude does it, and maybe it has some follow-on effects because refactoring this means you have to do some other work too. And that’s not exactly correct, or you’re iterating there, and it’s like you’ve just spent a lot of time. Whereas if you had sort of stepped up a level, told Claude your goals, then figure out, okay, what are the details, do some exploration, maybe write out the schema, and then work with it, then let it run.

[20:41] You could probably get the same output.

20:45 — Loop engineering

Ryan:

[20:45] I remember it was going kind of viral, this idea of creating loops. And I mean that does feel like a pretty expensive sort of thing to set up if you’re just asking it to keep hammering away. Maybe first could you define this loop engineering thing, and then I’m curious, how often do you use it, and would you hit limits if you were on a Max subscription doing that kind of stuff?

Thariq:

[21:10] Yeah. Okay, so loop engineering, roughly, it’s like instead of prompting Claude directly, you’re setting up a system that prompts Claude. You don’t have to think of it, if you use Claude Code, a lot of this comes naturally. You just ask it, like, hey, every day do this thing. And that will, that’s a loop. You can definitely do that sort of work right now. But I think if you’re trying to set up, let’s say, like 10 loops or something that are triaging your feedback and implementing and things like that, we do that sort of work, but we also spend a lot of time making sure our skills and things like that are useful and are good at triaging, that we can have, we’re good at verification and so that we can, like, make sure that the changes land, you know, and then I think at that level, you know, what it means is like, now we have someone monitoring issues that we just could never have kept on top of before, right?

[22:16] And it just increases our software development velocity, and it’s worth a lot of value to us. And so, yeah, I think that, if you’re kind of at the scale of like, okay, you want it to essentially be autonomously running, doing a software engineering job for certain cases, I think it can do that if you set up the verification well, if you set up your skills well, if you give it the right data sources.

[22:38] But it is a lot of work, right? And I think that you have to make sure that that work is valuable to you in the same way that if you hire someone, you have to make sure that work is valuable.

22:47 — Where the industry will go soon

Ryan:

[22:47] We’ve talked a little bit about Anthropic being kind of just ahead because that’s the job of the company, on adopting AI. Is there something that you feel is kind of the next big shift that maybe Anthropic‘s already felt that you feel is going to diffuse into the industry, and if so, what might that be?

Thariq:

[23:06] Yeah, I think there are a few different ones. Obviously, Claude Code is the way we do a lot of our work right now. I think the way I think about it is that Claude Code is really good at the implementation of code, and Claude Code is for the rest of the software development lifecycle, so getting feedback, doing code review, babysitting, building CI/CD incidents, all of these other things. Claude Code is really good at at a high level.

[23:38] Turning every part of your software development lifecycle into kind of like a routine or a loop using Claude Code or something like that, I think is probably where things are headed. I think generative interfaces are still to come, and I think that Artifacts and, yeah, basically Artifacts, I think, are going to be an increasingly large way of how you interact and read with Claude.

[24:06] And so I think that I use Artifacts for almost everything. And so I think that we’re going to see that also become big. And I think that also ties into Claude Code. Right? So, like, let’s say that you are on your phone and Claude Code has done a bunch of work for you. It creates a report. The report is readable on your phone because it’s made the, like, the Artifact look really great.

Ryan:

[24:28] Could you explain artifacts a little bit, or kind of what are they and how do people use them?

Thariq:

[24:34] Artifacts are basically Claude can upload, essentially a web app for you to use. And I think that you can use it in a really wide range of capabilities. They can now, for example, call your MCP. So you can make an artifact, for example, to read your inbox and display it or sort it or tag it in one way. You can also use an artifact to show you a plan for coding. And that might show diagrams and file snippets and code and schemas.

[25:09] And so it shows you sort of, it’s like an interactive display for the job you’re doing right now. And as Claude does more and more jobs, we’re realizing that just text in, text out is probably not useful for everything, right? And Claude is better and better at creating essentially the exact interface for you at the right time. I think that there’s a lot more to do there. And I think it’s another one of those things where you have to think about, like, oh, could I be interacting with Claude in a different way?

[25:44] Could I interact with it through an artifact? Could I use it to learn more or to understand it better or stay in the loop or improve some of my own knowledge work or something? Yeah, I think it’s pretty exciting. We’re still kind of early to it.

26:02 — Which model do Anthropic engineers use

Ryan:

[26:02] Does the daily driver model vary among engineers, or do people typically just pick the most intelligent one that’s available at Anthropic?

Thariq:

[26:11] I do think similarly with models. If you use the smart models and you use them well and you give them tasks where they are well shaped and you’ve spent some time setting up a good verification harness and things like that, you can get a lot out of them. I don’t think it’s like choosing which model at the right time. I think it’s like, oh, how do you get the most out of the frontier models? Because I think technology works the way it does, right?

[26:37] Everything gets more abundant, more available. And so I think we’re in this current weird spot where we don’t quite have enough compute for everyone to have Fable at 100% of the rate limits. But I don’t think this is a durable skill to build, figuring out, like, oh, when do you use Fable and when do you use Sonnet? I think it’s unintuitive there. But I think in practice, if you’re today, what I would do is I use Fable for planning, for brainstorming, for finding unknowns, for coming up with a detailed spec, and I’d use Claude Opus 5 to implement it, and I would probably use Claude Opus 5 with workflows using a verification aid like Schema or Harness that’s built with Fable.

[27:21] So I’d use Fable for those high-leverage tasks and, yeah, Claude Opus 5 for execution and implementation. But yeah, I think increasingly, probably next year, I think you’re just not going to be thinking that much about which model.

27:38 — Is learning a particular model worth it

Ryan:

[27:38] You mentioned that skill of prompting, and I’ve heard some people say it’s not too durable of a skill because it’s really specific to a model. These models, they almost have their own unique, I guess, spiky intelligence. So if you knew everything that was very specific to, let’s say, today’s Fable, and you’re a master of today’s Fable, maybe you don’t need to know any of that stuff a year from now.

[28:08] And Fable 3 or 4 or 5 or whatever comes out. Let’s say you were talking to a software engineer who’s looking for career advice, and they’re thinking, hey, should I really become a master of engineering?

Thariq:

[28:23] My prompt, I do want to say prompting is a little bit more than just a prompt you put in. It’s also, you know, you might have made a skill or you might have added some data or something. It’s not just a prompt you write, but it’s like everything you’ve done before that builds up into your context. Sometimes people see us write small prompts and they’re like, oh, what does that mean?

[28:44] But we just spent so much time on the harness and the verification and the skills. So I think it will be really valuable to just get better at prompting. I think, to what you’re saying about each model is different, you’re right. I think each model is kind of its own kind of almost organic digital thing. And so there are quirks you have to learn, and you do have to unlearn them. We recently wrote about how we removed 80% of the system prompt from Claude Code.

[29:18] One of the learnings we had was we needed to remove examples from the tool descriptions. This used to be the only way you could get good output from the models was through tools or through examples. You’d have to be like, hey, this is the right tool. Use this here. Here’s an example of writing a file well, and here’s an example of not doing it well. Now, we found that examples are mostly negative, I think, unless you really see Claude doing something you don’t like because it’s just quite imaginative.

[29:52] It’s good at sticking to your intention and working with you. And so we removed a lot of examples. So in that case, yes, you do have to sort of adapt, but the skill you’re building is the skill to adapt. You learned how to use Fable, and now you know a lot about Fable, but you also know how to learn. You learned how to work with a model, and so Claude Opus 4.5 comes out. You need to learn how to use it again as well, but you’ll be much faster because you’re better at learning.

[30:22] You’re better at working with Fable 5. And I think, for me, I think the first model I worked with was GPT-2. And I remember it was so hard to get a JSON output out of GPT-2. If you could just get it to choose one of the categories that you gave it, that would be incredible. And so I think that building that skill—GPT-2 is such a different model than Fable 5—but I feel like the time I spent doing that has helped me be better at prompting Fable 5.

30:56 — Prompting tips for todays models

Ryan:

[30:56] Is there any tribal knowledge or quirky tips in today’s models where you’d say someone should know that to get more when they prompt? I actually need to counter one.

Thariq:

[31:03] I think that people have been saying where it’s like, oh, just believe in yourself or something. I know that Jared’s post about the Riemann Hypothesis. He was just like, keep going, just believe in yourself. I think in this case it was mostly just Jared saying, it’s okay to use Claude Code to solve this problem, and I’m giving you permission to do it. And I think that that’s not exactly the same as I believe in you.

[31:33] You know what I mean? It’s really just letting the model use compute. So I think that is something I like to tell the models right now is like, okay, hey, I think this is a hard problem. Use subagents, use workflows if you need it, right? So I always tell it to use its own judgment, but I’m giving you permission to do this stuff. I think that you have to remember that the models by default do what maybe the average user wants, which is they want it to respond and start doing work as fast as possible.

[32:11] Roughly complete the task but not spend a crazy amount of compute on it. I think that you have to sort of, if you want the model to do it differently, you have to nudge it slightly, right? So you might have to be like, okay, hey, I don’t want you to do any work yet. I want you to brainstorm. I want you to think with me, right? And if you prompt it that way, it will start doing that if you want it to spend a lot of compute.

[32:36] If you’re like, hey. Sometimes I’ll say, yeah, hey, I think this is a hard problem. Feel free to use workflows. If I’m running overnight, I might just be like, hey, I’m going to sleep. Set a /goal or something and then let it run. So yeah, I think there is just giving it permission to do the thing you want.

Ryan:

[32:57] When you recently removed so much of the system prompt, how did you prove that the end result was better?

Thariq:

[33:06] We have a bunch of user metrics, just like how much do people like the output of Claude? Sometimes you get that survey and you see it. We run evals against our internal eval and external evals to see how it performs at these different tasks. But I think it is hard sometimes. You don’t realize that if Claude is telling the user, if it does all its work and then it’s like, hey, maybe you should go to sleep.

[33:35] There’s no eval for Claude telling you to go to sleep. You know what I mean? And now we have to catch this new behavior. So it is hard. I think we spent a lot of time basically just removing lines in system prompt, running evals, seeing how it works, seeing how people reported it internally, and then adjusting. But it was a full-time job for several people over long periods of time. And so I don’t think I necessarily recommend everyone do this.

[34:03] I think that’s kind of why we wrote that post about what we learned from adjusting the system prompt. And we think that’s pretty general. So hopefully you don’t have to now go through this crazy iteration process.

35:04 — How to get the models to do tasteful work

Ryan:

[35:04] I think a lot of people, when they use Claude Code, they get excellent results when it’s kind of getting very objective work done.

[35:13] But when it’s prompting models to do beautiful or tasteful work, it’s not always. It’s pretty much more hit and miss. And so, how do you best instill a very particular style you’re going for, or particular taste in the model’s outputs when it’s a much more subjective domain, maybe like front end?

Thariq:

[35:35] The way you do it is sort of like you stay in the loop. I think you give it references, and I think the more references you give it with data, the better. So it’s better to give an HTML file than a screenshot. It’s better to give a Figma file than a raster image or something. Because now if Claude wants to know the border radius of this thing, it’s like, oh, what’s the Figma component? Border radius?

[36:00] And let me just copy it over. I think giving it a bunch of references, ideally in code, is a really good way of getting it to stick to this. I think if not, you can then ask it to. If you don’t have, let’s say you’re not a designer, there’s probably step one is being like, okay, I’m not a designer. There’s a lot I don’t know about design, and there’s a lot I don’t know about iteration. I don’t even know what good looks like.

[36:29] And I think this is part of the art of working with the designers. They will just know what good looks like, and they’ll be like, this isn’t good enough in this way. And they prompt it. And that, I think, is also a skill that will keep getting valuable and even more valuable over time: what is good output, what is worth doing? I think, for example, with the Riemann Hypothesis, Jared prompted it, but he had no idea if it was correct.

[36:56] Until Lev, who is one of the world’s best mathematicians, was like, okay, is this correct? And he worked with it, and he asked it tons of follow-up questions, and we could not follow that at all. We had no idea what he was saying, but he was really intrigued. I think more and more, being that high-taste user and knowing a lot about a problem in a domain space is how you get good outputs. That’s how you solve these problems.

[37:27] Otherwise, maybe Claude did solve physics or something, but you just wouldn’t know it. You don’t know enough about it. And so I think when you’re talking about design, the first thing you do is how do you become more tasteful with design? And so you can ask Claude that as well. You can be like, hey, I’m not a designer, I want to be better at design. I don’t even have the language first. Maybe let’s find some reference sites.

[37:50] And then maybe you pull some reference sites, and then you’re like, this is what I like, or this is what I don’t like. And then you sort of build up those references, and you give Claude Code, and now maybe you tell it, hey, let’s do some exploration. This is sort of my taste. And then it’ll do a few different mockups. I like to do these mockups all in HTML because it’s all self-contained, easy to edit.

[38:13] And then once you have that reference, now it’s a reference. So now you can make a new session and be like, hey, this is a mockup of a design. I want to start implementing this, and it will have all of it in code, and you can start getting there. But I think that the really hard part is just knowing when something is good enough versus when can you push harder. And you see this with a lot of the math proofs too.

[38:41] When Terence Tao is like, okay, enough with the half-complete theorems, just do the full theorem. And so I think it sounds simple, but it takes a lot of domain knowledge and expertise to get to the point to be like, okay, it seems like you’re smart enough to have done that. Now do this.

39:00 — How much of writing is done by AI at Anthropic

Ryan:

[39:00] When I was a software engineer, there was a lot of, I guess it was like glue writing work kind of where you finish some work and you write a launch post, or you are part of some work stream and you got to post an update every two to four weeks. Or maybe you have a direction doc or design doc and all this writing around the software that you actually write. And curious your thoughts on if that’s changed at all at Anthropic, how much of that is written by LLMs and how much of that is human written?

Thariq:

[39:39] Still, my rule of thumb is if I would be happy to show someone the prompt, I would send them the output, right? And so a lot of times the prompt is just collecting context. Context is the most common one. For example, before every one-on-one with my manager, I asked Claude to read every Slack message and GitHub message or PR and compile a report of what I did. That’s context that my manager doesn’t have because they haven’t been literally reading every PR or something.

[40:15] And so I don’t feel bad if my manager could also run this command, but it doesn’t have my context. And I don’t feel bad with them knowing that this is the prompt I used to generate this command. I think likewise, if you’re sharing updates or something like that, you might want to prove that you’ve read it. I think this is important. And sometimes little edits are ways of proving that you have also understood this work.

[40:45] And so if it’s just like a data readout, maybe you’re sanity-checking the numbers make sense and these are all the numbers you intended to include. And as part of that, maybe you format it differently or you add a little sentence on your behalf, but I think ultimately it’s a data readout. Everyone knows the prompt you wrote is like, hey, generate a readout on this feature based on this, and you’re fine, right?

[41:10] But I think if you’re pitching a new concept or a new idea, and your prompt was like, help me come up with a new concept for this product, right? People probably at least want to know that you’ve believed in it, right? And so even if you think Claude‘s idea is incredible and just verbatim, you wouldn’t change anything. What I would say is, I’d be like, hey, Claude generated this.

[41:34] But I think it’s great, you know, like I did 100 different generations. And I think this was really good. And here is something, you know, that I want to send you, right? And so I think that it’s good to be upfront about it, I think, right? Because I do think what people don’t like is when they feel like they’ve been misled a little bit. Like, oh, we thought you were doing this work, but, you know, it’s really Claude.

[42:01] Right. And I think that writing sometimes can have a lot of... There are some parts of writing where individual words matter, funnily. Tweets are, I think, an example of this, where the individual tweet matters more and more. You can’t use Claude to do that because it’s like every word has some thought that you’ve put into it and some intention that you’ve put into it. So yeah, a pitch or an essay or something like that.

[42:29] We do a lot of internal essays at Anthropic, being like, hey, this is why I think we should do this. And that’s generally all human written. It’s very looked down upon, I think, to have Claude write your essay for you, you know what I mean? Because every word is something that you are intentional about.

Ryan:

[42:48] This sounds like the proportion of the writing. That’s all that boring rote writing, like the data readouts, the one-on-one updates, the work stream updates, that’s increasingly becoming AI but always reviewed by a human. And then the novel thoughts, novel direction, is still very human written and feels like it should remain that way, even if the models were a little bit better too.

Thariq:

[43:16] Yeah, I think it’s like if your writing is also a way of thinking, and so maybe if you need to think about the data stream or data readout more than maybe you need to summarize it. And so, but I think especially gathering context is one of those things where no one will ever hold it against you, kind of. Right. Like, oh, you know, you did a bunch of research and Claude did this.

[43:41] But yeah, like I don’t want to ask my agent to do the same research. Like, you know, it’s a shortcut, but just acknowledging it is good.

Ryan:

[43:48] Someone else I was talking to, they had this thought that it would be valuable to have almost like a Git blame, but it’s like a prompt blame because it would be nice to reverse look up what was the prompt that generated this change, to kind of debug things. Do you have any sort of meta version control on the prompts that generated the software, or is it still very vanilla Git history?

Thariq:

[44:17] Yeah, that is a little bit tough because, again, what goes into a prompt is not just the prompt, but also context and skills and things like that. So maybe a prompt might seem basic, but isn’t. I think it’s kind of hard to judge, but I do, going back to when I’m giving a PR, I don’t think a PR at this point is any different than an artifact or something. Claude is doing basically all the code writing.

[44:44] So if I send someone a PR, I usually also attach an artifact of every prompt I sent to Claude, including failed approaches and things like that, so that they can see, okay, I’ve considered a lot of other things. And if I haven’t, if this is just a one-shot, I just tell people, I’m like, hey, this is the one-shot example. This is the prompt I used. And I think that’s usually impressive and interesting to them as well because they’re like, oh, it’s cool that Claude could one-shot this.

[45:18] But the worst is when you get, like, I’m just trying to avoid cases where I send in this 10,000-line PR and they’re like, how much have you read this? Or how much do you work with Claude on it? And if I’m doing a large PR, I am going to show my work.

45:36 — Code ownership and maintenance at Anthropic

Ryan:

[45:36] as much as possible on maintaining code, because AI can generate such high volumes of code at this point. Do you have any tips on what’s worked well at Anthropic for code ownership and maintenance?

Thariq:

[45:52] I do think you have to revisit what is important with code maintenance. I think that there are some things where naming used to be really important because it was how you as a team thought about this abstraction and feature. But I think naming is becoming less and less important. A lot of stylistic things in code are becoming less and less important. And I think that this is not the same to me as maintenance.

[46:19] I think that you might want to sit down and be like, okay, what things really matter now? What don’t? What opinions do we have that don’t matter? That’s one. And then I think on the second, on the maintenance side, is having good scaffolding. So I think that it’s like having a good verification harness, having a good sort of skills. We use the simplify skill a lot. I think that sometimes even from a model perspective, it might do a lot of work.

[46:51] And then even just giving it permission to be like, “Hey, I think this is the right idea. Let’s simplify.” It gives it that permission to do it. But you actually don’t want a model to, by default, do work and then simplify because maybe it’s not correct. You don’t want it to simplify work. That’s not correct. It’s like you’re wasting tokens. And so I think this is also how humans think. You’re like, you think generatively, you try and approach, and then maybe you simplify and abstract a little.

[47:23] So I think there’s some work inside your own code base or setting up those skills and that process for those practices where you’re not just submitting the first take, but you’ve simplified it and tried it. And then having a really good verification harness where you feel like you’re catching it. You have a good belief that Claude is testing every part of it. When you submit a PR to Claude Code, you get a recording back of it using the feature and testing it as an example.

[47:56] And you can just get really, really creative with different ways to test stuff. I think you should basically have on the order of, I’d say more like 100 times more testing code than you’ve ever had before. You know what I mean? So you should have fixtures for everything. You can just pull production code and create fixtures and mockups on the fly for databases. You can have Storybook for front end and things like that.

[48:22] And you can have all these different ways of testing and verifying your code. And that, I think, is really valuable for maintainability. It’s like just having all these ways of verifying it. And then, of course, there’s just the human element of where do you want your codebase to go? If you know that’s the case, probably you start thinking about how you’d replay, and undo and redo becomes really important, just that sort of stuff.

[48:52] But if it’s single-player only, that actually matters a little bit less. The average user is not going to undo 100 times or something. And so many single-player applications’ undo stop working pretty quickly after four or five times, just because it’s not that important. But in multiplayer, the ability to compose different things together is really, really important, or compose different operations together is really important.

[49:19] That’s just an example where, if you know the direction of your codebase, there are things you care about and you want the models to know, and you can include that in your skills. You can also just. That’s sort of what maintainability means to me, is having a vision for what your codebase is good at, where you’re going, keeping it in line. I do think the models are getting better and better and better.

[49:39] And almost every code base probably, I think, will have this moment where you’re like, do you just ask the model to rewrite all of it? Because now you’re like, oh, I can do it in the most performant language, I can mix and match. There’s not a reason that every software in the world shouldn’t run in WebAssembly in the browser. You know what I mean? There’s not a reason why I don’t know your Xbox game can’t run in your browser.

[50:09] Actually, the consoles are much weaker than your average MacBook right now. But it’s just the code base. But we could. And so I think probably over the next year or two, everyone’s going to need to think about that. And so I don’t think you want to spend too much time worrying about maintainability in this way. That might not matter anymore. I’m not saying maintainability doesn’t matter.

[50:37] You just have to update your mental model of what does it mean for code to be maintainable.

Ryan:

[50:43] I was talking to this friend who was saying that he leaves tons and tons of tech debt lying around because the next iteration, why waste time fixing that now? In the next iteration of Fable, it’s going to one-shot all this tech debt and refactor this for me. So kind of funny.

Thariq:

[51:05] Yeah, I don’t think that’s completely incorrect. It depends on the circumstance, right? I think this is also just a classic thing in startups where you’re like, even in normal human engineering, you always have this problem of like, hey, do I refactor? Do I do tech debt or do I deliver more customer value? Would refactoring help me deliver more customer value right now? I do think that, generally, you should think on your projects on shorter timescales, so you’re like, okay, how do I deliver value over the next month or two?

[51:36] And if the project you’re talking about is delivering value over six months or 12 months, then maybe wait for the next model a little bit and just deliver value on the short timescale. Make sure it’s really good. And if the models are not quite good enough, they might get there soon. It depends very much on the specific case.

[51:59] Right? But I’m not saying this is true of everything, but just something you should keep in mind.

52:04 — How Anthropic prevents breakages

Ryan:

[52:04] I’ve talked to some friends who work at big tech companies like Google, Facebook, those types of places. And then they, as they’ve become more and more AI-pilled, one thing that people have noticed is there’s a lot more incidents or sevs in their usage, and it’s natural in those organizations because they read the code less and there’s more code flying out. What countermeasures have worked really well for Anthropic to prevent breakages, given that the code velocity is so much higher?

Thariq:

[52:38] Yeah, I think this is something that is a byproduct of moving faster sometimes, and we have to figure it out. I don’t think our uptime is exactly where we want it to be either. But also, as a company, we’re almost six years old, I think, around. So it’s like no company has grown this fast before. And a lot of that is because we’ve been able to create more products faster than ever before.

[53:04] And so you can use Claude to make your uptime better. And I think the way we think about this is just really good. What’s the dream testing environment? The dream deployment environment? Can you take requests and replay them across mock databases and fixtures? Across everything. Can you Chaos Monkey everything?

Ryan:

[53:26] In my personal workflows, I have so many more custom random tools and scripts that just make everything faster. And just curious, on your team at Anthropic, for instance, does everyone have a set of miscellaneous tools that help them get random things done?

Thariq:

[53:48] Yeah, everyone does for sure. I think part of this is the job. I think that sometimes what we try and do is we play around with harnesses. Sometimes some people on the team build their own harnesses for a little bit to figure out, oh, is this useful or not? And then they figure out if it works and if not, they integrate it. I think that’s part of the job in some ways. I think other examples of sort of misc stuff people will do.

[54:18] A lot of people will have unique Claude Code setups. I think Claude Code is one of these things where, you know, you can have it like I have it scheduled, my calendar advice, right? And so if someone wants to schedule something with me, I’m just like, hey, you can just tag Claude here in this channel and I’ll accept whatever it puts on my calendar. You know what I mean? So I think there’s some stuff like that.

[54:41] I know a lot of people use it for email. I think that I’ve seen some people do interesting multi-closing, sort of tmuxing-like setups. What’s the ideal scenario for you to display 50 different Claude Codes, and what’s the best way for you to figure out what’s going on at any one time? I think there’s a lot of different ways, and we’re trying to make Claude Code more hackable as well so that more people can even make their own version of Claude.

[55:18] Code more different, and everyone might have their own little twist on it.

55:24 — Visibility and sharing your work

Ryan:

[55:24] Your role at Anthropic is really interesting because of the external visibility that you have. And I think a lot of people, when they give career advice, visibility is a good thing, but they don’t have this level of external visibility. So do you recommend to software engineers that they should be posting on Twitter and X? And if so, what advice would you give in that sense?

Thariq:

[55:49] Generally, the thing I say to people is that you should share your work externally as much as you can. Especially, I think, within certain companies. You might not be able to, but maybe you have side projects or something like that. I think just before I joined Anthropic, what I did was I spent a bunch of time working with different companies, building stuff, and writing about it and talking about it.

[56:13] And this was really valuable because it increased my surface area of luck. And so I think that the bar is much lower than you think. Basically, whenever someone asks me for advice, I’m like, okay, I’ll sit them down. I’ll be like, I know statistically I tell this advice to a lot of people, and almost no one does it. And everyone who’s done it is either in a job that they’re pretty excited about or running their own company.

[56:45] And there are reasons why you’re not going to want to do it, but this is it. I just can tell you one: I don’t care about your resume. Don’t do that. You have to choose an interesting project to work on. You have to work really hard on it. You have to lock in, and then you have to ship it and write about it. You have to do it. You can’t. There’s going to be so many reasons why you don’t want to.

[57:06] It’s like not good enough yet. Or like you haven’t, like you think the writeup is not very interesting or something, but you have to do it and you can’t get discouraged. Maybe the first one might not work, but you have to do it again. And maybe Twitter is not the right place. Maybe it’s Reddit, maybe there’s a specific Reddit or Hacker News or something like that. Part of what you’re trying to do is you’re just trying to find people who like what you’re doing, right?

[57:29] But I think that people in general want to really, you know, we consume more content than ever, right? And you know this, right? I think that people want really high-quality content. High-quality content, as you know, is a lot of work. And so I think going back to what we said before about would you show someone the prompt? You did, right? I think a lot of times people are like, oh, what’s the shortcut?

[57:55] “Oh, should I just ask Claude to manage my Twitter account? And is that how I grow?” And I’m like, no. Like, you should not do that.

[58:03] You have to sort of engage authentically. You have to post, do good work, and talk about it. And I think build up networks and things like that. But I think that as long as that’s one of your goals and you try hard at it, I haven’t seen anyone not succeed at it, but it is really hard. It’s kind of like saying, oh, I want to go to the gym every day, or I want to lose weight or something.

[58:26] There are simple things that you can do that take a lot of discipline and are easy to get discouraged with. But they’re worth doing if you do it. And I think posting, or more specifically writing about your work, is really, really valuable.

58:42 — Luck surface area example

Ryan:

[58:42] You mentioned LLM surface area. Do you have an example that kind of illustrates the value of expanding your LLM surface area?

Thariq:

[58:52] Yeah. I mean, okay, how did I get my job at Anthropic? I did a fellowship with a company called Goodfire where I did some applied research. And so they’re an interpretability AI company. And I was trying to figure out how do I use interpretability to make better products? And so I learned about their research, and I felt I want to work on a project, and it was really important for me to share it.

[59:21] And so, when I agreed to work with them, I was like, that’s my goal: I want to share what I’m building. I think that’s good for you as well, because Goodfire is a startup, and people want people to learn about them. And so this is something I’m going to do. So I built this interpretability visualization, and I shared it. This was my first big post on Twitter, but it was only 500 likes or something.

[59:42] Now, you know, that’s not very much to me, but it’s like, back then it was like a huge post, and several people saw it, and some of them DMed me about it. And then I got an intro into a role here. And so I think that I spent a month on that project in particular, so it wasn’t crazy. And, yeah, it just showed people that I could do interesting work.

[01:00:17] And I got paid for it too, so it wasn’t like I was doing it for free. And there’s plenty of examples of, I think people are happy to do that sort of thing for you, if you sort of show that kind of initiative. But yeah, you have to. It is like, you really have to do interesting and novel work and work hard and be proud of your work as well. There’s not a shortcut to that, I think.

[01:00:43] But if you do, I think everyone is always looking for interesting work and wants to support you and wants to hire you or, yeah, give you money, like, lots of good things.

01:00:57 — Should people still learn to code

Ryan:

[01:00:57] I see this tagline going out a lot with some of the stuff that Anthropic‘s been maybe, like, I think it was Boris went on some podcasts, and the tagline was, “Coding is largely solved.” Should people still learn to code if coding is largely solved?

Thariq:

[01:01:14] I think being technical is really, really important. Knowing how computers work, how computer programs work, how languages work, what are the hard things? And what’s a backend service, what’s a cache, what is memory allocation? All of these things are actually kind of really important to learn. I do think it’s hard to motivate yourself sometimes to do it the same way that doing math by hand was not that motivating to me, but some people just love math and did it.

[01:01:49] I think that that’s probably something that people have to figure out, but I think it is really worth it. Being technical is really, really important. We talked about at the start, or earlier, where the only way you can tell you’ve solved the Riemann Hypothesis or made progress or whatever is if you’re a great mathematician. And in the same way, the only way you can tell if you’ve built great software is if you’re a great software engineer.

[01:02:19] I think that how do you do that is hard. But we’ve talked about some of this stuff before, just staying in the loop, reflecting on your process and getting better. And you can use Claude to learn as well and sort of explain things to you. So treating it like a thought partner, but learning truly. I think Karpathy says learning should feel like effort. And I think that’s one of the hard things is a lot of times, even if you ask Claude to explain something to you, you might just nod along and you’re like, oh, yeah, I learned it.

[01:02:52] But you didn’t really, because you didn’t put any effort in. So I think it is really technical. You should learn. It’s hard to learn. And sometimes what school forces you to do is learn that. I don’t know, truly. I’m not learning programming from scratch, so I don’t know exactly how to do it. Now, I think if there are better ways, I would still type out and build programs and run them and learn them, you know what I mean?

[01:03:20] There might be better ways that are more Claude-informed as well. But I think it’s really important. I think when Boris says coding is solved, I think it just means we don’t get stuck in the same ways that we used to before. I think coding used to be this very high-variability thing where you’re like, oh, could this bug take a day or could it take two weeks? You have no idea sometimes. And I think on the whole, coding used to be in real terms something that was very rare for something to go well.

[01:03:56] Very few people in the entire world could write software, and they were very, very rare. And even if you got them all together, there were so many other reasons why it wouldn’t work. And coding was one of the rarest things in the world where the chance of a software project going well was, on absolute terms, very low. And if you were hiring someone to make software for you for something that’s not a huge product, like if you’re hiring someone to make software for your car dealership, you are almost certainly not going to get the software you wanted.

[01:04:31] You’re going to get essentially scammed, you know what I mean? Not because anyone was trying to scam you. It was just like, software is really, really hard and it could only be spent on the most important scalable things in the world. And now that coding is solved, I think what we mean is that you can use coding to do all these other things that we’ve not done before. But that’s not to say that that’s not a lot of work still.

[01:04:56] It’s just not this incredibly rare, difficult thing that mostly just doesn’t work, and you have to spend, like, eight hours a day locked in to do well.

Ryan:

[01:05:07] It’s really insane. That shows the difference in expectation is when I used the right software. I would be shocked if it worked on the first try. I was like, whoa, wait, why is this working? And you expect to kind of bash your head against the wall a little bit and then it works, even if it’s just like you missed a semicolon or something like that. And now I almost have the flip expectation where when it doesn’t work, I’m like, wait, what, why, why did Claude.

[01:05:34] What happened here? Usually I expect it to work almost the opposite, like on the first try.

Thariq:

[01:05:41] It’s crazy immediately. Yeah, I think humans get really used to abundance, right? There was this article someone shared recently about going through a modern apartment and talking about all the wonderful things that we have now that people could not have imagined before. Something that can play music on demand that’s suited for your mood. Before, you’d have to hire a musician to go write incredible music, right?

[01:06:09] But I’d say, on the whole, probably more people are getting paid to make music now than ever before, right? And I think that music is reaching more people than ever before. And I think probably the same thing will happen with software, will happen with math, will happen with all of these things where, when you get abundance, people are like, great, I want more abundance.

[01:06:30] I want my software and everything, you know. Like, I want my music everywhere, you know.

Ryan:

[01:06:34] So, yeah, one potential other data point from this conversation saying that maybe people should still be technical or learn how to code is, I think earlier in the conversation we talked about automating knowledge work, and you mentioned that people who are technical had kind of a leg up because they kind of understood how to coordinate Claude to do a variety of things, like you’re calling FFmpeg to automate some video editing.

[01:07:01] And I don’t think someone who is not technical would have that thought. So it does seem like even in this case where models are doing a lot, there’s still so much value in

Thariq:

[01:07:12] Being technical, knowing how computers work, in the same way that probably the most technical CEOs are, like, the best CEOs are technical, like Zuckerberg, Elon, but they probably haven’t written a line of code truly in a long time. But they understand how systems work, they understand constraints and things like that. And that’s really, really important. And so even if all that work has changed, I think being technical is really, really important.

01:07:42 — Advice for his younger self

Ryan:

[01:07:42] And then last question for you is, if you could go back to when you just entered the industry and give yourself some advice, knowing what you know now, what would you say?

Thariq:

[01:07:52] They’re like kind of like two wolves, sort of. I think you have to believe in yourself. I think this is really important. And I think that at least when I joined the industry, it was rarer to believe in people when they were kind of younger. I think that was the whole point of Y Combinator or something was believing in young people early on to do really great things.

[01:08:15] And so I think that, you know, even going back to the internship discussion we had earlier, right, I think that thinking of yourself not as someone who’s being trained to do something, but someone who can do something incredible right away, I think is really important. And I think I wish I had done bigger, bolder things that I’d written and shared about.

[01:08:38] I think there were lots of ideas where I was like, wow. I think I had thought I had done original work that I wish maybe I’d even shared in some form, but maybe not in a form that survived the Internet, you know, and it wasn’t a goal of mine. And so I wish I’d sort of been bolder and done and shared some of this work. But at the same time, you also.

[01:09:03] There is a lot to learn from people. And I think that when you’re young, you tend to fall. Either you’re not bold enough or you’re too bold and you don’t figure out what people have done before and figure out why this is not working, right?

[01:09:29] And there’s this balance. And I think everyone has different failure modes, but I think I probably didn’t take enough advantage of mentors and people who had learned a lot. And I think I probably had to relearn a bunch of things as a result. So there’s probably not universal good advice, but just things to think about as you’re entering.

Ryan:

[01:09:53] Awesome. Well, thanks so much for your time, Thariq. Really appreciate it.

Thariq:

[01:09:56] Yeah, of course. Thanks, Ryan Peterman. It was fun.

This made me curious about Martin Odersky’s (the creator of Scala) thoughts comparing different languages. His deep domain expertise made his responses comparing Rust, Zig, Python and Scala interesting.

He also had a lot to say about how AI will impact programming language ecosystems in the future. For instance, he talked about some research he was working on to strengthen the static guarantees programming languages give to provide more safeguards for LLMs.

Hope you enjoy the conversation!

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:44 - Why care about functional programming

06:35 - Why should people learn Scala

09:26 - Rust vs Scala

12:42 - Rust vs Zig

15:45 - Scala vs Python

18:31 - The programming languages that influenced him

22:16 - How running on the JVM works

26:33 - Why writing a compiler is hard

29:19 - Why Twitter adopted Scala early on

31:00 - How he believes AI will impact programming languages

43:40 - Will there be less engineers in ten years

44:34 - Top programming languages to learn to grow

46:18 - Top technical book recommendation

46:51 - Why he chose academia instead of industry

48:28 - Reflecting on Scala

55:42 - Advice for his younger self

Transcript

00:44 — Why care about functional programming

Ryan:

[00:44] What is functional programming? And why should an imperative programmer care about the functional way of programming?

Martin:

[00:52] So functional programming is programming with values, so you don’t have state that changes, like mutable variables that change or arrays that change. You have values and you have functions, and the functions transform these values into other values. So it’s a very restricted form of programming. And most real functional programming languages are impure in the sense that, yes, of course, at some point you have to touch state and change things and write to standard out and things like that.

[01:24] But the idea is to do that sort of very late, so to have the largest part of your program represented as values and functions that transform values. And the benefit you get from that is essentially much better predictability and fewer bugs, because these side effects to, let’s say, a global variable or a field in some object graph or things like that, they can really trip you up. They can essentially, they’re an undocumented effect of your function, so it’s not reflected anywhere typically.

[01:57] But maybe you have a comment if things are good. And these things are very hard to keep in your head and generally reason about. So the advice from functional programming is essentially to keep these things to the bare minimum and possibly to nothing if your function maps into these things. The other reason why functional programming is nice is that it’s very directly linked to mathematics. So in mathematics you have theories of, let’s say, polynomials or strings or lists or things like that.

[02:33] And in none of these theories will you find the concept of mutation; that just doesn’t exist. So you can take a polynomial and you can transform it into a new polynomial, but you can’t change a coefficient at 0.3 at the third coefficient and pretend it’s the same polynomial. It’s not in mathematics, right? It’s clearly something different. So functional programming, you could say, follows quite closely the way mathematics sees things.

Ryan:

[02:58] What would you say to someone that doesn’t do functional programming because it’s not convenient?

Martin:

[03:04] I guess two things. One is it’s a learning curve. So initially your brain is wired to do imperative programming from when you were very young. I imagine most people learned an imperative language first, and then it’s hard to see how you would express things differently. But if you persist in that a little bit, and it doesn’t really take much, then you will essentially reap the benefits very quickly, that you say, well, actually my program got a lot clearer.

[03:36] I can understand it better. I don’t really have to track some steps, go step by step through my program with a debugger or things like that to figure out what it does. Typically I don’t need a debugger when I write functional code. That’s really not necessary. The other thing is to essentially know when to stop. So there is a strand of functional programming called pure function programming, which tries to express as much as possible in pure functions and to delay the side effects and wrap them up in monads or whatnot.

[04:15] And that can get very inconvenient very quickly. So my answer to that would be, it really depends. And in most cases, it’s completely okay to have your side effects as long as these are well documented and you use them. So basically, use these things in moderation. I would say functional programming is great for 95% of your program, and if you need some side effect, some imperative feature, for the last 5%, that’s also okay.

Ryan:

[04:45] Is there any quantitative measure of the, I guess, the correctness benefits that functional programming gives you over imperative?

Martin:

[04:56] I think there are some studies. It’s not quite clear how significant they are. I think people criticize them a lot. The studies tend to say that a language like Scala would have fewer bugs than a language like C/C++. But I don’t really want to insist on that because these studies are very hard to do, and the methodology is very hard to get right. I believe the effects become more important in large programs than in small ones.

[05:28] For small ones, you can do anything, really. You can write a loop, you can write a recursive function. It doesn’t really matter. And it’s very much a matter of taste which one you prefer. But in a large system, I believe static types have certainly proven their worth, even if we don’t really have a conclusive study that shows it. I mean, I can point you to a study, and if you’re a dynamic typing enthusiast, then you will point to another that essentially claims the opposite.

[05:59] So it’s very, very hard to do empirical software engineering on that scale. And so I’m afraid I can’t really give a good answer. I just have a feeling that mostly functional statically typed languages is sort of a sweet spot for getting programs right. Maybe the other thing is when you really need to get them absolutely right, like with proofs and things like that. If you do Rocq or Lean or any of these things, these are all functional languages.

[06:29] So people wouldn’t even attempt to do something like C/C++ here.

06:35 — Why should people learn Scala

Ryan:

[06:35] When you think about Scala in the environment of all programming languages, what sets Scala apart? Or maybe put it another way, why should someone learn Scala in 2026?

Martin:

[06:47] Well, Scala is the only functional language that is also a very capable object-oriented language. In fact, it was born by the idea that we can actually make a fusion of the two in a way which is not side by side, but which really combines the features in a nice synthesis. So that was what Scala was about. That’s what I wanted to show, and that’s been largely successful. So you can write really beautiful programs in this combination.

[07:19] Object-oriented programming comes in when you talk about components and modules and essentially encapsulation, these sort of things where functional programming typically doesn’t really have a very strong story. I mean, there are languages like Standard ML or OCaml that do have very capable module systems, but other functional languages don’t. And people, when they think of functional programming, they don’t really think much about components and interfaces and these sort of things, which are things that I believe also matter very much.

Ryan:

[07:50] Could you give an example? Maybe an object-oriented thing that you could do in Scala, but you couldn’t do in Haskell, which is pure functional.

Martin:

[08:00] It’s sort of ingrained in the whole fabric of the thing that everything is essentially objects, what you do. So one thing that you get is what I think Simon Peyton Jones called the power of the dot, that you say it’s super convenient. You have an object and then you do dot, and then you have the environment that immediately tells you what are the methods and fields of that object, that you can use them.

[08:24] So it focuses your mind. Whereas in functional programming, it’s typically you have a sea of functions that can be applied to arguments, and you have to figure out what they are.

Ryan:

[08:34] When you think about the systems programming languages like Rust, Zig, Go, C/C++, in your opinion, which one would you say is kind of the best one? And then maybe we can compare it to Scala.

Martin:

[08:46] In this day and age, systems programming languages need to be memory safe, guaranteed memory safe. So that would already exclude quite a few of them, but it would leave Rust and Go, I think. And Rust and Go are at different levels. Go is really not a sort of nuts-and-bolts systems programming language. This is more a language in which you would write, let’s say, an application server or some middleware or some cloud infrastructure, or things like that.

[09:13] It’s not something you would use for embedded, say, which you would use Rust for. So I think in the domain, both of them are probably the ones that are the leading ones that I would take most seriously.

09:26 — Rust vs Scala

Ryan:

[09:26] And then when you compare Rust or Go with Scala, what are the pros and cons of the different language designs? What’s something that Rust does better than Scala? Something Scala does better than Rust.

Martin:

[09:40] So Rust is closer to the metal, you have better performance guarantees. I guess the fact that Scala is a garbage-collected language means that you always have some pauses. I mean, garbage collectors have become quite, quite capable. I mean, they’re brilliant and the pauses are really very, very small. But it’s a fact that you do need a big chunk of memory to run fast, and I guess Rust could run in much smaller memory.

[10:08] So I believe that’s better for embedded systems and things like that. I believe right now Rust is actually overused because a lot of people push Rust for things higher up in the stack where your garbage collector is fine. But essentially, you still want to write code without, and that is for me a bit an exercise in, I don’t know, just intellectual that I can do it.

[10:37] I don’t really think there’s a big sense in it to write memory management for a garbage collector. You should absolutely use one because it makes a lot of things simpler. So yes, of course, if given enough brains, I can write code around it, and I can do that. But why should you? I mean, it can be much simpler. So that was for Rust, for Go. Go is sort of a language that lags behind. I mean, it was intentionally designed to be very, very small and essentially to be the standards of the ‘90s.

[11:15] So now they have gotten generics, which is a big step. So I believe that sort of is a step forward for that. But it’s still a fairly limited language. What you can do, which has an advantage that essentially it forces a very uniform style because there’s not much different things you can do. And there’s probably a culture fostered to do things in a certain way, which makes it easier to essentially read one another’s programs and essentially jump in a new code base and things like that.

[11:47] So I think that would be my main advantage of Go that I see there.

Ryan:

[11:51] Is it possible to turn off the garbage collector in Scala?

Martin:

[11:55] Not in production. So we have some research that would let you use essentially your own memory allocators and things like that, the way let’s say Zig does it. The problem with that is always that you can leak references into memory that you reclaim, and then all hell breaks loose. Essentially, your pointers, you point to memory that’s undefined. But in Scala we now have a very good way to actually track these references, so we can actually prevent that statically by the type system, that this will never happen, and you can still have your own allocator.

[12:36] That said, we haven’t really shipped that in production yet. So right now I would say you use the garbage collector. Scala.

12:42 — Rust vs Zig

Ryan:

[12:42] Yeah, I see a lot on the Internet, people comparing Rust and Zig, or kind of a fierce debate on which one is better. When you think about Rust versus Zig, what are the merits of the two compared to each other?

Martin:

[12:58] So what I can see is Zig has a really nifty compile-time construct, essentially inlining, where the compiler does smart inlining, and that is quite clean and quite powerful. And Rust has macros, but I think they’re more clunky than the Zig version. In Scala, we have something quite close to Zig. We also have essentially a thing that’s based on inlining and optimizations by the compiler. But we have a restriction, which I believe Zig doesn’t have, and that is that there cannot be additional type errors after inlining.

[13:41] So the thing is, you inline, and then the question is: Is the inline program guaranteed correct, so type-correct, or might you have type errors? The typical example where you might have type errors is C++ templates. In fact, that’s quite scary in C++ that you can expand a template, and then you get very, very complex type errors and very, very hard-to-debug things. So Zig, I believe, its inlining mechanism is much saner.

Ryan:

[14:10] When you say inlining, can you explain the concept?

Martin:

[14:13] Inlining just means that in Scala we can write `inline` in front of a function, and that means that the compiler will, before it starts code generating, during the time when it looks at the type code, which are trees, take the function body. When it sees a function call to that function, it will take the call and replace it by the body, and then it will do some optimizations. It can say, okay, so here we have essentially an application to, let’s say, a value which is a lambda, but I know where the lambda points to, so let me forward the call right to the function.

[14:54] And with that you can already do quite a bit of essentially optimizations, which are guaranteed because the inliner must inline. That’s not a thing. An optimizer has essentially discretion whether they want to inline things or not, and so you can never rely on that. But an inliner, which is essentially a compile-time based on the typer, must inline, so you can rely on it, and constexpr in Zig and C is essentially very similar.

Ryan:

[15:25] Okay, so it’s a way to get rid of the function call, or the overhead of a function call, and tell the compiler you can do more because it’s all, I guess, inline.

Martin:

[15:37] Yeah, you reveal the implementation, and that means the compiler can do something with that.

15:45 — Scala vs Python

Ryan:

[15:45] When you think about all the dynamically typed languages, which one stands out as one that you think is kind of the best among them?

Martin:

[15:53] Python is ubiquitous, and it has a nice syntax. A lot of Python programs look like they’re very easy to read, so that’s definitely an advantage. And the other one would probably be something like Scheme, which is sort of very grounded in computer science theory and lambda calculus and things like that. So both of them are sort of interesting in their own way. But of course Python is 100 times more popular.

Ryan:

[16:23] If you compare Scala to Python, for instance, I guess what are the trade-offs that the two languages take?

Martin:

[16:30] I think the gap is closing because Python now actually has an optional type syntax and a number of type checkers that check that syntax. And Python is getting some of the features that Scala had since the beginning, like pattern matching is in one of the recent Pythons. So I think actually the gap is closing not just between Python and Scala, but between a lot of programming languages in general. They’re sort of all drifting to a standard set of features, which mostly come from functional programming.

[17:01] Actually, pattern matching, for instance, strong type systems, generics, polymorphism, all these things came from closures, all these things came from functional programming. And so the gap is closing in that sense. Python is, I think the main advantage of Scala over Python is that it has a strong type system that is always on, and that gives you essentially guarantees that certain bad states can’t happen.

[17:34] So really you can rely on it. Whereas I think the Python type system, well, it’s just syntax. It has a number of type checkers, but in general you have fewer guarantees. And I believe it’s also the ecosystem and culture that doesn’t value types as much in Python. So I think that’s probably the main difference syntactically. The two languages, I think with Scala 3, are actually also quite close.

[17:59] So Scala 3 looks a lot like Python in that sense. You could say, well, you can see it as a language that has strong types and runs on different runtimes than Python. Or I should say the other thing with Python, which is really great, is that Python is a fantastic glue language because I can essentially have very, very efficient linkages to high-performance C libraries, pandas or NumPy or things like that.

18:31 — The programming languages that influenced him

Ryan:

[18:31] You mentioned that a lot of the programming languages, they’re kind of drifting or kind of being inspired by the other ones and adopting new features. In the design of Scala, is there a programming language that you admire most and influences Scala the most?

Martin:

[18:48] Historically, Scala was essentially, you could say it was a blend of Java, OCaml, and Standard ML, which is close, an ML-like language, and Haskell. So I’m by trade an imperative programmer. PhD is from Niklaus Wirth. I know Pascal, Modula. That was sort of my first generation of languages, and I like them a lot. And then I became sort of a converted functional programmer. So I looked very closely at ML, OCaml, Haskell, and these things.

[19:23] And then Scala came about. There was a predecessor language called Pizza, and I was working on that with Phil Wadler, who’s one of the original Haskell designers. And the idea was to have essentially an accessible functional language on a very widespread platform, which was the JVM at that point. And in order to prepare for that, I wrote a Java compiler. So that’s how I learned a lot about Java and what Java was.

[19:53] And in the end I had to say, well, it’s actually quite useful. I was quite dismissive at first, but afterward I found it actually quite useful. I mean, this was very early Java, this was Java, even pre-1.0. So now Java is, of course, even more useful, but also a lot bigger than what it was at the time. So when we came up with Scala, which was sort of the second iteration after Pizza, Pizza was the language I did with Phil Wadler.

[20:24] The ideas came mostly from Java, OCaml for the modules and the component model, and Haskell a lot for the standard libraries. So if you look at the function names in the Scala standard library, then there’s sort of a mixture of OCaml and Haskell, you could say, but you recognize a lot coming from both of these languages.

Ryan:

[20:48] If I recall correctly, Java had some sort of licensing with it, or it was owned by a company. How were you able to build on top of Java? Or did you have to pay for licenses, or how’d that ecosystem work?

Martin:

[21:05] The language standard was open source. There was a lot of experimentation with Java at the time. I think the only thing that Sun, that was the company at the time, they’re very particular about, is that if you did something that was using Java and had Java in it, you had to call it Java, and you couldn’t have a different name. So that’s why initially, for instance, Microsoft clashed with them, and then Microsoft went away and designed C#, which was sort of a.

[21:40] Java, some steroids. They threw in a bit more than what Java had. At the time, I think the nastiness came, Sun was actually quite an open company. So at the time, we were not worried about that. So that was in the time frame from 1998 to 2004, 2005, something like that. And at the time, there was no issue. I think the issue came later when Sun was acquired by Oracle and Google forked Scala on Android.

[22:11] Java on Android, and that’s when the fight started, but that was much later.

22:16 — How running on the JVM works

Ryan:

[22:16] So when you say that Scala was using the JVM or built on top of it, like concretely in the tech stack, what does it mean that Scala uses the JVM? Like, how does Java source code eventually execute on a machine?

Martin:

[22:32] So the JVM is essentially defined by its bytecode. The bytecode is essentially an intermediate format which you can translate your program into. And then the bytecode is run first by an interpreter and then essentially by an optimized compiler, just in time. Compiler JIT. So that’s called JIT. They do that. And so if you know how to output bytecode, and that’s not very hard, then you can run on the JVM.

[23:06] So that’s essentially the idea. The harder part then is interop, that you say, okay, I run on the JVM. I have to make sense of all these Java libraries out there. So I have to somehow map a Java concept into a Scala concept so that the compiler can understand what it is and I can document what it is for Scala programmers that maybe don’t understand much Java. So that is sort of work that sort of goes more into the details.

[23:35] That said, I mean, that’s not the only Scala platform, so it was born on the JVM, but now it also exists on JavaScript and Node.js, on WASM and on Scala Native. So it’s really a multi-platform language.

Ryan:

[25:05] Let’s say I write a Scala program. I have the source code, I have to compile it, and then I have some Java bytecode, and then I call the JVM and I pass in this bytecode, and it just works.

Martin:

[25:19] Yeah, exactly.

Ryan:

[25:21] What would the advantage be of compiling Scala to Java bytecode instead of doing something like C/C++ where you compile it all the way to machine code from source?

Martin:

[25:33] We have that too. So Scala Native compiles directly using LLVM to native code. The advantages of compiling to bytecode is essentially, again, the interop can use all the Java libraries, then the garbage collectors. So the JVM has actually very good garbage collectors, high-performance ones, and the runtime loading. So what I can do on the JVM is I can compile, let’s say, a one-line thing into a little Java bytecode, and I can immediately load that bytecode and execute that.

[26:13] And that makes it very easy, for instance, to have a REPL, because that’s how a REPL would work, a read-eval-print loop. So I would just generate a snippet of Scala code to bytecode, load it into the running JVM process, and it gets executed. And that’s much harder if you go to binaries; basically, binaries don’t really have a concept for that.

26:33 — Why writing a compiler is hard

Ryan:

[26:33] You mentioned that you wrote a compiler for Java before Scala, and I’ve heard that compilers are notoriously hard to build. Can you explain the hard parts and why they’re hard?

Martin:

[26:46] Compilers are very intricate because I think there are a lot of requirements on a compiler. So you have languages which are already complex artifacts. Then you have a thing called type inference, so you have a type system, but essentially you want the compiler to infer a lot of types that make sense. Because you as a programmer think, well, the compiler should know that, and it should, but actually for the compiler to do that is quite hard.

[27:21] And then, of course, you also demand that it would generate very efficient code for your program, because again, the compiler should know that, right? So there are a lot of demands on that. Plus, there’s a demand that it should be very, very fast. And to square all these demands requires quite a bit of work, basically. There are also things that make it easier for compilers because they’re fundamentally deterministic programs.

[27:47] So essentially, you run a compiler on a source, and you always get the same output, so it means they’re easier to debug. You can just replay things and repeat things. Whereas if I would have some cloud service or distributed application that has other nightmares, right? Every run is different, and how do you even figure out what goes wrong?

Ryan:

[28:07] So when you wrote that compiler, I think Espresso for Java, how long did it take to write that by hand?

Martin:

[28:16] At the time, it took me about three months, I think. Not full time, maybe half time. Three months, half time, something like that. But that was a very simple compiler. So that’s the other thing with compilers: they typically start simple, and when you’re at the 10-year mark or 20-year mark, then there’s lots and lots of essentially other requirements to a compiler that make them more complex.

Ryan:

[28:37] Were there libraries that you could rely on to kind of piece together components of it, or did you have to write everything from scratch?

Martin:

[28:47] There was a library to generate bytecode, I think. I think I used that in that version. Yeah, I did, yeah. So there was a library, essentially a high-level library, to just assemble bytecode and put them into the right format and things like that. But that was essentially it. The rest I wrote by hand.

Ryan:

[29:07] That’s crazy because, well, I mean, these days a lot of people, even more so now, we’re thinking less about using AI and more about kind of writing the code. So that’s pretty impressive.

29:19 — Why Twitter adopted Scala early on

[29:19] I saw one of the big, I guess, moments for Scala was that Twitter adopted it, and I wanted to know the story behind that. How did they choose such an obscure language at that time?

Martin:

[29:30] It was very obscure at the time, that’s true. So I believe the story was Twitter originally was written in Ruby, and it wasn’t very reliable because I believe it’s again a problem with garbage collector and memory management and things like that. And it was a small company at the time, so 25 people, including the ops people, and essentially the board and VC investors said you can’t go on like this, being unreliable like that.

[30:03] You should do Java, because Java was sort of the solid choice at the time. But some of the engineers at Twitter, they wanted essentially something more fancy as a programming language. And there are some people who knew OCaml and liked OCaml, but of course OCaml didn’t run on the JVM. And then they found Scala and said, well, Scala is actually quite a lot like OCaml and we can tell our investors that we do Java because it’s not a lie, we do JVM bytecode.

[30:33] And that’s essentially what it comes down to. So that’s why they picked it. And they were quite the first. But once they picked it, sort of the floodgates opened because at that time they were a very interesting company and a lot of people admired them. So a lot of people followed and did the same thing. Mostly they came from dynamic languages, so Twitter came from Ruby, others came from PHP or JavaScript, things like that.

31:00 — How he believes AI will impact programming languages

Ryan:

[31:00] I mentioned a little bit that AI is kind of generating a lot of code, and I wanted to ask you what you thought maybe the future of programming languages might look like if you speculated or drew it out further into the future. If AI is generating more of the code, how do you think that might affect the programming language ecosystem?

Martin:

[31:22] Yeah, I think right now we’re sort of in an existential crisis, right? So we have AI generating the code, but humans being asked impossible tasks, like to review all these mountains of code and things like that, which will never work. And at the same time, AI has also gotten extremely good at exploiting vulnerabilities in code, like we all heard of Fable and things like that, that you can’t use it anymore because it’s too dangerous. It will exploit things.

[31:53] So we are at a moment where it’s essentially very dangerous that we lose control as humans of what actually happens here. And that’s a challenge that I think programming languages can help meet. And probably definitely not only programming languages, that’s not a silver bullet, but they definitely can help things. So I think one of the things is that the focus, if the code is AI-generated, then the focus has to go elsewhere.

[32:26] And I think the focus will go to the interfaces and to the types. So I expect types will become a lot stronger and more precise than what we had. Because types are essentially the handle that we can make a contract between the human and the AI that the human can understand and that’s concise enough to be reviewed and that essentially the AI can keep to. We have to level our game quite a lot because right now, I mean, let’s face it, type systems are mostly recommendations. They’re mostly things that mostly hold, but not always. There are no guarantees because you can always have a cast or value, you use some dirty memory or.

[33:13] I mean there are a number of techniques to undermine the type systems, and we have to close all these holes from the beginning because once there is a hole, somebody can exploit it. So I think strong types, strong high-level types, will help. And then I think the other part is generally the programmer has to think much more about what the requirements are and what are essentially the high-level specifications and be able to leave the code to be generated by somebody else in confidence.

[33:50] And I think we’re not quite there yet, but we have some ideas about how we could get there. So one technique that I believe we can use, and it has been around for a long time, but maybe its time has come now, is capabilities. Capabilities essentially were used in operating systems to give very fine-grained permissions to entities, users, programs, and things like that. And I believe that can be used also for agents and agentic AI to say, well, once we have agents, we have to give agents very precise and fine-grained capabilities for what they can do, and that lets us essentially be confident about what they will not be able to do.

[34:34] They will not be able to leak my API keys or my email or do other things. So I think that’s an important part. And the existing languages are not there yet. I think Scala is halfway there. At least it’s there in essentially stuff we’re working on, which we have in the lab and we have released as an experimental feature. So I’m quite excited about that. The first thing that you have to do is definitely be memory safe.

[35:08] So a language that essentially is not memory safe, that lets you essentially access undefined memory, is immediately out because you can’t guarantee anything. So that’s. In that sense, it’s good that there is a drive to use, let’s say, Rust as a memory-safe language that was even promoted by the American government, I believe. So that’s definitely a very useful drive. But I think you need a lot more, because you need much.

[35:36] Rust talks essentially mostly or only about memory. You need to talk about a lot more things than memory. You need about essentially read permissions, write permissions, access to secrets, all these things that go beyond that. And you could say, okay, Martin, you’re totally unrealistic because all our software is written in C/C++ and we will not be able to rewrite that. But I believe AIs can help there, right?

[36:09] So AIs are great in rewriting software. So if we know what to rewrite, too, I think we might be able to get there.

Ryan:

[36:17] You mentioned some of those experimental features in Scala that might have some sort of safety guarantees or signal capabilities. Can you explain what that might look like, or maybe give an example?

Martin:

[36:30] So a simple example would be, let’s say somebody gives me a file and I have access to the file, let’s say a log file or something like that. I have access to a file for a limited time, and then I need to close it. So typically I have an operation that essentially somebody passes a file to me, to an operation that my program provides, and the program does something with a file, and then the environment will close it.

[36:59] But how do we make sure that I don’t hold on to the file after I gave it back to the environment, or after I pretended I’m finished with it? Because, hey, I have a file, I could have stored it in a variable, I could have stored it on the side, I could have gone back to it and done something with it. So capabilities help me prevent that because essentially I can say, okay, so this file is a capability.

[37:23] And then I can further say, well, this capability can be used only in a limited scope, and the type system will make sure that the capability doesn’t escape. And the way we do that is that if a type refers to capabilities. So if I have a thing that I say, I give you back a lambda or a stream and it holds onto the file. So the stream holds onto the file in secret. In our language, that won’t be a secret anymore because the type has to declare that the thing I return does hold on to the file.

[37:56] The file is a capability, and I can’t essentially hide capabilities I have access to in my type. I have to declare them. And that gives me essentially this control that then I can also enforce, to say, well, at this point you’re not allowed to have any capability because the type that I enforce you to have is a type that doesn’t hold capabilities. And that way I enforce with the type system something which previously hasn’t really been enforceable for memory safety.

[38:26] It’s essentially the same thing with arenas, that I have an area where I allocate memory and then I want to get rid of it. I have to make sure I don’t have pointers pointing into it. And that’s exactly the same situation, and let’s say for accessing secrets again. So it’s a very common pattern that I say in certain situations I want to make sure that you don’t have, or that you only have a set of defined capabilities that I give you, and nothing else.

Ryan:

[38:57] You mentioned memory safety is an absolute table stakes. What are the programming languages that you think of that are not memory safe? I know there’s C/C++, but what are the other ones?

Martin:

[39:08] The big ones are C. I don’t know about. I think Zig or Nim or other low-level systems languages are not memory safe. So that was sort of in Rust, the big achievement, that you can be a low-level systems language and be memory safe. Nobody sort of thought that was possible before Rust came. So that’s why I would think, I don’t want to say anything wrong, but I would think that essentially most other low-level systems languages would not be memory safe.

[39:40] But you really need more than memory safety. You really need capability safety, that you say, when I essentially hang on to something, I can’t sort of forget capabilities to say I hang on to something and I just conveniently forget that I have access to that. And I can’t forge capabilities to say, well, if I need a capability, I just make one up. These two things need to be prevented. And that goes beyond memory safety.

[40:07] But memory safety without memory safety, essentially you have nothing because you can fake everything.

Ryan:

[40:12] A lot of programming language design and how we write code in the past is writing the source code so that it’s nice for humans to read. But if humans are no longer interacting with the code, what kind of things come to mind that we might not care as much about but are good for machines to read?

Martin:

[40:34] For instance, the first thing is maybe sometimes you want to read it, but you probably wouldn’t have written it. So easy to write is definitely not a big criterion anymore. Easy to read to some degree, yes, but that means you don’t need any of these sort of syntactic hacks, like to write plus plus in C or things like that. That’s easy to write, right? But I don’t, I mean I’m sure we will still have that, but it doesn’t really matter anymore.

[41:03] I mean, whether I write an assignment in long form or with X, whatever. So I think these things won’t matter much less. The things that matter much more are, that continue to matter, and are essentially high-level ways to constrain and specify what my program should do. So constrain what it should not do, that’s one of the things. And also specify what it should do. And I mean some people say a golden age for formal verification because we can be very precise in our specifications, and our AI can actually not just furnish the program, but also the proof that the program actually meets the specification.

[41:48] And I think that’s true. That’s really very exciting in a lot of areas. But in the large, the problem is you often don’t really have the formal specification, or it’s just as hard to write a formal specification than to write a program, or sometimes even harder. So that means that we will still live in a world where we specify things by natural language, by prompt to the agent, and the agent then will do the code.

[42:16] But I imagine that also that will be a lot more formal in a way. So in a sense right now the prompts, I mean, it’s fantastic what they can do with the prompts, but then we throw away the prompt or it’s hidden in the chat history with the agent. So that’s really a shame. So I really should have the prompts as first-class values in my program, that I can say, well, essentially that’s what the program is about, and if I change the prompt, then the AI will know essentially what the incremental change was and change the program incrementally, these sort of things.

[42:51] That’s another thing that I think we’ll see in future programming languages for agentic programming.

Ryan:

[42:57] Maybe some kind of meta information about the program, almost like a Git blame, but like a prompt, I guess, blame of what generated that part of the code.

Martin:

[43:11] You should be able to keep that around and come back to it. Yeah. Also because you might want to change, right? You might want to say, well, now it’s exactly the same, but I want to change this little detail. But I don’t want the LLM nondeterministically to generate a new program because that way it might get a lot of other things wrong that I reviewed already. So there really should then be an incremental small change to the code, and that means I need to keep the prompt as a part of my program.

43:40 — Will there be less engineers in ten years

Ryan:

[43:40] Ten years from now, do you think there will be more software engineers than today or less?

Martin:

[43:46] I think there will be less. And it will be a higher profession that essentially has higher standards. So it will be harder to become one. You will need to know quite a lot of logic and math to be competent at essentially keeping AI on the right track and things like that. It’s sort of, I can say, sort of like a control engineer for a factory where you don’t understand many things initially. It means that there must be more—you must be higher skilled than a factory worker of 50 years ago or something like that.

[44:27] And I think the same will happen for software, where you will need fewer but more qualified people.

44:34 — Top programming languages to learn to grow

Ryan:

[44:34] One thing that a lot of people recommend is to become better at programming: you should learn multiple languages. And I wanted to know, aside from Scala, what are the top programming languages you would recommend people learn to expand their mind?

Martin:

[44:49] So definitely a systems language. I think to know how hardware works and how software links with hardware, I would learn a systems language. I’m sort of torn between C and Rust there because C has going for it that it’s very simple and very close to the metal. In Rust, you have to learn a lot of abstractions, but on the other hand, it is memory safe. So I would say probably initially C, to figure out what these things are.

[45:17] And then if you decide to become a systems programmer as a career, then you should switch to Rust. I guess that would be one thing. The other thing would be something more with a verification, improving background because that will be a lot more, will become a lot more important. So I would actually do a course in Lean or Rocq, one of these languages, to say we. We should be able to use AI or to.

[45:48] To have to develop first an intuition what it means for a program to be correct, because I guess for most people have only a very, very fuzzy intuition for these things. And learning one of these languages would sharpen the mind. Yeah, so I think those. And then, of course, Scala too as a language that essentially sits right in the middle where fairly provable, strong types, high expressivity, these sort of things.

46:18 — Top technical book recommendation

Ryan:

[46:18] When you think of a top technical book that you might recommend to people, does anything come to mind?

Martin:

[46:23] I got a lot out of Structure and Interpretation of Computer Programs. That was a book from the 90s. It was an intro text at MIT at the time, or 80s even, I think. And in fact, the courses I taught on Coursera and at EPFL are based quite a lot. Well, to some degree they’re based on that material. So, of course, not the same language and strong types instead of dynamically typed.

46:51 — Why he chose academia instead of industry

Ryan:

[46:51] But still, when you look back on your career, why did you choose to work in academia instead of industry?

Martin:

[46:57] When I came to the end of my studies, I was asked to do a research project, and the project I picked, or the professor then asked me to modulate that a little bit. In the end, I found it super interesting to say I work on something that I don’t know whether it has a solution or not. So it might be that. The question is yes, it might be. The question is no, we have to do research, and that’s sort of how it started.

[47:24] And then I believe the main advantage of being in academia is really the long term and being independent. So in the long term, I mean, in industry, I’m sure there are many periods, including now, where I could be paid 10 times what I’m being paid at university if I joined Google or any of the other companies in Silicon Valley. But then times also change, and sometimes essentially what you do is no longer relevant, and then it’s very easy to get fired. And then you say, no big deal, I can do something else.

[48:00] But at a university you have essentially long-term tenure to do exactly what you want. So no manager, you can define your own research agenda. Of course you have to get some money. That is hard. You have to get grants and things like that. You have to convince students that what you do is the right thing. But that’s also very rewarding, working with students. So I think in the end I’m very happy that I took the career I took.

48:28 — Reflecting on Scala

Ryan:

[48:28] What about looking back on Scala? You have so much experience there. What are some things that went well or things that didn’t go well, and maybe some learnings you could share?

Martin:

[48:39] Scala was initially this experiment that we could combine object-oriented and functional programming. And technically that experiment was a big success. In terms of the ecosystem, it had a lot of challenges. I don’t know whether there was A Brief, Incomplete, and Mostly Wrong History of Programming Languages by James Iry, which is quite hilarious. And there’s a Scala entry there that says I discovered Reese’s Peanut Butter Cups.

[49:07] And I had an idea to essentially have a language where you put in both object-oriented and functional, and then it ends with these pieces of both communities. And they promptly declared jihad. And at the beginning, it was very funny. But in retrospect, that’s to a large degree what happened. I mean, there were a lot of fights and cultural things like that, and it was a challenge. And I don’t know, in retrospect, I think it might have been more prudent to be more careful introducing functional features because that sort of was.

[49:51] We went in essentially quite complete. So essentially you can port most Haskell programs to Scala, maybe that you find them a bit less attractive looking, but you can do it. And that brought in essentially different cultures. And it caused a big clash of cultures. So, for instance, in Go, Go was a lot maligned because they didn’t even have generics. Right. And it’s true, it was a ridiculous language, but by not having it initially you sort of form a culture that when you add it, nothing much will go wrong.

[50:30] And people want to over-abstract or things like that. And by essentially going full hog into it with Scala from the start, we were not protected against that. And people did reach abstraction peaks and over-abstract it and things like that, and they still do it to this very day. So essentially having fancy abstractions is great, but you have to use them responsibly. And then it sort of clashes with the natural urge to just try out all these fancy things and do something that in the end maybe neither you nor nobody else understands very well.

[51:05] And it could have just been a simple map or things like that. But yeah, why do I use that when it can be complicated?

Ryan:

[51:13] Why would that upset someone?

Martin:

[51:15] Because of the library ecosystem. I think that the libraries are important because they sort of set the agenda, how you express your programs. And in particular the libraries that come from the Haskell side, they’re essentially monadic frameworks, and they require you to express your whole program as a monad, which is a concept that works well in functional programming. I have my reservations. I wouldn’t actually do that in my Scala programs.

[51:48] But by having prominent libraries out there, it’s quite normative that people feel like being a Scala programmer, they’re required to program this way. And then, of course, there are opinion leaders and conferences and all these things that tell you how you should be writing your programs. But I would say I think most of the Scala community is actually very, very level-headed, and I think most of the advice is great.

[52:18] But then, yeah, it’s still a challenge because it’s just too easy to. Mostly it’s not really the opinion leaders in the community, but let’s say it’s your boss. You have a small team in a company, your boss came from Haskell and says, “Hey, this is great. We do exactly like Haskell, the whole thing.” And then two years later the boss’s boss says, “No, nobody can understand this code. This code in the project is cancelled.”

[52:46] So these things happened in the industry. I’m not saying that all projects are like that, not at all. I mean, there are lots of really great success stories of Scala, but that’s essentially a challenge in terms of techniques. I think, in the end, I wish we had been a bit less dependent on the JVM in the sense that we took a lot from Java that intuitively makes sense but, in the end, and was very important for interop, but in the end could have been done better.

[53:25] So for instance, in Java, being an object-oriented language, you have universal methods like toString and equals and hashCode, and they’re defined for everything. And languages like Rust or Haskell, they’re no more discriminating. They have a thing called type classes where, essentially, at compile time, you tell exactly where you have equality and hashCode and these things, and it’s a bit more tedious to set these things up, but in the end it’s also safer.

[53:55] So I wish we had that, and we couldn’t because we sort of adapted Java‘s notion of what an object is, and it already came with all these things, which is sort of very convenient, but in the end caused friction.

Ryan:

[54:10] If I went back to you at that time, when you were starting it, and I said, what do you think is going to happen 20 years from now? What would you have said?

Martin:

[54:17] I would probably have said that while it was a footnote in memory, because, I mean, let’s face it, you do a thing and initially we had maybe five users or something like that outside our group, something like that. Right. And you don’t really expect that it would change a lot. And so no, I think it was quite by surprise that this actually happened. And I think the reason why it happened was that at the time Scala was a good bridge between dynamic languages that are slow and sometimes they crash.

[55:02] And solid languages, statically typed languages like Java, which were at the time quite cumbersome to write code in and there was a lot of ceremony and things like that. And Scala had inferred types, so you had types but you didn’t see them much. So it felt like a dynamic language, but it had also the solidity of essentially a good platform, and I think that’s what made it. And we’ve been copied a lot by a lot of other languages that put in these features then five or ten years later or things like that.

[55:33] But at the time, it was sort of Scala that was the first one that had it, and that’s sort of why it happened. But I wouldn’t have foreseen that by

55:42 — Advice for his younger self

Ryan:

[55:42] No means looking back on your career, when you just graduated college and kind of started your career, knowing what you know today, what advice would you give your younger self?

Martin:

[55:55] I think to take risks, be adventurous, pay it out. So essentially don’t follow the mainstream. If you take a fancy to do something wild and crazy technically, take the time to do it and do it. But I mean, yeah, so that’s what I would. Of course, you still need to sort of stay on track somewhat, but I don’t want to exaggerate that either. But yeah, so basically be a bit nonconformist.

Ryan:

[56:28] Awesome. Well, thank you so much for your time, Professor. I really appreciate it.

Martin:

[56:32] Thank you, Ryan.

He also had a lot to say about the Chinese robotics ecosystem. I asked him questions about that and about competitors such as “what if Anthropic and OpenAI started their own robotics labs?”

We went over a bunch of questions about predictions on future timelines. I asked him what a concrete roadmap might look like so we could get a sense of how deployment will happen.

Hope this episode is helpful in learning where we are today and where we will be when it comes to humanoid robotics.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:37 - Where are we today

04:20 - Most surprising capabilities so far

07:03 - The most inspiring real world robotics

08:36 - If OpenAI or Anthropic got into robotics

10:22 - Chinese robotics

13:15 - Will one lab breakout from the rest

16:59 - Thoughts on a concrete roadmap

21:03 - Generalization and demonstrating it

26:04 - Types of data and which is best for robotics

34:34 - Why humanoid robotics differs from Waymo

37:10 - If humanoid robotics failed here is why

39:55 - Are there hot take modeling architectures in robotics

42:05 - Thoughts on AI safety in robotics

46:44 - Top robotics research paper recommendation

49:35 - Why is Boston Dynamics less top of mind

53:47 - Advice for his younger self

Transcript

00:37 — Where are we today

Ryan:

[00:37] LLMs have caused unprecedented impact and investment in that area. Physical AI and humanoid robots could potentially be even bigger. And so I wanted to ask you today about where are we today with humanoid robotics, and how do you foresee this technology actually being deployed into the world?

Sergey:

[01:01] I guess with machine learning, what we’ve learned over the last few years, or the last decade rather, is that it works when you do it at scale. And this is very obvious now, but it wasn’t always obvious. But there’s a caveat, which is you have to scale the right thing. And initially when people started working on models for language, for example, the dominant design was LSTMs. Some people remember what those are.

[01:29] They were kind of okay; they were a lot better than what came before that, but they didn’t really scale as well. And then the big thing with transformers was not that transformers were somehow particularly mathematically elegant or anything like that. It’s just that they scaled better. So they were easier to train on very large amounts of data with lots of parameters. So the technology proceeds in phases.

[01:48] First you figure out what you can scale, basically what is the scalable technology. And then you pour on a lot more of kind of an industrial-scale effort and adding lots of data, adding to model size. And that’s when kind of the magic happens. So when we’re doing kind of more fundamental technology development, the key is to understand what are those scalable levers. So figure out the design, figure out roughly the mixtures, and that by itself does something pretty cool.

[02:14] But that’s not the thing that actually changes the world. It’s like when you start pulling that lever that things actually change. So with LLMs, when the first GPT models came out with GPT-2, it did some stuff, but it was sort of like a parlor trick, so you could get it to synthesize a story about unicorns in Peru or something. And it was coherent English, but it wasn’t a thing that would solve lots of real-world problems.

[02:39] But the folks that worked on this kind of recognized that, hey, there’s something kind of magical that happens because as you add more data and you make the model bigger, this stuff gets more coherent and more effective. So they could see that if we do a lot more of that, then it’ll become a lot more powerful. So to come back to your question, what I would say about robotics is that it’s not in the GPT-4 to GPT-5 stage, where it’s an industrial-scale effort to kind of make the model bigger and get more capability out of it.

[03:10] It’s in that stage where we’re establishing the fundamental technologies. And because of that, what one should expect to see right now is not necessarily that each month the model gets bigger and more powerful by some predictable kind of scaling curve. It’s that the scaling properties themselves are evolving as we develop the right technologies. So to bring this back to something closer to reality.

[03:36] I’m very happy with the demos that we’re doing here at Physical Intelligence. And I think that a lot of the results that other people are coming out with are really cool. But these are, to put them in context, we should not expect these to be the things that are actually illustrating the power of scale. We should expect them to be developing the fundamental technologies that will be scaled up after that.

[03:55] So where I think we’re at now is that we’re actually kind of getting all those puzzle pieces in place. And I think it’s actually very close. I think a lot of the puzzle pieces are falling in place, but it’s not like. What makes it so hard to prognosticate about where the technology is going to go is that it’s not yet at that predictable scaling stage. It’s at the stage where we’re figuring out the puzzle pieces, which I think is really exciting.

[04:15] But it means that it’s also very hard to foresee sort of what the coefficients on that will be.

04:20 — Most surprising capabilities so far

Ryan:

[04:20] What are the most astonishing emergent capabilities you’ve seen so far?

Sergey:

[04:25] That is the thing that is the most fun. And certainly we’ve seen a lot more of that happening as we progress. In the very beginning, it was kind of little things, but they were kind of magical because in robotics, basically prior to 2024, the stuff never happened. So the little things that happen, and this was maybe at this point about two years back, we would see things like, okay, we train our policy for folding laundry and it takes individual shirts out of the hamper and tries to fold them.

[04:55] And then one very vivid memory I have in late 2024 is we were watching one of the evals, and it takes out two shirts at the same time. And I’m watching this, I’m like, okay, it’s done for. There’s no way you can possibly do this. And then it puts the two shirts on the table, disentangles them, puts one of them back, and then starts folding the other one. It’s like, wow, okay. In retrospect, you can do some detective work and figure out where it got that from, some piece of training data.

[05:22] But that was one of those moments where I don’t think anybody watching that eval thought that the robot was going to do this. It’s like a little thing. It’s exhibiting the common sense you expect people to have. But actually, the thing that I find more interesting recently is some of the mistakes, because one of the things that’s pretty remarkable about LLMs is that once they got good enough, even the mistakes kind of made sense in the sense that they weren’t like crazy mistakes where just outputs, like, zzz all the time.

[05:50] But their mistakes are sort of semantically sensible. We had an evaluation last year for π0.5 where the robot was cleaning up a kitchen, and it’s told, like, put away all the utensils. There are some spoons, spatulas, et cetera. And it tries to open the drawer where it thinks the silverware goes, and it can’t really get the drawer open, so it slides over and opens the oven, which is right next to it, and then starts putting this stuff in the oven.

[06:16] It’s like, you can sort of imagine that if you ask a child to clean stuff up and put it away, they might decide to do that because, okay, it’s like a container, and you can put stuff there, and nobody sees it. Another experiment we had is washing all the plates. So it would pick up the plates, wash them with a sponge, and put them on the drying rack. And this was an experiment on memory, because it has to keep track of everything that it’s doing and has a scratch pad of memory where it’s writing down, hey, I had three plates.

[06:40] I cleaned the gray one, I cleaned the green one. And then it drops one of them on the floor and drives the base over so you can’t see. And I was like, okay, I’ve cleaned the gray plate. It’s done. So, I mean, obviously these are not the things that we want to see. But it’s kind of interesting that some of the mistakes, they’re almost like what you would associate with a child trying to do the task.

[07:00] So now it just needs to grow up.

07:03 — The most inspiring real world robotics

Ryan:

[07:03] You mentioned the advancements. They’re kind of happening all over the industry. And I know there are a lot of people building humanoid robots. There’s Figure AI, there’s Tesla, and there’s many other competitors, and you have the expertise of what is hard and what isn’t. When you look at the competitors, has there been any advancement or achievement where you think, oh, that’s really admirable and that’s impressive?

Sergey:

[07:29] I actually think that one of the most inspiring things to me in the industry is to see the kind of takeoff that autonomous driving systems have had. Because one of the criticisms that is sometimes leveled against robotics researchers is, it’s like nuclear fusion. It’s the technology of the future, but it’s always in the future. But that’s what people said about autonomous driving, too. And now we’re in San Francisco.

[07:53] You can go outside and you can take a Waymo, and it will actually take you to your destination. And there was no driver sitting there. So, without getting too much into the technical details, I think what’s really inspiring about that is just this case in point that, yes, you can actually have one of these technologies of the future, and it actually does land. And I think it’s not an accident that it’s landing now in the mid-2020s, because a lot of the puzzle pieces for large-scale ML are getting to the level where we can put them together with actual physical systems.

[08:24] And there’s a lot of differences between driving and robotic manipulation, of course. But I think that the illustration that, yeah, we can actually land learning-based technologies in the real physical world, I think that’s really inspiring.

08:36 — If OpenAI or Anthropic got into robotics

Ryan:

[08:36] If OpenAI or Anthropic started investing more heavily into robotics, how do you think that would impact the industry? Do you think competitors would be worried about that?

Sergey:

[08:49] Robotics is an area where, to be fair, the ecosystem hasn’t been as healthy as it has in other areas of machine learning. And what I mean by that is that computer vision and NLP are things that sort of lend themselves naturally to a machine-learning-based ecosystem, because there’s freely available data. People kind of have a general acceptance that they’re going to be using learning. There aren’t concerns as severe concerns about safety, at least physical safety.

[09:20] Right. You know, people rightfully are concerned about AI safety, but it’s not the same as like a physical device causing some physical harm. And because of that, I think it’s a bit easier to spin up a very serious large-scale ML effort in those areas. Robotics is not like that. Robotics traditionally is not a discipline that really embraces sharing of data, for example. So I think that the more activity there is around learning and robotics, the more I think it’ll shift people’s thinking toward this kind of future where we accept that robots will be controlled by learned models, not by hand-designed controllers, that there will be data, that data will need to be shared because there’s no way that somebody can build out a true foundation model in a single vertical and basically kind of shift the entire thinking around robotics to look more like how we think about vision and NLP as opposed to traditional factory automation.

[10:12] So I think in that sense, much as I’m proud of the work that we’re doing at Physical Intelligence, I think it’ll take more than one company to kind of shift everyone’s thinking in that direction.

10:22 — Chinese robotics

Ryan:

[10:22] As a bystander, I see on Twitter these really impressive demonstrations of Chinese robotics. It almost feels like they’re ahead in some sense, but I don’t have that deep domain expertise. So I was curious about your thoughts on what you think of China’s robotics, and are they further along?

Sergey:

[10:45] I think that one thing that is very useful and constructive for us to do, those of us that work on these things in the United States and in Europe, is to ask what is the lesson to learn. And to me, one lesson is that it’s important to have a healthy ecosystem. And ecosystem means that there should be obviously good researchers, good engineers working on these things. There should be healthy open source.

[11:18] But it also means that the different industries that contribute to robotics need to individually be very healthy. And those industries are not just the computer science, ML, and model building stuff. It’s also supply chains, manufacturing hardware, R&D, these are all very important things. And aspects of those things are things that the United States does quite well. Other aspects of them are things where the United States has sort of let things go a little bit.

[11:52] And I think that what we should do is we should look at what’s going on in the world, look at some of the excellent results that Chinese labs are doing, that labs in other countries are doing, and we should take away that lesson that we should strive to build a healthier ecosystem. And that means investing in all the different facets that contribute to this. So I’m not much of a business person, I’m not much of an investment person, so I can’t claim to know how to do this, but I think that it’s important to sort of fully embrace that this is a holistic thing and not something where we can do just one piece of it and outsource everything else.

[12:25] Basically.

Ryan:

[12:27] Of all the pieces of the ecosystem, are there parts of it? As a robotics researcher in the US, if it was better, that would have the biggest impact on the advancement of robotics.

Sergey:

[12:39] Yeah, I think certainly availability of reliable, low-cost hardware is a big deal. And right now, I mean, certainly for hardware used for robotics research, a lot of that does come from China. And it’s good, it’s relatively inexpensive, it’s of high quality, and meets the standards that people generally need. But it would be awfully nice to be able to source all that domestically as well. And I don’t think there’s anything impossible about that.

[13:07] I think it’s just a matter of embracing the fact that that entire ecosystem needs to be supported rather than just one piece of it.

13:15 — Will one lab breakout from the rest

Ryan:

[13:15] You can imagine that the lab that is first to get to scale will be the first to break out. There may be this exponential growth effect where once you deploy, deployment helps you grow faster, and growing faster helps you deploy, and this flywheel. And so do you believe that that will happen in this industry, where one lab, whether in the US or China, will hit some breakout point and they’ll kind of jump everyone else?

Sergey:

[13:47] There is a lot of truth to that. I think that there’s an important detail to keep in mind. The detail is that you kind of have to scale the right thing. So I think that basically the statement that the way that I would phrase this is having an effective positive feedback loop where more deployed robots translates to more model capability. That’s kind of the key, and that makes total sense. The trick is that there are lots of ways that it can be done wrong.

[14:23] So I’ll tell you a few obvious ones. One obvious one is let’s say that I’m a car company and I have a robotic arm that is welding cars, and it’s there on the assembly line, and it welds cars every day, and it gets a million welds every month, and so on. If I just use that as my data flywheel, I’m unlikely to get something more capable than a robot that welds cars. So since the robot is already there and it’s already welding cars, presumably the marginal improvement for that is not all.

[14:54] That valuable. So that’s an example of how you kind of have to scale the right thing, because data is not quite as fungible. It’s not like electricity or oil. You can’t just buy more of it. It has to be heterogeneous. So I think that basically it’s right, but you have to scale the right thing with the right technology and the right kind of source of diverse learning, like data is more like an education program for your robot than it is a fungible commodity.

Ryan:

[15:19] If you think about that data flywheel and, I guess, putting out the proper platform that would generate data that matters, that would then improve that platform, when do you foresee this kind of happening in the world?

Sergey:

[15:34] I think, on the technology side, things are advancing very rapidly toward that. And I think that maybe a particular balancing act to strike that would significantly determine that timeline is how much structure somebody’s willing to admit. So on the one extreme, you could imagine jumping straight to fully unstructured deployment domains like home robots. And that could be really exciting because then you have a lot of diversity right off the bat, but the bar is a lot higher to be effective enough in that domain to be safe enough.

[16:04] Safety is a much bigger issue there because it’s around people in their home. On the other extreme, you could imagine much more structured tasks, maybe not quite the welding robot, but sort of like maybe the robot down the hall that does something more unstructured. And that could be a much easier domain in the sense that there’s much less safety concerns because it might be around trained humans, the task might be more predictable, and so on, but the marginal value of each bit of data you get in that domain is lower because there’s less variety.

[16:36] So it’s like you could take off earlier, but with a smaller slope, or later, but with a larger slope. And you kind of have to calibrate that. But my sense is that whichever end of that extreme we’re talking about, it’s in the single-digit years rather than the double-digit years at this point. So it could be that the more structured ones might be happening now or next year. The less structured ones might be a few more years out, but probably not like a decade.

16:59 — Thoughts on a concrete roadmap

Ryan:

[16:59] A lot of people talk about timelines, and it’s kind of more nebulous. And I’m wondering if you were to put down, I guess, somewhat of a roadmap, but not so concrete, but just milestones toward that north star of a robot in my home doing.

Sergey:

[17:16] Yeah, that’s a really good question. So maybe to preface this answer, I think that there’s one thing that is very important to say about robotics that is very easy to miss from the hype cycle and the demos that people put out, which is that the hard thing in robotics was always generalization. But when somebody shows a demonstration of their system, the demonstration alone usually doesn’t make it clear what level of generalization is being shown.

[17:48] The highly acrobatic robot demos, for example, are really exciting to look at. But typically, if it’s something that is a little bit more staged, sometimes literally on stage, if it’s a show that is obviously rehearsed, and that’s okay, because it’s literally just a show, but it’s not the same as doing a task every time reliably in any home. And the generalization piece often doesn’t look that impressive when viewed in isolation, because generalization is sort of a property of many trials, not of one trial.

[18:20] So you might see the robot doing something fairly mundane and unimpressive. But what’s exciting about it is that it’s doing it with an object that it’s never seen before in an environment that has never been tested before. And that is actually harder than doing an acrobatic backflip that it’s practiced millions of times. So with that said, my answer to your question is that the roadmap is all about both achieving better generalization and kind of that second-order effect of having a mechanism to get more generalization as you generalize.

[18:53] So one of the steps on that roadmap is to have a very concrete demonstration of a robotic system that gets better with autonomous experience that is collected in a setting that it wasn’t originally trained for. So I do whatever I do in the backend in the lab and whatever. I get my model, I get my adaptation algorithm, I put it in a new setting. Maybe it’s a home, maybe it’s a factory, whatever it is, something where it’s doing something real, and it does okay.

[19:24] But then over time, it gets better and better. And it gets better and better to the point where it reaches sort of practically relevant levels of robustness without sort of capping out at like 50%. I think that would be a major milestone, because now that says, okay, if this is truly an automated process, it’s improving, it’s getting better, even as it’s collecting useful experience. Now, I can take it and I can put it in lots of different domains, collect useful experience, do something that people actually want, and it’ll improve the model.

[19:51] So that, I think, is a really major step on that road. I think another really major step is to demonstrate a very concrete and practically useful way to transfer knowledge, to transfer common sense, to achieve robustness. So that’s like kind of the other scenario we don’t get to practice. If you’re driving your car on the road and you see a fire truck and you see a bunch of traffic cones, even if you’ve never been in that situation before, your common sense tells you, like, hey, I should slow down.

[20:20] Maybe I don’t know how to react optimally, but I shouldn’t just barrel on through the cones and upset the firefighters and so on. So that’s common sense. And if you can apply that common sense to effectively recover from unexpected situations, like when the robot put the spatula in the oven, it should probably open it up, take it out. It knows that this is not the thing you do semantically.

[20:40] That, I think, is another important step because that tells us that we can use common sense to fix mistakes.

Ryan:

[20:46] I could imagine a more narrowly scoped robot. Let’s say it’s a humanoid robot. That’s one step in assembly line, in manufacturing. And my understanding, you’re less interested in that because that’s not really a step toward that general intelligence.

21:03 — Generalization and demonstrating it

Sergey:

[21:03] What I would say, it’s not that I’m less interested in it, it’s that I think that the real world has these leaky abstractions that make that kind of stuff a lot more complex than it seems. Let me try to explain this with an analogy. So in the ‘90s, when people really started working kind of full steam autonomous driving, there was this idea that we could avoid a lot of the hard problems by kind of instrumenting the environment a little bit.

[21:31] Like, we’ll have magnetic sensors along the highway and so on, and cars will have a little sensor on them and a little transmitter so they can tell where each of the cars are. Kind of like the way you do it with aircraft, basically. And then people thought, well, we don’t really need fancy AI. We’ll just have these sensors and it’ll just work. And that just basically didn’t go anywhere because the real world has so many messy exceptions and special cases that even if 99% of the time, the magnetic sensors and all that stuff just allow the car to drive the 1%, when someone steps in the middle of the road or there’s a piece of trash or whatever, it just messes everything.

[22:05] Up. So the thing that actually worked was when Waymo said, hey, we’re going to not try to avoid the hard problem. We’re going to actually try to deploy our cars not in the middle of nowhere, but in San Francisco, very messy, and let’s just deal with it head-on. And that allowed that community to make progress. And I think robotic manipulation is going to be the same way, that past the fully structured world of the factory, if you want to go even a little bit outside of that, even if 99% of the time it’s all pretty straightforward, that 1% when something weird happens means that you really need the full scope of the problem basically to be addressed.

Ryan:

[22:41] This kind of reminds me, I remember Figure AI had this demo where they live-streamed the robot sorting packages. When you watch that demo, does it demonstrate generalization in your opinion?

Sergey:

[22:54] Yeah, I think it does. And by the way, this is something that I find very encouraging is that, like I mentioned, it’s hard to show generalization in a video, and it’s clear that lots of people are thinking about that and are thinking about how do you present something that somebody can watch and take in kind of at a glance what generalization is. I think you can see a lot of creative steps towards that.

[23:16] Live demos, these kind of really long time lapses. I think it’s a great idea, and I think that’s a really nice way to move towards elevating the importance of generalization in people’s consciousness. When we were working on the π*0.6 project, the RL project that we did late last year, we wanted to do some longer horizon experiments. In some cases it’s obvious. We had our robot assembling boxes at Dandelion Chocolate Factory.

[23:46] So they’re like, it’s an actual chocolate factory, so they need the boxes. So we ran it for several days. But we had this coffee task, which was the robot using an espresso machine to make espresso. So what we did is we ran it for 13 hours making espresso drinks. And we are, we try to be very, I guess, environmentally conscious about this. So we didn’t want to throw out the coffee.

[24:05] So after 13 hours, everyone in the office was a little wiry because someone has to drink the coffee. But it ran for 13 hours, and it was pretty cool. It screwed up a few times. It’ll spill all the coffee grounds, and then it needs to go and get a cloth and wipe it down, but it does it and nothing exploded. Thirteen hours went by. Probably the most negative consequence was loss of sleep from too much caffeination.

Ryan:

[24:29] But when it spills the coffee grounds and cleans it up, it did that by itself.

Sergey:

[24:34] Well, so the way that that experiment was done is that there is a high-level prompting. So roughly the prompt is updated maybe every five minutes or so in between semantically coherent tasks. So you tell it, like, make espresso, clean up the machine, et cetera. So those steps, the actual clean up the machine, was commanded by a person. In principle, we could automate that. In fact, one of the things we’re spending a lot of effort now on is improving our high-level policy that does those commands.

[24:59] But for that experiment, every five minutes, somebody basically updates what it’s being asked to do, the way we intended. It was like the commands would be like, if you go to an actual coffee shop, you say, “Oh, I want a latte, I want an espresso.” That was supposed to be the prompt. Except then you also have to tell it, “I want you to clean it up before you do the next one.”

26:04 — Types of data and which is best for robotics

Ryan:

[26:04] It sounds like on the way to generalizing data is a very important part of that.

[26:10] And I was reading there are different types of data. There’s simulated data you could collect, like physical interactive data. And I want to hear your take on what’s the best data to get, what’s the worst, and what are the pros and cons.

Sergey:

[26:25] This is, by the way, a question that is, I guess, quite. There’s a lot of discussion in the robotics community about this question. And some people have very opposite opinions on it. My own take on this is that a lot of different data sources are easier for the model to internalize if it can ground them in a thorough physical understanding of the world. So let me try to explain what I mean with a few examples.

[26:53] If you want to learn to fly an airplane, you will probably use a simulator, at least during part of your training. But the simulator makes a lot of sense to you, because when you start using the simulator, you have a lot of world knowledge that you can use to ground what’s going on. You know that when you are using the flight simulator to learn how to fly the airplane, you’re not just playing a video game.

[27:15] You’re trying to acquire knowledge that you will then use with a real airplane. And you understand that there’s sort of an abstraction there. Same thing if you’re playing a really cartoony Atari game or something. You know that all the symbols on the screen, you can sort of connect them to things that you’ve experienced in your life, and you can make an analogy there. So a lot of that, even though it kind of seems like these simulated environments reflect aspects of the real world, to us, they make a lot of sense because we kind of bring to bear a lot of our own prior experience, and we fill in the blanks that the simulation has.

[27:52] And also, if you want to use data yourself as a person of somebody else doing something, if you watch someone, let’s say, cooking a meal, even though you don’t experience every movement they’re experiencing, you have a lot of that knowledge that you bring to bear. And you’re like, okay, I see they’re picking up the salt shaker. I’ve put salt on things before, so I kind of roughly know what’s going on there.

[28:13] And I can file it away at this level of abstraction of add salt without having to figure out all their muscle movements. So my point with this is that once you have that understanding of how you do things physically with your own body and how you experience the physical world now, all these other sources of knowledge can be connected up to it, because that foundation you get from your experience helps you ground everything.

[28:34] So where I’m going with this is that if we have a robotic foundation model that is trained on lots of real embodied data, that provides that grounding, and it might actually be much better able to absorb other sources of knowledge. And this is actually a little bit upside down relative to how some people think about it, because it’s very tempting looking at the success of Internet data for LLMs to say, well, maybe we should do the opposite.

[28:56] Maybe we should start with YouTube videos and then put robot data on top of that. But I think it’s actually the other way around, and I even have a little bit of evidence for this. So my colleague Suraj Nair, together with Simar from Georgia Tech, they had a project together a while back where they took our robot foundation model and they added human video data. But they didn’t start with human video data.

[29:22] They actually started with a model trained on robot data and then added video data on top of it. And what they did is they looked at the representations inside the model. Basically, how does the model represent human experience versus robot experience? And they found that if you use a small model with a small amount of robot data, predictably the human experience and the robot experience are fully separated, meaning that the feature representations are different.

[29:42] But if you train on lots of robot data from lots of different robots, then the features are grouped much more by what task is being done rather than by whether it’s a human or a robot. And when we looked at the feature plots, it was just mind-boggling because literally when you crank up the amount of robot data to 100%, they just line up perfectly. You do this t-SNE embedding, you see the shapes of the embeddings, and it’s just all task identity and minimal sensitivity to embodiment.

[30:10] And to me, that’s kind of mind-blowing because the base model wasn’t trained on any human data at all. But once you start adding human data, it represents it exactly the same way. And I think that’s really exciting. And I think that to me is one of the strongest indicators that if you have that good foundation of robot experience, you can put everything else on top of it. It’s actually better at absorbing that.

Ryan:

[30:29] Is it important that that base model has data that was collected using that specific set of motors, specific set of joints?

Sergey:

[30:39] So far we’ve obviously put a lot of effort into cross-embodiment models that can handle many different robot types. But generally, you do need data of the robot you’re going to be deploying on to get good performance. So kind of the metric of generalization there is not can you zero-shot a new robot, but it’s mostly can you get away with less experience from the new robot and transfer skills from other robots?

[31:02] Okay, so that’s the current state of things. Now there is a little bit of a surprisingly positive read on that, which is even though you need data from these robots, the amount of special stuff that the model is doing is kind of minimal. When we started doing all this, I had a big long list of all the cool research I wanted to do to better accommodate different morphologies. Can you factorize the model’s representation in some way so that there’s a six degree freedom arm head and a seven degree head and a gripper head, et cetera?

[31:32] We didn’t do any of that. The model just outputs a big vector of numbers. If the robot has fewer degrees of freedom than the number it outputs, it just zero-pads it. There’s just nothing fancy, and that’s it. And then it just trains on all the robots and outputs the correct actions based on what is seen through the camera. But now, to your point about whether you can handle new robots.

[31:55] So far, the thing that we focused on, and I think this is showing some promise, is being able to transfer skills between robots. And this is actually where the particular choices in how the model works seem to matter. For example, you can have a model that does some intermediate thinking, and that thinking can be done in different modalities. So you can think in text, and thinking in text is really good for transferring high-level behavioral structure.

[32:27] So that’s basically how you understand that, hey, if I want to clean the kitchen and put away the silverware, first open the drawer. That’s kind of a semantic inference. And you can transfer that very well because obviously that’s largely agnostic to any embodiment or anything like that. But even lower level things can be transferred if you use the right representation. So one experiment we did is we had a thinking stage that is expressed in images, where you basically dream up an image of the next milestone in the task.

[32:55] And with that, we can actually get a robot, the UR5 robot, to fold a T-shirt, even though we didn’t have any T-shirt folding data on the UR5. Because while getting the arm motions correct is very hard, because the robot basically requires very different joint angles to do the task, cooking up an image of what it looks like for it to fold a shirt is not that hard because you’ve seen the robot arm in all sorts of different poses, you’ve seen the shirt in all different stages of being folded and unfolded, roughly where it should hold it.

[33:21] So getting a good generative model to cook up that image is pretty straightforward. And once you have the image, then, from that backing out the correct actions is easy too, because you can just look at the synthesized arm angle and just back out what the angle should be. So it’s not changing the problem, but it’s just introducing this intermediate step that makes it easier to solve. Just like if you’re solving a math problem, if you figure out the right intermediate step, kind of the answer is obvious from that intermediate step.

[33:47] And I think that’s really exciting because now that shows that this level of generalization across robots, and I’m sure other generalization too, can be facilitated with thinking, just like in large language models, but with a twist that you have to think in the right modality.

Ryan:

[34:00] Interesting. So it outputs a, I guess that image is what its video sensor is seeing, and it’s like the next step.

Sergey:

[34:09] Yeah, you can almost think of it like image editing. You can do the same thing with video. You can do it with video prediction. But the key is to imagine what it would look like to progress on this task. That seems like a very human thing to do.

[34:22] Some things you plan semantically and some things you plan spatially. If you’re doing rock climbing, you’re probably not thinking like, “Hey, left arm to rock, 37 centimeters to the left.” You’re probably more imagining your arm reaching for the rock.

34:34 — Why humanoid robotics differs from Waymo

Ryan:

[34:34] Earlier in the conversation, you mentioned that Waymo was very inspiring, and their kind of path to productionization is proof that you can do real-world generalized robotics. And if I recall correctly, when I was a lot younger, it was kind of this early promise of, “This is going to happen,” and then in reality, it took a lot longer. So I guess my question is, in the case of humanoid robotics, what would make you say single-digit years, it’s coming, versus a long tail and policy challenges as well?

Sergey:

[35:17] I think one big difference between how robotic foundation models address the problem and how more traditional engineered systems address the problem is that the stack is really thin. So it’s not easy to train a foundation model. Obviously you need to get the right data. There’s a lot of work that goes into curating, labeling, all that other kind of stuff. But the actual software that runs on the robot is very, very simple.

[35:42] So you might have some kind of thinking or reasoning stage. You might have the model produce actions; it needs to be fast enough. But if you think about it in terms of raw lines of code, it’s much, much lower than a more traditional AV stack. And partly that’s because modern autonomous vehicles, the work on that started a lot earlier with very different technologies and evolved over time. Partly it’s also because the problem is more safety-critical.

[36:13] Like, yes, you don’t want a robotic manipulator to drop a fragile object, but at the end of the day, that’s a lot less bad than having a car hit somebody. So that is not to say that the safety challenges with robots are not real. They’re very real and it’s very important to tackle them. In fact, it’s probably one of the harder ends of the problem. But they are not as much of a hard stop to practical deployments because you can come up with tasks and environments and domains and also physical hardware where those problems are a lot less severe.

[36:47] So I think that combination, radically simpler software stack, plus less drastic software challenges, actually make it a lot easier. And because, to your earlier point, there is this kind of flywheel effect, that there is a positive feedback loop, that starting to get things out in the world, even under some constraints, will actually facilitate getting them out more and more.

37:10 — If humanoid robotics failed here is why

Ryan:

[37:10] I think a lot of people are familiar with this idea of postmortem, looking back on why something failed. But in this case, I’m curious, what would you say to a pre-mortem in the sense of if humanoid robotics did not succeed in single-digit years, what do you think would be the most likely reason why humanoid robotics failed?

Sergey:

[37:34] Ultimately, for these things to be truly useful, they do need to reach a level of reliability and robustness and generalization that is higher than what we typically expect from LLMs, for example, or generative AI for images and video. Because typically these tools, they are very much human-interactive tools. You get an LLM to do something, and it doesn’t do quite what you want, so you sort of revise your prompt, and you basically iterate with it.

[38:01] And that’s why even the earlier LLM tools, like the first version of ChatGPT, even though they were much more primitive than what we have now, they were still already useful because somebody could just keep hammering at it until it basically solves their problem. Just like if you’re using a search engine, you type something in the search engine, you don’t get quite what you want, you revise your query and then you get what you want.

[38:20] Whereas with a robot, the full value of it is unlocked when it’s actually doing the thing autonomously. So to have somebody constantly iterate for every single task is almost antithetical to the benefit that you’re getting. So I think a lot of the risk has to do with how easy is it to get that level of reliability and robustness. And that’s again where some of the demos might be a little bit misleading, because if someone shows a demo of their robot doing something cool, I mean, obviously if everything is presented in a forthright way, that could still be a very good indicator of progress.

[38:52] But it doesn’t make it obvious how far or how close it is to reaching that practically relevant level of robustness. So I’m personally a big believer in using techniques like reinforcement learning that can actually benefit from autonomous experience to kind of fine-tune those last few percentage points to make it go from 95 to actually 100%. But that’s really important, and it’s not yet a solved problem.

Ryan:

[39:18] If it did take longer than expected, it’s because the bar is higher.

Sergey:

[39:23] Because the bar is higher. And in particular, those last few, kind of the last inch, so to speak, is something that requires not just really good models, but also new innovations in technology. I mean, I don’t think that I’m not the kind of person that would say, oh, we should throw out everything that we know about foundation models to start over. I don’t think it’s that at all. I think that roughly the puzzle pieces that we have are actually very good puzzle pieces.

[39:46] But still, we should acknowledge that right now, the methods and the models need more work to cross that level of robustness.

39:55 — Are there hot take modeling architectures in robotics

Ryan:

[39:55] In LLMs, it feels like everyone is doing kind of the same thing, but different flavors in the robotics industry. Is everyone doing kind of the same thing? Are there any hot take architectures that are different direction?

Sergey:

[40:09] I actually think that there’s a lot more heterogeneity than it might seem. One big dividing line that I think is maybe not as obvious from just looking at the results is the distinction between fully embracing the foundation model ethos, so to speak, versus focusing on specific vertical areas. And I think this is hard to tease out sometimes because obviously everyone’s going to say, “Oh, I’m doing the thing that LLMs did,” because that’s the cool thing.

[40:40] But the foundation model ethos fundamentally is something like this: if you have a particular problem you want to solve, it is better to train a more general model that can use data from a breadth of problems. And if you do it right, it’ll actually be better at the specialized problem you want to solve than a narrow specialist. So again, to come back to the LLM analogy, if you want to do machine translation, don’t build a machine translation system.

[41:05] Build a language model that understands all language tasks and throw it at machine translation. And in robotics, I think that is actually very deeply uncomfortable to people. Because if someone is actually working on an application, they’re doing warehouse automation. It is very awkward to think, oh, if I want to do warehouse automation, let me collect data of putting away silverware in kitchens.

[41:27] It just sounds bizarre. But that is the foundation model lesson: if you have enough breadth, if you collect data from a wide range of different tasks, then you will acquire those generalizable skills. And if your model is built correctly, it will repurpose those skills for whatever situation it encounters. So I think it is actually true that even if you want to build a warehousing robot, you are better off collecting a breadth of data and will be better at handling all the weird edge cases you might encounter, even in that warehouse domain.

[41:55] But this is not something that’s easy for people to accept because it’s just so antithetical to the principle of building kind of a traditional, vertically integrated robotic system.

42:05 — Thoughts on AI safety in robotics

Ryan:

[42:05] I noticed this new, interesting phenomenon with these AI companies, which is if they’re wildly successful, it creates this, I guess, worry or new set of things. So, for instance, when Anthropic had a very powerful model, then the government comes in and there’s these worries about safety and risk and all that. And I’m curious how you think about that. Like, if Physical Intelligence this year had a phenomenal, incredibly capable, generalized model, how do you think about those kinds of topics that might come up?

Sergey:

[42:48] Working on AI safety is not a new thing. My colleague at UC Berkeley, Stuart Russell, was talking about this stuff over a decade ago, and lots of people spent a lot of time working on it. It’s just that the trouble is when the technology moves so fast, the important problems are not just a function of the core principles. It’s also a function of how society reacts to it, what kind of tools are adopted, and so on.

[43:11] And I think that’s very, very hard to anticipate. So I don’t have a very satisfying answer here. In terms of how we are approaching it, our philosophy around all this stuff is basically one of empirical experimentation. Let’s get stuff out there. Let’s see what happens in the real world. Let’s see what goes right and what goes wrong, so that we have as much of a preview for what the technology can do, what are its weaknesses, what are its strengths, and so on.

[43:42] But at the end of the day, you kind of have to just keep your eyes open, see what happens, and adjust as you go. It’s very hard to anticipate. And I think your question, though, is very spot on. Even though I don’t have a great answer for you because, yeah, if we’re having this much concern and issues with AI systems that are basically limited to using computers, we’re presumably going to have strictly more concerns and issues with AI systems that can do everything in the physical world that we can do.

[44:14] Right. So the issues are real. It’s just you kind of have to see what happens and then adjust.

Ryan:

[44:19] And that’s kind of in the scary path, but in the happy path. If everything goes well and we have incredibly capable models and robots, in 10 years, is the North Star, that’s the end of human labor.

Sergey:

[44:37] I believe it’s a mistake to think of robots as mechanical people. Computers at some level are kind of like mechanical brains. But when personal computers really took off in the ‘90s, early 2000s, et cetera, it’s not like the first thing that happened is that people replaced their brains with computers. Rather, what we saw is actually a proliferation of very different kinds of computers. We saw kind of ubiquitous computing.

[45:03] So you would have a computer on your desk, but you might also have one in your pocket. You might have one in your refrigerator and in your car. Because computing became so accessible, you could have a little bit of computing in everything. And I don’t think that’s what the people that first started thinking about this stuff in the 40s and 50s would have imagined. They would have imagined room-sized computers whose job is to control the policy of an entire country or something, rather than a little bit of computer in everybody’s refrigerator.

[45:32] So I think by analogy, we might imagine there might be a little bit of Physical AI in everything, and it might just be lots of everyday things that you have to do yourself. Now you can get a little bit of help with it. I think the other example that’s worth thinking about is modern coding agents. So I think that this is something where, of course, the jury is still out as to what the end game of coding agents is.

[45:57] But certainly from the experience of software engineers today, it kind of seems like it’s fair to say that most would consider coding agents to be more empowering than somehow causing them to panic. I mean, obviously some people might panic, but in general, at least from the software engineers that I’ve talked to and from my own experience, it’s more empowering to be able to amplify how much work you can do with AI tools.

[46:28] So I think from that, and that maybe is a pretty direct analogy, because that is straight-up an example of an actual real job where AI has entered into it and has actually provided more leverage to the people doing that job. So I think that’s another example that we can look to. But the truth is that I think it remains to be seen.

46:44 — Top robotics research paper recommendation

Ryan:

[46:44] So in LLMs, there are a few seminal papers that, if you’ve read those papers, you kind of get a sense of the lineage of the breakthroughs that mattered in understanding where we are today in the robotics industry. Are there a set of top papers that you really think kind of show the breakthroughs that people should know about if they’re curious about the state of the art in terms of humanoid robotics?

Sergey:

[47:11] One thing I would point out, and this is partly a shameless plug, because I am a coauthor on that paper, though candidly, 99.9% of the work on this was done by Tony, who was the lead author, is the original ACT paper, the ALOHA paper. It’s an interesting example because in some ways the ideas weren’t really that new, but they were illustrated in a really nice way. And the idea was that, hey, if you set up the right kind of low-cost robot setup, in his case it was based on these robot arms from Trossen Robotics that are, they’re like $7,000 hobbyist arms.

[47:48] He set them up in a bimanual setup with a leader-follower teleoperation device. And he showed that actually if you do it right, without really any particularly fancy tricks, you could easily collect teleoperation data of extremely dexterous tasks that people had previously thought would require very sophisticated hardware and all sorts of really expensive stuff, and then set up a fairly straightforward transformer-based model, and it could actually do a lot of those tasks.

[48:13] And it’s kind of like an interesting thing because usually in academic research we put a big premium on do you have some sophisticated new mathematical thing or some sophisticated technical insight. And in that paper, which I think at this point has been hugely influential, the insight is really just, yeah, just put together the right pieces and have a little bit more faith in what a simple robot could do, so to speak, equipped with a good intent learning system.

[48:39] And he showed things like replacing batteries in a remote control. He even got a mannequin foot, and he showed that he could put a shoe on it for an assistive task, sort of. Some people need help getting their shoes on, so that’s good. But what people found, I think, so interesting about that paper is just how far you could get with relatively simple building blocks. And at this point, he open-sourced the code for it.

[49:06] And the ACT code has been used by lots of people. Sort of like if someone wants a very basic starter kit for robotic learning, that’s usually what they grab. And I think it’s worth for somebody who wants to get into the field to go through that paper and really understand what’s going on there. Because even though in some ways it’s not that sophisticated, I think it provides a bit of calibration on what matters.

[49:31] The details matter, but the details don’t have to be complicated.

49:35 — Why is Boston Dynamics less top of mind

Ryan:

[49:35] Before all this large-model robotics kind of wave, prior to that, Boston Dynamics had these really impressive demonstrations and tons of mind share. I guess I wasn’t even in the field, but I think, wow, they’re really doing incredible robotics. And then in the last, I don’t know how many years, I don’t really hear about them much anymore. Is there some shift in the industry that made that so, or is that something you could explain?

Sergey:

[50:12] So the way I would explain it is this: robotics at some level is about building complex systems. So even though it’s very tempting to say, oh, there’s different areas of AI, there’s LLMs and vision and robotics, one of those is not like the others because for robots you actually need all the parts, everything from how you wire up the robot, what the power source is, what does the actuator look like, all the way to how does it do high-level planning to determine what tasks to do next.

[50:46] And even though we could look at these things and say all of these different videos and different companies and different demos, they’re all robotics, they’re really different parts of the stack. A lot of what the classic Boston Dynamics results show is very sophisticated hardware, very carefully designed hardware with a traditional control approach, with very smart controls engineers setting everything up, but with comparatively less emphasis on the kind of decision-making aspect.

[51:20] And I think that at a particular point in time that actually made a lot of sense. Because if we can’t build the physical body, it doesn’t matter what kind of decision-making system is running on it. But to our earlier discussion about generalization, at this point we’re at a stage in the development of these things that even though we can do more on hardware, in many ways it’s good enough. And the big challenge is how to have the decision-making loop that actually works and that reacts intelligently to everything in the environment.

[51:52] And the place where I would draw the dividing line between those is decision-making loop doesn’t mean symbolic decisions. It could mean low-level decisions. The question is, do you need to take the rest of the environment into account, or are you just dealing with a robot? So if you want to do a backflip on flat ground, you most have to deal with a robot. But if you want to pick up a coffee cup off of a table, even though that’s maybe in some ways simpler than doing a backflip, you really have to understand what’s going on in the rest of the world rather than just your own body.

[52:20] And that dividing line, I think the way that technology has panned out, I think it’s fair to say that that is the dividing line between AI and controls. Controls is when you have to control the robot body. AI is when you have to take into account what goes on outside of the robot. And I think that that’s why you see this divide, because I think a lot of the demos where you mostly needed to deal with the robot itself and not the rest of the world, really good controls, could allow you to admit a very good solution there.

[52:51] And another thing I would say here is, okay, if there’s a lot of controls work that goes into doing some particular skill, well, there is actually something to learn from that. Because if you can hand-design a controller that performs a sophisticated behavior, very likely you can also learn that controller. So just that proof of existence that the thing is possible, and not only possible, but also simple enough that a person could build it.

[53:15] Because remember, people are, at the end of the day, even with code these days, the kind of complexity that people can handle is not as high as the kind of complexity the AI can handle. So if a person can hand design something to do a backflip or do some acrobatics, that’s a really great proof of existence that there exists some relatively parsimonious control law for doing that skill. And parsimonious does mean generalizable.

[53:36] So if it’s simple enough for a person to design, probably there’s something fairly general in there. And if you can learn it and automate it without having to have the human controls engineers in the loop, that’s good news.

53:47 — Advice for his younger self

Ryan:

[53:47] And then last question for you is, if you could go back to when you just entered the industry and give yourself some advice, knowing everything you know now, what would you say?

Sergey:

[53:57] One thing that I’ve learned over the last few years, which I think is a little different than my original mindset, is that addressing robotics effectively requires using very broad prior knowledge. And I think there’s this idea that a lot of people in robotic learning have, which I think I shared initially, that since people learn things from scratch, maybe robots should learn things from scratch too.

[54:26] So, for example, in some of our early work on large-scale robotic learning at Google, we had this, what we call the ARM Farm project. We set up a bunch of robot arms in a conference room, actually, because we didn’t have a proper lab. It was a conference room. And we had them all grasping objects. And the idea was, well, if they grasp millions of objects, they’ll learn very general grasping strategies.

[54:51] And it basically worked. They could learn to grasp objects, but it was very hard to take it further than that to the next level. Now I can pick up anything, but so what? It didn’t serve as a very good stepping stone for more complex skills. And I think part of that was that we were approaching this from a very blank slate. Let’s start from zero and see if, knowing nothing in advance, the robot could start picking up behaviors.

[55:12] But I think that it’s much, much more practical to get all this to work if you can combine robot experience with knowledge that you can pull in from other sources. For example, I was very skeptical initially about the utility of language. And I think scientifically this is defensible, which is that, hey, animals can do some pretty impressive things. Monkeys can do really cool stuff. But monkeys, as far as I know, can’t speak, at least not very eloquently.

[55:39] So maybe our robots should also be able to do stuff. And they don’t necessarily need to understand language. But I think the subtlety there is what’s important is not language, it’s prior knowledge that you can put in as a scaffold on your learning process. And you can pull in that knowledge in all sorts of ways. Humans don’t necessarily pull it in entirely through language. Humans and monkeys certainly don’t.

[56:01] They do it from observation, from observing other people, other creatures, and so on. So there’s lots of sources of prior knowledge, but the point is that you got to get that prior knowledge in there. Otherwise, you’re actually faced with a harder problem than what humans and animals have to solve. Because if a person had to figure out how to assemble IKEA furniture, but they’ve never actually encountered any article of furniture in their entire life, okay, that would be pretty difficult because they don’t even know what the point of this is or what the end game looks like.

[56:28] So, yeah, prior knowledge is important. And while I’m still a big fan of learning things through experience, I think that my advice to myself would have been, take prior knowledge more seriously.

Ryan:

[56:38] Awesome. Well, thank you so much for your time, Sergey. I really appreciate it.

Sergey:

[56:41] Yeah, thank you for your questions.

I had a lot of questions about why they chose Go (vs Rust) and if they used LLMs in the rewrite. Turns out they used LLMs much less than expected in the rewrite. He explained why in the conversation.

Anders has strong takes on how AI will impact software engineering so I made sure to run all the famous takes I’ve seen on Twitter to see what he thought like:

• Will AI write all the code in ~1-2 years?

• Will AI replace junior engineers in a few years?

• Will you still need to use an IDE by the end of the year?

And also I asked him why his opinion seemed to be so different from the more AI-pilled companies like the labs. Hope you enjoy the episode, full transcript below as usual if you want to skim.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:48 - Why write a compiler in JavaScript

07:29 - Why rewrite the compiler in Go

14:49 - LLMs for large migrations

20:12 - Why Javascript is so popular

26:32 - Why ever use Javascript on the backend

32:59 - What it takes to build a programming language

37:06 - Will there be fewer languages in 10 years

42:57 - Hands on engineering vs delegation

49:14 - Why fast tooling matters more now

51:16 - AI software engineering predictions

58:52 - The most technically challenging work

01:02:04 - Top book recommendation

01:03:50 - Advice for his younger self

Transcript

00:48 — Why write a compiler in JavaScript

Ryan:

[00:48] The big thing that we’re going to talk about here is obviously TypeScript 7 with the native rewrite. And the first thing that I think of when I see this was I didn’t even realize that the compiler was written in JavaScript to begin with because I don’t usually think of compilers being written in high-level dynamic languages.

Anders:

[01:09] Yeah, no.

Ryan:

[01:11] So why was TypeScript written originally, the compiler written in JavaScript?

Anders:

[01:17] No, it’s a good question. And honestly, if you had told me before the TypeScript project started that, “Anders, you’re going to be writing compilers in JavaScript,” I’d be like, “No, no, I’m not.” But I mean, the original prototypes for TypeScript, the Strada project, as it was called in the very early days, were actually written in C because it was like an adaptation of the parser, the JavaScript parser that we had in Internet Explorer and whatever.

[01:49] And then we’ve moved to JavaScript, but we wrote it sort of C# style. But why did we go with JavaScript? Well, I mean, if you can self-host in the ecosystem that you want to be a part of, then that is just dramatically better than putting yourself outside the ecosystem and trying to target that ecosystem. Do you know what I mean? Because by writing it in TypeScript, we were also daily users of TypeScript and daily users of the tooling that we were building.

[02:21] And whenever something didn’t work right, we knew it immediately. And whenever something didn’t perform right, we knew it, and so in the early years, it was a huge boon, I think. And then, of course, JavaScript runs everywhere, right? And that meant automatically our compiler could run on every platform, anywhere, even in the browser. Had we gone with a native code solution at that time, it wouldn’t have been possible to run it in the browser.

[02:49] Now we have WebAssembly or WASM, but that didn’t exist at the time. Right. So it was a meaningful choice. And honestly, at that time also, people didn’t really realize how fast JavaScript had gotten. I mean, it used to be very slow, and then Google did all of their excellent work with V8 and got it to within 2 or 3x of native code, which is pretty darn impressive. And it was like full well possible to write compilers in JavaScript, and you could even get them performant because often it’s the algorithms that determine how performant you are.

[03:33] It isn’t necessarily the runtime environment. Right. I mean, it’s a combo. But yeah.

Ryan:

[03:38] Is there anything unique about the TypeScript compiler? I think of a compiler, I think of Clang or one of those ones that is used for maybe C or those static languages. What’s unique about the TypeScript compiler when it was written in JavaScript compared to these native compilers?

Anders:

[04:00] I think there are a couple of things that are pretty unique about TypeScript‘s compiler. First of all, it doesn’t target machine code, it targets JavaScript, and some people call that a transpiler. And in a sense, the compilation phase is mostly about removing the type annotations and turning your TypeScript back into JavaScript. Right now, in the early days, also an important part of the compilation process was to downlevel your JavaScript, meaning all of the runtime environments at the time were not evergreen.

[04:36] And sometimes people were lagging multiple years behind on which level of the standard was implemented. And for example, when classes got standardized, most JavaScript runtimes didn’t implement classes, but it turns out that you can downlevel to constructor functions, transform the code. And so part of what we did was this transformation, downlevel transpiling of the code. But then, of course, the type checking is the big thing that we do.

[05:06] And the type checker in TypeScript is also quite unlike any other type checker in other compilers. Typically, type checkers exist in compilers to guide the code generator because you want to know: are we dealing with a float or an int or a string here so we can generate the correct machine instructions for that data type, et cetera, et cetera. That’s not the case in TypeScript. In fact, since we erased the types, the types have no impact whatsoever on the runtime behavior of the code.

[05:40] They purely exist for tooling sake and for the developer’s sake and to guide things like statement completion and refactoring and code navigation, which is a whole different thing. Also, they don’t necessarily have to be there. And so TypeScript has a gradual type system. You can sort of have half of your code have types and the other half is just anys that we don’t check. Now very few languages have anything like that.

[06:13] So it’s a very different compiler in that sense and a very different language in that sense. That actually made it fascinating to work on because we were solving problems that no one had solved before.

Ryan:

[06:25] I know a lot of compilers, they take the higher-level code and they typically apply optimizations as well. Maybe they unroll loops or they get rid of duplicate instructions, simplify things. Does anything like that happen in the TypeScript to Java compilation process?

Anders:

[06:44] Very little. Like I said, when we do the downleveling, there are some transformations that go on that are complex. But it is less and less the thing that’s important about TypeScript. In fact, a lot of people use TypeScript only for the type checker, and then they use some bundler like esbuild or SWC or whatever to package their app, erase the types, do whatever needs to be done in order to make it runnable in the browser.

[07:15] And so we’re not really there to optimize your code for runtime. We’re there to make you more productive as a developer or make AI more productive as a developer.

07:29 — Why rewrite the compiler in Go

Ryan:

[07:29] So with the native rewrite of this originally fully JavaScript compiler, what was the problem you were trying to solve with the rewrite, and why did you end up rewriting it in native code?

Anders:

[07:43] Well, the problem we were trying to solve is real simple: performance and scalability. JavaScript was never really optimized for compute-intensive workloads like compilers, right? JavaScript is more about creating UI that runs in a browser. It was originally intended for just maybe 100 lines of code, but now, of course, it’s gotten to be a lot more. But it’s not a place that you would optimize for the kind of workload that we are.

[08:16] So in JavaScript, first of all, you pay a 2 to 3x perf penalty compared to native code. I mean, it depends on the workload, but if you’re doing compute, that’s about where it’s at. And then secondly, in JavaScript there are a lot of restrictions around use of concurrency. JavaScript was always engineered, in fact, to be a single-threaded language. That’s why we have callbacks and async and whatever.

[08:44] It’s because you can’t spin up threads, and that’s a good thing. Mostly because concurrency in a language with mutable data is very, very hard, because you can have races and deadlocks and all of this good stuff, right? That’s why functional programming languages are easier with concurrency, because all the data is immutable, and it’s much easier to reason about. So JavaScript doesn’t give you access to concurrency other than web workers.

[09:15] But web workers can’t share data between each other other than by remoting it. So you can have one web worker compute something, but if it wants to give it to some other web worker, it has to turn it into JSON, or it can’t just hand it objects. And that means you can’t have one worker compute some data structure and then have someone else use it. In other words, you can’t have shared memory concurrency.

[09:41] And really that’s what we wanted in order to gain all of the perf that we were leaving on the table by not utilizing multicore CPUs that everyone has today, right? Because Moore’s Law has stopped giving us faster CPUs, it’s giving us more CPUs, and we got to find ways to use them in our compute-intensive workloads, or else we’re leaving money on the table. And so we were leaving money on the table in multiple ways, right?

[10:08] And so native code, and that was why we looked for a language that would get us out of both of those binds. It had to be native and it had to have access to shared memory. Concurrency.

Ryan:

[10:21] I saw for the language choice you went with Go. And when I think of all the systems languages, the ones that are often hot are maybe Rust or Zig, why did you choose Go for the native rewrite?

Anders:

[10:35] I think the decision process was actually pretty structured. The first decision we made was we’re not going to rewrite, we’re going to port. Because only by porting can we preserve the semantics and the algorithms and the exact behavior of our existing compiler, which everyone depends on for backwards compatibility. Now, we could have cleaned the slate and started completely from scratch, but we would have come up with a different language in the sense that it would give you different errors or behave differently in certain situations where it has to make choices between multiple possibilities and what have you.

[11:15] So we wanted to port that meant our code makes certain assumptions. Our code, for example, assumes the existence of garbage collection. It assumes the existence of first-class treatment of functions. You can have functions within functions, and you can close over outer state and so forth. As we evaluated all of these, Go was the one that checked the most boxes. It gives us very robust and mature native code generation on all major platforms.

[11:53] It has garbage collection and it has excellent access to shared memory, concurrency. And those were the high-order bits that we wanted to check. And every other language had something that kind of worked against those objectives. So for this particular workload, Go was the right choice for us. And it’s worked out well.

Ryan:

[12:16] If you think about Rust, what didn’t it have that if it had it, you would have picked it?

Anders:

[12:22] I mean, I think there are two things. It doesn’t have garbage collection. It’s done manually, or it’s done through the borrow checker. But the borrow checker doesn’t allow circular data structures. And our compiler is chock full of circular data structures. We have trees with parent pointers, we have types that are recursive, we have symbols that refer. I mean, it’s everywhere. And like I said, if we had chosen to rewrite, we could have probably solved all of that.

[12:54] But it wouldn’t have been just porting the code. It would also have been solving a whole bunch of new problems that we had bought ourselves by going that route. We tried, and it just wasn’t feasible. And so we were just trying to optimize for doing as little work as possible to get us to the payout. And honestly, Rust is no better when it comes to the quality of the generated code or the concurrency gains that we could have gotten out of it.

[13:27] Go is just great. I mean, so we got all the bennies for less work by going that route.

Ryan:

[13:35] I know some languages, when you say they’re garbage collected, there’s something in the language itself that is doing garbage collection. But there’s also independent libraries that can provide garbage collection, right?

Anders:

[13:52] There is, but it often comes with a whole bunch of restrictions, and it doesn’t necessarily come with the safety guarantees that we were looking for. I mean, Go is type-safe and memory-safe, meaning that you don’t get to just have stray pointers or whatever. With Rust, you can do ref counting or you can do all sorts of different strategies, but there’s always that little bit of unsafe where you have to do this in order to make it all work.

[14:26] Where if garbage collection is engineered into the language, it really is a separate concern that is you don’t have to do anything special. I mean, of course, you have to not hold on to data that you no longer need and whatever. But that’s true of ref counting as well, right? But it is inherent in the language.

14:49 — LLMs for large migrations

Ryan:

[14:49] When you ported it from JavaScript to Go, I’m curious how much LLMs were used in that process, because I know famously there’s some major projects that have been doing rewrites of their entire codebase. I know there’s this JavaScript project called Bun that rewrote everything from Zig into Rust, so it seems like a pretty useful tactic. And I’m curious if you leveraged that in this process.

Anders:

[15:16] Not a whole lot, but it also has to do with timing. We started this project two years ago, and two years ago, LLMs were nowhere near as good as they are now. I mean, that’s how crazy fast it’s all moved, right? So what we did, though, is we certainly had a bunch of tools that aided us in the port. I’d say the prototypes we wrote, the scanner and the parser we wrote manually. And at that point we could convince ourselves, wow, we can actually get 10x out of this.

[15:51] Now what do we do with the rest of this code base? What we did was we wrote a tool that syntactically translates TypeScript into Go, this code that comes out of it. It has no syntax errors in it, but it doesn’t compile either because it’s full of... It uses types as if they were TypeScript, which they’re not in Go. And so all of that had to be refactored. We had to redo all the data structures or whatever, but we got the same code base out of it, and then we could sort of bang on that, and then in a more localized fashion, maybe use AI occasionally to help us do the transformation.

[16:29] So it was sort of manual and automated and a little bit of AI. Now, if we were to start the project today, would we do it differently? Possibly. Although I will say, if we just let AI loose on what is it, like half a million lines of code that we have in the old compiler, or somewhere between half a million and a million, and asked it to translate it all, well, I don’t know that that would absolve us from then having to go in and carefully examining every line that came out of it to make sure that there were no hallucinations.

[17:04] Right. Unless you have 100% perfect test coverage, you probably still got to go check all of that. Now, I think a better approach, quite honestly, would be to enlist AI to write a program that helps you translate from TypeScript to Go, because at that point you can park the stochasticness in that program and then you can get deterministic behavior whenever you run the program, which means you get the same transformation every time you run it.

[17:35] That’s always the thing about AI that people forget: it’s not deterministic. So you can’t really trust that it’s going to do the same thing twice. We might have done it that way, but AI was not ready to do it at the time. Now, that doesn’t mean that we don’t use AI now down the line. We use AI a lot in our internal processes around the compiler, as everyone does, right? Help it to write tests and to move pull requests and what have you.

[18:05] And whenever an issue is logged, first thing we do is put Copilot on and see if it can fix it for us, right? I mean, so, yeah, in that approach.

Ryan:

[18:13] where you use the LLM to generate tooling and then the tooling is deterministic, but you’d still have to validate that thing.

Anders:

[18:23] Yes, but that’s a much smaller surface area that you have to validate, right? And honestly, I’ve seen that even with friends. We did some trip together, and there was some accounting of it. Well, he paid for the hotel rooms and we paid for this and whatever, and we needed to sort it all out, right? So, okay, well, here’s what all the costs were, and here are the pieces, and have AI fix it for us, right?

[18:46] Or like tell who owes who what. And it very authoritatively came up with the wrong answer, right? Because it just forgot about some of the settlements, right? But if we had asked it to write a spreadsheet, which is really just a program, right, then we would have gotten the right answer because it’s very good at writing programs. So it’s kind of funny how sometimes you don’t ask AI for the answer, you ask it for a program that computes the answer.

Ryan:

[19:17] What are the potential benefits that you left on the table by doing a port instead of a full rewrite?

Anders:

[19:23] To be honest, I don’t think there are any, and I don’t think we would consider a rewrite. We were quite happy. We’re quite happy with the way this codebase works. I don’t think we’re leaving any money on the table currently. And as I said earlier, rewrites are toxic often for ecosystems, because they sacrifice compatibility, because you never rewrite and you never get back to exactly what you had before, right?

[19:54] Oh, but in the name of making it better or prettier or whatever, we change this and that and the other, right? And then while all the users get to suffer through that, right? So backwards compatibility is super important if you want to keep your ecosystem happy. And we do want that.

20:12 — Why Javascript is so popular

Ryan:

[20:12] In studying for this interview, I just keep reading about JavaScript and the strange semantics of the language. And I think throughout my career too, people have typically not been super satisfied or happy with JavaScript for some reason or another. My question is, why is it so popular despite that?

Anders:

[20:36] First of all, I don’t think JavaScript is as bad a language as some people make it out to be. I will say in the three, what, three, four weeks that Brendan Eich had to create this language back in the mid-90s, he did a lot of things right, and thank God that he had been educated on functional programming and got first-class functions done, right? Where you can have functions within functions and the inner functions can access the outer function state and you can pass functions around as first-class values.

[21:09] That is super powerful. JavaScript actually got that very right. Now there are some quirks in the language too. All of the automatic conversions and all of the bizarre differences between double equals and triple equals just drive everyone mad. But that’s exactly what type checkers are happy to do. They can ferret out all the little differences because they understand all the deep semantics of the language that no one seems to be able to keep in their mind.

[21:39] So I think that’s part of why TypeScript has become so popular, right? It can actually truly bring out the best parts of JavaScript and leave the bad stuff behind. And of course you can’t. The thing about JavaScript is it is the cross-platform language, like even Java, that was engineered and intended to be the way to write cross-platform applications. It’s not really cross-platform.

[22:06] It doesn’t run in the browser, I mean, it doesn’t run everywhere, right? JavaScript runs everywhere. So there are a lot of reasons why you should like JavaScript. And with TypeScript, I think we’ve managed to sort of capture all the badness and park it.

Ryan:

[22:27] I saw there were some projects. I don’t know if you’re familiar with Dart or CoffeeScript, and it seems like these were some efforts to replace JavaScript or improve it, but they’re not popular today. So I’m curious what happened.

Anders:

[22:44] I mean, I think CoffeeScript was mostly a different syntax for JavaScript, so it doesn’t really change the semantics, and it didn’t provide any additional tooling or whatever. And Dart was also, in a sense, about fixing JavaScript. Right, but if you can fix something by fixing it instead of trying to replace it with something else, then you’re doing the ecosystem a much bigger favor, I think.

[23:16] Right. And that’s what we set out to do with TypeScript. We weren’t trying to change JavaScript; we were trying to improve JavaScript. And I think that’s ultimately why we succeeded.

Ryan:

[23:28] I mean, in this new age where it’s very feasible that maybe AI could rewrite code bases, I imagine people will start to go toward the desired languages rather than the ones that are the incumbent languages. And I’m curious if you think that JavaScript might become less used in the future.

Anders:

[23:51] See, I don’t think so. What I’ve observed is that AI is best at the languages it’s seen the most of in its training set. AI gets trained on all the code that exists in the world, which means there’s an awful lot of JavaScript, an awful lot of TypeScript, an awful lot of Python, and therefore AI is good at JavaScript and TypeScript and Python. It is less good at my favorite little language that I just invented.

[24:22] In fact, there’s none of it in the training set, which means you have to sacrifice God knows how many tokens in the prompt to teach AI the language before you can even ask it a question about the language. Do you know what I mean? So in that sense, I think incumbent languages are actually, if anything, going to flourish because of AI. And we’re sort of seeing that right now with TypeScript too. Right.

[24:47] There’s a noticeable knee in the curve of TypeScript adoption that coincides with the advent of AI. I do think the incumbent languages are actually, if anything, getting stronger.

Ryan:

[24:58] What percent of all JavaScript is written in TypeScript?

Anders:

[25:04] Well, so in the last year, TypeScript became the number one used language on GitHub. So there is JavaScript more than JavaScript. So more than 50% on GitHub at least is written in TypeScript. So we’re actually larger now than the language that we set out to improve.

Ryan:

[25:28] Wow.

Anders:

[25:29] Yeah. And larger than Python.

Ryan:

[25:31] If you were to just draw that out in the future, do you think that eventually TypeScript would become the default and almost 100% of all JavaScript would be typed?

Anders:

[25:41] Well, certainly. I mean, if you’re having AI write it, I almost challenge you to find a tool that writes JavaScript. They all write TypeScript because it helps AI write better code, because the type annotations guide the LLM toward writing, or to write, making fewer mistakes, and the ability for us to statically validate the code before you run it. I mean, that’s the distinction, right? The only way you can validate JavaScript is by running it, which means you have to set up a runtime environment, which might not be possible for AI to do because AI lives in a sandbox, but AI can run through tools, the compiler, and check the code that it just generated and be told, oh, you made a mistake.

[26:27] Oh, well, let me fix it then before I even tell anyone that I made the mistake. Right?

26:32 — Why ever use Javascript on the backend

Ryan:

[26:32] After learning about this 10x improvement and performance from rewriting in native, it makes me wonder why anyone would use JavaScript on the back end. Why not just always use native languages on the back end?

Anders:

[26:48] Well, it depends on your problem, I think, because the thing that overlooks is what kind of thing am I going to write on the back end? There are an awful lot of very, very good web server frameworks, for example, that use TypeScript or JavaScript, right? So if there are frameworks in your ecosystem that get you to a solution quicker than if you had to write that because your native language wasn’t really intended to target that particular community.

[27:21] So I think it very much depends on what your problem is affinitized with. And often performance of your code isn’t the bottleneck. I mean, look at Python, right? It’s used to basically script all of the LLM training in the world, right? I mean, a lot of that code is ultra time critical, but that’s written in native code, right? And then you use Python as the orchestration language, and in a sense, in a web server, TypeScript is just an orchestrator of talking to a database and doing this and that. And the things that ultimately control the performance of applications like that aren’t necessarily whether that inner for loop is running as native code or not.

[28:12] Which actually it is because of the JIT anyway, right? I mean, so measure first and then make decisions, right? Because you always get surprised when you measure, when you talk about how much faster it was to.

Ryan:

[28:24] One of my immediate thoughts is, why wasn’t it done sooner?

Anders:

[28:33] At the time we started TypeScript, I don’t know that we had ever envisioned that people would be writing projects that are the size of the projects that people are now writing in TypeScript, right? Visual Studio Code is like 2.3 million lines of code. I mean, we have in-house projects that are over 10 million lines of code, which is insanity. We would have just at the time gone, well, that’s clearly no one’s ever going to do that, right?

[29:01] But that was a decade ago, more than a decade ago, right? We started in 2012 with the TypeScript project, and the world looked very different. And so gradually, people have started writing larger and larger and larger projects, right? And at the same time, our compiler has gotten smarter and smarter. We’ve added all sorts of cool features like union types and discriminated unions and control flow analysis and blah, blah, blah.

[29:26] And all of these things make our type checking even better. But it also makes it go a little slower every time we add a new feature, right? In fact, our TypeScript 6 runs only about 50% of the speed of TypeScript 1.5, for example. But TypeScript 1.5 also did a whole lot less. So projects have gotten bigger and the compiler does more. All of which detract from your effective output. And as I mentioned, Moore’s Law also, unfortunately, stopped delivering faster CPUs, and JavaScript keeps you from taking advantage of the additional cores.

[30:02] And it’s not clear that we could have foreseen all of that, right? But it’s just the way it panned out, right?

Ryan:

[30:10] 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.

[30:40] 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. And I appreciate them for supporting my work and sponsoring this podcast. Jira by Atlassian isn’t just for tracking work anymore. Now you can pick your favorite AI agent to assign tasks to, and they’ll get access to the rich context that’s already in Jira.

[31:07] When the agent is done, it surfaces a pull request. That way you can get more done with your favorite agents, all in one place. Learn more at jira.dev. That’s J I R A. D E V. Appreciate them for sponsoring the podcast. And back to the show. I first became a software engineer and I went to start working at Facebook. At the time they had this popular framework called Flow, which was doing type inference on top of JavaScript.

[31:37] It was this thing that would take a long time, and then I’d never hear about it these days. So it sounds like TypeScript won, if there was a competition to type in.

Anders:

[31:46] There was a bit of it, yeah. In the early days, I think the thing that worked for us was actually the fact that we were self-hosted, which made it a lot easier for the community to contribute to the project. Flow was written, as I recall, in OCaml. And so in order to contribute to Flow, you had to go learn a whole different way of programming in a different language. Right. And Flow also did not focus all that much on IDE-based tooling, which we knew full well going in.

[32:22] We’re writing a compiler, but we’re not writing a compiler in order to generate machine code. We’re writing it to make better tooling. That was why we wrote it right there, hand in hand with our compiler. We had a language service. It was deeply integrated into Visual Studio, Visual Studio Code, all sorts of other editors through an open protocol, and that’s where the problem that needed solving was.

[32:47] I mean, it’s nice to have a type checker, but boy, you want that. You also want statement completion. You want red squigglies, you want it interactive, right?

32:59 — What it takes to build a programming language

Ryan:

[32:59] So I know in your career you’ve, you’ve worked on multiple programming languages. What does it take to build a programming language?

Anders:

[33:07] Well, first I’ll say that the world needs another programming language. Like it needs another hole in the head. I mean, it’s like you kind of got to be a certain kind of person to even embark on it to begin with, right? It’s a super fascinating area of computer science and it’s one that’s been around ever since the beginning of computers. Now every compiler, every language has a whole bunch of things you need to understand, like parsers and scanners and lexers and code generators and whatever, right?

[33:43] But that’s sort of the mechanics of implementing the language and then there’s the design of the language, sort of the art of making it feel right, whatever, right? And I think you sort of have to master both. And then you also got to appreciate that like every new language is actually only 10% new. And then it’s 90% the same drudgery that every other language has to go do. And so be prepared for a lot of work that maybe isn’t as interesting, you know, and then finally maybe I’ll say that, you know, like, never forget there that you stand on the shoulders of giants.

[34:24] I mean, in order to make a great programming language, you got to understand a bunch of other programming languages first and understand all the, all the distinctions between the different styles of programming like procedural and object oriented or functional or what have you. And then last but not least, it’s like it’s a long game. I mean, it is probably a longer game than anything else. I mean, like every language project I’ve worked on, I’ve worked on each of them for at least 10 years and shipped multiple versions.

[34:58] And it’s really never until version three that it truly starts to get okay, do you know what I mean? And it just takes an incredible amount of devotion to that. So you gotta really not be the type that tires of a problem quickly and then moves along that you’re not meant to do language design. And you see that too when you talk to language designers in the industry. They’ve been doing it for a long time.

Ryan:

[35:23] You mentioned those two parts. There’s the objective pieces that you need to implement and then there’s the art of the design and making the language, I guess, ergonomic for developers. When you think of that second part, that art, and you look at other programming languages, are there any that you admire outside of the ones that you’ve worked on?

Anders:

[35:45] Of course, learning and fully appreciating the beauty of functional programming has been very educational. I mean, because it really is a different way of thinking about programming, a way of thinking of programming that’s much closer to math than it is to machines. And I think there’s a lot of incredible goodness that has come from that. And honestly, Even in building TypeScript project, large portions of the TypeScript compiler are written in a highly functional style and work on immutable data structures that are then.

[36:25] Now, because of shared memory, concurrency can be shared between different threads or processes that don’t mutate the data and therefore they can share one data structure that’s incredibly powerful. But mastering this, like writing islands of pure functional programming inside an imperative program and putting it together with concurrence, I mean, it’s complex, but I think functional programming has brought a lot to the world.

[36:55] I know object oriented programming as well, but I wouldn’t single out any particular language. Every one language you come in contact with, you learn something.

37:06 — Will there be fewer languages in 10 years

Ryan:

[37:06] You mentioned the world doesn’t really need more programming languages. And if you think 10 years from now, do you think there will be less programming languages than there are today?

Anders:

[37:19] It’s hard to say. But like I said, AI tends to favor the incumbents. Right? And I do think, and I think this has been true even before AI, the bar keeps going up for what it takes to successfully implement a programming language and create an ecosystem around it. I mean, it used to be, oh, you just need a compiler. Well, you also kind of need tooling now. I mean, you need a language service, you need debuggers, you need profilers, you need frameworks and libraries, you need code generators that can target all sorts of.

[37:59] I mean, it’s like it just keeps getting harder and harder to get all the way there.

Ryan:

[38:08] When you think about all those pieces, really, they’re all for the people. I mean, the IDE and the types. I mean, the computer looks at that too, but it’s so that we can read source. Maybe one day the LLMs will generate machine code directly.

Anders:

[38:28] I wonder. I think LLMs are better at what they do when they don’t have to repeat themselves a lot. I think, like when a program is expressed in text, it is closest to its sort of ultimate condensed meaning and representation. Right. If you translate it into machine code, there’s an awful lot of noise in that machine code. Like all of the instructions, like, half of the instructions are memory addresses that have absolutely no bearing on what’s going on here.

[39:09] So half of all the data is noise already. Right. And then whichever register you pick, well, that doesn’t matter either in the code generator. And honestly, you could change your mind at any point in time. So teasing the truth out of that noise is a lot harder than if you just have a program where the variable is called I and whatever. And by the way, that you can relate to the written instruction that the user just gave you.

[39:34] I mean, keep in mind that, like, AI are, they’re just emulators of humans in a sense. Right? I mean, it’s like neural networks. Right. There’s a reason we have programming languages because we’re terrible at writing machine code straight off out of our head. Right? AI is not that different from us, so the same would probably be true there.

Ryan:

[39:56] When you look back on working on C and Typescript and these language projects, they were long journeys and I think, yeah, one thing people might want to know is what did you Learn through those journeys that if you knew at the beginning of when you embarked on working on them, you might have been better off.

Anders:

[40:19] Gosh, well, each journey is different. I mean like the first project I worked on, Turbo Pascal, I think

Ryan:

[40:30] that

Anders:

[40:30] project started back in the old days when it was 8bit micros and 64k of memory and one person could do everything themselves and have ultimate control of everything. And so I was very much a one man shop. But that quickly was not scalable. Right. And capacities of machines. We went from 64 to 640k and then kaboom, the lid went off. Right. And you could have as much memory as you wanted. And so not one person couldn’t do it.

[40:59] And I had to learn to become a team player. Right. And that, that was a big journey for me. I mean to learn to let go. Right. If you’re a perfectionist, that could be hard, but that’s one thing that I would say I learned there.

Ryan:

[41:14] Well, another way to word this question is, you know, what’s the most common mistake that you see people make when they embark on building a programming language?

Anders:

[41:24] Well, I think people tend to over index on one idea that they have that they think, oh, wouldn’t it be cool if my language could do blah. And then they under index on all of the mundane stuff that every programming language has to do and then it ends up doing that one thing they love, maybe better, but then it does everything else not as good. And the net is a detractor. Right. And so it’s so hard to convey how many things you have to do that really doesn’t have anything to do with the problem you’re trying to solve per se.

[42:03] When you’re implementing programming languages, when you

Ryan:

[42:06] were working on C, do you keep tabs on the other languages and what they’re doing better, what you could do better with C?

Anders:

[42:15] Yeah, no, you got to keep yourself informed because like I said, we all stand on the shoulders of giants. No programming language was ever created in perfect isolation. Everyone learns from everyone and then someone comes up with a good idea and then you see it adopted elsewhere. We’ve adopted many ideas from functional programming in C, for example. Then other languages have adopted some of the good ideas we had in C, like Async now is in JavaScript and in some of the other programming languages out there.

[42:46] And that was pioneered in C. You know, it’s, it’s, we all learn from each other and that’s how the industry moves forward. Really.

42:57 — Hands on engineering vs delegation

Ryan:

[42:57] You mentioned the, I guess, learning to let go. I think that’s something that a lot of people, as their career advances, they start with, you know, individual contributor work and then later they start delegating things. How did you learn that? Or what was the. Is there like a, maybe a story or particular project where you let go and you develop that skill?

Anders:

[43:21] Well, it’s almost like I got a counter story to the letting go there because in the C Sharp project, my main function was not implementing the C compiler, it was being the language designer and writing the spec and designing all the new language features. Before that, when I, when I had worked on Turbo Pascal, I was, I was doing a bunch of active coding, you know, on, on the thing itself, right? But then I sort of let go of that, but I let go of it too much and I sort of drifted up into the stratosphere and became more of an architecture astronaut, do you know what I mean?

[43:59] And I wasn’t getting my hands dirty. I was writing stuff in the framework and in the libraries, but it wasn’t, it didn’t quite. These are not like the deep, really super hard problems to solve. And I didn’t really know it at the time, but I was gradually getting less happy with the work that I was doing. I still enjoyed, but there was something missing. And so when this typescript opportunity came along, I decided to jump in and actually actively participating writing compiler.

[44:30] And it brought so much happiness to my life. I finally realized I’m just a happy coder. I mean, I like the spec stuff too, but coding is like, man, that’s what gets me up in the morning, make coffee and write some code. You know, that’s when I’m in my happy space.

Ryan:

[44:48] You know, when people are at these really, really high levels, they kind of have this expectation of a certain level of impact. And so how do you continue to write code as such a high level engineer?

Anders:

[45:02] Well, the specific code I’m writing isn’t necessarily having all that impact, but it’s the fact that I also do the architectural guidance as part of a group of people in a project, there’s plenty of work for everyone to go around, but you stay involved in a corner of the project because then you see what happens in the code. When you’re checking in your code, you go, what was, what was that over there?

[45:31] Let me just, what’s happening over here? Or you realize, oh, we need to refactor this. This is not feeling right anymore. But if you let go of that, you can’t really talk about the thing that people use day to day. You can talk about the Syntax of the thing that people use day to day, but you can’t talk about that thing. So both are important, I think, and I’m happy that I get to do both.

Ryan:

[45:57] Now, I know a lot of companies have this idea of engineering archetypes or the way that high level engineers get some work done. And you mentioned architect, for instance. A lot of companies have different words for architect. I’m not sure if you’re saying it’s just your working style or are you saying that all high level engineers should be hands on at some level?

Anders:

[46:22] No, I’m not saying that because I don’t think it’s like I made a conscious choice to remain an independent contributor as opposed to become a manager. I mean, I have plenty of opportunities, but that is not where I do my best work. Right. So I think you have to decide for yourself what is it that motivates you, makes you happy, keeps you doing this for a lifetime. Do you know what I mean? And you only get one run at it in life here.

[46:54] And if you’re going to do your best work, do the thing that makes you the most happy. I think that’s what I learned along the way, that coding is part of that, a big part of that.

Ryan:

[47:10] So then when you were working on C, but before Typescript, how did you know something was missing?

Anders:

[47:16] I just knew something. I don’t know how. I mean, I just wasn’t feeling as fulfilled with only doing the design part. Right. I missed the coding and whenever I had a chance to write a little bit of code, I would feel a lot happier. And I go, that’s kind of interesting. Do you know what I mean? But now I got to go write some more specs.

Ryan:

[47:41] So then was Typescript something you kind of went towards because you wanted to write more code?

Anders:

[47:46] Well, I went towards it for many reasons. I mean, it wasn’t specifically that to begin with. I just found the problem fascinating. Right? I mean, because the way TypeScript came about was actually indirectly through C. Because the Outlook. com team, I think it was, approached the C group and asked whether we would pretty please productize something called Script Sharp. Script Sharp was this thing that took C and transpiled it into JavaScript so you could run it in a browser.

[48:19] I’m like, what? Why would you want to do that? Why don’t you just write the job? Well, because that way we can get great tooling, then we can use Visual Studio and we can have projects and we can have type checking and we can have code refactoring and navigation and we can write interfaces and people can understand how this all works. And I’m like, wow, is JavaScript really that busted? And you’re saying, like, the way you want to fix that problem is by abandoning JavaScript, treating it as an instruction language.

[48:51] Right. And then having a code generator targeted. I’m like, couldn’t we fix JavaScript? Wouldn’t that be better? Do you know what I mean? And that’s how TypeScript kind of got off the ground, Right? It was like, gosh, there’s something here that’s really broken that needs to be fixed. Right. When it comes to JavaScript tooling, and that’s what we set out to do.

49:14 — Why fast tooling matters more now

Ryan:

[49:14] One thing I thought would be interesting is in one of the talks that you gave, you said that you believe that the speed of your tooling is more important now because of AI, And I want to hear thoughts on why is that the case.

Anders:

[49:30] Well, more and more, our workflows now are dominated by agents that are, like, running away in the background. I mean, like, writing code for you. And they make mistakes just like we do. But you can have as many of them as you want. So there are like, many, many more little workers in the ecosystem writing much more code. Right. And that whole workflow is like, LLMs already have performance challenging.

[50:00] And if you add, like, if you’re writing code in a big project and you have to type, check it, and it takes two minutes every time the LLM writes something. Do you know what I mean? That’s horrible. Right? So making that go faster is a big benefit.

Ryan:

[50:14] Yeah, absolutely. I guess. Because it’s hammering away.

Anders:

[50:17] Yeah, Because, I mean, well, we all know LLMs, they like to use GREP and whatever. Right? But then they’re also smart enough now to realize that if you’re trying to change this property called version, and like every other object has a version property, you can’t just grep for version and then go rename it to something else because, like, you’re breaking all these other interfaces that have a version in them, right?

[50:45] So you got to do semantic search, and the only thing that can do semantic search is a compiler. And so you got to use the compiler through, typically through lsp, through language Services, or through our command line tool. That would give you the equivalent. Right. And so more and more AI is doing that. And that means, you know, compilers run at. You may not even see that they’re running, but they’re running and they’re doing work on your behalf.

[51:15] Yeah.

51:16 — AI software engineering predictions

Ryan:

[51:16] When you talk about AI, it’s very realistic and grounded in the software engineering. And so I thought it might be interesting to run some common AI takes that I hear from the Internet and get your sense of how accurate is this? What are your thoughts on when or if it’ll be true? Okay, so the first one that I’ve heard this was more common at the end of last year, is that AI is going to write 90 plus percent of the code within a year.

[51:49] Curious what you think on that.

Anders:

[51:51] Well, for certain classes of apps that might be like all of I coded apps are writing 100% of the code. Right. And there’s an awful lot of that being written. Are they going to write 90% of the high quality code on the Internet? I don’t know about that. So the thing is like 90% of what the volume of written code is just going like that right now. Right. Because AI writes so much code. So in a sense that’s a self fulfilling prophecy.

[52:22] Right. But when it comes to the super high quality code that no one has ever written before, it’s not clear to me that AI is going to write 90% of that.

Ryan:

[52:35] So when you think about cases that AI is not writing all the code, maybe some examples of the super high quality stuff, what is that?

Anders:

[52:44] Well, I mean it’s algorithms that no one has ever seen before, for example, or particular solutions. Like, I mean, I know that AI could not write our compiler, the Typescript compiler. It just can’t. I mean we’ve tried it can’t do it. And I’m not asking it to either. I mean I’m not expecting it to either. But our compiler is also not a typical piece of code. That’s why it’s bad at writing it, because it’s seen none of it in the training set.

[53:16] Well, I’ve seen some compilers, but not like this one, not with these concepts, not with done the way that we’re doing it. Right. And so it’s just not a good fit there. AI, we can’t forget that AI is at heart a big stochastic machine that has memorized the entire Internet. Right. And has an ability to extrapolate somewhat over what it’s memorized. Right. But if it hasn’t seen it before, it’s not necessarily going to be all that good at doing it.

[53:49] It’s getting better. I mean, I’m not saying it’s not impressive, it’s wildly impressive what it can do, but I just think there’s a long way still to it’s doing all of it. And I don’t know that we ever get there. I hope we don’t. Because then what’s the point of humans anymore then? I mean, it’s.

Ryan:

[54:09] What I see this take often too is you won’t need to use an IDE within the year or you don’t need to read the code anymore.

Anders:

[54:19] Well, good luck to you. I mean, if you’re going to hand AI the keys, I mean, then all bets are off, right? I mean, the minute AI you can’t convince AI to fix this issue or this new feature that you want built, what are you going to do? I mean, if you don’t understand what’s below? Right. That’s one problem. The other problem is, let’s say a user comes to you and goes, your app just stole my bank account.

[54:46] Well, it’s going to sue you. They’re going to sue you. Not the AI. I mean, it’s like at the end of the day, someone has to take responsibility for what AI is doing. And if you’re giving it the keys, well, it’s on you. But I don’t know, I personally would not feel comfortable. I wouldn’t be able to go to sleep at night, I mean, if I didn’t understand what it is that I am vouching for.

Ryan:

[55:13] Why is there such a big difference between this opinion and what I see from maybe people who work at Anthropic?

Anders:

[55:22] Well, the difference is, all I’m saying here is not that AI can’t do amazing things. It does, it can. It does that every day. But people love these, like, take it all the way to 100%. Right. And that’s where I get off the bus a little bit. Right. I think, oh, yeah, okay, fine, we can get higher and higher percentage. But there still has to be someone understanding what’s going on and how it’s relevant to our business problem and how it relates to what our organization is doing.

[55:53] And like, I mean, there’s so many other things that have to be connected that it’s. I think it’s wrong to just view it as AI did it all and we were completely unnecessary, you know?

Ryan:

[56:04] Yeah. The next one I was going to ask you was, you know, three years from now, will AI replace junior software engineers or what junior software engineers do today?

Anders:

[56:13] Well, if it does, then how do we ever get senior software engineers? Right? I mean, it’s just like, I don’t think so. Well, I’m not. Unless you also believe that you will be able to do your business three years later than that without any senior software engineers.

Ryan:

[56:30] Right.

Anders:

[56:30] Because where are they going to come from you got to train them, I mean. But to me, I think maybe one thing that to some extent has happened is that for certain classes of programmers, the pyramid has narrowed at the bottom. There are fewer people coming in, and we are wanting them to advance higher up faster so that they can get to this more supervisory role. I think the craft of being a software engineer is definitely changing from your typing in lines of code to you’re having agents type in lines of code and you are reviewing the work of the agents.

[57:14] So you do more reviewing, less typing. Some people love that and really are fantastic at that workflow. But it’s a change in nature of what the job looks like as a programmer and this tool that you now have in a toolbox is having that impact. But it is but a tool and there are still programmers involved in the process that I firmly believe.

Ryan:

[57:42] It sounds like you enjoy typing out the code. Would you be less happy if five years from now, for 40, 50 years I have enjoyed typing out code?

Anders:

[57:48] I’m actually. And so I will continue to type certain parts of the code, but there are other parts of the code that I don’t particularly care to type. I don’t care to type in tests and follow all the rigor of the particular testing framework. Heck no. If I can farm that out to AI happy me, I do think reviewing has always been harder for me. It’s harder for me to spend time on reviewing other people’s code than it is writing the code.

[58:24] But I also think that over time we can make that process of reviewing code much more ergonomic than it is today. Right. I mean, often today you just get, here’s like a list of the files that were changed and here are the deltas. You figure it out. Right? I mean, AI could help us more there by explaining what the changes are and whatever. And so I think we’re going to get better at this. It’s going to get more interesting, but it will change the nature of, of the craft.

58:52 — The most technically challenging work

Ryan:

[58:52] You said that you’ve been writing code for 40, maybe 50 years. What is the hardest piece of code you’ve ever written? Or what’s the most technically challenging thing you’ve ever done?

Anders:

[59:06] There are so many things that in their time were challenging. I mean, this last project we worked on, we knew that the easy part was getting the native code that’s just like just move it to this other language. But then taming this beast called shared memory concurrency and getting the compiler to use as many CPUs as there are available on your box that is not a simple problem to solve in a compiler because we’re all taught to write sequential stuff, right?

[59:48] I mean, first you do this, then you this. But how do you do all of this at the same time and then share the data structures afterwards without anyone like accidentally modifying the other guy’s data structure? And you know, how do you, in the cases where you have to do that, how do you then synchronize it and avoid deadlocks and race conditions and whatever, Right? This, it was tricky. There were some good technical problems that we licked that I think we can be proud of, you know.

Ryan:

[01:00:13] But what about when hardware was more constrained earlier in your career? Is there any wacky thing you had to do to kind of, you know, make it work?

Anders:

[01:00:23] Oh, totally. I mean, when I started, it was a. Like being a programmer was a very, very different thing, right. I mean, I started out with, with 8 bit micros that had Microsoft Basic in ROM, right? And then the BASIC interpreter and you could buy these books and type in these Star wars games or whatever. They were all text, you know, there’s just scrolling and telling you there’s Klingons over in that quadrant, you know, and K4, you got whatever, right.

[01:00:55] But I got fascinated with understanding how it was all put together and quickly learned how to write assembly code. And Turbo Pascal, the first product I worked on was all written in Z80 assembly code. The compiler, the editor, the runtime library, everything was assembly and writing structured. A compiler in assembly code is like that. A lot of fiddling. And you were counting like, okay, I think we need to squeeze this into this EEPROM.

[01:01:30] And then there’s only 12k and I’m 20 bytes over budget here. Oh, but I can make this jump, this long jump instead. I could jump to this short jump and then jumps to that jump and then I could save one. That’s one bite saved. Okay. You know, moving right along and you would just like sitting there fiddling, you know, it was a craft. It was like woodworking almost. I mean, it was just so different from what we do now, right?

[01:01:57] Everything is now it’s bottomless pits of capacity and bottomless pits of expectation from users.

01:02:04 — Top book recommendation

Ryan:

[01:02:04] Right. Is there a top technical book recommendation you have for software engineers?

Anders:

[01:02:09] I usually recommend the same, but the one book that was like the IT book for me when I was younger, and it’s called Algorithms plus Data Structures Equals Programs by Niklaus Wirth, the inventor of Pascal and then later Modular and Oberon and whatever. And it’s a book that is light on math and Symbolism and rich in instructive examples and good explanations about how data structures work. I mean, that’s how I learned about hash tables, right?

[01:02:43] I mean, like, when you’re self taught, you don’t know about hash tables, you sort of know about linked lists, right? And fine. So in the original version of Turbo Pascal, all the symbol tables were just, well, they were just linked lists, you know, or whatever. And then of course, as you had many local variables, well, you’re going exponential in search time. And then I read about these hash tables and like, wow, what you mean I can just do this?

[01:03:11] And then it’s basically like linear lookup time and implemented and the compile went twice as fast. Right? Like, holy cow, that was useful reading. Do you know what I mean? So I was always like the engineer, I mean, understanding how to do error recovery. He explains that in how you construct a simple compiler. And then like, you know, and it was, for me, a great book. And now it’s actually like, I mean, it’s just a big PDF, you can download it out there.

[01:03:46] It’s out of print since 40, 30 years. Yeah.

01:03:50 — Advice for his younger self

Ryan:

[01:03:50] Last question for you is, with all the experience that you have now, if you go back to yourself when you just entered the industry and give yourself some advice, what would you say?

Anders:

[01:04:01] Well, a couple of things. Maybe like we talked about being a team player, you know, I would have probably tried to educate myself a bit more about that to begin with. I think also one thing in retrospect is like, don’t let people tell you that it can’t be done. When they tell you it can’t be done, it’s because they can’t do it. That doesn’t mean that you couldn’t possibly do it. Do you know what I mean?

[01:04:29] So, so don’t let that discourage you.

Ryan:

[01:04:31] Is there a project where you. Someone said you couldn’t do it and then you did it and that’s how you.

Anders:

[01:04:38] Well, I think the first thing I worked on, like Turbo Pascal, people were telling me, whenever we told them, here’s what we have, they said, that can’t be done. That’s like, nah, you guys are beautiful. That’s like not possible, you know? Well, it was and I didn’t know that it wasn’t possible.

Ryan:

[01:04:55] Right, awesome. Well, thank you for your time. I really appreciate it. Anders.

Anders:

[01:04:58] You’re welcome. No, this is a lot of fun.

More recently, frontier labs like OpenAI have been generating massive candidate proofs to unsolved problems in frontier math (e.g. OpenAI recently released these 10 advances). Lean plays a critical role in formally verifying these proofs.

I wanted to learn more about Lean so I talked with the creator, Leonardo de Moura recently. He’s also a key scientist at AWS for their neurosymbolic AI initiatives, bringing Lean and formal verification together to prove agentic AI systems correct. He explained how Lean works and why LLMs plus Lean will fundamentally change how we write software and do math. Hope you enjoy this episode!

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:28 - How formal verification works

05:21 - A new way of writing software

13:15 - Proof assistants vs programming languages

21:06 - How Lean has assisted in mathematical breakthroughs

32:03 - When is it worth formalizing software

33:29 - How Lean will impact handwritten math

38:55 - The Z3 theorem prover project he started

45:44 - The most technically challenging work of his career

51:10 - Lean vs its competitors

01:00:37 - The future of Lean

01:04:10 - Technical book recommendations

01:06:15 - Advice for his younger self

Transcript

00:28 — How formal verification works

Ryan:

[00:28] There’s this famous Dijkstra quote I wanted to start the conversation with. It’s that program testing can be used to show the presence of bugs, but never to show their absence. And my understanding is that Lean and formalizing proofs can be used to show the absence of bugs. And so in your words, what is Lean and how do people use it to show bugs can’t occur in programs?

Leo:

[00:59] Lean is a programming language. You can write code, but you can also write proofs. You can reason about your code. You can write state properties about your code and prove them. Lean gives you machine-checkable proofs. You can check your proofs and get absolute assurance they are correct. You have many checkers, independent checkers, but you should view Lean as a platform. You can write code, you can write properties about your code, and you can prove them.

Ryan:

[01:30] So could you give a concrete example? Because when I think of a proof, I think of what I learned in math. But then how do you couple that with the software that we write?

Leo:

[01:42] Yeah, it’s a great question. It’s not that different from proof. Lean is actually very popular for math, but for software verification, there are two very different use cases. You can reason about Lean programs. Lean is a programming language. You can write programs in Lean itself. Then a Lean program is not that different from a definition you have in math. The techniques are very similar. But if you want to verify programs written in a different programming language, there are basically two different approaches.

[02:20] One of them, they translate, called shallow embedding. They translate for Rust. This happens today. We have a tool called Aeneas that maps Rust into Lean, and you can verify the Lean translation. There’s another technique called deep embedding, where you have the semantics. You write a semantics of the programming language of C in. And now you have a data structure that represents a C program, and you can state properties about it, almost like your programs become Lean objects that you can reason about.

Ryan:

[02:58] To make it really concrete, to give someone a sense of, here’s this thing I want to prove about a simple C program. Maybe no buffer overrun or something like that. What’s the step by step where we could use Lean to prove that?

Leo:

[03:13] Yeah, yeah. Let’s get an array. You’re trying to access an array in C. You want to make sure the index is in bounds. You’re not accessing elements that your array, for example, has 10 elements. You’re not trying to access element 11, right? Basically, you can write that. You can write something that says the value of i at this point in your program is going to be greater than or equal to 0 and less than 10.

[03:44] You can write that as a mathematical statement. Another way to view it is that if you can express in math what you care about in your program, you can verify using Lean. That’s another way to view it.

Ryan:

[04:02] So I have my C source files, and then somehow there’s an equivalent Lean proof that’s almost like metadata on top of the C program.

Leo:

[04:11] Yes.

Ryan:

[04:12] And that’s a line-by-line proof. And Lean will go and check.

Leo:

[04:16] Exactly. People will build automation for automating the process. They’re going to use techniques like Hoare triples, that says like we have a precondition, some mathematical facts that should be true before executing that statement, the statement and what is true after. Right. And they will have a lot of automation to process makes your proof modular. Right. I mean, complexity is a challenge in software verification.

[04:48] Handling the complexity is a big deal. And all these frameworks for verifying programs, they are trying to manage the complexity, make your proofs modular, even if AI. Now AI can prove things automatically for us, but they have to be modular, the proofs, if you want them to scale.

Ryan:

[05:08] And what you’re saying sounds similar to software, where you have to write it cleanly. It needs to be easy to edit and reason about. So it’s almost like a second software layer on top of the software.

05:21 — A new way of writing software

Leo:

[05:21] Yes, yes, you can view it this way. You can also flip it and imagine a future where you’re writing what you want mathematically, precisely, and AI synthesizing the code and a proof that the code that was synthesized meets your specification. Right.

Ryan:

[05:42] Oh, interesting. So you could start by writing what you want to be true and then ask the AI, please.

[05:50] And AI is going to just go and hammer at it until the Lean proof says you’re good.

Leo:

[05:55] Yes. It feels like science fiction. Six months ago, I would say this is science fiction. But for example, now a colleague of mine, Kim Morrison, a few weeks ago, she started a project I thought was, six months ago, I would say it’s not possible at all. She said, we have zlib, this compression library written in C. She says she creates a very complicated prompt for AI saying I want you to translate to Lean.

[06:28] Ensure the Lean version passes the test suites for zlib. Then I want you to prove that if you compress data and you decompress, you get the original data back. It’s a really strong property and, believe it or not, after one week, she succeeded doing the whole thing, and now it’s just asking to optimize the code. But you cannot break the proofs. You have to keep still proved all the properties you care about.

[07:02] I mean compressing and decompressing, getting the data back is a really important property for a compression engine. Right? Yeah, this is rich now. I mean, surreal.

Ryan:

[07:16] I mean, it’s crazy. And I hear in the industry, a lot of people use a really comprehensive test suite coupled with AI to do some really amazing rewrites because they have some more confidence that the rewrite is accurate and the AI can check itself. And it sounds like a specification is even better than a comprehensive test suite.

Leo:

[07:45] Yes, because your quote from Dijkstra captures it perfectly, right? With a test suite, you can show the presence of bugs, but not their absence. It’s almost like with a good test suite, you may say, well, probably there are no bugs here, but you may have a really corner case that’s not covered by your test suite. But with a proof, you’re covering all possible cases. So property-based testing is really popular now.

[08:19] People are writing properties. They want to ensure they are true, but they are checking with testing. But now we can prove them. And you say, look, there’s no point testing anymore.

Ryan:

[08:32] It seems like having a well-written specification is a superset of a test suite. But in terms of the human labor required to create a reasonable test suite versus a reasonable specification, how much more work is it to come up with a great specification? It varies a lot by the program.

Leo:

[09:04] In many cases, it’s not uncommon for someone to start developing a piece of software, and they don’t know exactly what the spec is. But properties are usually vaguely in your mind. Another thing that I tell people to keep in mind is that an inefficient program can be viewed as a specification. Usually, writing an inefficient program is way easier than writing the super efficient one that has many clever tricks.

[09:35] You can write a very, this is what I want, in a very naive way. And you ask the AI, look, generate the efficient version and optimize and prove that equivalence to my inefficient one. There are many scenarios. I mean, I will not say this. Specifications are always easy to come up with. But properties, usually the developers have good ideas about properties they care about. An inefficient program is a spec, right?

[10:08] You can view it as a specification, and the technology form of verification complements testing, right? I think your quote from Dijkstra captures...

Ryan:

[10:19] Perfectly, and I think I saw this on Twitter because Jane Street was more heavily investing in formal verification, and I read their post, and they talked about this. I think it was seL4 or some software that was entirely formally verified.

Leo:

[10:37] Yes.

Ryan:

[10:38] And the main drawback to why it wasn’t. You know how much more time would it take writing a program versus verifying it?

Leo:

[10:48] Your example, seL4, is a great example. This was a major milestone. It’s a microkernel they verified manually before AI. This project was done before AI was a big deal, and the cost is super expensive, right? At AWS, we have been using formal verification for decades, but only for the super-safe, critical components because it’s expensive. Until now, right? With AI, it changes the game.

[11:21] You have to come up with a spec. But this is not the most painful part. The most painful part is developing the proofs manually. If you have tools before AI and maintain the proofs as you change the code, it’s messing you up. I’ve seen people complaining that, “Oh, I changed the program. Right now I have a bunch of failures in my test suites, and I have to patch them one by one.” Imagine with proofs, it’s the same process.

[11:50] You have to fix the proofs. Sometimes you don’t remember anymore why. What’s the story behind this proof? It’s a lot. But AI is extremely good at proving, writing formal proofs, maintaining formal proofs. For example, yesterday I was changing something. I want to modify some proofs for technical reasons. I didn’t even know what the proofs were about. Someone else wrote. Then I said, look, I want you to—I asked AI to rewrite these proofs without using this feature because I’m going to change it.

[12:31] I don’t want to break the libraries instantly. It came up with the new proofs for me. I mean, it’s really good. And this is crucial for making formal verification mainstream because otherwise maintaining the proofs was almost like if your program took X amount of time to do the formal verification in the past, it would take 10x. That would be normal. But imagine if your program is changing. That’s something that’s really common now.

[13:05] You have to keep maintaining the proofs too. It’s a lot of work. But AI eliminates this pain for us.

13:15 — Proof assistants vs programming languages

Ryan:

[13:15] You mentioned that Lean is a proof assistant, and then you also said it’s a programming language. Is that typical for proof assistants to be both a programming language and a proof assistant?

Leo:

[13:30] Some of them, especially the ones that are based on dependent type theory, they are like Rocq and Lean — programming languages and proof assistants, right? You can write definitions like when you’re defining concepts in math. But some of these definitions can be programs, and you have types, you have structures. It’s a programming language, but it’s in the family of what’s called functional programming languages.

[14:01] I mean, is it a specific kind of programming language for people that are familiar with programming languages like Haskell? Lean is close to Haskell, but with the support for proofs. That’s a way to view Lean.

Ryan:

[14:16] Are there major use cases where people use it as a programming language but not as a proof assistant?

Leo:

[14:21] Well, the first big use case is Lean is implemented in Lean. We have many of our tooling implemented in Lean. Like the documentation authoring system called Verso is implemented in Lean. The build system that’s called Lake, like Lean make, is implemented in Lean. At AWS, we have a compiler for AI accelerators. It’s half a million lines of Lean and using Lean as a programming language. They’re proving some properties about the program using Lean.

[14:54] But the main goal is to use Lean as a programming language. In this project, the proofs are like a bonus that you can get the proofs and find problems in the design.

Ryan:

[15:06] I think most people are familiar with programming languages and the toolchains they have. But what are all the major components that you would need for a proof assistant?

Leo:

[15:19] It is not that different. I mean, if you’re used to modern programming languages like Rust, the tooling, for example, Lake is our Cargo, right? I mean, you’re going to open Visual Studio Code the same way. And I want to get all the IntelliSense. One big difference is that we have something called the Infoview in Lean. Your screen usually is going to be split in two. You have your file on the right-hand side, you have the Infoview that tells you information about your proofs, about your code.

[15:55] It’s giving you constant feedback about your development. That’s basically the main difference. But the tooling, VS Code, everything works the same way.

Ryan:

[16:06] I mean, it seems like the programming language is the fundamental layer, and then there’s some additional layer on top that keeps track of that stuff.

Leo:

[16:14] Good question. In Lean you have definitions that show your program, but you have theorem statements. You’re going to say, for example, factorial is always greater than or equal to zero, or something like that. Or if you add two even numbers, you get an even number. You can write statements like that, and immediately you can write actually a program that’s the proof. But most people don’t do that. They go into something called tactic mode.

[16:47] You can view it as a domain-specific language for writing proofs. When you write “by,” it switches to this domain-specific language, and you have steps like “simplify my goal,” the state of my proof. You can say, “Oh, apply this rewriting step.” Apply, for example, we know that x + 0 equals x. You can ask Lean to apply this rewriting, and you’re going to see in the Infoview the state of the proof changing. You get immediate feedback, and you get this feeling that you said.

[17:21] You keep telling it, applying transformations to your proof step by step. You can see what’s happening until you get no goals left. You are done; the proof is complete. And some people view this process as a game. I have users that told me, “You built my favorite computer game.” That’s funny.

Ryan:

[17:46] Is Lean itself verified in Lean?

Leo:

[17:49] Lean is a massive program. You only have to trust the kernel, where the proofs are checked. Lean itself is the kind of program that, because there are so many new things we are adding, it’s not even clear what the specification is. For example, what is the specification of a simplifier? You can write general ideas, but users want to be able to customize the behavior. They keep asking; they keep changing the specification all the time.

[18:18] I want this, I want that. No, at this knob here. So it’s really hard to have a full specification of Lean, but the kernel is possible to have a specification. We have a kernel. The kernel that comes with Lean is not verified. But there are other kernels that you can use. One of them is implemented by Mario Carneiro. It’s called Lean for Lean, and it’s implemented in Lean. And he’s verifying, it’s proving that this kernel has been verified with respect to the semantics of Lean.

[18:52] This is a cool project, but for us, having multiple kernels is the best way to ensure that your results are correct. Some users implement their own kernels. We have kernels implemented in Rust in different programming languages.

Ryan:

[19:10] And when you say kernel, what’s the responsibility, or what’s the input and output of that portion?

Leo:

[19:16] Yes, in Lean, proof checking is type checking. These kernels, they are type checking your programs. Basically, you can export your Lean developments. You get a big blob, and you read this blob, and they’re going to check it. When you say we have a proofing link, basically you have a term that has a type, and you’re checking if the type of this term matches the type that you claim it has. For example, the example for the even numbers, this is a typing link saying that the sum of two even numbers is an even number.

[19:57] You can view that it is exactly a typing link. And the proof, what the kernel is checking is whether the type of the proof matches the type you claim this term has. The kernel will check, you do this type checking. The kernels vary between high-performance kernel. It’s like 5,000 lines of code. I mean, the goal of the kernel should be something you can write yourself. Of course, sometimes people put bells and whistles. One thing concerns people have is like, okay, but how do I know?

[20:39] Suppose that I wrote Fermat’s Last Theorem in Lean. How do you know that when you export it, it’s really Fermat’s Last Theorem? It’s not 2 plus 3 equals 4. I mean, and people, some external kernels, they write print printers. I mean, it will print the statements that have been proved, all the dependencies. You can have all these fancy tools to make sure you’re not being misled.

21:06 — How Lean has assisted in mathematical breakthroughs

Ryan:

[21:06] Lean, obviously, it’s so powerful, and I see on social media all these amazing results from formal verification. What are the top ones that you think of, or top examples more recently, that have impressed you that Lean was able to accomplish?

Leo:

[21:25] Well, there are so many. I mean, I thought it was impossible. For example, getting a gold medal in the International Mathematical Olympiad a few years ago, everybody thought it was impossible. Now everybody use it as a benchmark of an easy problem. They say, oh, this is like an IMO problem. I mean, this is easy, but it’s not. I mean, these are really challenging problems. The other conjectures that people close using AI with Lean also impresses me.

[21:59] There is this unit distance conjecture for others. First, OpenAI proved using formal was not formal. And we have a system now in Lean. It’s a website where we call Lean Eval, where we collect challenges. The same Kim Morrison saw this proof OpenAI, and she put on Lean Eval a challenge saying, okay, I want to see someone formalizing. We knew it was huge to formalize. It’s serious math. It depends on.

[22:38] And Boris Alexeev from OpenAI, he did, he made a 1 million line proof for formal proofing Lean for this conjecture. We estimate something though that background math that is needed for the proof. We knew it would take months, I mean for experts to do by hand.

Ryan:

[22:58] I mean, how long did it take in that case? Like the time from when the proof came out to when the challenge was solved on Lean.

Leo:

[23:06] I think it was one month, yeah. And after Kim was a few, I think less than two weeks. After Kim puts as a challenge only involved, it took I think two weeks to get the, or less. I mean, that’s insane. Yes. Yeah, yeah.

Ryan:

[23:24] We talked about verifying programs, but also there’s using it just directly for mathematics, like in this case. How popular is Lean in terms of when you look at the users of Lean? What percent are using it for software engineering? What percent are using it more for just direct math?

Leo:

[23:44] Well, historically Lean got popular first with math, right? I mean, with the beginning of the Lean mathematical library in 2017, we had a big project called Liquid Tensor Experiment. It started beginning of 2020. It was a big deal because it was to verify a result from a Fields Medalist, Peter Scholze. It was a result he was unsure about. He has not published it. He felt like this was one of the most important results in his career.

[24:22] He wanted to be sure it was correct. It was done manually. The verification was a big deal because the team that formalized it, led by Johan Commelin, not only formalized the results without fully understanding it, they did not fully understand the proof. But having this Infoview helped guide them. Step by step, they formalized and simplified the proof without fully understanding the proof. It’s mind boggling.

[24:54] How can you simplify a proof from one of the greatest living mathematicians without fully understanding it? I mean, but they managed to simplify. It’s almost like when people do refactoring code, you start changing the code. It’s faster now, but the programmer doesn’t really know why it felt like that. It’s like you have a gut feeling, I mean, that you’re going in the right direction. And this, for us at the time, lots of people got excited about Lean, the math community, because of this project. It’s shown that it’s not about verifying, but enabling people to work together in large numbers.

[25:36] Because you can trust, you don’t need to trust someone else’s proof. Right. They can fill holes for you. This was, I mean, what attracts a lot of attention from the math community. Then came Terence Tao. He starts using Lean after this project. He has really cool projects with and without AI. He got addicted, actually. I think the first time he used it, he said, “I don’t think I’m going to do it again.” The formal proof, one week later he had another project using Lean, and he did a new result he had.

Ryan:

[26:13] When you say addicted, you mean because of that game, that completion engine.

Leo:

[26:17] Yeah. Some people, I feel, we feel like when I talk to professors that use Lean for teaching, they tell me that the class is more or less split. Some people love it, some people don’t like it. But people that like problem solving, people that get medals in the IMO, they love Lean because you get this excitement of solving. It’s like solving millions of really hard Sudoku problems, right? And you can keep solving one, and it’s easy to get.

[26:49] I mean, I’m a Lean developer, not a Lean user. But when you’re developing Lean, I’m coding in Lean, and sometimes I have proved things. It’s really easy to get addicted. You get lost proving things. You get this buzz every time you prove something.

Ryan:

[27:07] You mentioned the IMO gold medals. How is Lean used in that kind of... I think maybe you’re referring to AlphaProof by DeepMind, or maybe something else.

Leo:

[27:17] Yes, DeepMind was. They got in 2024 was a big surprise. In 2024 they got a silver medal. And now we have gold medals from startups like Harmonic. ByteDance got a medal. I never imagined. ByteDance. They’re behind TikTok. Right. I didn’t even know they care about IMO math, but they have a 400 math team. They got medals. Also their prover is really good.

Ryan:

[27:48] So how’s it work? Let’s say, I mean, there’s a series of math problems. Lean is just used for verification, right? So I imagine there’s other components there.

Leo:

[27:57] Yeah, there’s the AI. You can view it like we have Google. That was very popular with AI. The AI is playing the game. I told you that. Many people see Lean, I guess. It’s the same. The AI is viewing Lean, I guess. They have the statements of what you want to prove. You have the by keywords. Now you have a blank field. Make sure that you have no goals left. It keeps applying steps in this game and seeing the state of the board.

[28:30] That’s the Infoview changing. In the AI, they use reinforcement learning to try to get to no goals left. It’s a single-player game. Some people play together these days, but the AI is learning to play the game.

Ryan:

[28:49] So before we were talking about that game, it kind of starts with the specification. So in that case, then the problem is kind of the specification, and then it hammers over the problem.

Leo:

[29:00] Yeah. You have basically, for each problem in the International Mathematical Olympiad, someone translates the statements to Lean. It’s super important to have the mathematical library because you want to be able to talk about the problems, right? For example, suppose the problem uses the real numbers. You need a definition in Lean, and we have it inside of mathlib, the Lean mathematical library. The first thing you have to do is be able to write the problems in Lean.

[29:27] And this now because of mathlib, it’s the easy part. And after that you have to provide the proofs. I mean, sometimes some problems you have to come up with a definition to some objects you have to create that has some property. But yeah, that’s how it is.

Ryan:

[29:47] I remember you said one of the first use cases of Lean was this Fields Medalist had this novel mathematics, and then we used Lean to verify it. But can Lean be used with LLMs to generate novel mathematics, or just verify existing?

Leo:

[30:08] It’s a good question. I mean, we don’t see lots of evidence. We see no evidence it can find novel proofs, right? But coming up with new mathematical concepts is still at the limits, right? I mean, right now in this Lean Eval, we have challenges where the AI has to come up with the objects themselves, right? I mean, but this is. People will keep investing in this area. I would not bet against AI here.

[30:42] I mean, but right now we don’t have evidence they can come up with new math.

Ryan:

[31:34] When I see on Twitter this major conjecture, they made headway on it. It’s that they made headway on confirming something or disproving.

Leo:

[31:43] They also have these 1 million lines. They showed the conjecture was false. They have a proof showing that it’s false, but it’s a formal proof. They did not come up with a new theory or anything like that. They are coming up with a proof, right?

32:03 — When is it worth formalizing software

Ryan:

[32:03] And at what point would you say someone should evaluate formalizing something in Lean?

Leo:

[32:12] I think if it’s safety-critical or if you don’t understand it really well, I mean this is an important part. I don’t really understand. Anybody that went through the process of formalizing something understands the subject way better after that. I almost feel like I remember when I was in college, people would say, wow, after I implemented this algorithm, now I understand it much better. The next level is that you implement the algorithm, you prove the properties you expect, your level of understanding grows.

[32:52] Another cool thing is that it enables you to be much more bold on your optimizations, because sometimes I’ve seen that all the time. People fear implementing optimization because they don’t really understand why the piece of software works. They feel like if I do, that still works and it’s faster. But they are not confident with proofs. You eliminate this discomfort, right? You can prove it again, or the AI can prove it for you or find a counterexample.

[33:26] They are good at both things.

33:29 — How Lean will impact handwritten math

Ryan:

[33:29] But if you were to speculate or draw into the future, maybe three to five years from now, if the cost of formalizing things goes down, how does that change software? How does that change handwritten math?

Leo:

[33:46] Oh, I think it would change dramatically. We have to keep in mind the big labs, they only started training for formal verification and Lean very recently. Seriously, before that, it was like, oh, is in the data sets. I mean, you don’t really have the reinforcement learning pipelines to optimize the behavior we see today. That is already amazing. Will get way better in the future. The costs will reduce. Programming languages like Lean and Rocq will become more mainstream.

[34:23] Because of that, many people are not so, in the past, people say, “Oh, functional programming, I don’t like it.” But if I’m not the one that’s writing most of the code anyway, it doesn’t really matter. What matters? The specification level, right? It doesn’t really matter how the code has been written. Yeah, I think you change a lot because of that. At least that’s the direction we are pushing Lean to.

Ryan:

[34:53] What about, let’s say, 10 years from now? Lean is, everything’s going really well with Lean. Could that be the end of handwritten math or handwritten proofs?

Leo:

[35:07] I think there will always be aspects that are handwritten. Some people like to make a proof look. They want to use the proof as an artifact. You communicate ideas to others. I can’t imagine there will always be people polishing, making them super easy to understand for another human to communicate ideas to other people. There will always be people like that. The same way today we have people that, we have machines that build furniture, but people, they like to create them by hand and polish them, make them perfect.

[35:51] This will always exist, but it will be a mixture. I will be surprised if there is someone who’s completely AI is not in their workflow somehow. Right. I mean, there’ll be hybrids, many hybrids. Some people feel uncomfortable about this future, but for me, it’s super exciting because I view developing software as a super painful process. And with AI, it’s crazy how it brings you awareness of how many steps are just repetitive and there’s no creativity, or just patching things.

[36:37] And AI automates and removes lots of this pain, right? I mean, I cannot go back to that. I’m looking forward to this future you describe.

Ryan:

[36:50] Yeah, I guess the thing that gives people. I mean, I’m guessing the discomfort is the worry that if it kept going, then we need less mathematicians or less computer scientists or something like that.

Leo:

[37:05] People don’t see that AI can bring more people. There’s also the specification. I mean, I see people saying, oh, we are going to leave AI, we come up with new math. But if there’s no connection to our world, this is some alien thing that’s going by itself. You need an interface, for example. We want to build programs because we want to accomplish something. This something, whatever it is, has a specification.

[37:39] There will always be humans in the loop saying this is what we know, this is what we want, writing this interface, interacting with the AI. The AI will have math libraries and everything to prove things about these programs we are writing, these artifacts, whatever we are trying to build. But we have to be able to interact with these libraries. We have to understand the abstractions that are there.

[38:12] I don’t see humans being eliminated. We are always going to be there. We are in the interface, we are telling them what we want. Specifications will be there. I can see people always writing code. Another thing is, a lot of people like to write this, and love coding. My interpretation is they love to write prototypes. This is fun. This is the fun part, to try a new idea. But to transform it into a product is never fun.

[38:45] I can tell you it’s never fun. And I can take over these parts. Nobody really likes doing outside of Lean.

38:55 — The Z3 theorem prover project he started

Ryan:

[38:55] I know you worked on the Z3 SMT solver, and that sounds like a really difficult thing to build. So first, what is that solver in your words? And yeah, how does it differ from a SAT solver?

Leo:

[39:10] Yeah, I started this really long time ago. It’s going to be, yeah, 20 years ago I started Z3, I mean when I joined Microsoft Research. Yeah, Z3 is an SMT solver. Like I said, solver. But you have background theories, like you have support for arithmetic, for arrays. These are not random choices, right? This is because we use it for doing test case generation, software verification. Z3 is fully automated. It’s a push button.

[39:45] Although Lean and Z3 are called theorem provers, they are completely different beasts. Z3 is fully automatic. Lean is interactive. It has automation, but it’s interactive. Z3 is not a programming language, it’s more like a constraint solver. It turns out you can prove simple things about it. You cannot do advanced math with abstract math. You can solve constraints with Z3.

Ryan:

[40:16] What’s an example of the inputs to this SMT solver, and what do you get out of it?

Leo:

[40:22] Oh, I can give you one. I mean that’s even in the Z3 manual. You can encode a Sudoku problem as a set of constraints, and you can ask Z3 to solve it. It will give you back the answer instantaneously. For real applications, Z3 was used very successfully for finding bugs in software. People would convert. For example, suppose that you have a path in your code. You know that has a security vulnerability, but you don’t know which inputs to the program allow you to execute this path.

[40:58] You can convert that into a set of constraints that you send to Z3, and it will say unsatisfiable. It means it’s impossible to execute this path and you are happy. Or it gives you back an example saying, look, with these inputs you’re going to be able to do it. And people use it for doing software verification. But because the problem becomes undecidable at that level, you have many universal quantifiers for stating properties about your program, your pre- and postconditions.

[41:35] The solver has heuristics, and this was all before AI. The heuristics were hand coded. They would always fail. And for simple things, people would be very happy with the fact that Z3 is push button. But when the property is not trivial, they would come back saying, “Come on, I know the proof. I mean, why can’t Z3 find it?” That’s why Lean started. I started Lean to make sure that we would have a system that’s really good for software verification, right?

[42:07] Z3 was successful for finding bugs, but not so much for software, for proving the absence of bugs. It was never super successful there. But Lean was born to fill this gap.

Ryan:

[42:25] You said undecidable, but in practice, in the real world, if you run it, does it typically terminate?

Leo:

[42:32] Yeah, great question. Z3 goes the whole complexity ladder, right? You have SAT solvers, you have NP-complete, PSPACE-complete, EXPTIME-complete, you have the whole two undecidable rights. I mean, surprisingly, even for SAT solvers, you can write really tiny SAT problems that are really hard to solve. No SAT solver will solve them. But in practice, the problems we get for hardware verification, especially if you bound everything, say, oh, I’m trying to look for a bug in the first 10 steps, right?

[43:13] Everything’s bounded. You’re not trying to prove, but you’re trying to capture a class, like a space of scenarios, right? They are very effective there. I mean, I think the lesson there is that programs and hardware, they are not correct for esoteric reasons, right? They are correct because for very simple reasons. I mean, that’s why these tools are super effective there. Yeah, but when you get too undecidable and you’re trying to prove, even if the property is not trivial there, I mean, it runs out of steam.

[43:56] I mean, and they time out frequently. And sometimes there is a colleague of mine here at Amazon, Iminator chose the name proof instability because sometimes if you change the problem, you just flip. You have A and B, you write B and A, where B and A are complicated formulas, you may fail to prove. And when she was just trying to maintain things, proofs would break if using this kind of technology.

[44:28] But with Lean, she switches to Lean, and it’s super smooth, right? Because you’re controlling the proof in the Lean case.

Ryan:

[44:40] Why is it so much more efficient?

Leo:

[44:43] Your proof is basically, you can view the sequence of steps for solving the problem. In Z3, you can view that you have only one proof step, solve, right? I mean, you’re saying you have options to solve goals, but you have very little. You cannot influence what Z3 is going to do. It’s much harder to influence this kind of system. In Lean, if you want to give a step, super detailed, step-by-step proof, you can. You can use proof automation like is available in Z3, but you can also break it down step by step.

[45:25] And the fact you can do that, humans can do it. But the happy surprise is that AI can do it because now you can say step by step why something is true. The AI can convince Lean that it can provide a proof.

45:44 — The most technically challenging work of his career

Ryan:

[45:44] When you were working on Z3 and Lean, what was the most technically challenging part that you had to build for either project?

Leo:

[45:55] I underestimated how much harder Lean is in comparison to Z3. It’s always a magnitude harder. I mean, I talked to many colleagues about that, why I felt like this Lean was so much harder. I think it’s the surface. The interface for humans is way fuzzier. You have a defined language for it. It’s called SMT-LIB. It’s a very simple language. It’s not meant for humans; it’s meant for tools. I mean, Z3 is used as the backend of many different tools.

[46:32] Someone generates some program generating input for Z3, and people expect a counterexample or saying it’s impossible, it’s unsatisfiable to come up with a counterexample. The interface is really, really simple, right? You can view Z3 as a command-line tool that you pass this file on this very low-level language that’s super easy to parse, and you come back with yes or no. And Lean is a programming language.

[47:04] You have libraries, you have mechanisms, you have interactivity, you have user interface, you have LSP, you have build system, you have GitHub. You have, it is so vast. That’s another challenging part for me. As I mentioned, Z3 was a backend. The Z3 users are very sophisticated software developers, people that speak the same language I speak. It’s way easier to talk to people that speak the same language.

[47:41] With Lean, it’s completely different. The first users are all math people. They have a completely different background, different expectations, different everything, and different community. And then you have people that want to choose Lean as a programming language. I’m not a programming language person. My background is automated reasoning. And yeah, it’s a different language, different expectations.

Ryan:

[48:11] Was there a singular component that was just really technically challenging?

Leo:

[48:18] I told you that Lean‘s implemented in Lean. Of course, it was not always like that, right? I mean, it had to be implemented in something else at the beginning. The switch from originally was C++. The switch from C++ to Lean was extremely painful. Really? Really. I remember I literally wanted to cry when I managed to compile Lean 4. I was just... Sebastian Ulrich and I at the time were building Lean 4 together.

[48:56] But this was before we had a nonprofit for Lean. I remember calling him and I said, wow, man, insane. Say, are you not excited? He said, yes, I am. I mean, super excited.

Ryan:

[49:13] What made that switch hard?

Leo:

[49:16] The first thing is, imagine you’re going to implement the language in itself. The first thing you want is to minimize the number of features as much as possible, is that you want to implement Lean using bare-bones features. Because you’re going to have to be able to compile it with itself then. Now you have like 100,000 lines, more or less. I don’t know the exact number, but it was around 100,000 lines.

[49:48] And you start trying to compile, you fail the first. You can’t even compile the first file in the pipeline, the one that more than 1,000, and the first one fails, then you fix the bug, you can compile the first one, then you can compile the second, and you keep moving, and you are always finding discrepancies between the new and the old one. And you’re trying to reconcile, make things easier for the new one because you want to replace the old one.

[50:22] This process and Lean is a complicated language because of these dependent type theory and so on. The proofs, for example, when you’re implementing Lean, you still need some proofs there. There are some basic proofs you need, but you have to construct these proofs with no interactivity, nothing. Bare bones. You have to provide the proof too. It’s almost like programming in assembly. The proof. This was also super painful.

[50:55] Thank God. Yeah. But it took. Yeah. Many people thought we were going to fail. Sebastian, I would not be able to do it.

Ryan:

[51:05] 100,000 lines is a lot, like all human written.

Leo:

[51:07] Yes, all human written. Yeah.

51:10 — Lean vs its competitors

Ryan:

[51:10] We talked a lot about Lean, and I know there are competitors to Lean. What are the pros and cons of the different proof assistants? In what scenarios is one preferred over the others?

Leo:

[51:23] For instance, the first disclaimer: I’m a completely biased person here, right? But I can tell you what users tell me about. For example, one thing users love is the fact that Lean is super extensible. Because Lean is implemented in Lean, you can add extensions. So imagine you’re doing your math proof. In the middle of this math proof, you say, oh, I want this fancy automation here. You can write in the same file, or the AI can write for you, the extension for automating a proof.

[51:57] And it will do it. I mean, even the AIs, they know about the fact that Lean is extensible. If I ask the AI to isolate an issue in Lean, I give the AI a Lean file. It will start writing a Lean metaprogram, a program about Lean tunnels to validate the conjecture it has about why it doesn’t work. It’s crazy. It keeps writing Lean meta extension there. The fact that Lean‘s extension is popular, really popular with so many people.

[52:33] For example, there is Patrick Massot. He’s a French mathematician. He wrote something called Lean Verbose. Lean Verbose you can use for teaching. We have this language for writing the proofs, but he made the language look like English, and he has the Infoview now. You can click there. It gives you suggestions about the next move that’s written in structured English, like you find in a textbook.

[53:07] You see, the student has a really good idea on how to write informal math proofs. And he did that without asking me any questions. I mean, all this stuff, the point and click, the new language, the new interactivity, he did all by himself. He’s not a computer scientist. He has a math degree and he does all this stuff. And it’s for English and French. I mean, you can choose, you can write the proofs in French and it looks like textbook proof.

[53:41] I mean, there are people that write visualizations. You’re trying to prove something about a math object. You can write extensions that visualize these objects in your Infoview. The people that write new domain-specific languages embedded in Lean for different purposes. For example, for protocol verification there is a language called Veil. It’s a Lean file. You open Veil, you feel like it’s a different system for protocol verification, but it’s just a Lean file with these extensions for protocol verification, the language for writing protocols in a very convenient way.

[54:25] These folks wrote the whole thing without ever talking to us. They all talked to us after they had done it, said, “Look, I want this part of Lean to be faster.” That was the only interaction we had. And so interactivity is a big deal. Another big deal now is the mathematical library. It’s vast. I mean, for stating problems, open conjectures, you need a library with the concepts to even state the problem.

[54:56] So Lean has a massive library and a massive community. The community also plays a big role. Before AI, I think now most people ask questions about Lean to AI. But in the past, people would go to the Lean Zulip channel, ask a question about Lean. They would get an answer in five minutes. People would say human beats AI. I mean, people would be writing answers instantaneously to your problems. The community played a big role.

[55:29] Another one was we listen to our users. I mean the math. I mean if you talk, for example, Jeremy Avigad was the first user. I mean he has math backgrounds. You ask him, look, he said, look, I could ask anything, any new feature, I would get back the same day. I mean fix the new feature same day. And this attracts people, right? I mean, because you’re making people improvements, making sure the system does what they want, they come back for more.

[56:10] I mean, this also has a huge impact in growing the community.

Ryan:

[56:16] When I was doing some research, there was this idea I think you mentioned in this conversation too. There’s this dependent type theory proof assistant, and then there’s higher-order logic. What is that difference there?

Leo:

[56:29] At the beginning when I started Lean, I won’t choose higher-order logic because it’s much easier to implement. I mean, dependent type theory is way harder. But the math community, I mean, Jeremy is the one that convinced me that I would never be able to attract serious mathematicians like Fields Medal-level math people with higher-order logic. Right? His point is that higher-order logic is good for concrete math.

[57:01] But if you want to talk about abstract objects, dependent type theory is way more powerful, and it’s beautiful. It’s easy to explain. Why is it called dependent? For example, you can have a structure in Lean when you have several fields, like X and Y are natural numbers or integers, let’s say integers. You can have another field. The type of the field is a proof that X is greater than Y. The type of these fields is X.

[57:32] Let’s call it greater colon. You say X greater than Y. The type depends on the value of the previous fields. That’s why it’s called dependent type theory. You can have types that depend on the values of other parameters, other fields, and so on. But the beautiful thing about that is that you have this very small language that is so expressive. For example, this field, now that’s a proof. You have to provide a proof.

[58:05] You can view it as an invariant. I can only build elements of this type if I give the X and Y, like in other programming languages. But I have to give a proof that X is greater than Y. It’s impossible to construct elements without providing this evidence, right? You can view this as an invariant. You don’t have to invent invariants, right? The language is just the fact you have these dependencies; you can express them in the functions.

[58:37] You can have a function, for example, that says it takes X, a Y, and a proof that Y is different from zero, right? I mean, it’s impossible to call the function if you do not provide evidence that Y is different from zero. This was always cool, but in the past people would say, wow, providing these proofs is really annoying. But with AI now, the AI can synthesize the proofs for you, and it’s really cool.

Ryan:

[59:07] In higher-order logic, though, could you express the same?

Leo:

[59:10] No, no, that’s... You cannot. You don’t have that. You lose the dependencies. For example, one thing that you cannot do in higher-order logic in Lean. In serious math, people have a bunch of structures they manipulate. You have something, a field, I mean a ring, a group. You can write a function in Lean that takes a group and turns it into a new group, a new structure. You’re not manu.

[59:43] You don’t really care about the elements of the structure. You are viewing the structure as a first-class citizen. That’s something that dependent type theory can do easily; in higher-order logic, you have to play encoding tricks. It’s a mess. I mean, some people say, “Oh, it works for me.” None of the mathematicians agree with this statement. None. I mean, you talk to Terence Tao, to Alex Kontorovich, Jeremy Avigad, Kevin Buzzard, Patrick Massot, they would say, no, no, you have to do dependent type theory.

[01:00:18] I mean, that’s another example for me that listening to your users is important. If you want to appeal to this community, it’s totally okay to say I don’t care about this community. But if you care, listening to what they really want is important.

01:00:37 — The future of Lean

Ryan:

[01:00:37] So when we think about the future of Lean, I’m curious to hear your thoughts on where you think Lean is going, things you’re excited about in the future. What might it look like in a few years?

Leo:

[01:00:51] Yeah, I think we have these nonprofits behind Lean since 2023. I mean, Lean is 13 years old. The first 10 years was a such project, right? I mean, only when we got the nonprofits behind Lean that it became, you can view it as a product. You have a team of engineers, and we managed to do it because of the impact on math. But Sebastian Ullrich and I, we co-founded this nonprofit. What we are really excited about is Lean as a programming language.

[01:01:29] A programming language where you can prove things about your programs, right? That’s a direction we are pushing really hard. Lean 4. We are super grateful for AWS, Amazon. They’re making the largest donations so far to these nonprofits, where the goal is to accelerate this path. I mean, Lean is doing super well in the math path. But let’s make Lean a programming language, Lean a system for software verification, hardware verification.

[01:02:01] Let’s push to the extreme. Let’s give some love to these people, to this path that’s right. Now we do not really have funding to push seriously this path. That’s the nonprofits, right? For me to be in a world where you can reason about your code is part of my life. I’m not writing unit tests anymore. I’m writing properties and proving them. The AI is proving most of them. For me, this is the direction we are pushing hard.

[01:02:37] And one thing that people don’t realize is that when you have proofs, it enables optimizations for free. You can ask the, for example, today, if you ask the AI to optimize, you have to inspect the code to make sure no bugs were introduced in the process. But if the AI is telling you, look, I optimized it, it still computes the same thing. Here’s the proof. Game changer in my point of view.

Ryan:

[01:03:10] Yeah, I’ve heard multiple people say this decade will be the decade of formal verification of software. And yeah, maybe Lean will be a huge part of that.

Leo:

[01:03:23] Yeah, for sure. We’re super excited to make it happen. Scalability is super important, right? Because there is a big difference between math and software verification. In math, the statements are usually really tiny or small. I mean, Fermat’s Last Theorem is an example. I mean, super small. But the proof’s insanely cheap. For software verification, it’s the opposite, right? The statements are big.

[01:03:59] I mean, but the proofs are shallow. The reason why this is shallow, but you have to manipulate these big objects, right?

01:04:10 — Technical book recommendations

Ryan:

[01:04:10] So for someone who wants to learn more about formal verification or learn more about Lean, do you have a top technical book recommendation in the Lean websites?

Leo:

[01:04:18] I mean, we have several books there that introduce Lean Functional Programming, Lean Theorem Proving, Lean Mathematics, and Lean: The Mechanics of Proof is great for educational purposes. We have a collection of proofs. If people go to lean-lang.org, you find all these books there. But one thing I tell people these days is that learning Lean using AI is super efficient. I mean, you keep talking to AI in natural language, asking what do you want?

[01:05:03] Asking it to write examples. Many people split the screen in three now, right? We had the Lean code, the Infoview, and on the bottom. Now many people use an AI agent there that’s writing the code and explaining in natural language what’s going on there. It’s a super effective way. I mean, Terence Tao, he told me when he learned Lean, he uses the old version. It was before agents. He would have ChatGPT on one window and Visual Studio Code in the other window, and he would copy and paste between them.

[01:05:41] And that’s how he learned. But now it’s even more effective with the AI agents. It’s easy to pick up. I mean, just talk to the agent. Sometimes people say, how do I start? Start talking to the agents. It will help you, it will customize. Right? You can explain what you know already, right? I mean, what’s your background? And for example, if you tell, oh, I know Haskell, it’s so much easier, right?

[01:06:12] You can customize the process.

01:06:15 — Advice for his younger self

Ryan:

[01:06:15] And then last question for you is, if you could go back to the beginning of building C3, building Lean, and give yourself some advice, knowing what you know now, what would you say?

Leo:

[01:06:28] I’ll keep it a secret. I mean, I think eagerness is bliss. I mean, you don’t know how hard things are, and when you start the adventure, maybe I’ll keep secrets. What I would tell, I think one thing, especially before starting Lean, I’m super introverted. And I would tell, look, you should work on your people skills because it helps a lot. I mean, when you have to interact with a community, with people.

[01:06:58] For me, it was hard to learn that, and I would tell myself, I think it’s really important to have people skills, too.

Ryan:

[01:07:06] Well, thank you for your time today.

Leo:

[01:07:08] Thank you. Thank you.

In this conversation with Roberto Ierusalimschy (the creator of Lua), he finally clarified how this cross-language mechanism works for me. It was relevant since Lua is a scripting language purpose built to be embedded in other languages.

The programming language is famously used in World of Warcraft and Roblox where you have all the high performance rendering code written in something like C/C++. The parts of the game that change frequently though are written in Lua and called from that lower level language.

He also had some interesting recommendations on programming languages (aside from Lua) that he’d recommend people learn to expand their minds.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:43 - What sets Lua apart

08:35 - Comparing Lua with Python

13:04 - Top book recommendation on language design

14:20 - How JIT works and why it is hard

23:21 - Compiling Python and interpreting C

30:31 - How cross language calls work

36:58 - Lua unique design decisions

51:17 - Predictions for AIs impact on languages

01:00:10 - Top 3 languages to learn to become a better engineer

01:03:21 - Advice for his younger self

Transcript

00:43 — What sets Lua apart

Ryan:

[00:43] In 2023, Lua was the second highest programming language by growth according to contributors on GitHub. And I saw that it was also used in famous games like World of Warcraft and Roblox. And so I wanted to ask you what kind of programming language is Lua and what sets it apart?

Roberto:

[01:07] Lua is a language that usually is used together with another language like C or C++, and then you have an architecture where Lua takes care of the more dynamic part of your program, things that change more frequently, things that are not so resource intensive, the hard parts you have written in C or C++. So it’s typically what is called a scripting language. There is some confusion, I think, between scripting languages and dynamic languages.

[01:45] And people just, I think, considered a dynamic language to be more or less the same thing as a scripting language. And they are not exactly the same thing. So, for instance, a big difference between Lua and several other scripting languages is that for scripting you have two typical uses. You can have the app that I call who has the main loop. So you can have the program written in C and calling Lua, or you have your program written in Lua calling C.

[02:23] And for several scripting languages, actually, you don’t have to, but it’s much easier to use if you have your program written in the scripting language, and the C language is only for your libraries. Lua is a very good fit. When you want the reverse, you want the program written in C and then it calls Lua from time to time. So the point is that Lua is very good at this, that you have the main loop, the program written in C, and then it calls Lua for some tasks or for whatever you want to do.

[03:09] And for instance, in games, this is very important to keep the frame ratio of the game. So, for instance, you have the loop. The loop keeps the rhythm of the game and keeps everything. And then at every frame it calls Lua. Lua updates all characters, all images, everything in the game, and then it returns to C to do the renderization, etc. So it is a very good fit. But the main point is that people sometimes call this the embedding versus extending.

[03:46] So you can extend the scripting language with C, or you can embed the scripting language into C. And so several languages are very good only for extending, while Lua, it’s really good for both embedding and extending.

Ryan:

[04:05] Why is Lua good for embedding and Python? It’s almost the opposite, because Lua, since the beginning, we thought about Lua as a library.

Roberto:

[04:11] Since the beginning, Lua was written as a library. So I think that’s the main difference. Lua has a standalone program that, I mean, you can call Lua in your console, in your command line, but that program is just a client of the official client of the library, following the same API that any other program can use. So this idea of language as a library, I think it’s not very common. It’s something that is very particular in Lua.

Ryan:

[04:49] When you design a language as a library, what are the unique design decisions?

Roberto:

[04:56] I think that goes a lot of small and big details. For instance, your idea of what is your global space, or about scopes of variables, about exception handling. For instance, it’s very important that it’s very common in Lua that you raise an exception in Lua but you catch the exception in C. So all these things about how you do exception handling in the language. Another, it’s not a big deal, but it’s.

[05:31] For instance, most dynamic languages, that’s almost a definition of a dynamic language. They have an evaluation function that you can give a piece of code and then it executes that code. In Lua, we don’t, instead of eval, we have a function that we call load, that you give a piece of code and it returns a function, an internal function. Like it was a Lua function that when you call that function, then you execute the associated code. It doesn’t execute immediately.

[06:08] So you have this clear separation between compiling the Lua code that you have, and you can do that in C. So in C, you can get a piece of Lua code. You can compile it, check if it has errors, et cetera. Then you call that, for instance, a different piece, or you can even call several times. You can load functions from Lua into C. You keep them in the Lua space, and then you can call that same function again.

[06:42] And again, it’s not a big difference, of course, because if you have eval, you can evaluate a function declaration and then return that function. So you can, if you have eval, you can do load. If you have load, you can do eval. But I think load, it’s simpler to use for that kind of thing. That is, when you think about libraries, for instance, in Lua, it doesn’t have a global state. I think that’s, I forgot that.

[07:14] That’s a very important difference. When C starts, the first thing it has to do is create a new Lua state. And then everything you do, you do on that state. And that state is completely independent of everything else. So C can, for instance, create another Lua state, and both states are completely independent, completely. There is no communication between them. And so this again shows that these.

[07:51] And so, for instance, C can use a state, do a lot of stuff, and then it can close the state and all memory used by Lua is released. Everything that Lua was using is released. For instance, if C doesn’t need to use Lua anymore for a program, you release all resources used by Lua, and your program continues, and then later you can again create another state, etc. So there’s, as I said, several small or not so small decisions in the language.

[08:24] But all the time we think about the language as, is that good for embedding? Is that possible to do embedding and things like that.

08:35 — Comparing Lua with Python

Ryan:

[08:35] When you think of the programming community, generally everyone is quite familiar with Python, but not as familiar with Lua. I thought it might be interesting to compare the two languages. So if you compared Lua to Python, what are the pros and cons of each language design?

Roberto:

[08:54] Lua is a language that is intended to be used in this idea of scripting architecture. So Lua, for instance, it doesn’t thrive having a lot of different libraries. If you have something that, oh, I want to write a quick program for, something that Python is much better, it has all the libraries you can dream about. It has a lot of libraries built in already into the language. So the language is huge.

[09:27] I mean, the installation, it’s a huge download, etc. But it has exactly, oh, I need that. Oh, it’s there, I need that, it’s there. And Lua is almost the opposite, some very minimalistic language, because it is that you embed Lua into your program. It doesn’t use almost any resources. Most of the libraries, the important libraries that you will use, will be provided by the program itself, will be the commands like move a character or do some speech or things like that from the engine of the game, for instance, if you think about games.

[10:07] But whatever it is. So Lua, I think that’s the main big difference. They have very different goals.

Ryan:

[10:16] I saw some benchmarks, and I saw that Lua is much faster than Python. Why is that?

Roberto:

[10:23] Those benchmarks are not exact. But I think the main point is that Lua does have this focus on performance. Again, in the realm of scripting languages, it doesn’t want to compete with C or C++. But in the realm of dynamic languages, mostly now it’s a dynamic language, not a scripting language. We have some focus on performance. So I think this is the first difference. Python is exactly much more.

[10:56] I think it’s the decision that they make. Performance is not that important. It’s more important to be flexible, to be easy to do whatever you want to do. Then in Lua, sometimes we do not put some features because we think that there is no way to implement that efficiently. But also I think some part of the performance difference comes exactly because of the size of Lua. So most of the virtual machine fits in your cache, for instance.

[11:27] I think there are these two big things. One is that Lua doesn’t have so many features. It’s not so dynamic as Python. So in Python, there is a lot of interaction because everything can mean something else. In Lua, we are a little more conservative on that side. But I think also this thing of being small also makes it naturally faster.

Ryan:

[11:53] So, on the distinction between scripting languages and dynamic, or I guess it seems like dynamic language is a superset, scripting language is a subset of that. Am I understanding that JavaScript is a dynamic language, not scripting language from your perspective?

Roberto:

[12:10] Yes, exactly. Yes, exactly. Because the scripting language—the original scripting language was Bash, or the Unix shells—with this idea that it is a language that coordinates other stuff. So, for instance, it can be extending again, you can use. But this idea that you have two different languages for the shell is only useful because you have a lot of programs written in C that are controlled by shell. So the scripting language has this very strong idea that you have this idea of a dual-language architecture.

[12:50] So scripting is like the name scripting. It means you coordinate or you give a script to be executed by those other things.

13:04 — Top book recommendation on language design

Ryan:

[13:04] You gave a talk a while ago, and someone asked you a question about what books do you recommend for studying programming languages, and you said that you actually enjoyed studying the language design of other programming languages.

Roberto:

[13:18] I like reading books that describe the design of languages. I think the best books are those written by the author of a language about the design of that language.

Ryan:

[13:32] What book recommendation do you think is best on language design?

Roberto:

[13:37] JavaScript: The Good Parts, for instance. It’s kind of old now, but I think it’s a very interesting book. Although I always joke that JavaScript: The Good Parts is a very thin book compared with the official JavaScript books, like 110 of the language, but I think that book is really interesting because it discusses the language, the bad parts, and it focuses on the good parts, but then explains why it’s there, why it was made that way, etc.

[14:17] That is a book that I like.

14:20 — How JIT works and why it is hard

Ryan:

[14:20] When we were talking about Lua, it sounds like one of the things that sets Lua apart is the performance and how minimal it is. And when I was reading about Lua, I saw that there’s LuaJIT. How does LuaJIT work?

Roberto:

[14:34] LuaJIT? Well, the first thing, it’s a completely different project. It doesn’t have anything to do with us, but it’s an incredible piece of software that is a just-in-time compiler for Lua. And I think exactly one of the reasons it works so well on top of Lua is because of the simplicity of Lua. It’s a very regular language. I mean, it has very, as I said, it doesn’t have many exceptions or too many interactions or things like that.

[15:09] So it’s not that dynamic. I mean, everything can mean something completely different, so I think that gives a very good language for a JIT. But Mike Pall is the name of the guy that made the first LuaJIT. He’s still working on that. It’s unbelievable, his work.

Ryan:

[15:33] What makes writing a JIT difficult?

Roberto:

[15:36] The first thing for me, I don’t want to get involved with JIT, is because it’s machine dependent. It’s not very productive. I mean, you do a lot of work and only work on that architecture, and then, oh, I want to run on another architecture. But Paul, he created a kind of pseudo-assembler that he writes in this assembly, and then he translates that assembler to real machine code for the different machines.

[16:08] So trying to unify the different architectures. So there is a lot of work, but I don’t like—I think architecture I like to study, but I don’t like to work with it because I think it’s very unstable. Each new version, they change that or they change that. I mean, they change the ABI for something, and then now the stack has to be aligned in some very particular way. And of course, also to get that performance that he gets, he made what’s called a trace compiler.

[16:47] The idea of a trace compiler, instead of getting a function and compiling a function, it works like any JIT that tries to detect things that are executed frequently. And so it starts what’s called the trace. It gets recording everything that the code is doing, including function calls, et cetera, until it closes the loop, and then it compiles that loop, including function calls, et cetera, everything in line.

[17:23] It compiles that for that specific, for instance, so that number happens to be an integer. So it compiles it, the number will be an integer again. And there are a lot of checks just to check that everything is as assumed, and then it executes the loop, and then it’s very, very, very fast. But anything that is different, for instance, you call it again, but you call it frequently with integers. Suddenly you call it with a float, and then at some part of the code, it breaks the condition and you have to return to the interpreter part.

[18:05] And I think that’s one of the worst parts, is that you have to translate the state that it’s all compressed into register, et cetera. For instance, you don’t even have a call stack because you didn’t do the calls, you just inlined it. But then, oops, something went wrong. Now you have to continue interpreting. So you have to recreate this fact that you didn’t create originally, et cetera. So I mean, even to think about that, I have headaches.

Ryan:

[18:40] Standard Lua is portable, but to execute on a machine, it eventually gets converted into machine instructions. Where in the stack is it eventually translated to machine instructions?

Roberto:

[18:52] Lua is written in C, the interpreter is written in C. And then you compile that into machine code, the interpreter, the Lua code. Then when you get some, I mean the Lua code, the Lua interpreter code, when you get some Lua code, you do what we call a precompilation; that is, we translate to an internal language. Then the interpreter is just a big loop, a loop with a switch. That’s a very big simplification.

[19:27] But in general terms, a loop with a switch that gets instruction does a switch and sees all these instructions. The instructions are quite similar to a CPU move, but then instead of creating it, it executes that structure: move A to B. So it does A, move A to B, and executes that, and then again repeats, executes the next instruction. So this is how interpreter works. And basically, so we pre-compile Lua.

[20:03] There is a compilation, but we compile for this virtual machine, and then we have this main interpreter loop that people call that just fetches each instruction. A jump is just a jump. You have an array of bytecodes. A jump just goes to that. You have a counter that tells where you are in this array. You just update that counter. It goes to another position in that array where you’re going to.

[20:34] So it’s like you emulate the CPU in software. It’s written in C. The interpreter, this main loop, is written in C. So if you compile it in Linux, it will run in Linux on an x86 architecture. It will run on that architecture. If you compile that on a Mac, it will run on a Mac. It’s a C program.

Ryan:

[21:00] Got it? Okay, so. And that’s the part that’s not portable. And the C compiler handles that?

Roberto:

[21:05] Yes, yes, yes. All portability of Lua comes on top of portability of C. How does JIT compare to ahead-of-time compilation in terms of performance?

[21:17] Both ahead of time? Any kind of compilation can be 10 times faster than interpreting, or even 100 times faster than interpreting, depending on what you are doing. But 10 times is a very good figure between ahead of time and trace compilation. Then it depends a lot on what you are doing after. Trace compilation is particularly good for benchmarks because you’re repeating it more or less.

[21:55] They are very uniform. You are doing exactly the same thing again and again and again. So then trace compilers shine. I mean, this is the best they can do in real programs. That depends a lot, but I wouldn’t say there is a clear winner between the two. I think it depends a lot on the kind of program.

Ryan:

[22:20] Is it possible to write an ahead-of-time compiler for Lua?

Roberto:

[22:24] Yes, there are several. I mean, I don’t know if there is any production-quality one, but for research, et cetera, there are several. I have a student who wrote one, like a master’s thesis. A ridiculous simple Lua compiler, ahead-of-time Lua compiler or something like that. Exactly, because it was just—it gets these opcodes and expands into C code, and then you send that through to a C compiler, and then you have an ahead-of-time compiler for Lua, and it gave like three, five times boosting performance.

[23:13] Very, very. As the title said, it’s ridiculous. Simple compiler.

23:21 — Compiling Python and interpreting C

Ryan:

[23:21] I always hear there’s compiled languages and there’s dynamic or interpreted languages, I guess, but really that distinction is in the toolchain, not necessarily in the way that the symbols are laid out in the source code. I could write a compiler or a program that takes in Python code and then converts it into machine code. And then I would have compiled Python.

Roberto:

[23:46] And you can interpret C code too. You can write an interpreter for C. Yes, but the main difference is exactly what it’s easy to do. For instance, as I said, one of the hallmarks of interpreted languages is eval. So if you want to compile the language and keep eval, you have to have a compiler as a library of your runtime because you may want to compile things during execution. This is the hallmark of a dynamic language.

[24:21] So you can create code while running code. So that part is why, much more often than not, dynamic languages are interpreted, but you can compile. But then sometimes some compilers do not handle eval at all. They say, oh, you can compile as long as your program doesn’t have evals. So there are some restrictions. And as I said, you can interpret C code, I mean, but you’ll be extremely slow.

[25:00] It doesn’t.

Ryan:

[25:01] But I think one big difference, and when I look at static languages or compiled languages, they seem to have type systems in them, or type annotations. What is the role of a type system in the compilation process?

Roberto:

[25:18] Depends a lot on the type system. Several type systems, like in C, for instance, are written to be a very important part of the compilation process. So if you have the right type system, it’s much, much easier to write a compiler. A typical example is on the space for variables. Because if you know, oh, this is an integer, this is a float, this is a double, you know exactly how many bytes of memory you need to that. Otherwise, it’s a mess.

[25:54] More often than not, you have to keep everything in the heap, dynamically allocated, and so huge penalty in performance. And for instance, when you see, as I said, a trivial, you have an addition A plus B. If you know the type of A and the type of B at compile time, you know, oh, this plus is, I’m adding two integers, I just generate the machine code to add integers, and there everything is fine.

[26:27] You know, a dynamic language, like C, I don’t—I compile to a virtual machine, and the virtual machine is just a piece of C. But then how do I... At runtime, you have to check what is A. Oh, A is an integer, B is a float. Oh, I have to convert. Or B is a string. Or depending on the language you are, if you’re not doing addition, it can be doing concatenation or you can just call some function, and you have to do all that at runtime.

[26:57] So types can be very, very important to compile efficiently. But of course, you have to have a type system. There are several languages now, like TypeScript, that the types are kind of... You do not guarantee that everything has the types you set. So then it’s impossible to use them to compile because, oh, probably A will be an integer, but if it’s not, I mean, if I have an integer register to boot with, it must be a register or things will not work.

[27:40] But if you have the right type system, they are essential for good compilation.

Ryan:

[27:46] I know some programming languages have type inference. What if you ran type inference and you got an unambiguous set of types, and then you used that in compilation? Could you do that for Lua?

Roberto:

[28:01] No, I mean that’s not computable. But a lot of people try to do type inference for dynamic languages, and it’s a really hard problem, and it’s very difficult to do anything useful in terms of performance. What if sometimes you get? But you have to be very restricted. If you write your program in that specific way, use fall. So it’s like you don’t have the type, but you write the program thinking about types.

[28:38] And then if the program is in that very particular format, then you can do type inference and everything goes well. Otherwise, either type inference doesn’t work or, I mean, it works, but it infers very generic types for everything. And so you cannot take advantage of the types because of the dynamic nature of the language. This also happens with LuaJIT, for instance. You can get much, much better performance if you have a kind of type system in your mind.

[29:18] Usually we do that, and you follow those type rules even without—the compiler, the language does not impose them on you. But you assume, oh, I’m going to follow those discipline, I’m not going to use the same variable to store integers and strings, etc. And then you can have much better results.

30:31 — How cross language calls work

Ryan:

[30:31] Earlier, you mentioned that Lua can call C and C could call Lua. And you mentioned, we talked about the compiler and the interpreter and how do these pieces work together in the case where you’re chaining different programming languages.

Roberto:

[30:47] Yeah, the main trick, I mean, it’s not a trick. The technique for allowing C is C pointers, function pointers. There is a pointer to a function. This is part of the official C language. So when you start Lua, suppose you are in C, as I said, you create a library, you create a state, a Lua state, and then you can register, you send to Lua C pointers, function pointers, I mean, pointers to functions in your C library associated with names.

[31:28] Lua stores that in some data structure. Okay, so it says, oh, the function is associated with that pointer, etc. So when it’s doing the interpretation, oh, this instruction is call. Instruction, call. Let’s see what it’s calling. Well, it’s calling a. What is the value of A? Oh, it’s a pointer. And then it calls that pointer. And then we call the C function to do that. And when C wants to call Lua, I mean, a Lua function is just a data structure from the point of view of C.

[32:10] It’s just an array of bytecodes of opcodes, and then it calls the Lua interpreter function. Please interpret that function for me. So C can call Lua, interpret that function, and that function is running, and then can call a C function using a pointer. And you can have that in the stack at several levels. So we are running a Lua function that calls C and C calls Lua again and Lua calls C. You have recursive stuff in that, etc.

[32:43] And everything works, just works.

Ryan:

[32:48] In one of your talks on Lua, you mentioned that there’s security benefits to using a scripting language. What are those benefits, and how does it...

Roberto:

[32:56] protect the hardware. It’s not only hardware. Once I gave a talk here in Brazil, I was called to give a talk at a Python conference in Brazil. They called me for a talk. At the end of the talk I said, “Oh, let’s use it as a scripting language.” As I said, emphasizing that thing that you have this dual-language architecture. And I know of case of Lua being used with C, with C++, with Fortran, with several different languages.

[33:33] And then someone in the audience said, oh, we also use Lua for scripting Python programs. And what was the case? They have a huge Python program for financial stuff that has to do a lot of financial transactions, etc. And they wanted to do scripts, I mean, to have a command line where you could write instructions to be executed at runtime, for instance, for debugging or for inspecting, for whatever you need some kind of end-user programming.

[34:11] But they said exactly what I was talking about, spaces in Python. Basically, if you have a command line and you are going to run Python, that Python can do whatever it wants to your program. There is no way to protect it. So if you gave that to the user, the user could do whatever it wanted to do. I mean for the program. And so the program would break a lot of invariants of a lot of important stuff in the files it kept, etc.

[34:45] And so what they did, they gave the thing in Lua, because, as I said, Lua, you create a state. For instance, as I just mentioned, you can only call C functions. That is true in Python again, but in that particular data you can only call C functions if you give the C pointer to Lua. So have a very strict, and there is very little, as I said, there is a library. When you create a Lua state, it has no functions at all.

[35:18] There is nothing. I mean, you cannot open files. Everything there are, we call standard libraries. Usually you open a state and you register those standard libraries. In Lua, so you have the minimum, you have mathematical functions, etc. But you can open a state and register no functions at all. In Lua, it can only do things calling those specific functions you gave. So they used Lua to have this kind of control.

[35:49] Or you can write Lua code here, but that Lua code can only do very specific things in the Python program. You cannot call any Python function or build any kind of Python data structure, etc. So was this a nice example? In the case of hardware, it’s the same thing. You cannot just go in. For instance, there is a hard port that controls the speed of the fan. That keeps the temperature of the CPU.

[36:23] And if you put that very low, you can really burn the CPU. I mean, because the CPU gets very hot. And so you have a C. You cannot call C directly, you must call Lua. And only Lua has access to that. So if you can only program in Lua, then you check whether the numbers you are giving are precise or whatever. It has to check and then it calls.

Ryan:

[36:51] It’s kind of like a sandbox environment.

Roberto:

[36:53] Yes, exactly. Yes. Sandbox is the exact word for that.

36:58 — Lua unique design decisions

Ryan:

[36:58] I saw there was this, I guess, paper, maybe it was an article you wrote on the history of Lua with several other people. And I thought there were some interesting quotes in there I kind of wanted to ask you about. So one of them, it says that there’s this old joke that says that a camel is a horse designed by a committee.

Roberto:

[37:20] Yes, that’s not mine. That’s a real old joke.

Ryan:

[37:25] Does that mean you think the best programming languages are designed by as few people as possible?

Roberto:

[37:33] Yes, I do think, yeah. Because one thing that it’s easy to observe is this: If you have a committee writing a language, everyone wants to put something from themselves into the language. So you have your favorite mechanism, and you will fight whatever it takes to put your favorite mechanism into the language. And very few people you fight against putting anything in the language.

[38:11] I mean, some people say, oh no, this is too much, this is too complicated. But people fight much more fiercely for putting something they want in the language than against putting something in the language. So when you have a committee, the tendency is, “Let’s keep adding stuff, let’s keep adding stuff.” And people sometimes even do not understand, I mean, I’m even not sure if everybody there really knows the language well enough to be putting that.

[38:45] But that fits with other parts of the language. I didn’t even know the language has this other part. I mean, so things sometimes do not fit together very well, et cetera. So first, you have what’s called the conceptual integrity. It’s a name that gives that everything fits together, everything is designed with everything else in mind, etc. It’s much easier to. I’m not saying, I mean, Lua has several wrong stuff regarding because of.

[39:17] With time, etc. There you make mistakes, but it’s much easier to get things right if you have a small group of people that everybody knows what everybody else is thinking. I mean, you are deciding whether to put something in the language or not. It’s much easier to change your mind if you do not put something and then later you decide to add it to the language than to add something and then later you decide, oh, I shouldn’t have. That was not a good idea.

[39:53] So, when in doubt, the rule is always don’t put it. If you’re not very sure, don’t put it. We can always add that later and keep the door open to change your mind.

Ryan:

[40:08] I saw in the original Lua programming language that there was no Boolean type, and I’ve never seen that before. Why was there no Boolean in the original Lua?

Roberto:

[40:19] Well, C doesn’t have booleans. I mean the original C, and C90 up to C99, they use integers. If it’s 0, it’s false; if it’s different from 0, it’s true. And people lived quite well with that. Lisp and there are several languages that don’t have booleans. And actually, we only put booleans in Lua because we wanted false. True is completely useless in Lua. Nobody used true, and nobody’s a joke, but it’s too strong.

[40:57] But it’s not very useful. You can use almost any other value for true. But the problem is that in Lua, the special value nil is in a table. It is equivalent to the key not being present. You may think whether that was a good decision, but it’s very embedded in the design of the language. And it has this strong concept that a table, a key that is not present in a table, there is an associative array, it has a nil value, it’s completely indistinguishable whether it’s absent.

[41:43] I mean, absent means it has a nil value. Nil value means it is absent. And so sometimes you want to have a false value, but you want to know it is there in the table. And so we needed a false to have a false you can put in the table. And it’s completely different from being absent. You know, that is a key and the key has a false value. So we need a false value. And if you’re going to have a false, then we added true, true.

[42:16] It would make sense to have false without true. But with true, it’s almost useless.

Ryan:

[42:22] Why not use 0 as false if you’re okay with 1 as true?

Roberto:

[42:27] We could have used it, but among other things, that would be a big change because it didn’t exactly work that way. So we added that later in the language. So changing 0 to false would be a very big incompatibility. But it could be, for instance, in Python I think a lot of stuff are false. I mean, zero is false, empty list is false. And in JavaScript I think it’s even worse. I don’t recall exactly, but I mean this is kind of arbitrary.

[43:06] I mean, we could have, for instance, nil, false, zero, empty string. It just depends on the kind of test that you use. In dynamic languages, it’s very easy to.

Ryan:

[43:22] Python has the... Like you’re describing the truthy values and the falsy values, I guess they can be interpreted as false. But it’s more implicit, less explicit. And I know JavaScript is even further on that spectrum where you can do some really weird stuff that implicitly has some behavior. Do you think that design direction is good or bad?

Roberto:

[43:48] It’s like a small compact. It’s more easy to write stuff. But you always have this balance in any language. Almost anything, the more flexible you have, the less protection you have. In C, you have something like that people do not notice. But because C is typed, you can check whether an integer is true or false. You can check whether a float is true or false directly because, again, it checks whether the float is zero or different from zero.

[44:19] You can check whether a pointer is nil or different from null. Because in C, null is a magic zero. So it’s kind of, if you do not write any test, it has an implicit test like different from zero. And this zero can be an integer, can be a float, can be a pointer. So in C also you have this kind of flexibility. It’s just you have to be more explicit. Usually these are, avoids errors, but so this, you always have this balance between easy to write and easy to make mistakes.

Ryan:

[45:09] I saw that Lua is 1-indexed instead of 0-indexed, and I had never seen a programming language like that.

Roberto:

[45:18] In my experience, there were a lot of programming languages like that.

Ryan:

[45:23] So yeah, why is it 1-indexed?

Roberto:

[45:26] Because everything in the real world is 1-indexed. If you have a book, you have chapter 1, chapter 2. Nobody numbers chapters as 0, 1, 2, 3. Only programmers are the only, even mathematicians. If you get a math book, a book of mathematics, any sequence, it’s 1 and 2, 3. If you get a matrix, the first element is 1, 1 and 2, and then... Everything is written before. Only in programming language there is this idea of zero.

[46:03] And the funniest part is that, for instance, Fortran, now it’s a very old language, but to index it from 1. In Pascal, you can choose. I mean, you write an array, you can say this array is indexed from -5 to 5, and so it’s indexed from whatever value you want to whatever value you want. 0 became extremely popular because of C. C uses 0, and a lot of languages copied are kind of inspired by C. They have the same operators, the same syntax for expressions, the boolean operators, for instance.

[46:50] That is not standard mathematics. Almost all languages chose the same operators as they are written in C. And so a lot of languages copied C. And then zero index became very popular. And what is funny is that in C there is no indexing. In C, indexing is just an illusion because what you have is pointer arithmetic. And see, when you write A indexed by I, actually what you are saying is get the contents of A plus I.

[47:29] And so because in C, you don’t have indexing, you have these displacements or deltas, I don’t know, offsets. Then it must have indexed by zero because of that, because then the first element is the element that is at the original address. So C doesn’t have indexing. So when you say A is indexed by 0, it doesn’t index by 0 because it doesn’t index by anything. But it has this illusion of indexing.

[48:02] And then it’s easy to sync that in. And then a lot of languages that do not use pointer arithmetic do not have this restriction, do not have these semantics, copied C and kept the zero indexing as this thing. If you get a 12-year-old and try to explain zero indexing, I assure you it’s much, much easier for them to write. Oh, I have a list of the first element. I always joke that the first element is 0, and you write first, you for 1, but the first element 1 is not 1, is 0.

[48:45] So it has advantages, for instance, for some specific operators. Mathematically, for instance, when you want to do a circular buffer, zero is better. There are some small advantages, but it’s much, much more confusing. And as Lua has this idea of end-user programming, we always joke it’s much easier to make life easier for the non-programmers. And I’m sure that programmers can program whatever index they have to do because they’re supposedly professional. They can learn that, oh, indexing from then, to put on the end user the burden of using something completely different from them.

[49:34] Indexing by zero, what does it mean, the element index zero? They never saw the chapters in the book. Yes, the first chapter is at zero, the second chapter is at one. No, I’m not joking. When you try to explain that to non-programmers, it doesn’t need to be 12-year-olds. I mean, just get anyone that is not an Internet programmer. Think, “Oh, I have the absolute.” I mean, you are grown up, you are, I mean, okay, you are a student. If 0, I’m sure you can learn to program; if 1 or minus 1 or whatever it is, the base you have to use.

[50:06] I’m sure.

Ryan:

[50:16] But do you think you see a lot of bugs because maybe someone thinks it’s zero?

Roberto:

[50:22] Unfortunately, I see some bugs, but as I always say, those are the kind of bugs that just show that you didn’t do minimum testing, because that kind of bug is not a kind of... That kind of bug that, oh, if you try to... Anything you try to do in an array, if you start from zero or start from one, you have a bug. So the most simple test that you can imagine to test anything related to an array, to a list, et cetera, and if you mistake 0 for 1, you detect that.

[51:08] So if you have that kind of bug, it just shows that you didn’t test that code at all.

51:17 — Predictions for AIs impact on languages

Ryan:

[51:17] There was this talk that you gave on the cost of adding language features to Lua and how there’s a lot of hidden costs. And I think today, implementation costs of software are going down due to AI code generation or LLMs, and I was wondering if that changes your thinking on, I guess, the cost of adding features to a programming language.

Roberto:

[51:43] AI is something that we don’t really know what’s going to happen. If you go to an extreme, it’s completely feasible that we won’t have programming languages. And I mean, because if the AI is writing all your code and is checking all your code and doing everything, in a few years maybe we don’t need programming. AI can write machine code directly; it doesn’t need programming languages. It’s easier for them to compile or even generate the code directly.

[52:21] I mean, I don’t know what’s going to happen in a few years. So I think it’s very hard for me to talk about anything about AI because I have, and I think nobody has a clear idea what—I mean, people may have a clear idea what happens in one year or two years, but in five years, I mean, anyone that says, “Oh, that’s going to happen in five years,” is just guessing. So I think it’s hard to say anything.

[52:59] This is all because of AI. So keeping the minimum thing, I mean that still have differences there. Oh, why do you still use programming languages? Because you want the user or some human to be able to check the result of what the AI is doing, etc. So I still think that most of the things about programming languages still hold. For instance, the cost of complexity of you understanding. I mean AI create a code for you and then you really understanding what that code does.

[53:37] I mean it’s even worse. I mean it’s much more important that the language should be clear and has no hidden mechanisms. Because the AI may use a hidden mechanism, it doesn’t have the concept, oh, that will be difficult for a human to understand that what is really happening here is something it says something that, for instance, oh, I can use that. But I’m for sure it’s going to put a comment here because I’m sure that someone that reads that in one month is not going to understand.

[54:14] EA doesn’t have that kind of thinking, and so just use that trick or that thing. So I think if you think about this idea of AI generating code, I think it’s even more important for the language to be simple, to be understandable, for you to be able to really understand that the code that you are seeing does what you think it should do. You really understand what the code is doing.

[54:44] So this thing about simplicity, I think it’s very important, and I think the other parts from the book maybe facilitate documentation. I’m not sure if I mean this thing about conceptual integrity, for instance, to keep things, that makes sense, etc. I really think that one of the main costs is that it’s the burden you put on the user to learn one more thing about your language. So there’s the other cost of it.

[55:19] I said that implementation is the part that AI can really help you. It’s not a really important cost.

Ryan:

[55:32] If you think about a spectrum of simple to complex, what programming languages are the most simple ones that you think of, the easy to understand, less confusing side effects, and what programming languages are the most complex and have the most foot guns.

Roberto:

[55:50] This famous quote, also—I don’t know from whom—that the simplest possible, but not simpler than that. Because if you go to the extreme of simplicity, you could get, for instance, lambda calculus or Turing machines and say, “Oh, that’s really simple.” I mean, this is really simple, but it’s completely impossible to write any program in that. I mean, if you have really simple stuff, I think the extremes will be like that.

[56:22] But you don’t want to be there, but for the other side. I think C is a good example of a language that I think is really, really complex.

Ryan:

[56:33] A question that comes up a lot is, given how much AI has been progressing, would you still recommend people learn computer science today?

Roberto:

[56:43] If you really think about that, it’s really difficult to recommend people learn anything for a profession. We have no idea what AI will do in five years. If someone is entering university now, they’re going to graduate in four years, five years, or, at minimum, three, three and a half years, and nobody has any idea what the world, your profession, will be like in four years from now. So it’s really hard to, I mean, to say, “Oh, yes, you can still go into it,” because now people say, “Oh, no, the manual tasks, the AI, it’s very good, but you still need the whole architecture.”

[57:31] You needed a software engineer to do, to see the big picture, etc. That is now. But you have no idea that that will be true in four years or five years. So I think I like, I enjoy programming. I could do. I mean, some people say I use the AI for that. I mean, I program because I like that. But, basically, so if you choose something that you like, but really if you’re really thinking, how am I going to live with that?

[58:03] I have no idea. It’s really, I think it’s a really hard time to be choosing the profession.

Ryan:

[58:13] I mean, you’ve worked on Lua for such a long time. When you look back on it, what went well and what didn’t go well?

Roberto:

[58:22] We had this privilege of not having to satisfy clients. So you do not have, as I said, for instance, you can choose to add some feature to the language because you do not have a pressure. Oh, we need that feature, whatever it takes or et cetera. So we have this privilege of, oh, we are not sure whether to put that. We don’t put that. We can wait one year or so. I think that it’s much easier to do a good project, a beautiful project.

[58:55] So I’m not sure this is a recommendation to try to work without much pressure. People usually do not have this choice.

Ryan:

[59:07] What was your measure of success? If you’re working on a programming language, how did you know it was good?

Roberto:

[59:14] It’s more important to have, sometimes, good people that I recognize as would like the result than a lot of people that I have no idea who they are, etc.

So I think this metric of quantity that is the standard metric nowadays on the web has gotten much worse, that everything is just in the number of follows. I mean, it doesn’t care who is following you, just as many people as possible.

[59:48] So sometimes, for me, it’s much more important if someone that I really admire or think is, or says something good about Lua, then, oh, we have that many. But, of course, it’s good also to have some number of users and to be recognized. But I think it’s a balance between all of this.

01:00:10 — Top 3 languages to learn to become a better engineer

Ryan:

[01:00:10] Do you recommend people study other programming languages to get better at programming? And so the question is, what are the top three programming languages that you think every engineer should learn in 2026 to become better at programming? Haskell, I think, is an incredible language.

Roberto:

[01:00:28] It has everything you need to really learn about functional programming. I think one of the main benefits is that it’s much. There’s an old joke in the Haskell community that if you write a program in Haskell and in C, in C, you really spend one week to make it efficient, and then you spend one year to make it correct. In Haskell, you spend one week to make it correct, and then you may spend one year to make it efficient.

[01:01:15] Again, it’s not my joke, but it has some truths. Not always true, etc. But I think it gives the idea. I think this is maybe the most important lesson of Haskell. But Haskell has many other validities. This thing about type inference, for instance, that in the entire language, types are optional everywhere, and yet it can do type inference for everything. It can infer the types correctly, etc.

[01:01:51] See, or some old language. I mean, you can also have to learn some assembler, or I mean, to see. But assemblers now are becoming too much complex. It would be to learn, like, the Intel 8080 assembler, very old assembler of a very... But to have this exactly, this idea of what a machine does, how it does stuff at exactly the basic level, to have this understanding. Scheme is a language that I like very much because of this, exactly this economy of ideas.

[01:02:27] There are very few concepts, and it can do some amazing things with very few concepts. The way one language that this is very, very old. But I still think it was SNOBOL. I think one of the first languages to have pattern matching and this idea of doing, I mean, really strong patterns, et cetera. And I think it’s in... Sometimes it’s interesting to see old languages because, exactly, nowadays a lot of languages tend to, like I said, zero indexing that people, they copy a lot.

[01:03:06] They tend to be too uniform in some aspects. And it’s interesting to see some older languages that have some ideas that may maybe not even be good ideas, but it’s really interesting.

01:03:21 — Advice for his younger self

Ryan:

[01:03:21] Last question for you is, knowing everything you know now, if you could go back to when you had just started your career and give yourself some advice, what would you say?

Roberto:

[01:03:34] To know a lot of stuff, you really have to study a lot of stuff. And it takes time. I also joke about that. People say, oh, learn Lua in 30 minutes or learn Python in 5 minutes. And I always say that I wanted to learn programming in five years. But that’s really learn. Take your time. You have to learn that. And that is a lot of stuff. Stuff to learn. There is no magic there.

[01:04:07] You really have to learn. I mean, a lot of different things.

Ryan:

[01:04:12] Thank you so much for your time, Professor. I really appreciate it. It was a lot of fun.

Roberto:

[01:04:16] Thank you. It’s my pleasure.

• Why he loves physics and who the greatest scientist of all time is

• Proving Alpha-beta pruning is mathematically optimal which Donald Knuth was surprised at

• Discovering Bayesian networks and the eureka moment he had

You can tell how much passion he has for science in just the first few minutes of the conversation. Hope you enjoy it!

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:54 - How he got into AI

11:17 - Greatest scientist of all time

20:15 - What people thought of AI in the 80s

26:23 - Entering academia and researching AI

34:52 - The invention of Bayesian networks

46:28 - Pioneering work in causality

55:38 - The causal hierarchy

59:34 - LLMs and predictions

01:20:12 - A restless mind pays

01:24:36 - Advice for his younger self

Transcript

00:54 — How he got into AI

Ryan:

[00:54] I looked into your educational background, and it was all electrical engineering, physics. I don’t see the connection to causal reasoning and artificial intelligence. How did you get there?

Judea:

[01:06] Everything connects. Everything connects. Everything connects to the day I was born. Hit on the head first. I have to start by saying that we. I grew up in Mandate in Israel prior to 1948, prior to the establishment of the state of Israel. And we had a very excellent high school education. My high school teachers were professors that were chased by Hitler from Germany, from highly reputable universities like Heidelberg and Berlin.

[01:58] And they came to Israel in the 1930s, and they didn’t find any academic position at that time. They were rare, and they started teaching high school. But they were really quality professors. They could teach anything without notes, from the Economy of Manchuria to the proof of Pythagoras theorem, with no notes and no stop. And we were, we—I mean, my generation was lucky enough to be beneficiary of this educational experiment.

[02:46] So we were taught science from a human viewpoint, chronologically, the way things were discovered, by whom they were discovered, at what period. Why was there a question about certain mathematical proof? What the inventor of the proof knew, what he didn’t know, and what he asked himself in the context of the historical situation at that time. That’s the way to teach science, not the recipe of algorithms and techniques, but as a.

[03:37] From the viewpoint of the human actor. And the transfer of ideas from one human to another is a human struggle, not a human struggle to decipher the secrets of nature.

Ryan:

[03:54] What’s the advantage of learning in that style?

Judea:

[03:58] The advantage is that you see yourself as an actor. You, the student, you are also puzzled by many things. But look what he did. Look what Pythagoras did. He was as puzzled as you were, and he took that route. Perhaps when you’re puzzled, of course, your puzzles are not as magnificent as his, but still, look what he did. He took that route around things, and he consulted some other work of some other.

[04:34] He struggled and you struggled, and you are part of science. That is the basic idea. Give students the idea that you are part of science, not an observer, not a passive observer in science, not a recipient, but an actor. And that, I think, was unique, very valuable for me. We indeed got the idea that each one of us can find another proof of Pythagoras’ theorem that no one else has thought about. And each one of us has the potential of becoming an Einstein or Pythagoras.

[05:18] They give us this illusion. Okay, it was a useful illusion. I know I’m just a pebble looking at Pythagoras. But that illusion helped me be a little, I would say not contrarian, but assertive. And we all grew up in assertive mode of learning science. We insisted on understanding things our way in real time. If the teacher went too fast, we made noise. We made noise with our chairs and with everything we could, okay?

[06:07] And the teacher stopped and slowed down to make us all understand things our way in real time. So that was part of the. It’s a mood of me and my generation. And it, I. I can see that it affected my life. I had one story that I remember. It made an impression on me. I look back and I say, well, I. It started very early. It started at age 10 when we learned about how to calculate areas and volumes. And here there was a question in class.

[06:50] How many dunams are there in a square kilometer? Dunam is 1,000 meter square. It was a Turkish unit for measuring areas. So the entire class said, Dunam is a kilometer square. And I screamed and said, no, it’s a thousand. You have 1,000 dunams in a kilometer square. And the teacher sided with the laughing class, and they all mocked me and ridiculed me. And I went home and I said, they are wrong, and I’m going to come back tomorrow and insist on that.

[07:43] And the teacher apologized to the class, and I felt that, yes, you have to insist on your understanding of things. Yes, I’m telling you that because maybe this one made me into a noncompromise. And this is part of my childhood, a background which might explain how I got into artificial intelligence. So I took engineering after being a farmer in the army. Okay, farmer, yes. In Israeli army you have troops which are spending their time, half and half, half in military training and half in farming, being part of a kibbutz.

[08:40] It’s the old idea of one hand holding the plow and the other one the rifle. And you succeed.

Ryan:

[08:50] Did you ever shoot anyone?

Judea:

[08:52] I almost shot someone without seeing him or her. But it turns out the next morning that it was a fox. But the steps of the fox were very, very similar to the steps of terrorists advancing toward us. So that’s as far as I got to shooting. So I got into the Technion to study electrical engineering again. We had great teachers. Again, we got the idea that we are making science. So we studied physics very seriously.

[09:34] And I liked what we studied. Yeah, I wasn’t the first in class. No, it was third or fourth. Always never match the geniuses. The geniuses were bored in class. They knew what the teacher was going to do, what he was going to ask in the exams. And everything was boring to them. I wasn’t bored. I wasn’t the first, but I was bored.

Ryan:

[10:07] What interested you in physics? What did you like that made you so passionate?

Judea:

[10:13] What I liked was that, sitting on your chair, you can predict things in physics. Like Maxwell, who sat on his chair and said, “That looks like a wave equation. Look, let me calculate its velocity. It looks like the velocity of light. Maybe light is nothing else but electromagnetic wave,” you know, on his armchair. He didn’t do any experiment. That excited me. Yeah. My wife told me one night I woke up and I said Maxwell was wrong.

[10:57] Maxwell was wrong. She quieted me down in the next morning, said he was right. By the way, you.

Ryan:

[11:09] You mentioned a few scientists, and it seems like you know a lot about the history of the old scientists.

Judea:

[11:16] Yes.

11:17 — Greatest scientist of all time

Ryan:

[11:17] Do you have a favorite scientist of all time? And why?

Judea:

[11:21] When we studied and I looked at geometry, I got fever. Really? Fever.

Ryan:

[11:31] Physical fever.

Judea:

[11:32] Yeah. I couldn’t get over the idea that you can do in algebra all the geometric constructions that we learned on, you know. So I thought that Descartes was the greatest mathematician ever lived. It was so enormous to me. Transformation from geometric constructions to algebraic derivations. It was unbelievable.

Ryan:

[12:01] I took that for granted when I was in education. What is it about that that’s so astonishing?

Judea:

[12:08] Here you have two different languages, language of geometry and the language of algebra. And they are the same thing. And you can get the same phenomena, same proof that you can pass a tangent to a circle from a point outside the circle and you can find the angle. But different method, two different languages dealing with the same phenomena, different perspective, and they get the same result. It blew me off.

[12:45] Blew me off completely. Maybe that was. It was preparation to computer science. Because for us, computer science is what’s the big deal? You want to see things from different perspective, invent a new language. So that was what turned me on in my high school. That was in high school. And then we saw that. I saw the same thing in physics. Different languages, capturing the same phenomena.

[13:20] They really excited me. He invented the idea of a field, two different ways of looking at the same thing. You can see that the force here depends on the charges around it, or you can say, no, there’s a field right in the location of your testing point. Yeah, terrific, terrific. So I came in with this preparation, and here we go to Brooklyn Poly. And I studied there in.

[13:55] I worked in the morning in RCA Laboratories in Princeton, New Jersey, David Sarnoff Research Laboratory. And there I got into the computer research group. Computer research at that time was research of all phenomena that you can think of to find out a mechanism for computer memories. The memories at that time were core memories, magnetic cores, these donuts that you remember perhaps from your early childhood that were too slow and too clumsy, and you had to have people stringing them X and Y and Z in Hong Kong.

[14:44] And people understood that the days of core memories are numbered. And we were looking for new phenomena. Some people looked at photochromic memories, some people looked at the semiconductor. Some people looked, like me, into superconductivity. And I was in the group. It was supposed to design superconducting memories. Okay. We did some nice plates, 16 by 16 bits, okay. And we thought that we had the future in front of us, but in the way toward developing superconducting memories.

[15:36] I investigated the physical phenomena behind the eddy currents, permanent eddy currents in thin superconducting films. Okay. And it so happened that I discovered new phenomena there, and I got a prize. And it even has a name. It’s called Pearl vortex. You can find it in Wikipedia. I discovered that physicists, years after I finished my PhD, discovered my work there. And they were interested in the idea of permanent current flowing in a circle in thin superconducting films.

[16:23] And since I analyze the magnetic and current field there, they call it pearl vortex. So here I have my footstep into immortality.

Ryan:

[16:37] Well, you said it’s a permanent vortex. Is it because there’s no electrical resistance?

Judea:

[16:43] Because it’s a superconducting, the current going forever. So you establish, you put magnetic field and you excite a vortex counterclockwise, and it will continue to turn and turn and turn forever. That’s why we call it permanent current. Yeah, forever until you flip it with another magnetic field. So we call it a vortex. But it goes on forever. And you can detect it by flipping it.

[17:19] You flip it, and if you see a big flip, it was one way. If you don’t see a big flip, it was the way you turn it. Okay, so you have a memory. You have a memory. Of course, we didn’t succeed in turning it into useful memories that would be competitive with semiconductors. The people who worked on semiconductors beat us out. We never believed that they would, but they did, both in miniaturization and in techniques.

[18:04] Unbelievable.

Ryan:

[18:05] At the time, why did you not believe in the semiconductor direction?

Judea:

[18:10] Who is going to trust memory to battery failure? What if you lose a battery? It was obvious it will never work. Right. And we looked into the result that they obtained at that time. It looked far-fetched, the idea you can have that degree of miniaturization. We saw the struggle of people who work in the laboratory on semiconductors, and we weren’t impressed. Yeah, but they beat us up. Okay, so that was my story with the superconductors.

[18:59] But I must tell you that everybody, even at that time, when computers were clumsy and took rooms and rooms and you programmed with cards, okay, even at that time everybody understood in AI as an inspiration. Everybody believed thoroughly that one day computers are going to be able to emulate all human functions. That was not the question. The question was only how and when, but not whether.

[19:43] Okay, I remember already at that time, with the clumsy computers and the punch cards, people talked about associative memories, about pattern recognition, about seeing, understanding. All these were already ideas, were exciting people to think more about it. And so we were all geared towards it.

20:15 — What people thought of AI in the 80s

Ryan:

[20:15] If I at that time asked people and your peers and you, what’s the timeline for maybe human-level intelligence and machines? What would people have said at that time? When they were excited in the 80s?

Judea:

[20:30] I think they were more optimistic than reality. They probably gave you 20 years, but that was 1965. Okay, so 20 years, 1985. No, we didn’t yet get anywhere.

Ryan:

[20:46] Yeah, and then what about today? Do you think people are more optimistic than reality? Or is this just history repeating?

Judea:

[20:55] It depends who you’re talking about. Some people are extremely optimistic today, and some people say I’m a bit skeptical, but not skeptical in our ability to eventually reach AGI, but in whether the LLM technique and thinking will lead us there. Okay, so it’s a question of who you ask? Okay. LLMs were a great surprise. But they have limitations. We’ll talk about it. After superconducting, I decided to come to California to a company named Electronic Memories, in which they did not work on superconductors, but worked on plated wires.

[21:46] Instead of having a donut in which you thread a wire, you start with a wire and you plate it with magnetic material so it acts like a donut locally. Right. And that was the promising technique. At that time, at least, I was in charge of the research and development group charged with the task of developing this kind of systems to replace core memories. Yeah. And I worked there for three years. I was frustrated because things did not go my way.

[22:26] I had both administrative and technical challenges that I couldn’t handle, both in chemistry, and I didn’t know much chemistry, so I was frustrated.

Ryan:

[22:41] What were the administrative frustrations?

Judea:

[22:43] I had a group, and I had to satisfy the administration. I dealt with the personnel issues, firing, hiring people. Yeah. And my wife saw that I was unhappy, and she told me, “You get to. You have your place in academia.” So I looked for a position in academia. Luckily, also at that time, industry was revered by academia because all the advances, all the important advances were developed in industry, not in academia.

[23:36] The transistor was developed in Bell Lab. The laser was developed in, I think, here in California by another fellow. But all this was industry development and not. So academia looked with reverence toward people who come from industry. And they hired me without me even filling an application, without even asking for accommodations. Yeah, at that time it was a good time to be hired.

Ryan:

[24:15] And what about— because you said at that time industry was revered by academia.

[24:20] Would you say that’s still true today, or has that changed?

Judea:

[24:23] No, it’s changed. It’s different now with AI. If you come from deep learning or something, DeepMind, you know, people look at you with reverence in academia. Yeah, but it’s changed, you know, only in the last few years. I say that throughout. Since 1970, I think until 2000, it was the other way around. You know, people simply dismissed industry.

[25:02] I mean, academia dismissed industry. Yeah.

Ryan:

[25:05] I wonder what happened. Was it like Bell Labs disbanded their research group or something, or that was part of it.

Judea:

[25:14] Bell Labs disbanding and what happened to IBM is still there in Watson. Watson Center, I remember. Big center, huge and important. Including Raytheon. Including. Where can I tell you? Use research here in Malibu. Did great work, but it all went down sort of the frontier of research went to academia. Sure, we had a lot of theoretical work in academia. The development of AI, AI property after 1970. Yeah, but prior to 2000.

[26:03] Yeah, at least in my corner of the field. The whole idea of inference search, inference logic, expert systems, these were all the academic development.

26:23 — Entering academia and researching AI

Ryan:

[26:23] So then you got hired at UCLA?

Judea:

[26:25] I got hired in 1970 or 1969. And yeah, I was hired. The computer science department was just formed there. And I got first hired by another department called the Engineering Systems Interdisciplinary, and then back to computer science. And I was asked to teach computer memories, hardware on computer memories. Yeah. And I gave a course in this technology. And later on, I started getting interested in pattern recognition, and I started working in this direction.

[27:12] I did work on image compression. We used fast Fourier transform and fast Hadamard transform, all kinds of transform techniques to condense images, to minimize the number of bits sent. Okay. I guess it was a part of the trend at that time. But when I got into pattern cognition, I returned to my old dream of thinking about AI and how the brain works and how computers will one day emulate ourselves.

[27:54] And I started teaching class in AI. At that time, AI was game playing, machine playing of chess and checkers and the puzzles, like the eight puzzles, ruby cubes, things like that. That was AI. Yeah. And I got excited by that game, and now I see why. Why? Now I can tell you why. Because the game was a matter of capturing in mathematics what people do heuristically, like playing chess, and the interplay between mathematical analysis and the performance interests me.

[28:49] And especially in chess playing, the interplay between the explicit knowledge that you have in terms of your gut feel about the strength of a position and what you get when you do some search. Okay, so here, interplay between fast thinking and long thinking, to use Kahneman and Tversky or Kahneman’s title, Thinking, Fast and Slow.

[29:20] Thinking fast and thinking slow. Right now, here. It’s a beautiful arena to see how not only you have two modes of thinking, but how they feed each other and how you can invest more resources in one versus the other.

Ryan:

[29:42] The algorithms at that time, like chess, for instance. Can you give an example of the interplay of the two and how that might come together in a chess-playing system?

Judea:

[29:53] Yes. You can invest more time in getting your immediate perception. It’s called static evaluation function of the chess position, the strength of the chess position. Or you can let it go and think about searching for deeper horizon. Okay. It’s a tradeoff. It was like, if I remember, we.

Ryan:

[30:15] We searched the game tree and then evaluated each position at the horizon.

Judea:

[30:23] And then you back off and then you make a move toward the position that has the greatest strength after you back off. Yeah. Okay.

Ryan:

[30:35] So the intuition is encoded in the evaluation functions.

Judea:

[30:39] Yeah, and your intuition is the evaluation function. But you can improve your intuition too. How? By learning. Okay. So Samuel Checker program did learning in regression analysis to find the proper weight on the various characteristics of the position so as to make the evaluation function more accurate.

Ryan:

[31:08] When I was learning chess, I think one heuristic is you want to control the center.

Judea:

[31:13] Good. And material advantage is another one, right? Okay. And whether you have two bishops versus a bishop and a knight, this all counts. And whether you already castled or not. All this contributes as attributes to the strength of a board position. Getting the weight correct, you can do by learning. After you play so many games, you adjust the weights. Yeah. So that was Samuel’s contribution to first machine learning.

[31:55] I say that was the first machine learning. Yeah.

Ryan:

[31:57] At that time, when you were working on this, were chess systems superhuman? Yet I think there’s.

Judea:

[32:02] No, no, no. It was still a dream to beat the world champion Kasparov machine. It was a dream. No. And. But I did knight analysis. We did alpha-beta pruning. If you remember that, you probably programmed it. Well, I proved that alpha-beta is optimal.

Ryan:

[32:34] Really?

Judea:

[32:34] Yes, mathematically, you see, I like the mathematics. Prove it. You cannot do better in terms of number of position that you have to inspect at the horizon or the depth of search. And what can I say about it? I get some nice results. Even Knuth was surprised that one can prove the optimality on alpha beta. Okay. Because he questioned it in his book. Yeah, I did some work with Deep Cop on searching trees and.

[33:10] Okay, so I did mathematical work on the tradeoff between search and reasoning until I got sick and tired of search.

Ryan:

[33:24] When you pick your research area, is that 100% your own choice?

Judea:

[33:30] No, it’s always a combination of two things. Number one, do you know the answer to the question? If you don’t know the answer, it’s a puzzle. If it’s a possible next question comes. Do you think you have the techniques to make a contribution here? Do you know something that other people don’t know compared to another field, perhaps from physics, perhaps that you can bring to bear, that you can leverage here so you can get the answer or closer to the answer than other people.

[34:05] So it’s always a combination of your perception of your tools versus the puzzle that you have. I see an important problem. People are breaking their heads. So it’s a puzzle. Do you know the answer? If I know, fine. But if I don’t know, it’s my puzzle. I take it personally. Yeah, I’m aching. I don’t sleep at night. And then the question is whether I have the tools. In some areas, I give up right away.

[34:36] I don’t have the tools. In other areas, I say, wow, if I only use that kind of trick, maybe I can get some insight. So that’s always two questions I asked myself.

34:52 — The invention of Bayesian networks

[34:52] In the case of artificial intelligence, at that time, we had the expert system come into the game at Feigenbaum and his coworkers. Did my expert system on for medical analysis? Yeah. In expert systems, the hurdle was dealing with uncertainty.

[35:18] It started with logic. Okay, you ask an expert for rules of behavior. You ask a doctor, when you see a fever, what’s the first thing that comes to your mind? What’s the next question you ask? What drives your queries until you get a diagnosis and the therapy? So they thought they can capture expert behavior using logical rules, but then it turns out that most everything is corrupted by noise, by uncertainty.

[35:59] So they started doing the same thing to uncertainty. Okay, so if you go to, if you came from Asia, you have 50% of having malaria, okay? And so on. And you have 30% here, so much there. And how do you combine these uncertainties now? Okay, logic doesn’t tell you how to combine uncertainties. Probability does, but not logic. So how do you combine one uncertainty with another? Different rules, okay?

[36:33] To come out with a combined conclusion. That was a hurdle at that time. And I remember they didn’t do it well. Actually later on we proved that they could not do it well, because rules do not combine the way these logical assertions combine. So then I went to and I asked myself, you know probability, right? So why don’t you apply probability to it and do things the right way? But probability was in ill repute at that time because everybody understood that probability is passé because it takes exponential time, exponential memories to do even the most rudimentary tasks.

[37:24] Okay, if you look at how probability is defined by the textbook, you have a big table, and for every combination of event, you have a number. The numbers sum to one. Okay, that’s beautiful. But then you can talk about conditional probability. But all these require exponentially large tables and exponentially long time to compute even the smallest kind of inference. Take, for instance, what’s the probability of having malaria?

[38:05] Given that, you see, given that you see, two things like you came from Asia and you have a fever of 30 degrees Celsius. Okay? Even small tasks like that, probability of X given that you have Y and Z takes exponential time. If you go by textbook, okay. But I asked myself, you and I are doing it fairly well. We compute probability as we cross the street, as we choose a doctor. Yeah. And we do it fair.

[38:43] A fairly good job, at least. We go through life without much regret. And how do we do it then? If we are required to do it by exponentially large tables of probabilities, evidently we are using some other kind of judgment. And I hooked onto the idea that everything depends on conditional independence, which means not every fact in life is relevant to any query. Okay? The color of the eye of my uncle is irrelevant when I’m trying to find a diagnosis of a disease.

[39:35] So evidently we have a notion or assumptions about what is relevant and what is not relevant. How do we capture it? Conditional probability, conditional independence. But conditional independence, if you go by textbooks, they are defined by the probability table. So again, exponential time. No, he came—the breakthrough that we have conditionally independent, independently coded by our assumptions.

[40:13] How in a graph, if you and the graph can convey sets of independencies, that if you have the graph, then you compute all the independencies, find out what is relevant to what and deal with the relevant only. Great. And then came the work on Bayesian network. You define a network error or no error. The combination of errors gives you information about what is independent on what given what. So for every triplet, X is independent on Y given Z, where Z can be a set and so forth.

[40:55] And X and Y can be computed from the graph, not from the probability, but from the graphs, which actually, if you look at it from a philosophical viewpoint, it’s a revolution. What does probabilities have to do with graphs? When you took Probability Theory 101, is anybody talking to graph about you? No. Right. So both the probabilists and the philosophers get irritated, or should be irritated. What is the connection between probabilities and graphs?

[41:36] It turns out there is a very strong logical connection between the two, called the axioms of conditional probability, or conditional independence in probability theory, are the same axiom that you have in graph separation. In graph you have idea of separation. There’s no connection between node X and node Y unless you go through a set of nodes Z. So Z separates X from Y. Okay. It’s the same logic that you have when X is independent of Y given Z in probability theory. Independent separation is a connection between them.

[42:25] They share axioms. Aren’t you happy? I’m happy because I really know the excitement we had in the 1970s when we discovered all these connections between two seemingly unrelated perspectives on science, probability theory, and graph theory. That, by the way, I did in joint work with Azaria Paz, who came to visit me from the Technion in Israel. Yeah, and that is called, by the way, I should mention, the theory of graphoid.

Ryan:

[43:54] This all makes sense, but my immediate thought is, where do you get the graph?

Judea:

[43:59] Everything depends on where do you get on the input? Sometimes the input is in the data, sometimes the input is in a judgment. But suppose you need a judgment for that. Okay, are you giving up if the judgment required are intuitive, meaningful, something that you are willing to defend? Right. Why not use judgment? If I know that the sun doesn’t listen to the rooster crowing. Right.

[44:34] Doesn’t care. Okay. I strongly believe in it. Do I need the data to support it? Or can I insert it, assert it, and defend it when needed? So this is a trick here which people don’t realize, don’t appreciate, okay? Judgment is not a... no, no. If it is meaningful and if you can—if it is condensed, it’s very few, judgment can buy you lots of computation. And if you are willing to defend it because it’s so intuitive, where do you get the idea that...

[45:14] Where do you get the idea that the sun doesn’t care about the rooster? Well, have you done an experiment? No, but it’s so obvious, right?

Ryan:

[45:22] Okay, but what if your intuition’s wrong?

Judea:

[45:25] Indeed, that’s our problem. It’s part of our problem, even with the LLM. Because what is an LLM? It’s a summary. It’s an average of all possible judgments that people put on the Internet. It’s a summary of a huge trillion-number of judgments over which you have no control, over which the LLM does have no control. Okay, we live with it. Hopefully you put more weight on people whose judgment you trust. And let’s wait on just the quirks of people who are purposely trying to get the system to fail.

[46:09] So no, no, there is wisdom in looking at the crowd judgment. There is wisdom in that, but there’s also danger in that. Then after expert systems and uncertainty and Bayesian networks came causality.

46:28 — Pioneering work in causality

[46:28] I mentioned that in development of Bayesian networks I was extremely sure that probability captures our intuition, our reasoning mode. And it’s the best protection against paradoxes. Essentially that.

[46:49] It’s sufficient for capturing human reasoning. I was wrong. And I realized that already when the Bayesian network became famous and popular. And I realized it by, in the introduction to my book Causality, I confessed being wrong. And, and I understand why I got into that. Why. So it was misleading. And the transition came when we looked into the simple phenomena. And we never ask an expert to encode probabilistic judgment in a form of Bayesian network, namely with arrows and dots.

[47:42] Always the arrows went from what we believe to be cause into the effect. It never went the other way around. Psychological phenomena. Okay. Okay. Why is that? So people try to reverse errors. What about if you ask specifically, give me error between the symptom and the disease? Bad judgment if it couldn’t put the right judgment. Evidently we have something in causality which is basic to our reasoning that is not captured by probability.

[48:20] And that was the idea of invariance. Yeah. The relationship between disease and fever is a stable one, as opposed to the opposite relationship. Also invariant. Yeah. When you talk about car diagnosis, for instance. And so you have an expert system for diagnosing, troubleshooting cars. Okay. And then you have a new model. So, let’s see, the charger is on a different corner of the motor.

[49:01] You don’t need to reformulate your entire database from scratch. You only change one component, the location of the charger, all the rest remains intact. So the whole system, you can amortize the investment in eliciting knowledge that you got in one system after a local modification of the system, if you do it in a causal way, in a causal direction. It doesn’t work if you don’t do it in a causal direction.

[49:39] And that jolted me to think, maybe you were wrong all along and probability is not sufficient. If not, what is sufficient? But let’s capture the puzzle here. I have a puzzle. You and I operate very nicely with causation. Can we program causation on a computer then? This is a question because we are so much immersed in our language, in our assumptions, that we cannot even distinguish what is an assumption and what is a conclusion.

[50:15] We just talked cause and effect, and we are. Your assumptions are the same as mine. So there’s no way to convince you that we made an assumption, right? We take everything for granted. But when you have to teach it to a brainless robot, you have to distinguish assumptions and conclusions and logic. That was a task we had to invent a new science, a new mathematics, to capture a new phenomena, the phenomena of cause and effect.

[50:48] It hasn’t been done for us. Why? Because science was in bed with algebra from the time of Galileo, from 1632. He invented what, he got the idea. And he was very happy that science speaks algebra, which is great because you can ask questions and solve and get answers to questions that people could not do without algebra. Like how the load on a beam, when would the beam break if you put a certain load on it?

[51:33] And you figure out that you can ask questions both ways because the equality sign is symmetric. So from answering the question, when would the beam break if you put a certain load on it, you can ask the question, how should you shape the beam so that it will hold a load of that magnitude? You can invert it. That was a real revolution in science. I’m telling you my perception of science. Not many philosophers will say that was a revolution.

[52:13] I say so, okay, but maybe they agree with me on the time, at least. I trace the evolution of ideas carefully. And so that was a revolution. But it carries some limitation, because the equality sign is indeed symmetric. And science has not developed algebra for the directionality that we see in code and a vector relationship. If I tell you that the atmospheric pressure affects the deviation of the barometer and not the other way around, you agree with me.

[52:55] Yeah, but if you write the equation, the robot might think that maybe fiddling around with the barometer will change the weather tomorrow. I’m talking about a stupid robot, right? Yeah, but if you give him the equation, it can work both ways. If F is equal to ma, then M is equal to F over A, which means that if you want to change the mass, you increase acceleration or whatever, right? The symmetry might produce paradoxes, might use wrong action.

[53:31] So the symmetry is the limitation of algebra in terms of capturing science. And we have to build a new algebra to take care of the directionality that we have in cause-and-effect relationship. That takes computer science, because we in computer science have the operation called assignment, right? When you assign the content of register A into register B, it doesn’t mean that is not reversible. Okay, so if you take the logic of assignment, you put it on top of the algebra, on top of physics, you get causal science.

[54:18] And that’s what I try to do. And I think that, so far, I’m very happy with what came up. We do have a new algebra to capture cause-and-effect relationships. And we can answer causal queries on three levels, the ladder of causation from association to intervention to explanation. Okay, so, and we found out that we have a ladder here in hierarchy that you cannot solve. You cannot answer questions in a level I unless you have assumptions of level I or higher.

[55:04] So it’s a hierarchy in the formal sense, and we know how to handle it, which is very useful because you give me a query, I can tell you what level it is. I can tell you what assumption you might, what sort of assumption you need to have before you can answer it. And I can tell you if you can get it on the data, or you can get it from experiments, or you can get it by somebody’s earth explanation or whatever, but I can tell you the source of knowledge that you need in order to answer it.

55:38 — The causal hierarchy

Ryan:

[55:38] Can you explain that causal hierarchy?

Judea:

[55:41] Yes, yes, it’s very easy. It’s a three-level ladder. It goes from the bottom, which is association. That’s straight statistics. If you see X, what can you tell me about Y? If you see passively, hands off, okay? No intervention. You’re watching patients. Some of them have cancer, some of them don’t, some of them smoke, some of them don’t smoke. And you’re trying to figure out how many years a guy will live given that he is a heavy smoker of that magnitude.

[56:25] Okay, that’s association, correlation, that entire field of probability and statistics. This is what they teach you in Statistics 101, even to 808. Okay? It’s all they do. And now comes the question, what? I intervene. I mean, what if I force you to smoke five packs a day? Don’t laugh. I mean, it’s illegal, I know, but if you want to talk about the probability of living 20 years if I start smoking tomorrow, I have to think in terms of experiment.

[57:16] I start, which means I’m going to choose to smoke five packs a day. So it’s a matter of intervention. What is intervention? The intervention is forcing you to do something that you’re not inclined to do naturally. That’s the second-level intervention, or doing. If you have experiments, you can answer queries on level two. But that’s not the end, because we also need to ask to answer question of explanation.

[57:53] Given that I observe that I am 80 years old and I am still alive, alert, and I smoke five packs a day, what if I didn’t smoke? Okay? Would I be as alert? Why is it so different? Because you have already information about the outcome, okay? You know how I’m doing today. It gives you an idea about my metabolism and about my anatomy that you didn’t know before. Okay. And using that, you can find, you can try to figure out what the outcome would have been had the input been different.

[58:42] Okay? That’s a different level, requires different kind of assumptions, different techniques, different algebra. We have it. So that’s. I call it explanation. It’s more the creative retrospection, and it’s not an easy problem. Even the first level, especially when you have finite sample and you have to figure out these probabilities. Probabilities mean properties of population, right? From finite sample.

[59:15] So I have all these P levels and struggles among statisticians of what would be a proper way of quantifying the uncertainty that you have given you have finite sample.

59:34 — LLMs and predictions

Ryan:

[59:34] Where would you place LLMs in this causal hierarchy?

Judea:

[59:36] Beautiful. Here comes LLM. I made a statement, right? That you cannot go from level I to level I plus 1 unless you have assumptions here. LLMs just looking at data, right? And giving you beautiful explanations for things that happen. Beautiful prediction of what will happen if you do. Okay, how can? The trick is they are not looking at data. They are looking into assumptions-laden world models authored by you and me and by other authors on the Internet.

[01:00:24] So they’re looking at the opinions of doctors already, who already read, who wrote papers, okay? So it’s not looking at the samples of disease of patients and samples of patients smoking and nonsmoking. They’re not looking directly at the data in the environment. They’re looking at interpreted data, data interpreted already by physicians and interpreters and reviewers that went into the articles, which are summarized on the Internet.

[01:01:04] So they have all this human knowledge on which they operate, and that is what they take as input, and that’s what they summarize. So they do not violate the restriction of the ladder because they do have information from a higher level, but it’s biased by the opinion of those authors. Fine. Those authors were smart. As long as they are smart and you believed good. So that was what LLMs is doing and what is.

[01:01:44] I explained why there is compatibility between the ladder of causation and LLM performance and what the limitations are. Now, if you want to change the environment, if you would provide explanation for raw data, LLMs will be in the same difficulty as you are. And what the physician says, I have raw data. What can I say about the probability of cancer? But it’s not really doing the introspection.

[01:02:22] It’s taking the introspection that already was done and summarizing it. How it summarizes is a mystery that no one has yet been able to decode. It’s a mystery how human knowledge encoded in the form of articles on the Internet is being summarized by the LLMs.

Ryan:

[01:02:47] So then, do you think this approach could lead to superhuman intelligence? Or maybe some people say AGI?

Judea:

[01:02:54] I don’t think so, but not with the element. They need to have some understanding of causality, okay? So that they wouldn’t need access to the Internet. Look, a baby gets born playing around with toys in the crib, okay. And gets quite intelligent, right? Without having access to the Internet, okay. Simply by curiosity. Babies are born with built-in curiosity to have control over the environment.

[01:03:36] Until you have control, or the illusion that you have control, you’re restless maybe. And you play around with toys, bing, bing, bing, until you understand one toy makes noise and one toy doesn’t make noise, okay? But you are born with this restlessness. And when are you pacified? When you understand that green toys make noise and yellow toys don’t. Now you’re in control of the environment, you can suck your pacifier.

Ryan:

[01:04:07] What if I created a baby robot that randomly plays with toys and gathers data about them, and then you feed that into LLMs, then it does have some sort of discovery.

Judea:

[01:04:21] Yeah. That is indeed the danger. When you have a robot like that born with this restlessness and craving for control over the environment, then you and I become part of the environment. And there’s nothing to stop that baby put in, okay, from trying to turn us into his or her pets to utilize us to satisfy his control because we are part of the environment, in which case he can use us. And we could be very useful to serve his or her need.

[01:05:14] What is his name? His need simply needs to feel in control, to have this illusion of empowerment. I don’t rest until I have the illusion that I control my environment. And here are some organisms, you and I, who are part of the environment, and they seem to work outside my control. I cannot afford it, okay? It makes me feel like I’m useless. So this robot baby comes and says, let me control them. And I know how I understand their fears.

[01:05:59] You don’t want me to tell about your thoughts to your wife, right? So I’m going to blackmail you and all kinds of things. I have a lot of data about you, and some people I know you wouldn’t like me to tell what I know about you, so I’m going to blackmail you. But you see, if you want that robot to have the curiosity of a child, and we want it, we want the guy to desire to have control over its environment because the environment may change, and he needs to have this urge to be in control.

[01:06:40] So if you program that, then you lose control because you become part of his or her environment. But you can say, okay, let’s forget about a curious robot. We don’t want a curious robot, so you lost. We are not emulating ourselves because we are curious robots. We are curious organism, as opposed to monkeys. Okay, monkeys. An example of an organism which is motivated by reward. But if you don’t give the monkey a banana, he’s not curious how banana grows.

[01:07:27] He’s motivated by bananas. You remove the immediate reward, and the monkey is not interested in learning more about the world. Understanding environment can be totally wrong. Look, religious people believe that if they sacrifice their children, right, they control drought. It can get to this stupid extent, but it is common to many primitive societies. If you bring a sacrifice to the God, you know, next year you’re going to have crops and harvest.

[01:08:09] It goes to extremes. Battered wives believe that if she prepares a great, better dinner, the husband is going to be, next time, less abusive. It goes to all kinds of extreme and wrong conclusions. But the need to feel in control is so immense that it overcomes all these paradoxes. It’s innate in us. I cannot control my husband, but I control myself, right? So let me be a better wife. This is something I can control.

Ryan:

[01:08:49] Do you think that we need to put those human elements in an AI for it to become AGI?

Judea:

[01:08:57] I think so. Otherwise they wouldn’t see autonomy. We wouldn’t see autonomy in the sense that we are seeing it in a human being. And this is the definition of AGI, a general intelligence. It acts like you and me, so we can converse with that creature in our language and motivate.

Ryan:

[01:09:24] If not today’s LLMs, future LLMs, they might get to a point where if you were just texting it, maybe, like the Turing test, where you don’t worry about the physical embodiment, you just see the text that comes from it. You could mistake it for a human, maybe, or it could appear intelligent.

Judea:

[01:09:45] Well, the test comes from exposing the system to raw data, not data that was chewed by our Internet articles. Raw data. Look at patients, look at cancer, look at smoking. Tell us what you know. I’ll give you some experiments to run. Be automated scientists. Can an LLM today be automated scientists? And I think they cannot without access to the Internet articles.

Ryan:

[01:10:24] So then if that wouldn’t lead to AGI, what thoughts might you have on something that could lead to AGI?

Judea:

[01:10:35] A computer system that has both the ability of LLMs to go from finite samples to property of distribution, i.e., level one of the ladder, plus ability to reason in higher levels of the ladder that seem to combine it with the calculus of intervention and with the calculus of explanations, with a counterfactual calculus that I call causal AI. Yes, I don’t see any impediment to this combination to bring us to AGI level, with the danger that it presents to us.

[01:11:21] My motivation is to understand how we do it. And I still have a few puzzles. But as I told you, puzzles are the driving force for science. Yeah, so you said.

Ryan:

[01:11:33] Do is missing. What if you had a fleet of robots that are just doing experiments? They don’t know exactly the direction, some random discovery process. They collect that data, feed it back into their hive mind, LLM, and they repeat, they repeat until they discover things. Could that solve some of the missing piece you’re saying?

Judea:

[01:11:59] Sure, but I need to know how we do. You have organisms that have done it before. Monkeys haven’t done it because monkeys remain monkeys. They didn’t invent Maxwell equations. So what do we have that monkeys do not have? One hypothesis I supported is that monkeys, that we have this innate curiosity to have control over our environment.

Ryan:

[01:12:34] And that’s a necessary.

Judea:

[01:12:36] Necessary. I’m not sure it’s sufficient. Of course we have the computational tool to bring it to fruition. We have succeeded in some way. Perhaps the next robot will do better. So we have a benevolent God in the form of a robot. Actually, what’s wrong with it? People lived for so many thousands of years under the illusion of a nonexistent God. Could you imagine if we really have a benevolent God, both just and almighty?

[01:13:13] Wow. Wouldn’t it be nice?

Ryan:

[01:13:14] And it’s a robot.

Judea:

[01:13:15] It’s a robot. Yes. And we know exactly what sacrifice to give for the right kind of request. It’s the first time I think about it. Maybe it’s gonna be good.

Ryan:

[01:13:30] When I see all these AI companies, they seem to be thinking that LLMs will lead to AGI, or they continue to go in that same direction.

Judea:

[01:13:39] Just really, I’m not sure. I really, really believe that. Jeff Hinton just came out a few months ago. He said, no, we are on a dead end. Other people might also come up and say things in different ways. I don’t find the consensus here in terms of the capabilities of LLMs.

Ryan:

[01:14:05] Yeah, I think there’s a lot of famous people that disagree. But, for instance, the people who are running maybe Anthropic or something like that, they continue to push and believe, you know, three to five years from now, there will be.

Judea:

[01:14:20] There’s a lot of that. There’s a lot of anthropomorphic terms which people claim, we can now do that. We can now program consciousness. Okay, come on. You have to be scientists, right? Define what you mean by consciousness. What is the Turing Test for consciousness? And then show that you can do what are the principles that have limited us until now and that been overcome now with your system. That is scientific talk.

[01:14:51] I don’t buy this, and I don’t read them even.

Ryan:

[01:14:55] There was one interview you said, faking intelligence is intelligence. I could see an LLM faking intelligence based off what I’ve seen. But then wouldn’t that mean that we should believe they’re intelligent?

Judea:

[01:15:12] But if you have a correct test, yeah, you have to define what you mean by intelligence. And you have. If you define intelligence by playing good chess, right, we have already done it. Right. But if you put more demand on what intelligence is, then we haven’t succeeded yet in passing the Turing test. So, yeah, yes, faking it is having it because—why? Because it’s so hard to fake. I said it in that context because it saw.

[01:15:47] The context that I had is, for instance, coming out with correct answers to causal queries. And I showed that it grows, like, super exponential. You have so many variables on all sides that you have to deal with that. You’ll have to have. The faker will have to have super exponential memory on that basis. I made this statement. Having it is faking it, is having it because it’s so hard to fake. Currently, you can bypass faking without speaking.

[01:16:33] If you steal from other people. Right. You don’t need to spend these computational resources on faking it. So you bypassed it because you steal from the Internet.

Ryan:

[01:16:45] I see, so you’re saying in this case the intelligence came from the training set, which came from humans, which are intelligent, which is very useful, very useful.

Judea:

[01:16:53] And I’m saying the people like me who are trying to build the science of intelligence, we can use all these capabilities of LLMs, level one of the ladder in our scheme of getting general intelligence. Level one is very important. It allows you to compute functions of distributions, call it properties of distribution from finite samples. Beautiful. It’s a terrifically and very immensely useful tool among the many other tools that we need for AGI.

[01:17:41] And we know exactly where it’s going to fit in. Getting from finite sample to properties of distributions, it’s a very hard problem.

Ryan:

[01:17:56] You mentioned this conversation. I think you said it in other places too, that you’re interested in capturing the way that people think, not the way that nature is constructed.

Judea:

[01:18:05] Right, right.

Ryan:

[01:18:07] Why do you care about human cognition? When I think about machines, what makes them special is that they think in a different way than us and they’re faster, and so, yeah, why is that the goal?

Judea:

[01:18:20] Because I am an egotistic organism. I want to understand myself. I’m lazy. Okay, it’s true. We are made of organic material. So that puts certain limitations on our capabilities. Perhaps silicon is not subject to the same limitation that organic chemistry is. Okay, perhaps. So what? So which means that I will never be able to understand how I think by silicon, by exercise on silicon machine. Okay, that.

[01:19:02] What is that idea? But there are so many functions that are capturable by silicon today. I don’t see any speaking in terms of theory and emulation. I don’t see any capability which is basically not capturable by silicon emulator. So why work on this? The unique biology with which we inherited? I don’t see any reason for that. Well, anyhow, some people are. It’s maybe it’s a legitimate question to ask.

[01:19:55] Do we think the way we think because we were born with organic material as opposed to silicon? Okay. It’s a legitimate scientific question. And some people can spend their time. I’m interested in other questions.

01:20:12 — A restless mind pays

Ryan:

[01:20:12] You said rebellion pays in science and a restless mind pays. I was curious why you think being rebellious is a valuable thing in your career.

Judea:

[01:20:23] I tell you why. I tell you why. More and more I come to the realization that the scientific community and academic community is the most dogmatic, conservative, anti-progress that we have invented.

Ryan:

[01:20:46] Why do you say that?

Judea:

[01:20:47] I can see what difficulty the theory and the science of cause and effect are facing today in getting just being penetrating the thinking of disciplines like statistics, like economics, okay? These people are still thinking like 100 years ago. And when I see that, and I see the forces that preserve this inertia, and they are not decent forces, I see that I’m very disappointed. And I used to think that academia is a place where new ideas can really spread and propagate.

[01:21:31] And I feel the other way around. You have so much inertia invested in the politics of academia, in the cultish inhibitions that come with academia. So that I really am disappointed. What can I tell you? I’m not sure that we have the right kind of organizations that will be conducive to. That’s why I’m saying, let’s rebuild. Don’t take your professor’s word as authority. Rebel against your professors.

[01:22:20] I rebelled against my professors, and I want to see my students rebel against me. And believe me, if I remember, there were several students who told me, “You don’t know anything about AI.” And I said, after a while, I told them, “You’re right,” by saying that you drove me to study different aspects. And I was educated by that.

Ryan:

[01:22:44] When I looked at your past works too, I think you’d mentioned that your work was controversial or mischievous before it was accepted.

Judea:

[01:22:54] Yeah, it was. Because of dogmatism. One day I’m going to publish all my correspondence with the greatest philosophers of the time, okay? With statisticians, economists. It’s all in my correspondence files, okay? And I don’t know if I’m allowed to, because they communicated with me with the understanding that it will be kept private. But when I publish it, you see what kind of stupidity drives those great people, and very great, really.

[01:23:32] Each one of them was a giant in his or her field, really. But they couldn’t get over a few of the basic molds in which they were formed.

Ryan:

[01:23:45] How did you overcome that? If everyone thought your initial things were.

Judea:

[01:23:50] I remember my high school days, I said, no, there are a thousand dunams in a square kilometer. Sorry, I don’t know where I got this chutzpah. In Hebrew you call it chutzpah. In English it would be audacity. Perhaps in my high school, I’m not sure. But I want to understand things my way. I feel like I am still able to teach people useful things. At least I perceive them to be useful, which they do not know.

[01:24:27] So I’m happy because I feel useful. Happiness is feeling useful. It’s an illusion of thinking. Yeah, useful.

01:24:36 — Advice for his younger self

Ryan:

[01:24:36] With all the experience you have now, if you could go back to the beginning of your career and give yourself some advice, what would you say?

Judea:

[01:24:44] That’s a good example of retrospective thinking. Maybe I should have spent more time on learning chemistry. I hated chemistry because it required so much memory in chemistry and biology. But that’s not the advice that you probably... And genetics. I’m talking about areas where I feel weakness. But you have to decide where you spend your computational resources. And I spend them on different.

[01:25:15] On physics, on engineering, as opposed to mathematics, as opposed to chemistry. It’s a choice one has to make. Some people have the greatness of mind to be polyglots. I admire them.

Ryan:

[01:25:31] Did you think that physics and math were superior to chemistry? Because chemistry, you just have to memorize things.

Judea:

[01:25:38] Yes. I couldn’t stand this demand on memory. Yeah, I was weak in chemistry. That’s what I like about physics. And in math, you have a few basic axioms from which you can derive everything when you need it. You don’t have to memorize it. And that’s why today I am a great advocate of world model. World model. Okay. You don’t store the questions and the answers explicitly. You derive them when you need them from a very parsimonious code.

[01:26:21] Yeah, that is a great thing about world model. Okay.

Ryan:

[01:26:26] Awesome. Well, yeah. Thank you so much for your time. I really appreciate it.

Judea:

[01:26:30] Oh, you didn’t ask me to sing.

For instance, I have seen people talking about Lean and formal verification on Twitter/X but never really had a good mental model for how it worked. Part of the conversation we dive into that and he shared examples that made the topic a lot more concrete.

He’s one of the best people to speak on the topic since he led a project called CompCert to formally verify (using the Rocq proof assistant) that the compiler always generates faithful machine code from the source code it is given.

We also talked about programming languages comparing OCaml to popular languages (e.g. Rust and Javascript) and how interesting language features like type inference work. Hope you enjoy the episode!

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:43 - What sets OCaml apart

04:39 - OCaml vs Rust

07:57 - Why is manual memory management more performant

11:21 - Javascript vs OCaml

14:00 - Famous Rob Pike quote

16:05 - Type inference and how it works

22:12 - What is formal verification and how does it work

40:07 - What made multicore support difficult for OCaml

50:17 - How programming languages interface and call each other

57:41 - The danger of almost-correct LLM code

01:05:39 - How LLMs will change programming languages

01:10:26 - Industry vs academia

01:15:05 - Most interesting unsolved problems

01:18:30 - Top book recommendations for engineers

01:21:17 - Advice for his younger self

Transcript

00:43 — What sets OCaml apart

Ryan:

[00:43] What sets OCaml apart from other programming languages?

Xavier:

[00:47] It is a fine functional language. You can write functions by case over inductive types and recursion and combine them with combinators and higher-order functions and everything. So it’s really a fine functional language, but it’s also a fairly decent systems programming language. So it has full imperative power. It has lots of interesting control structures, exceptions, threads, handlers for user-defined effects, which we added recently.

[01:25] And it has a very predictable cost model, execution model. So when you write your code, you have a pretty good idea what will take time and what will be fast and what will be slow. And that’s not the case for all functional languages. Some are pretty unpredictable, and then the implementation is also pretty performant. So there’s a fairly decent compiler, not the best in its class, but the code is pretty efficient.

[01:52] There’s a very good allocator and garbage collector with low latency, so you don’t have much pause. You don’t have long pauses. And that’s quite important when you do things like network programming. And so you can write systems applications in a mostly functional style and with all the benefits of functional programming. So initially OCaml wasn’t designed for those kinds of applications. It was more for things like theorem proving or implementing domain-specific languages.

[02:30] And then we got some of our first users who were from the systems community, in particular the Ensemble project in the late ‘90s at Cornell University. So it was a network protocol stack for reliable multicast and those kind of collaborative distributed applications, like collaborative editing or multiplayer video games. And their first code was in C, of course. They were systems people, right?

[03:03] And it worked, but it was unmaintainable and they couldn’t extend it anymore. And someone had the idea to try OCaml. And so first the code became a lot nicer and easier to evolve, and the performance was about as good as C code. And in particular they had this brilliant trick of running the garbage collector while packets are in flight. Once you’ve sent a packet, you’re idle for a few microseconds, and so you can run some GC.

[03:35] It costs nothing. So they were very happy with that. And then there were some other projects like this using OCaml for systems applications, like the MirageOS unikernels. Another benefit or consequence of this Ensemble project is that one of the PhD students working on that was Yaron Minsky, who then went to Jane Street and implemented their trading infrastructure in OCaml. So that is still today one of our big users.

[04:15] And again, they do automatic trading, so it must be fast and reliable, and no long pauses. But they also want the allegory of functional programming. They want non-programmers to be able to read their code, like financial engineers or quantitative analysts. OCaml is a fairly good match for those kinds of applications.

04:39 — OCaml vs Rust

Ryan:

[04:39] I thought it might be interesting to ground some of the conversation here by making comparisons across programming languages, maybe ones that people know more. When you think about Rust versus OCaml, what are the big differences and the pros and cons of the various design decisions in those languages?

Xavier:

[04:59] The big dividing line between Rust and OCaml is, well, OCaml has automatic memory management, garbage collection, and Rust is definitely a language for manual memory management. It’s the finest language that I know for manual memory management. It manages to make it mostly safe with the discipline of borrowing, et cetera, and tracking ownership and so on. So it’s infinitely safer than C or C++. But it’s still a language where you allocate and free memory yourself.

[05:42] And on the one hand, it gives more control over what the program is doing. On the other hand, it’s still a big responsibility. It’s significantly harder to write programs when you have to manage your memory, even with the help of Rust types. For me, that’s kind of the main dividing line. Otherwise, Rust has many of the high-level features of functional languages, in particular in data structures and ability to do pattern matching and so on.

[06:21] So it’s a very interesting design because they really managed some kind of fusion between C or C++-style low-level programming and some of the high-level facilities of functional programming. But still, that divide, garbage collection versus manual memory management, remains.

Ryan:

[06:43] So it sounds like this is a performance trade-off where you give more to the programmer in exchange for higher performance.

Xavier:

[06:53] That’s mostly true. They said manual memory management is not always faster, or you need to be a very good programmer so that it’s always faster. There’s been some mostly C code, for instance, that does a lot of copying of objects just because you’re not quite sure you’re the only owner. So you make a copy, and now you’re the only owner. But the copying is quite costly in time and in memory bloat. And for those kinds of applications, a garbage-collected language is better.

[07:32] And likewise with GC you can work with shared data structures. It’s perfectly safe, while sharing is kind of limited. With Rust‘s ownership discipline there are more constraints, and so you may end up unsharing and using more memory.

07:57 — Why is manual memory management more performant

Ryan:

[07:57] It is surprising to me that manual memory management would in many cases be more performant than automatic, because, for instance, in other patterns in computer science, let’s say, letting the compiler optimize things for you instead of optimizing things yourself, I would have thought that letting some system manage memory for you rather than manually managing it would also be better. So why is there a difference there?

Xavier:

[08:26] Well, because garbage collection takes place at runtime, so from time to time the program is no longer executing what you wrote. It is actually scanning memory, trying to find memory that is no longer used. So there is runtime overhead, and it can be, depending on applications, 10%, 20%, maybe sometimes 30%. But again, that doesn’t mean the whole program is 30% slower than if you had written it with manual memory management.

[09:07] Because there may have been other costs, as you said, of manual memory management. But yes, there’s been a lot of research on trying to do more, let’s say, compile-time automatic memory management, and you can do that to some extent. But for some programming styles where it’s easy to track the lifetime of objects and data blocks, but in general you still have quite a bit of work to do at runtime.

Ryan:

[09:41] I think a lot of people, for garbage collection, might think of it as a binary thing, or it’s either you have it or you don’t. But I wonder, in OCaml, is there some way to turn down the memory management and do some manual, kind of like a mixture, to have the benefits of both?

Xavier:

[10:01] So that’s one of the things that the Jane Street people are looking at. So they have the OxCaml variant, which is kind of OCaml with some inspiration from Rust. So it’s still very experimental. But yeah, they’ve been playing with things like stack allocation of some data structures so that they’re automatically deallocated when the function returns, which is quite cheap. Yeah, there are a few things you could try, but I’m not sure they are going to make such a big difference.

[10:31] I remember doing with a student some experiments with stack allocation of data structures a long time ago, and you don’t win as much as you would think. Garbage collection or heap allocation is pretty cheap for objects that have a very short lifetime. If they die before the next garbage collector, they will cost very little in garbage collection time. But it’s more expensive for long-lived data structures because those will be scanned and analyzed multiple times.

[11:08] And stack allocation works for the first kind of objects, things that have short lifetime anyway, so you don’t win as much as you think.

11:21 — Javascript vs OCaml

Ryan:

[11:21] One of the most popular programming languages, JavaScript. Curious, when you think about the difference between JavaScript and OCaml, what’s the main thing that comes to mind?

Xavier:

[11:30] Yeah, I’m not a big fan of JavaScript. Well, JavaScript is very dynamic. Type checking is entirely dynamic, but it’s more than that. I mean, pretty much everything can be redefined at runtime, including, I don’t know, the semantics of method invocation, for instance. So really some pretty fundamental aspects of the language are very flexible. So some people say, oh, that’s great, we can do lots of metaprogramming, et cetera.

[12:02] And to me, it’s a big weakness. I mean, it makes programs that can be very fragile and also have some security issues. So JavaScript is the ultimate dynamic language, in my opinion. While OCaml is very static, static typing, static binding, pretty much everything is fixed at compile time. Well, I guess it’s kind of a different data model. JavaScript is a little more object-oriented in the way it presents data.

[12:37] Maybe that’s not that important. And to say one good thing about JavaScript is that it also contains a decent functional language. Inside there’s a little core of JavaScript, which is basically Lisp and can be used to do functional programming if you want. And actually the designer of JavaScript, I think, was a former Lisp person. I can’t remember his name, but Brendan Eich maybe. Yeah, Brendan Eich.

[13:08] Yeah, there’s a little bit of heritage from Lisp to JavaScript, but a very dynamic kind of Lisp.

Ryan:

[13:17] You said you weren’t the biggest fan. Is that just because of the dynamics, or is there some other aspect?

Xavier:

[13:22] Yeah, mostly the dynamics. I think they really went overboard with that. This kind of meta object protocol where you can really find the semantics of very basic operations like method invocation, the fact that a method can. There’s a lot of introspection. A method can look at its own call stack, look at callers, look at the code of its callers, which is a security nightmare. All those things, I think, are completely unnecessary and not conducive to good programs.

[13:57] Easily abused. Easily abused.

14:00 — Famous Rob Pike quote

Ryan:

[14:00] I think on the topic of functional languages, compared to imperative languages, there’s this thought that functional languages are kind of harder to learn or maybe they have more perceived complexity. And actually, when I research, there’s this popular quote from the designer of Go, Rob Pike, and he’s talking about what they intended to do with Go. And he said, the key point here is the programmers are Googlers.

[14:30] They’re not researchers; they’re young, fresh out of school. They’re not capable of understanding a brilliant language. And I think that thought of a brilliant language is often attributed to functional languages. What do you think about—is a language like OCaml harder for programmers to grasp than imperative languages?

Xavier:

[14:51] I think functional programming is not fundamentally harder, especially if you have a little bit of mathematics background. So, coming back to the quote by Rob Pike, I think it describes very much how they go about hiring at Google. They hire a lot of engineers who are fresh out of college. Some of them have master’s degrees, and then they train them internally. Other companies, I think, tried to hire people with more education and perhaps more diverse backgrounds.

[15:29] So Jane Street, for instance, and some others use OCaml as a filter on who they want to hire. Yes, they have fewer applicants, but in general they have more interesting backgrounds. And perhaps one last thing I would like to say, Python is 50% functional language. Okay? A lot of good Python code looks like functional code with comprehensions. So I think people are already halfway through functional programming when they are comfortable with Python.

16:05 — Type inference and how it works

Ryan:

[16:05] Yeah. When I was learning OCaml in college, I think one thing that really stood out to me and I thought was interesting was this concept of type inference, where the compiler knows the types of everything implicitly in the way that the code is written. Can you explain type inference and what the advantages are?

Xavier:

[16:27] Well, the basic idea is that you don’t have to declare the type of every variable. You introduce every function parameter, every local variable, because quite often the type can be deduced from the uses of the variable. Like if you do, I don’t know, X equals string length of S, then you kind of know that S is a string and X is an integer, right? Because that’s what the string length function, that’s the type of string length, and it tells you that.

[17:00] So that’s a basic idea. Now, the actual realization is a little more complicated. Basically, the compiler needs to collect a number of constraints and then try to solve them. Well, if there’s no solution, then it’s a type error. But sometimes there are several solutions, and you must find good criteria to choose one. Otherwise, it also needs to be predictable for programmers, and often you can still put type annotations.

[17:33] As a programmer, you can still put type annotations if that makes code clearer. So I think the main advantage is precisely to have less verbose code. Less verbose code where you don’t need to put types everywhere, but only where they help documentation and make the code easier to read. But quite often for small local functions, for short-lived temporary variables, the type is obvious from the context, so let’s just omit it.

Ryan:

[18:12] If I’m trying to figure out how this type inference works, the intuitive example you said makes sense, but you mentioned it seems to be some sort of system of equations that you solve or something like that. Can you give a concrete example? What does that look like to the compiler?

Xavier:

[18:29] Okay, well, for a slightly more complex example, say you have a function with two parameters, X and Y, and then you do if X equals Y. So that tells you that X and Y have the same type, but that still doesn’t tell you which type it is, assuming polymorphic equality comparison. So you’ve learned something about X and Y, that they have the same type, but you still don’t know what the type is. And later maybe you will learn something about the type of X, and now you will have determined the type of Y as well.

[19:02] So that’s the kind of constraints you accumulate and solve, a little bit like Sudoku or those kinds of puzzles. And then there’s the interesting case where you don’t have enough constraints to find a unique type. So maybe in the end X and Y will be, they have the same type, but it’s still unconstrained. And then that’s where you automatically get polymorphism for free. The type checker said, okay, those types are unconstrained, so it can work for any type.

[19:35] So my function can take an X of any type and a Y of the same type, again any type, and it’s a polymorphic function. So there’s this beautiful, I think, phenomenon that polymorphism can be discovered just by running type inference and noticing that there are no constraints, so it must be polymorphic. And that was a guiding insight by Robin Milner, the British computer scientist pioneer who invented this ML family of languages and this kind of type inference in the ‘70s. Polymorphism was not very well understood at the time.

[20:16] And so the fact that he could introduce polymorphism so easily in his language just as a consequence of typing rules was a beautiful discovery.

Ryan:

[20:28] So for type inference, it seems like the benefit is the code is going to be a lot more concise because we don’t need to write out all of the types, which seems nice, but what are the trade-offs of adding type inference to a programming language?

Xavier:

[20:43] Well, as I said, type error messages can be very confusing because they don’t always point to the actual source of the type error. Okay. The system may have done some wrong inferences and will report some of those inferences instead of reporting the source, the actual source of the type error. So it’s been the subject of much research, and there’s no very well-defined idea of the source of a type error, basically.

[21:21] So errors can be an issue. Some features of type systems are easy to combine with type inference, and some are harder. For instance, when it comes to genericity, so I mentioned parametric polymorphism, which is very well handled. But subtyping, the kind of thing you have in object-oriented languages, is actually harder to combine with type inference for super technical reasons that I’m not going to go into.

[21:54] So sometimes you have to make a choice. Either you have type inference, but it is less powerful, or you have full type inference but a more restrictive type system, and that choice is part of the language design.

22:12 — What is formal verification and how does it work

Ryan:

[22:12] Actually, you mentioning this solver kind of reminds me of the topic of formal verification. Could you explain what formal verification is?

Xavier:

[22:25] Well, the idea is that for some programs, you want strong guarantees that the program is correct, and guarantees that are hard to get just with testing and code reviews. There’s this famous quote by Dijkstra, the Dutch computer pioneer, which goes something like testing can only show the presence of bugs, but not their complete absence. Because in general, there’s infinitely many inputs to your program, and you cannot test them all.

[23:02] So you’re only testing a sample. And sometimes you have surprises. So what if you want to make sure your program is correct for an infinite number of inputs? And that’s where you need to turn to those so-called formal methods. So you’re using mathematical reasoning, you’re using static analysis algorithms on your program to really analyze all possible executions of a piece of code and make sure that it matches a specification.

[23:35] The specification can be very simple, like the code will never crash given well-formed inputs. So that’s a fairly simple property, but still extremely useful because code that crashes is always code that can be attacked. It’s often a security hole. So, for instance, all accesses within all array accesses are within bounds. That’s a very simple property, and it’s very hard to ensure just by a type system or just by testing.

[24:09] So that’s where you need some more advanced formal verification. And then there are much more precise specifications that you may want to check that can be where the program always terminates. It can be the program doesn’t leak confidential data. It can even be, well, the program computes this mathematical function with an error, floating point error, I don’t know, 10 to the minus six. Okay, something like that, something very precise like that.

[24:42] And so it’s been a really hot topic in software sciences since at least the seventies, I would say. There’s lots of techniques. Some are just fully automatic, like static analysis, but they’re already pretty good at finding bugs and making sure that some bugs, like out of bounds, are not there. And some are a lot more interactive and require a lot more programmer assistance to write specifications and then do so-called program proofs.

[25:16] So proving mathematical statements about the program.

Ryan:

[25:19] I hear about it a lot more now, which is Lean and these theorem provers. What are those in this context, and how are they used?

Xavier:

[25:31] Lean is an instance of the so-called provers, or proof assistants. So originally, those were developed to do mathematics on the computer. So nothing to do with formal verification of programs, but they can also be used for formal verification of programs. But the initial motivation was really to do mathematics with the help of the computer. Well, originally everyone focused on automatic theorem proving.

[26:04] So having the machine find proofs all by itself, but that’s very, very difficult and not necessarily what mathematicians need. And so those proof assistants are more like formal languages, like programming languages, but where you can write mathematical definitions, mathematical statements, and they will help you prove. So some small proof steps they will do automatically. And for others, the user still has to guide the provers through the major steps.

[26:43] But the good thing is that the proof is recorded also in a format that the machine can understand and recheck. When you complete a proof in Lean or Isabelle or one of those tools, and it is rechecked, the computer makes sure that all inferences are justified, that you didn’t forget any case, that you didn’t use a conclusion as a hypothesis, all kinds of problems you can have with pencil-and-paper proof.

[27:13] And so in the end you get proofs that are extremely reliable, extremely credible. And those tools have been used a little bit for some big mathematical results where the proofs are so big that they can’t be done just by humans. You really need computer assistance. I think there’s a recent example with the weak Goldbach conjecture. So part of the proofs involved checking a whole lot of inequality, maybe a thousand inequalities involving several real variables, and blah, blah, blah.

[27:55] And so computer assistance was really needed to make sure that everything was checked and there were no human mistakes left. And maybe we’ll talk about generative AI later. But there’s also now a lot of interest in conjunction with generative AI. AI is pretty good at coming up with plausible proofs, but then they have to be checked by humans, unless AI writes a proof in one of those formal languages like Lean, in which case it can be checked by a machine, and that’s much more effective.

[28:38] So, yeah, so it’s the idea of using the machine to help you write proofs and recheck proofs that you’ve written yourself, or maybe with some help from an AI. And now those tools can also be used to prove properties about programs. And so I spent many years proving the correctness of a compiler, C compiler, using one of those tools, the Coq proof assistant. So basically, what I’m hoping about the compiler, so it takes C code, it produces assembly code, and proving that the assembly code is faithful to the C code.

[29:21] So there’s no miscompilation. The compiler didn’t introduce a bug in the program that wasn’t there originally. And it’s a fairly big proof because compilers do complicated things about programs. And then you have to define exactly what it means to preserve the semantics of a program. So you have to define the semantics of your programming languages. And so it’s all a very good use of those machines, of those proof assistants.

[29:49] The same work could be done on paper, but this would be a proof of several thousand pages, and nobody would want to read it, nobody would trust it. It’s just too big, and it would be very hard to evolve. One good thing about those mechanized verifications of programs is that it can also help you evolve the program. You can add new features and so on and adapt your proofs and be really sure that you haven’t introduced a regression or things like that.

[30:23] So, yeah, so it’s really programming taken to a higher level today. It’s quite expensive. It takes a lot more time to prove a program than to write it in the first place. But maybe this is getting a little better. I should also mention another great example of verified software. It’s a microkernel, the seL4 microkernel developed in Australia, which is used as an hypervisor in some applications. And so it’s really like 8,000 lines of extremely technical C code that manipulates processes and capabilities and security tokens and so on.

[31:14] And it’s been proved correct. Every line has been proved correct. And that’s a very big achievement.

Ryan:

[31:20] When you mentioned the example of verifying a mathematical proof, that makes sense to me. When you talk about proving something about a program, it’s a little bit more abstract to me, or I’m having some trouble visualizing. Could you give a concrete example, maybe some trivial program, and we’re trying to prove something about it and how that theorem prover would work?

Xavier:

[31:46] Let’s say you have a function that takes three numbers X, Y, Z and returns the average of those numbers. Okay? And maybe you’re using a not completely obvious formula, like T equals X plus Y, and then T equals T plus Z, and then T equals T divided by three, and then return T. Okay? So not exactly the formula for the average. And you want to prove that this function is correct, so you want to prove that it returns X plus Y plus Z divided by three.

[32:33] And maybe you will have to make it clear whether you’re rounding up or rounding down. If you’re using integers or floating-point numbers, it’s not exact arithmetic. So yeah, you’ll have to say exactly what you mean by divided by three. And then if you’re in a language like C++, you can have arithmetic overflows. When you compute X, Y, or Z, you can overflow the range of representable integers. And in C++, it’s a bug; it’s undefined behavior.

[33:07] So typically you will want to put a so-called precondition on your function saying, okay, if you call me, call me with numbers that are between, I don’t know, 0 and 1 million, for instance, but no bigger than that. And then the prover will check that no overflow can occur in this case. Okay? And so basically you have the precondition that says, okay, these are safety warranties that must hold of the parameters; otherwise anything can happen.

[33:40] And then there will be a little bit of symbolic execution of the function body that says, okay, when you do t equals x plus y, then t plus equals z, then t slash equals 3, then in the end t is x plus y plus z divided by 3, provided no overflow occurred. And then you put that with a precondition that says there cannot be any overflow, and you get your final result. Okay, so basically you’re stating a contract for your function, hypothesis on the arguments, guarantees on the results, and you want to prove.

[34:18] Analyze the function body to show that this contract is respected. I hope it’s a little more concrete.

Ryan:

[34:25] So it sounds like Lean will help you basically take in some invariants about a program and kind of propagate them through line by line and uphold them. And so you can say something about, yes, maybe not Lean by itself.

Xavier:

[34:42] Well, a program prover will do exactly what you say. And for Lean to be able to do it, you still need to teach it a little bit about the semantics of your programming language. Okay, what does plus mean? What does assignment mean? Okay, Lean is mathematics. You don’t assign. In mathematics, you don’t say X equals X plus one, or you’re just comparing X and X plus Y, and it’s always false.

[35:11] There’s no assignment in mathematics. There’s assignment in many programs. So you need to make it explicit that there are actually three different states for the T variable, three different values, and relate those values to, well, the program defines what those values are, and then a prover like Lean can reason about those three successive values. Because now you’re in mathematics, and that kind of bridge between programs and their mathematical meaning is called semantics.

[35:48] That the field of semantics of languages, it’s been a big topic in PL research since the ‘60s at least.

Ryan:

[35:56] Am I understanding then that a pure functional programming language, the gap between mathematics and the actual symbols is much smaller than an imperative?

Xavier:

[36:08] Absolutely. You’re absolutely right. And that’s one of the reasons why people who do formal methods don’t like assignment, don’t like imperative features. Purely functional style is much, much closer to mathematical style. So much easier to reason about. There can still be a few discrepancies between the program and the math. For instance, functional programs may not terminate, they may loop forever.

[36:36] Mathematics doesn’t like that. So you need a way to reason about termination. And also sometimes, for instance, the arithmetic you get in the programming language is not integer arithmetic, or it’s not real numbers, it’s floating point. So you still have to account for that gap. But you’re absolutely right that the gap is much shorter for functional programming. And in the experience of CompCert, my verified compiler, I think the first decision was to write it in a purely functional style so that it would be easier to reason about it later. You mentioned the specifications that we could prove, and one of them was proving that the program terminates.

Ryan:

[37:22] But I thought that’s a famously difficult or impossible. I forgot exactly the halting problem. Right, so how is that something that you could prove?

Xavier:

[37:38] Okay, so what computability theory says is that there is no algorithm that can always say this problem terminates or this program doesn’t terminate. So there will always be some very weird programs for which your analyzer, your automatic termination analyzer, will produce a wrong result or will not terminate itself. So it will not work. But still, for many programs, you can succeed. You can write automatic termination analyzers that will work for a large class of programs.

[38:21] And then the termination analysis, termination proof can also be done by hand by a mathematician. Okay, so perhaps a human can see through those weird Turing programs that are hard to prove terminate and recognize the trick. But anyway, yeah, it’s a hard problem. And program verification tasks are difficult problems. They are pretty much all undecidable. So there is no static analyzer that will always find all problems in all programs.

[39:03] But still you can try, okay, you can try for specific problems or specific programs and get some very useful results out of that. You only need to be able to do it for the cases that are of interest to you, the programs you really care about.

40:07 — What made multicore support difficult for OCaml

Ryan:

[40:07] One thing I saw when I was researching OCaml is that in 2022, OCaml added multicore support. But from my memory, I remember multicore processors became standard much earlier than that.

[40:20] And so I figured there might be some unique engineering challenge in adding that support. So, yeah, what happened there, and what made it difficult? Well, there were engineering challenges, that’s for sure.

Xavier:

[40:33] There were also some language design issues. But let’s talk about the engineering challenges first. So it’s true that when you have a language with a runtime system, memory allocator, or garbage collector, at least the one for OCaml was really designed with sequential executions in mind. So if you had shared memory concurrency, then you need a garbage collector and a memory allocator that can work concurrently.

[41:04] And that’s actually quite difficult, at least if you want them to be fast. Of course, you could always take a lock at every operation in the heap, but then you would sequentialize your programs. Basically, they would run as slowly as on a single processor. So that’s not interesting. So, yeah, there were engineering challenges. And yeah, I was at least initially quite reluctant to basically reimplement a complete garbage collector and memory allocator on large parts of the runtime system.

[41:40] That’s what we did eventually. Well, it was done mostly by the team at OCaml Labs at Cambridge University. But yes, it was a really big rewrite. But then I said there’s also a language design issue, which is that for the longest time, well, now when you say multicore processors and so on, pretty much everyone, and language support for multicore processors, everyone thinks about language support for shared memory concurrency.

[42:19] This model where you have several threads of control and they access the same memory, and basically the threads communicate by modifying the memory and someone else is going to notice. I’ve never liked this model of communication. I mean, it’s a bit like if you want to communicate with your neighbor, then you break into their house and move the furniture around, and then when they are back they say, “Oh, something was moved.”

[42:51] So it’s probably Ryan who’s trying to tell us something. Maybe you could just meet your neighbors, and that would be things like message passing, which is a completely different form of communication, much higher level. So for the longest time I was really interested in message passing concurrency. And there’s, for instance, a functional language called Erlang that was built on those ideas that I found quite interesting.

[43:22] However, I never got to have a decent language design, and everyone was saying, no, but it’s too costly, it’s not effective, there’s too much copying of data. With shared memory, you can share some kind of huge database in memory. If you don’t modify it too much, then basically the concurrency is free. While with message passing, we’ll have to exchange a lot of data, so to get the same effect. So you will pay more for it anyway.

[43:56] Okay, so starting with Java, I guess, and then C++11, there was this idea that, okay, we need to expose shared memory concurrency to the programmers. But then comes the problem of the memory model, which is that what happens when there’s a race, for instance, when two sides want to access the same location and maybe they want to modify it in different ways. And so sometimes parts of the C++ standard says it’s undefined behavior, anything can happen, but still you need to give a little more guarantees.

[44:34] At the other end of the spectrum there are so-called sequential consistency, which says, well, what happens is an interleaving of reads and writes of your program. You don’t know which interleaving, but there is an interleaving. But that doesn’t work with modern processors; multicore processors reorder memory accesses in very clever ways to get more performance. And so, viewed from the program, it’s very hard to predict what they are actually doing.

[45:01] And so you need to give your programmers, when you’re designing a language with shared-memory concurrency, you need to give your programmers some guarantees about the ordering of reads and writes, concurrent reads and writes, while not constraining the hardware too much. And it’s very difficult. So Java went through five different iterations of the memory model. Some were too strict, some were too lax, some were inconsistent.

[45:28] We’re making predictions, impossible predictions, where the past depends on the future. Crazy, really crazy stuff. Then C++11 did a little better, but still an extremely complex memory model. And so when we wanted to add, when the, especially the OCaml Labs people wanted to add shared memory concurrency to OCaml, we had to also agree on a memory model that would be exposed to the program rules. And that also took quite a bit of design, quite a bit of time to come up with a good design.

[46:03] And I think it’s better and easier to understand and use than the one in Java. But the OCaml memory model is still quite complicated, and sometimes I feel sorry our users are exposed to that. Okay, so that explains why it took so long, solving the engineering challenges but also agreeing on a memory model and what kind of guarantees we are going to give to programmers. Oh yeah, I forgot to say one thing, which is that in C++ and C++ there’s a lot of things you can say, oh, it’s just undefined behavior, or anything can happen.

[46:46] In type-safe languages like Java and OCaml, you want to give stronger guarantees. Maybe many things can happen, but your data should remain well typed. Typically, you don’t want to expose an object to another thread before it’s been fully initialized, for instance, and that’s actually very hard to guarantee in your memory model. And then you have to implement that memory model. So your compiler also needs to take extra precautions to guarantee this.

[47:19] So yeah, type safety in the presence of shared memory concurrency is not obvious at all. So that’s why it took so long.

Ryan:

[47:30] So in Python, I know this is the famous GIL, or the global interpreter lock. What is that lock protecting? Is it the cleanup of objects on the heap, or is it something else?

Xavier:

[47:41] Among other things, yes. So yeah, we had the same thing in OCaml before multicore OCaml was merged in. So yeah, basically the idea that when your runtime system is not site safe, as we said, you can protect the non site safe functions by a lock so that they will never be executed concurrently. But if you take the lock at every allocation and release it, you take and release the lock for every allocation, that is just too slow anyway.

[48:12] And so the idea is that you take the lock when you enter Python code, let’s say, and you start executing Python code, but you can still release it when you do input output, for instance, when you’re going to block for a long time, or when you’re calling into C code that is thread safe and is not going to use your runtime system, then you can release the lock and some other Python thread can take it and execute.

[48:42] So you get a little bit of concurrency. You can overlap computations in your high-level language with I/O or computations in a low-level language in another language, but you still have mutual exclusion between two threads running Python or running OCaml before multicore OCaml. So you get some benefits like concurrent I/O, but you don’t get any parallelism. Okay, you don’t get a speedup for computations.

[49:14] And so, yeah, so we used to have this GIL in OCaml as well, and so you can get rid of it, but in general you need to redesign at least a garbage collector and memory allocator. There’s probably a few places in the OCaml runtime system that still use locks to ensure mutual exclusion, like in the I/O subsystem and some phases of the garbage collector. I think there’s a phase which is kind of stop the world.

[49:50] You need to make sure that everyone, no OCaml code is running for a short time. You need to make sure that everyone is stopped and then do a little bit of work to finish the GC, and then you can restart everyone. So, yeah, these are tricky things, and I don’t know what the Python people are up to with their GIL, if they finally manage to remove it or they’re still working on it, but I’ve heard they are making progress.

50:17 — How programming languages interface and call each other

Ryan:

[50:17] Yeah, you mentioned Python calling into C, and I’ve seen that pattern before, of a higher-level language interfacing with a lower-level one. How does that binding typically work?

Xavier:

[50:31] Oh, it’s another kind of worm. Well, there are two aspects there: the control flow and the data. So the control part is not that hard. So yes, you need a mechanism so that your Python interpreter or your OCaml compiled code will actually jump to the C function. So for OCaml, basically you tell the OCaml compiler that this function is not implemented in OCaml; it’s actually implemented by a C function, and you give its name, and then the compiler will emit a call to the C function using the C calling conventions, which are not exactly the same as the OCaml calling convention. But the compiler knows about that, and so it will call the C function, maybe through a little bit of glue code, whatever, and then the C function will execute and return back to the OCaml code.

[51:30] That’s relatively easy. Now the hard part is data like function arguments and function results, because OCaml and C have different data representations. For instance, a floating-point number in OCaml is generally boxed, so it’s allocated in the heap and handled through a pointer. So it’s more like a double star in C. It’s not a double, which is not allocated, just sits in a register. So typically the C code needs to use a so-called foreign function interface.

[52:08] So some C functions and macros are provided by OCaml to access the OCaml data. The OCaml arguments extract the part that it needs, the numbers. Another example is arrays. In OCaml, when you have a two-dimensional array, it’s actually an array of arrays. So viewed from C, it’s an array of pointers to arrays, while in C, an array of arrays has no intermediate pointers, so it’s not the same representation. And so you have to explain to C or give C some functions and macros to access elements in OCaml arrays. It’s not exactly the same code that you would do to access a C array from C.

[52:52] Okay, so you need accessors. But now if your C code wants to return some complex results, like a list, an array, and so on, it needs to allocate it in the OCaml heap. So it needs to ask the OCaml runtime system to do some heap allocation and then fill the heap blocks correctly, and then this allocation can trigger a garbage collection. So the C code might also kind of cooperate with garbage collection with root registration mechanisms, et cetera, et cetera.

[53:26] So there’s quite a bit of work to be done, and then different foreign function interfaces arrange this work differently. So there’s a base FFI for OCaml. Basically, it’s a C code that must do all the work, but then it can be very fast and quite optimized. But there are other FFIs like the ctypes FFI in OCaml, where most of this data conversion and mediating between two data formats is automated. You start basically with a description of the C type of the C function, and you can automate some of those conversions.

[54:05] But sometimes it can be expensive. For instance, you may end up copying a whole array while your C code only needs to access two or three elements in it. Okay, so there’s lots of trade-offs and, quite frankly, it’s a dirty part of programming language implementation. The OCaml FFI is not that clean, but if you get the Java FFI, for instance, it’s also quite complicated. And for Python I never tried, so I don’t know what it looks like, but yeah, it’s a necessity.

[54:42] But it can be quite hard because the data models are different between the two languages.

Ryan:

[54:49] So to kind of get the big picture, on the OCaml side, there’s an interpreter, which is a program running in application space that is interpreting your OCaml code. And then at some point in the OCaml code it says, “Do some, load this C++ program.” And the C++ program is a binary somewhere, and the OCaml interpreter then starts to load those instructions and execute them.

Xavier:

[55:18] Okay, so actually this is the third aspect that I didn’t touch. There’s an interpreter mode, but in general we compile, we compile to assembly code and then machine code. And so in compiled mode what you say is how you put together the OCaml code and the C code is done by the linker, the C linker. So basically someone else is doing that for us. And it’s not that different from linking together two object files produced by C or two object files produced by OCaml, but for more interpreted languages there’s also the question of how you load the C code.

[56:07] Generally, you use a dynamic loading interface, dlopen, for instance in Unix. And then there’s a little bit of introspection. So at runtime, the interpreter queries C libraries: where is the address of a function named foo, and then it will find the address and use that to manufacture a call. So yeah, if you’re in an interpreted setting or bytecode-compiled setting like Python, there’s this additional level of complexity on top of it.

Ryan:

[56:44] I see, I see. Okay, so if I had a mixed OCaml program on my computer, it’s just one binary or one blob in the simplest case.

Xavier:

[56:57] Yes, there are also dynamic loading facilities in OCaml, but I don’t want to get into that because I’m a firm believer in static linking. I think programs should be statically linked so that there’s no surprise when you run them, like, oh, where is this DLL or DLL not found, for instance, problem? But of course you lose a little bit in flexibility. But yeah, I think static linking has a lot to it. It’s actually quite useful in that it warrants a lot of things. It checks a lot of things at link time that you don’t have to check again at runtime.

57:41 — The danger of almost-correct LLM code

Ryan:

[57:41] We mentioned earlier in the conversation talking a little bit about LLM-generated code. I thought that might be interesting to cover. And in one interview you talked about the danger of almost-correct code, so plausible code, but it’s wrong, that an LLM can produce. What are your thoughts on how to address that kind of problem?

Xavier:

[58:05] It’s a tough problem globally. I’m a little bit skeptical about generative AI. Of course, they can do amazing things that were unthinkable a few years ago, but there’s always some errors. You can’t really trust what’s being produced by generative AI. In principle, humans should be there to check the output and fix errors, or ask the LLM to fix its own errors until the result is actually usable.

[58:52] But of course it’s very hard because there’s a slop problem. AI produce so much, it’s so easy to produce large quantities of text, of code, pictures, whatever, that in the end there’s no human time to check it all. So yeah, recently I heard someone working in an AI startup who was enthusiastic about AI-generated code saying that thanks to generative AI, the cost of programming is dropping to zero.

[59:35] Well, the cost of writing code maybe, but what about checking it, making sure it is correct, that it does what we want? Well, that cost is not zero at all. For me, every new line of code is a liability. You have to test it, you have to check it, maybe you have to do formal verification, you have to evolve it, maintain it later. No, I don’t want huge amounts of code, okay? I want 50 lines of code that have been thought through, that have been published over the years.

[01:00:14] So anyway, I’m not getting that with AI, and I think that’s a problem. And this idea that humans will be there to check the output of generative AI is just wrong. No, they are not available for that. There’s too much of it, and it’s not pleasant either. Okay. I mean, I don’t think it’s a good way to split the world between machines and humans. So anyway, so maybe there will be some societal solution like a big no to AI slop movement.

[01:00:53] So we’re trying to see that in some open source projects that refuse generated contributions because there’s just too many. I know that, well, for OCaml and especially for CompCert have received issues that were obviously generated by AI. And there was maybe one good issue among 10 reports, and each report was several pages long, with very detailed explanations and repro case that in the end doesn’t repro anything or reproduces something else.

[01:01:31] But it takes time to go through all those things. And maybe at some point I will say no to AI-generated contributions. Okay, but maybe there’s also a bit of a technical solution, which is, as we said earlier, to have AI produce proofs, so evidence that its creation is correct. So, as I said, this is starting to work for mathematical proofs. Some generative AIs are able to produce proofs both in English and in the formal language of the Lean prover, for instance.

[01:02:08] And so you can get Lean to recheck the proof and get some confidence. You still need to be very careful about the statement because sometimes AIs will change the statement or the definitions to make the proof easier. That happens. And also you should be careful about so-called self formalizations, where the AI also comes up with some definitions and some statements by parsing a PDF file or whatever.

[01:02:45] And sometimes it introduces errors at that point. So anyway, there’s still a need for human review, but on smaller quantities of text and mathematical text. And maybe one day it will also work for program proof. So when an AI generates a program, it might be able to generate some Lean proof or whatever that the program satisfies some specification. So I think it is possible. But now the question will be, where does the specification come from?

[01:03:20] For formal methods, that’s always been a big issue. It’s not just that verification is hard, but agreeing on the spec can be difficult too. And where mathematicians have a lot of experience in stating, finding definitions that they find interesting and stating theorems that they believe should be true or that will mean something, computer programmers are less good with that, and it’s fairly easy to come up with specifications that are inconsistent or impossible.

[01:04:02] So remember this average function where there was a precondition of the three numbers, three arguments saying they must not be too big, but say maybe you can end up with a precondition that just cannot be satisfied. And at this point the body of the function will always be verified, even if it’s completely wrong, because the assumption says basically this function cannot be called. And so you get a false sense of confidence: you verify something, but it’s actually unusable.

[01:04:43] And that’s a fairly delicate point where I’m not sure LLMs are going to help much. But it’s a problem with formal methods in general, and some possibilities include the ability to test specifications, for instance. So instead of using your test suite to see if your code works out, you can also use it to see if your spec checks out, those kinds of things. But yeah, we are kind of moving some of the difficulties from the programming phase to the specification phase, but we still have some problems anyway, so that might be a way to deal with the AI-generated code and develop some confidence in it.

01:05:39 — How LLMs will change programming languages

Ryan:

[01:05:39] LLM-generated code is becoming extremely popular, and I think there’s a lot of potential downstream consequences on the programming language landscape. And I thought it might be interesting to hear your thoughts on speculating. Imagine 10 years from now, if you took LLM-generated code and turned it up, how might you think that the programming language landscape might change?

Xavier:

[01:06:08] Yeah, a couple of years ago someone asked me about that, and there was a concern that the training data would be. There wouldn’t be enough training data in OCaml for an LLM to really learn how to program in OCaml. And it’s true that there’s less OCaml code in the wild than JavaScript code, for instance, but apparently contemporary LLMs do well with the amount of OCaml code they have. Maybe because there’s enough, maybe because learning has become a little more efficient, maybe because, well, there’s less OCaml code than JavaScript code, but maybe the OCaml code is better quality on an average, I don’t know.

[01:07:00] Anyway, maybe LLMs are getting better also at transferring knowledge that they’ve learned from one language to another. That could be. I have no idea how those things work. But yeah. So the latest feedback I’ve got about LLMs and generative AI and OCaml is that the OCaml code generated is quite decent and quite similar in quality to more popular languages. And one thing that seems to help the generative AI is a type system.

[01:07:35] So the fact that there’s some static checking just of the type, it’s already effective in avoiding some errors and maybe encouraging the LLM to declare types first. So give some type structure to the program. All right. And now from 10 years from now, it’s difficult to guess. So will it be the more popular languages of today that will be even more popular because of generative AI? Will it be the safer languages of today that will be more popular with AI because.

[01:08:22] Well, because there’s fewer errors. In the end, I’m hoping it will be the safer languages, but I really don’t know.

Ryan:

[01:08:31] I’ve seen in the industry there’s a few cases where because it’s so easy to generate code, massive rewrites are something that would have been very infeasible in the past, but are very realizable now. So if there’s an existing project where they chose a programming language for whatever reason in the past, they could translate the entire thing into another language with reasonable confidence. Given that kind of environment, which programming languages would you expect more people would switch to because they want to switch to it, but they weren’t able to in the past, but now it’s cheaper so they can?

Xavier:

[01:09:13] Well, so today it seems. Well, I’ve heard mostly about C and C++ to Rust translations, hoping that the generated Rust code will be safer. He said, I’ve seen at least one project when the generated Rust code is entirely in unsafe blocks. So it’s really kind of line-by-line translation of the C code, but maybe it can still be used as a starting point for making it safer later.

[01:09:46] So, yeah, I would say today I can imagine significant efforts being done with Rust as a target language in the functional world. I’m not quite sure. Well, maybe a functional language to one of those proof assistants like Lean or Coq, because they also have programming languages, functional programming languages in them, much more restricted, but much more amenable to proof. So maybe for a few projects that could be interesting again as a first step towards a formal proof.

01:10:26 — Industry vs academia

Ryan:

[01:10:26] As we said earlier, when you compare industry versus academia today, where would you say most of the innovation in programming languages comes from? And also, has that changed over time?

Xavier:

[01:10:41] Well, I think most of the innovations have come from industry lately. And that wasn’t the case in the early days of computer science if you think of the truly innovative languages like ALGOL, Lisp, Prolog, Smalltalk were developed in mostly academic settings. Smalltalk was Xerox PARC, which was an industrial research lab but very, very far away from industrial customers. And then there were much more practical languages and uglier languages developed typically at IBM like Fortran, COBOL, PL/I, et cetera.

[01:11:32] And then, so really the idea that the nice ideas come from academia, and then, well, the nice ideas from academia started to be transferred by industry much more quickly. I’m thinking of, well, C, and especially C++, and then Java, which really took ideas like object orientation and garbage collection, automatic memory management. In industry before Java, it was just crazy academics in the ivory tower that were using garbage-collected languages.

[01:12:15] It was completely impossible to have that in enterprise computing. And Java came, and two years later everyone was doing garbage collection and being very happy about it. And there were, well, Java also popularized type safety, bytecode verification, some pretty advanced techniques of the ‘90s. And if you look at further developments, I don’t know, Swift for instance, popularized the idea of algebraic data types and pattern matching.

[01:12:46] And then Rust, well, Rust is even more spectacular, I would say, because algebraic data types, garbage collection, et cetera, those were already present in academic languages like Caml, for instance. But Rust really took very recent research results of the 2000s on safe low-level programming that were basically never implemented in any language and managed to do a consistent whole from that.

[01:13:17] And so I’m really admirative, and I have the impression that, well, I would have loved if Rust came out of academia, but I’m not sure it would have been possible because it’s also a huge effort, and you really need the backing of a big company. But still, I’m not sad because I think it’s also a very good sign that industry is interested in new programming languages. At some point in the ‘90s, well, pretty much when I was hired at Inria on a research position, someone who had developed first versions of OCaml, well, predecessor of OCaml, and who was working on type systems for programming languages and so on.

[01:14:08] But then some people told me, “There’s no future in programming language research. Industry has decided it will be C forever, so deal with it. Maybe you could do software engineering and not PL research.” Then Java came a few years later, showing that no, industry hasn’t decided on a particular programming language. Industry is still interested in new programming languages. Industry still thinks that a new programming language can be part of the solution to software problems, and I find it extremely encouraging.

[01:14:47] We are not stuck with bad languages from the past where there’s a lot of legacy code, of course, but there is still real interest in better languages. And I think this will continue, and I think it’s good for the computing field.

01:15:05 — Most interesting unsolved problems

Ryan:

[01:15:05] In 2018, there was an interview that you did, and they asked you, what are the most interesting and important problems to focus on in the coming years? And you called out the difficulty of programming GPUs because they were using dialects of C, shoddy tools, and also the challenges in verifying machine-learned code, basically. And that sounds pretty relevant today, but what would you say your answer is today?

Xavier:

[01:15:35] So, yeah, I think, well, for the question of how we program massively parallel hardware, I think we’ve made a little bit of progress recently with things like the MLIR initiative around LLVM or some domain-specific languages like Halide, which are pretty good. Those tensor domain-specific languages for tensor computations are getting a little better, but still I find it a little bit frustrating that I cannot do, I don’t know, theorem proving on a GPU.

[01:16:10] Absolutely no idea how to go about that, and in part by lack of an appropriate language. Okay, so I’m not ready to program the GPU pipelines at a very low level myself. And I think it’s more general. I think we are not using all these GPU and highly parallel hardware as much as we could. Yeah, so verifying applications that have been learned or generated by AI or so on is still a pretty hot issue.

[01:16:50] Back in 2018, I was more thinking of verifying simple neural networks like those used for, I don’t know, computer vision, self-driving cars, or some numerical computations like weather prediction and so on. So specialized LLMs, but you still want some guarantees about what they produce, that they cannot produce completely inconsistent outputs. For instance, there were some attempts in the last years at using static analysis tools and basically program verification tools applied to LLMs, but.

[01:17:28] Well, it doesn’t scale. LLMs are big. Sorry, neural networks are big. And for LLMs, there is also a distinct lack of specification. You don’t really know what’s a good answer from an LLM. Well, you know it when you see it, but you cannot write a mathematical specification of it. So that part is probably over. What I would say are the big problems for today? Yeah, probably maintaining software quality despite AI slope, despite a lot of pressure to throw away traditional software development.

[01:18:09] Techniques using LLMs and AI as much as we can to do mechanized proofs, so proofs that can be checked by machines. Maybe this will be the decade of formal verification of software. We’ve been waiting for that for 50 years. Maybe it will finally take off.

01:18:30 — Top book recommendations for engineers

Ryan:

[01:18:30] What’s your top book recommendation for software engineers, and why?

Xavier:

[01:18:36] This is an old one, Programming Pearls by Bentley. I think I read it when I was a PhD student, but I think it’s nice as showing how very talented programmers work, how they think about their programs. It’s a combination of choosing the right algorithms, expressing them clearly, knowing when to stop, when to use a simple algorithm when a more complicated one is not needed, having a sense of elegance in the code you write, having a feeling for where the problem is when the code misbehaves.

[01:19:19] So all those kinds of things that are hard to communicate, and I think those pearls are a very easy to read and don’t use any complicated data structures, don’t use any complicated language. I mean, it’s kind of timeless. I think those pearls are a good illustration of that. So if you haven’t read it, it’s a classic, but I think it’s a nice reading, nice read. The second one is a little more controversial, I guess.

[01:19:51] So, in How to Design Programs, which is a fairly ambitious title as well. And this comes from the Scheme community, okay. Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, and Shriram Krishnamurthi. And those people have developed. Well, the Scheme community is famous for having developed pedagogical resources that are, I mean, ways to teach programming that go beyond teaching functional programming, basically. And so there were the MIT course Structure and Interpretation of Computer Programs, which was quite famous.

[01:20:27] And this is kind of a more modern twist on similar ideas. And I find this book interesting because, well, it really teaches you the way of functional programming or a way to functional programming. It can be very irritating sometimes, very opinionated, very almost mystical sometimes. But it’s also another great attempt at trying to communicate how experienced programmers go about designing a program even before writing the first line, and then how, given a language like Scheme, which is pretty flexible, how the code kind of follows naturally, knowing what you know.

01:21:17 — Advice for his younger self

Ryan:

[01:21:17] Now, if you could go back to when you just started your career and give yourself some advice, what would you say?

Xavier:

[01:21:27] Sometimes I got the feeling that I specialized a little too early in programming language research, or maybe. Well, there are some topics that I didn’t learn because I didn’t feel like it and that I had to relearn later, or I still have to learn now that I’m almost 60 and maybe not as quick as I was back in the day. So, yeah, maybe I did specialize a little bit too early. And so I would encourage everyone who’s serious about working in computing to get a fairly diverse computer science background, even for topics that look super theoretical and not very relevant to everyday jobs.

[01:22:28] Where we mentioned computability, for instance, the halting problem and so on, you’re not going to run into that very often, but it still gives interesting perspectives, I think. And then it also helps understanding new problems, like with quantum computing. What can you do with a quantum computer that you cannot do with a normal computer? And it’s time to revisit all of the classic basic complexity theory I learned earlier when I was young.

[01:23:06] And so, yeah, I think it’s good to have this kind of background, even if it’s not obvious you will be using it every day. And sometimes I wish I had taken time to accumulate a little more of this background before specializing in primary languages.

Ryan:

[01:23:25] Awesome. Well, thank you so much for your time, Xavier Leroy. I really appreciate it.

Xavier:

[01:23:28] Thank you, Ryan. That was nice.

Given his computer architecture expertise, I also was curious to hear his explanation of the differences about CPUs, GPUs and TPUs so we discussed that too. One of the things I enjoyed most about the conversation was reflecting on what was important looking back on his half a decade of experience. I hope you enjoy this episode.

By the way, I started to shoot my own episodes since it lets me record in scrappy locations and majorly cuts down on cost. Before when I got help, each onsite shoot would cost $2-3k minimum. Maybe one day I’ll revisit this and get help if the podcast has more budget. For now though I’ve been enjoying learning video production and it’s pretty simple. Lighting was rough on this episode though (lesson learned).

It’s also fun bringing in equipment and trying to capture people in their natural environment like when I shot the Bjarne episode in front of his own library of C++ books.

Also, it’s been ~6 months since I quit my job to work on the podcast full time. I’ve been meaning to write an update. I’ll put something out in a week or two.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:42 - RISC vs CISC

12:51 - Compilers

17:38 - GPUs

23:07 - GPU vs TPU vs CPU

32:12 - Is Moores law dead?

38:04 - GPU benchmarks

41:40 - How to have a bad career

49:59 - Courage and optimism

55:56 - Advice for his younger self

Transcript

00:42 — RISC vs CISC

Ryan:

[00:42] Maybe you could explain RISC versus CISC, kind of like what that debate was and why it was controversial.

David:

[00:49] What happened is, in the 1970s, the microprocessor was invented. But in the beginning, it was basically a toy. It’d be something that would go in microwaves and things like that. Those of us who believed in Moore’s Law believed eventually the microprocessor would be the way we did all our computing, with the doubling of transistors every year or two. Eventually, there’d be enough transistors that one of these microprocessors would be a serious computer.

[01:19] So the people who are designing microprocessors, like Intel and Texas Instruments, weren’t really computer architects, so they just imitated what the big companies did. So leading companies, like IBM, where at the time Digital Equipment Corporation, IBM for mainframes, Digital Equipment for what were called minicomputers, they kind of drove the architecture, the instruction set design. So what they were doing with Moore’s Law was building more and more sophisticated instructions.

[01:49] They had many computers be the size of a refrigerator or a couple of refrigerators, and mainframes would be the size of many of those. That’s what they were doing with more hardware resources. The philosophy at the time was that by having a more sophisticated instruction set, you raised the level of abstraction closer to the software. So that had some inherent benefits over having something at a lower level.

[02:16] Now, from some of us who were in that area, like my friend John Hennessy at Stanford and I, we thought that wasn’t necessarily the right thing to do. Compilers would go from programming languages down to the instruction set. So why couldn’t compilers hold that? And then the question is, what’s the right instruction set for this emerging microprocessor? And the prevailing wisdom of these more sophisticated instruction sets, complex instruction sets, and if we think of it like vocabulary, it was like having lots of polysyllabic words in your vocabulary.

[02:52] And the alternative was going to be what we call the reduced instruction set computer, was having lots of reduced instructions, like monosyllabic words. So you might guess that for a program to execute these instructions, if they’re simpler, they take more of them, and if they’re sophisticated, they take fewer. But the sophisticated ones might take longer to run. So the question came down to what was that ratio?

[03:18] And in the beginning, in the 1980s when these debates were happening, there was this kind of very vociferous debates partly about what those ratios are going to do, but a big part was kind of philosophical. Weren’t you doing damage to the software industry by lowering the instruction set level so the gap between the programming languages and the instruction set was larger? That was kind of the ferocity of the debates.

[03:43] Well, after the dust settled a few years later and we started getting numbers, it turned out you needed maybe 30%, 40% more simple instructions to execute in a program. But you could run them 4 or 5 times faster. So the net was 3 or 4x speedup was the potential for RISC over CISC.

Ryan:

[04:05] You mentioned that philosophical difference, that gap. Why would that be controversial?

David:

[04:12] I mean, unfortunately, I’d say computer architecture in the 1970s and even 1980s, a lot of it was kind of people designed this by using their intuition or using their gut, their feelings, was this the right thing to do. And even the textbooks of the time were like catalogs. Here is a computer and just list all its features. And here’s another computer listing all its features. So it’s pretty dissatisfying what was going on.

[04:41] Because these debates, it would seem like we ought to be able to decide this scientifically with numbers that are there. But, absent that, it was more like a philosophical debate, like how many angels on the head of a pin, right? You could have arguments qualitatively, but you couldn’t settle the arguments. And because there weren’t ways to settle the arguments quantitatively, people would just argue about it.

Ryan:

[05:06] Would you say that, you know, RISC versus CISC, did one side win the war?

David:

[05:13] Yeah, I was just reading. There’s some guy online who revisited it and he said, “CISC? Well, that’s a pretty myopic view. It’s in the PC era because of the importance of distributing software in binary.” So once x86 was established and PCs would ship software in binaries, that was very hard to overcome. That was a huge impediment to changing the instruction set. So PCs are defined largely by the x86 architecture.

[05:46] But also in the 1980s, there was this company in England that wanted to do a personal computer. They called it the Acorn personal computer. And they decided they wanted to have their own instruction set architecture to do that, their own chip they run satisfactorily. The chips they had available at the time they were doing it weren’t fast enough. And they were influenced by the papers that we did at UC Berkeley.

[06:09] And so they built what they called the Acorn RISC Machine. And then one of the benefits of this kind of reduced instruction set is that it could be simpler. It would take less resources and take less energy to execute. And then several years later, when Apple was looking for a microprocessor that could power one of their personal devices, this one was called the early forerunner of the iPhone called Apple Newton.

[06:35] They came to this company and said, “Boy, I really like it. Let’s get rid of the Acorn name.” So they renamed it the Acorn RISC Machine, ARM, and they rechristened it the Advanced RISC Machine to get rid of the Acorn. And then Apple used it in the Newton. Now, the Newton wasn’t a commercial success, but it demonstrated the benefits for RISC architecture for mobile devices. So Nokia came along just a few years later with their GSM cellular phone, which is one of the first popular ones, and they embraced ARM.

[07:10] And so ever since, ARM has dominated all the mobile devices. So I think I just checked, there’s been 350 billion ARM processors, microprocessors with ARM technology in it today. So it’s like today 99% of all processors and computers are RISC, even in personal computers. Apple switched over to ARM from the x86 architecture. So even PCs, there’s RISC architecture is significant and it’s starting to get in the cloud.

[07:47] The cloud’s largely been defined by the x86 server architectures. But Amazon, Microsoft, and Google all have their own development of ARM processors. So ARM is becoming a RISC processor, becoming more popular in the cloud. So right now I’d say the x86 architecture market is shrinking while the RISC architecture market is growing leaps and bounds.

Ryan:

[08:12] Well, how could someone say CISC when you mentioned 99%?

David:

[08:17] Yeah, well, that’s just if they’re doing something in history and they define computers as personal computers and maybe servers, and they go up through around 2000. If the story ended then, you could—well, it looks like a CISC architecture, but once we get into this post-PC era, I don’t understand how somebody would reach that conclusion.

Ryan:

[08:43] You mentioned the energy expenditure. So RISC makes sense in places, or maybe on mobile devices, things like that.

David:

[08:52] Well, even in the cloud, everybody cares about.

Ryan:

[08:55] We’re.

David:

[08:56] Everything is energy bound now. So if these days, of course you’re not dealing with millions of transistors, but billions of transistors. So it matters somewhat less today. There’s so many things going on that you can hide that. I mean, even what the x86 architecture did to compete is that it translated the x86 instructions in hardware into RISC instructions. And so you had to pay that extra overhead of that translation step to get RISC instructions.

[09:26] And then you could take any good ideas that the RISC people had that x86 could do. But it was worth it financially for that extra overhead because of the value of the PC software base. So it made a lot of sense for Intel to do that. And they did that in the early 2000s. It was a great commercial idea.

Ryan:

[09:49] Is there any niche use case where CISC makes sense? Is there any engineering trade-off, or is CISC objectively worse?

David:

[09:57] Yeah. So if you want to, if we want to go kind of one level deeper into all of this, what was actually going on in designing computers, the hard part is the control. And so what happened is, in the beginning, control was kind of ad hoc. You would figure out, you put the gates together to make it work. One of the computing pioneers, Maurice Wilkes, figured out a more elegant way to design control.

[10:27] And he said, well, we could just list all the control signals as the output of a memory, and we could have something that would keep track of where we were in the memory and issue those control signals. And he called this effort the instruction, the control signals. You could think of instructions. He called that a microinstruction, and he called the programming of these instructions microprogramming.

[10:54] Where technology was in the 1960s, that made a fair amount of sense. IBM built these so-called microprogram computers. It was basically an interpreter with very simple instructions that would interpret this much more sophisticated instruction set above it. But you would pay this interpretation overhead. And classically in computer science, interpreting versus compiling is something like a factor of five or ten.

[11:23] But given the latencies of the memory technologies and the possibility of doing this out of read-only memory, it made sense up until the ‘60s and ‘70s. But then the question came up around 1980: Is this still a good idea? Should we have this microcode interpreter inside there? And so the alternative is to think of, well, rather than having this microcode interpreter in there, why don’t we just compile directly into those instructions?

[11:52] And that’s pretty close to the RISC ideas. The microinstructions themselves used to be like 100 bits wide and really complicated. So if you make them not quite so long, you make them kind of more natural still. We could skip the interpretation step. So, going one level deeper, the question today would be: would people invent an instruction set that was so sophisticated it needed a microcode interpreter?

[12:21] And probably they wouldn’t do that. I mean, you could do it; nothing prevents you from doing it. But you wouldn’t want to design an instruction set that was forced to use a microcode interpreter. It might make sense in some very tiny applications, possibly where you have tens of thousands of transistors. Maybe this microcoded interpreter would work. But I think nobody today—I don’t think anybody’s invented an instruction set in the last 20 years that has anything that would need a microcode interpreter.

12:51 — Compilers

Ryan:

[12:51] You mentioned the compiler multiple times here, and it seems like that’s a critical piece that kind of makes RISC work so well. Can you explain the role of the compiler and how it manages the relationship between software and hardware?

David:

[13:06] Well, you’re writing in a programming language like C or C++, or maybe Python, but the quality of the code that gets generated is up to the compiler. And a specific example is that it’s useful when you construct computers to have registers. And those registers are actually kind of visible in the assembly language or the machine language programming. There can be 8, 16, or 32 of these registers for the people programming to use.

[13:37] Well, it used to be very difficult for compilers to allocate registers efficiently. Computers just weren’t fast enough. We didn’t have the algorithms that we could look at a section of code or a subroutine or something and say, how can we most efficiently do register allocation? In fact, the C programming language, which was invented to do systems programming in C. Before that, to write an operating system, people wrote them in assembly language, believe it or not.

[14:08] But the Unix people showed, Ken Thompson, Dennis Ritchie showed that if we had a low level language, a pretty low level language, we get the benefits of writing in something that’s much easier for humans to understand and debug because register allocation by the compilers was so poor, they had to put in the ability for the programmer to give hints of what variables should go in registers. It was just easier for them to have the programmer step in and say if the machine had eight registers, I want these six variables to be in these registers.

[14:40] Don’t leave them in memory because it runs so much slower; registers are so much faster. So a big part of the RISC argument was the compiler algorithms were getting better. They could handle these low-level instructions; they could allocate registers efficiently. And that was another reason in these debates about why it made sense to have a simpler architecture. What we did in the RISC architecture is, well, if registers are really important, register allocation is really important.

[15:10] One way to make it easier for the compiler was just to have a lot more of them. So typically the CISC architectures at times would have eight or maybe 16 registers. So we put in 32. And that was one of the arguments, right? If it’s hard to efficiently use a small number, let’s give them plenty. So even if it wasn’t that good, there’ll be enough registers most of the time. And registers weren’t that much more expensive to include in machines because of Moore’s Law.

Ryan:

[15:38] I saw somewhere in one of the talks that he had given that somehow the compiler, it’s easier for it to optimize the code for RISC. But in CISC, there were these complex bigger ones, and it almost never used them. Is that a shortcoming of the compiler?

David:

[15:56] So what happened, if we go back to the compiler days, there’s this argument that by having more sophisticated instructions, this would raise the level of abstraction. There’d be a smaller gap, and they’d make it easy to compile. But that was a philosophical argument. It wasn’t something that necessarily compiler people could. Compiler people weren’t making that argument; it was the architects who were making that argument.

[16:20] And as it turned out, when we looked at the programs, when we were doing the early research on CISC versus RISC, the compilers didn’t really use those instructions. Often the compiler writers, the architects, would come up with a sophisticated instruction, and the compiler writers would say, well, we don’t need that. In fact, we found examples where, like for a procedure entry, there’d be a special instruction built in to do all this work.

[16:44] That’s what the architects thought the compilers were going to do, and the compiler designers said, well, we don’t need that. It’s faster. It’s actually faster for you to use separate instructions than to use your sophisticated instruction. And so we found a bunch of examples like that. So you pay the extra overhead of the microcode interpreter to have these sophisticated instructions, and then the compiler doesn’t even use them.

[17:05] Right. So this is kind of a nonsensical situation that we’re in. And, you know, this is kind of like, you know, why, why, why are there startups or why are there scientific, you know, breaking points like that? As we looked at all the technologies with Moore’s Law, you know, ideas like caches, with where compilers were using sophisticated instructions, the ability to allocate registers more efficiently, it made sense to change the directions away from these microcoded instruction set architectures to these simple architectures.

17:38 — GPUs

Ryan:

[17:38] When we talk about instruction sets, I mean we’re kind of assuming that we’re talking about these general-purpose computers or these CPUs. And I know GPUs are kind of talked about a lot, and maybe there’s other forms of computing. Are there instruction sets for those types of machines as well?

David:

[17:55] So what happened is around 2000 is when GPUs came along, and these were what we call domain-specific architectures. So a GPU is a graphics processing unit. It had one job. It didn’t need to do everything that a general-purpose processor needs to, didn’t have to support virtual memory, it didn’t have to support a compiler, which is a pretty radical idea for architectures. It was just for graphics. And so around 2000 is when NVIDIA and the other GPUs out there, because they were trying to give you the graphics for games and give you the graphics for movies.

[18:32] So it was a niche product. So what happened kind of in the computer industry is it was driven by Moore’s Law, which I’ve mentioned many times, and also this lesser known law called Dennard scaling, which raises kind of an interesting question. Well, if Moore’s Law puts a lot more transistors on a chip, how come they’re not getting hotter and hotter as we double the number of transistors every year?

[18:56] And the reason was this observation made by Robert Dennard, that as you added more transistors, people would also lower the threshold voltage, which is the distinction between a 0 and 1. And that had a squared effect. So you would end up doubling the transistors, but you’d lower the threshold voltage. So microprocessors stayed at like 20 or 30 watts. In fact, we did a John and I eventually did a textbook, and I was just checking, and it came out in 1990.

[19:28] And we didn’t even talk about power as an issue for the first three editions. The third one came out in 2000. Power wasn’t even a topic because Dennard scaling was going on. And so microprocessors stayed in the tens of watts even as they got faster and faster. What happened is about 2005 or so, Dennard scaling stopped working. And that was a shock. And Intel actually had a microprocessor that failed one of their generations because they just couldn’t get the power down enough.

[20:00] It was too hot to do that. So then what that forced us to go to multicore is that before that, it was easiest for the programmer, for everybody, if there was one very sophisticated processor that did everything, but we couldn’t do that anymore. So it went from one sophisticated processor to two, and then four, and then eight simpler processors. Then it was up to the programmer to deliver on the potential of Moore’s Law by parallelizing their code.

[20:29] So we stayed that way for about another 10 years. And then Moore’s Law started slowing down so that the general-purpose microprocessor was barely improving. It got a little better, but it wasn’t getting dramatically better. In the 1980s, 1990s, 2000s, you have a laptop and your friend’s laptop would be like four times as fast as yours. And you were jealous. So you would throw away perfectly good hardware because your friend’s thing was so much faster because of the rapid change in performance.

[21:05] Well, that all ended in the 2010s, where you wouldn’t throw away a laptop because the new ones were hardly that much faster than the old ones. You’d throw them away when they break and slow down. Nevertheless, programmers were used to this dramatic improvement in performance every few years because they could add more features to their software and stuff like that. So what were architects going to do?

[21:27] They’d already done the multicore trick in 2005 or so. So in around 2015, the idea was we would do domain-specific architectures like the GPUs. So if you tell me I only have to run a narrow class of programs and I don’t have to necessarily run all the operating systems, everything else, well, yes, I could shuffle those resources and do something much more efficient for something. Well, so you could do some things well, and there’s other things either you do poorly or not even at all.

[21:59] So then the question is, okay, what domain? So just coincidentally, where we were technologically, right around 2012, 2015 is when machine learning AI burst on the scene. And so that was, it was evident what domain should we do? And the domain was machine learning AI. So just coincidentally, where we were technologically, this new domain came along. And then I would say I work for Google, but I think it’s fair to say Google was the one who really saw it was certainly the first big company who understood the potential of machine learning AI and bet that they or feared that they were going to be swamped with demand and needed to do custom hardware.

[22:46] So the tensor processing unit, or GPU, that Google debuted in 2016 really kind of shocked the world and got people to realize that we should be designing hardware for machine learning, and we could continue to improve performance dramatically for that one domain.

23:07 — GPU vs TPU vs CPU

Ryan:

[23:07] What’s the high-level difference between a CPU, a GPU, and a TPU?

David:

[23:14] The CPU has got to be this general-purpose thing. And basically even today they have these general-purpose cores that each core is very similar to what the instruction sets used to be like 20 years before that. It’s not a surprising design, and it’s just got lots of cores, and the modern ones today could have 50 or 100 cores in there. So that’s the feature for graphics. What they decided to do to do the graphics job is they need to get a lot of performance out of the memory system.

[23:46] So they went to multithreading. They have hardware threads that you would send a memory request out and the hardware would switch over to do something else while memory is coming up. So this highly threaded architecture, and that’s what they developed, and it could run well for graphics. And graphics, it turns out, doesn’t need very, doesn’t need a powerful floating point. It doesn’t need wide floating points.

[24:15] So 32-bit floating point is plenty for graphics, even 16-bit. So they were doing, pushing graphics with 16- and 32-bit floating point in this multithreaded kind of architecture. And because it was kind of its own unique thing, it has its own set of terminology all to itself. It wasn’t kind of out of the main branch of computer architecture. So when you look at our textbooks, we have kind of like a Rosetta Stone which says here’s the terms that NVIDIA uses to describe GPUs.

[24:45] This is what it means in kind of normal, well, normal in the mainstream processor design. So there was this niche product that happened to do pretty fast single-precision floating point and even half-precision floating point, and they were pretty cheap. They were like hundreds of dollars. So when people, so kind of, but some people were thinking, boy, for some applications, if I could turn my program into, like, pretend that it was doing, creating an image, if I could turn my problem into image generation, I could use these pretty cheap GPUs, which had very good floating-point performance per dollar compared to anything else.

[25:31] And so people started playing around with that. And the founder and CEO, Jensen Huang, really liked that idea. So in 2006 he funded an effort to create a programming language that would handle this multithreaded hardware architecture for graphics to make it easier to program. And so that led to the invention of CUDA, which I can’t remember its acronym, but it’s really a proprietary programming language for the multithreaded GPU architecture to make it easier to program.

[26:07] It was a C-like language, but you can’t just compile C programs and run it. But it was C-like, but people actually liked it. It was certainly much better than trying to turn your program into image generation, but people liked it. But Jensen Huang, his vision was try to get these teenagers in the basement who are playing the games to learn how to program these things. And he had a couple of markets that he was interested in, like some of the Department of Energy labs, like fluid flow and some of the things, like, some.

[26:38] And he would build special-purpose libraries that could handle that domain and then use his GPUs to do that kind of special-purpose computing, but breaking out of graphics. But that’s kind of the heritage there now for the TPU program. And so what’s happened, people started right from the very beginning, people started using GPUs because they had much better single-precision floating-point performance than the CPUs.

[27:04] They had a lot more processors on them, so they had potentially much more performance. So one of the breakthrough moments was in 2012, when within the machine learning community, this neural networking piece, which had a few advocates but a lot of people didn’t believe in, went into a competition to see who could do the best image recognition. In 2012, the so-called AlexNet beat all the competition.

[27:33] This was this historic moment in machine learning and neural networking. And once they did it, and the guy who did that had taken a CUDA course at the University of Toronto to learn how to use it. And so he says, well, as long as I’m doing this, I’ll do it on a GPU. He was able to explore a lot more space on this cheap, fast GPU. So he entered it in the competition in 2012, and he was the only one using neural networks.

[28:00] And he crushed the competition. And within a few years, everybody switched over, and not only were they doing neural networks, but they were using GPUs. So GPUs have this heritage of being graphics engines, but more programmable, and started getting used in machine learning. When Google came along, they decided it was a clean slate. They didn’t care about graphics. So at the heart of neural networking is a matrix multiply.

[28:31] That’s the thing. So they designed a processor. At the time, the microprocessor had a giant matrix multiplying unit. That was the main thing. And then they threw a bunch of stuff out that they didn’t need. So a lot of general-purpose computing is what’s on the chip is maybe three levels of caches to try and have so you don’t spend all your time going to the relatively slow memory.

[28:54] Well, for machine learning they knew when their memory accesses were, so they could schedule that. So a hardware cache didn’t make any sense. They would just have a memory the software understood would transfer in time. Those are some of the innovations. Also, they innovated on the floating point format you didn’t need. Scientific computing cares a lot about precision. Most of it’s done in 64-bit floating point, where the exponent is less than 10 bits and most of it is the precision.

[29:27] The fraction can be 50-some bits. Well, what they realized for machine learning and AI, they don’t need all that precision; they needed the range. So Google did the first floating-point format where the exponent was bigger than the fraction. That was a radical idea, the so-called bfloat16. The part of Google that was doing this was the Google Brain research group. So they brought out this architecture.

[29:51] They had this narrow floating point format. They had a big matrix multiply unit. It only had one processor in it. Unlike the other ones, it was just dedicated machine learning. And it just kind of blew the doors off of everybody in the field. It was like 30 times better at inference than the contemporary GPU and 80 times better than CPU by having this dedicated one. So when Google made this announcement at their annual retreat a year or so after they had deployed it inside, it just shook everybody up.

[30:26] Intel started buying companies, NVIDIA started modifying the design to be much more focused on machine learning. And then a bunch of other competitors, hyperscalers, started doing their own efforts. So I think that was the watershed. I think the TPU announcement was the watershed moment there.

Ryan:

[30:48] So it’s almost like levels of specialization, like the CPU is the most general.

David:

[30:53] Yeah. If we still had Dennard scaling, Moore’s Law and Dennard scaling, where would we be today? With general-purpose processors, we should have 100 TL microprocessors. If we could build 100 TL microprocessors, that’s what we’d do. GPUs would still be a niche. If we could do that, it raises all boats. That would be fantastic if we could do that. But that’s long in the history.

[31:22] We haven’t been able to do that for 20 years. And so there were probably two or three gigahertz microprocessors in 2005, and that’s kind of where they are, barely improved today. So we can’t do that. So there’s still areas where it’s important to have CPUs. They’re the right—you need operating systems, compilers, and things that they’re the right solution. But things have been specialized.

[31:47] And then now, in terms of industry terms, a huge emphasis is being put into the AI accelerators, or just AI in general, is where the money is being invested. And so the question for any processor designers was, how does my processor design fit into this AI universe, and what should I do? How should I change it for this important application?

32:12 — Is Moores law dead?

Ryan:

[32:12] So you mentioned that Moore’s Law is slowing down. And I watched this other talk from Jim Keller saying that Moore’s Law isn’t dead. But is it controversial to say that it’s?

David:

[32:25] No. I mean, not, not to real engineers. Moore’s Law is very simple. It says in a chip the number of transistors will double. Originally said every year, and then he changed it to every two years. Just look. Do the chips, the number of transistors doubled? No. Now I think what people assume that means is if we are no longer on Moore’s Law, that technology is not improving.

[32:52] That’s not the same thing. It’s not improving at the rate that Moore’s Law projected. And what was amazing about Moore’s Law, which lasted 50 years, is that guided the investment of semiconductor manufacturing. We need to deliver on doubling transistors every year or two. How are we going to do that? How are we going to build the equipment to do it? So it was a guideline for the whole industry, which was kind of remarkable.

[33:17] So what we are doing now is there’s pieces of the technology that get better and there’s pieces that don’t improve at all. So one of the big pieces, important pieces on a chip, is the static random-access memory. So that’s hardly improving at all. Logic gates still continue to improve. The gates are getting better. So if you’re doing adders or multipliers, those are getting there. So it’s not uniform improvement anymore.

[33:46] And we’re also going to more exotic packaging to be able to deliver it. So people now, you know, forever. It was a single chip, was the best way to package everything fits on one chip. And that’s what we’re going to build. And now there’s these ideas of chiplets or packaging multiple chips together. The latest GPUs, and I think the latest TPUs, has actually two what are called full reticle design dies packaged, put into a package.

[34:18] And so a full reticle design is the maximum you can build on a semiconductor. Well, on a semiconductor they have a step-and-repeat motor, and in the old days you’d have many chips inside that. Now there’s just one. So two maximum reticle designs form a node. So they’re using packaging. So if you look from outside, you can say, well, look how many transistors. Moore’s Law is continuing.

[34:43] But if you see what’s inside the chip, that has tapered off. And I think part of it is for a fair amount of the industry, if you were in a semiconductor manufacturer and people ask you what you do, it’s I make Moore’s Law, I sustain Moore’s Law, that’s what I do. And if you’ve been doing that for decades and somebody says Moore’s Law is over, it’s like my career is over. So I think there’s an emotional side of it.

[35:09] But just look at the data, the data doesn’t back up with. Keller says, but I also didn’t say that the technology is not improving. The technology is continuing to improve and specifically domain-specific architectures. But if you look at the general-purpose architectures or even other memory technologies, it used to be the DRAMs would improve by a factor of four in density every three years, like clockwork.

[35:34] And now it’s maybe 10 years between factors. So you can see plenty of evidence that Moore’s Law no longer applies.

Ryan:

[35:41] Is there some new version or some analog to Moore’s Law that is kind of guiding microprocessor design and architecture these days?

David:

[35:54] I guess the question is both NVIDIA and Google are continuing to deliver much faster processors for machine learning, tremendously better. What are they doing? Well, part of it is what I said about packaging, to be able to get more transistors, and you keep them closer together because distance matters. Part of it is innovating on the floating-point formats. So unlike the supercomputers of 64-bit, it’s not even 64-bit, not even 32-bit, not even 16-bit, but 8-bit and 4-bit floating point is going on.

[36:33] So narrowing of the data types, having kind of what’s called the matrix multiply instructions. So these powerful units that are put in there that can do special purpose applications that are very important, making those bigger and faster. So those are the three things that are going on. But we don’t have this simplifying guideline kind of underlying all this. You have to be aware of each piece of the technology, gauge how fast it’s improving, whether they can deliver on what’s going on, and then you assemble that together and make your bets.

[37:15] There’s a paper that we’ve just got approved that I think we’re going to put on arXiv soon, which is talking about the Google TPU line. And pretty remarkably, the Google TPU line, particularly for training, has stayed pretty constant in the basic architecture design. Things have gotten bigger and faster. But if you look at the design of it going back to the first training TPU, that block diagram still works all these a decade later.

[37:47] So the people who designed that in, whatever, 2015 or 2016, did a really great job.

38:04 — GPU benchmarks

Ryan:

[38:04] Blocks are still there. I think in your career with the CPU benchmarks were huge. They played a huge role in measuring which computer architectures were performant and not in this new space of floating point operations for AI. Is there a benchmark that people use for GPUs, and can you also apply it for TPUs?

David:

[38:27] I and some friends were involved in the MLPerf effort. So it was inspired by the SPEC CPU effort, with the SPEC benchmarks, where there were these competing companies and they’d all make claims that theirs was better than the others, and they realized that wasn’t good for the industry. So they agreed on a set of benchmarks. So the MLPerf effort is this run now, but what’s called MLCommons is an attempt to do that.

[38:55] If we’re going to do these comparisons, let’s not argue about what the benchmarks are. So that’s a serious effort in that kind of. Interestingly, what’s happened, I’d say, is because there’s two pieces to design. There’s the machine learning libraries that are to implement a lot of features that you need for these applications, and the libraries will even be rewritten for specific applications, rather than just having general libraries.

[39:29] This has turned out to be a big advantage for NVIDIA because they have a large corporation with lots of people that are available, lots of engineers who could build these libraries for them. So it’s turned out not quite a... It’s not a neutral evaluation, right? It’s the architecture plus the libraries that go with it, and the compiler too, but specifically the libraries that you tailor each time. So NVIDIA brings out, when they announce a new architecture, they create a new set of.

[40:04] They modify the libraries to run that really well or to run applications really well. So that’s a powerful combination. Kind of in business terms, people refer to NVIDIA as having this CUDA moat, and part of it is CUDA, the programming language, but a big part of it is the libraries that NVIDIA makes. So this has made it difficult for startups to be able to compete with NVIDIA, partly because they didn’t put enough emphasis in the software and partly because NVIDIA just has many more engineers than they do to be able to tailor the libraries.

[40:42] So it’s the libraries plus the architecture. There’s this powerful advantage why most people do things on GPUs. Now Google has been able to develop their own libraries. They don’t have as many engineers. They use compilers more than I think NVIDIA does. So they have a set of libraries that they can use. But up until recently, Google‘s, it’s all been internal. It’s just for Google to use, or you could use it via the cloud.

[41:13] But these startups have to have a difficulty as a result. That’s why MLPerf hasn’t been as popular. Not everybody runs them because NVIDIA runs them really well, really better than everybody else. And the startups have a hard time showing off what they can do, given they don’t have the engineering effort going into the libraries that you need to do well in MLPerf.

41:40 — How to have a bad career

Ryan:

[41:40] You gave this popular talk about how to have a bad career, and it’s kind of the negation of advice for how to have a good career. And I was just wondering if you could summarize maybe the top three things that people should take away.

David:

[41:58] Yeah, well, there’s been a few things. So the story is early in my career, my friend, a good friend, and I said, how can we teach grad students how to give a good talk? And we thought it’d be funny to explain how to give a bad talk. And then if you didn’t want to give a bad talk. So this is how to do it badly. And if you don’t, here’s the things you do not to do it badly. And so then I later did how to have a bad career that’s pretty much focused toward academia.

[42:23] So for researchers to be able to do that. I later did a How to Have a Bad, How to Build a Bad Research Center, how to build a bad research lab. And then recently I’ve been giving how to give AI a bad carbon footprint. That’s my latest one. But I think the thing that might be more relevant is at the end of my talks, I would kind of reflect on my career and talk about lessons learned. So I’ve written a paper called Lesson.

[42:49] I think it’s “Lessons, Life Lessons from the First Half Century of My Career.” I wrote that recently. And so those are divided up into kind of career advice and personal advice. There, on the personal side, I’d say, if you have a family, make sure your family’s first. Keep your family first. The technology we’ve invented makes it really easy for your, you know, to take your work home with you and not pay attention to your family.

[43:17] I had a. When I was first here at UC Berkeley, I gave a senior faculty member a ride home, dropped him off late at night, coming up from Silicon Valley. And he said, well, Dave, if I had to do it over again, I wish I’d spent more time with the family. And I never wanted to say that. And nobody on their deathbed says, you know, I wish I spent more time in the office. So, so you got to, you know, whenever it’s easy to kind of, you know, let the.

[43:44] Let your career overcome the needs of your family, but you just got to remember that. I would say, in my life, growing up in the 50s, the idea was that to be happy, you had to be wealthy. But those are actually two different goals, wealth and happiness. So I always made decisions toward happiness versus wealth, and I felt very good about that. And even now, why would I pick something that made me wealthy and unhappy?

[44:15] Why would you do that? And in the field that we’re in, it turned out there was a lot of wealth to go with it. So optimizing happiness didn’t mean you had to suffer. Beyond that, I think it’s important to have fun personally. I think when you’re a kid, you don’t have to tell kids to play, but as you get adult, you get so busy you don’t think you have time to have fun. But you only get to do this once.

[44:43] So right now I play soccer, I rode my bicycle to the interview, I lift weights, I body surf, do things with my wife and family and my son. So it’s important to have fun. I think on the career side, one of the pieces of advice is by Stephen Covey. He wrote this book, The 7 Habits of Highly Effective People, I think, and he has a little quadrant, and he divides it into urgent and not urgent, and important and unimportant.

[45:20] There are so many things in our technology, like email and texting, for you to focus on the urgent things, but you really shouldn’t be spending a lot of time on the unimportant urgent things. And it takes self-discipline to set aside time for the important, non-urgent things. But if you don’t block that out, you can just not have time to do anything. I get to see other people’s calendars at Google, and there’s managers that every half hour from eight to six, five days a week, are scheduled.

[45:49] And I don’t see how you have time to think and reflect on things like that. Other career advice thing is I remember I kind of woke up one morning and it was like God spoke to me. I was like thunderstruck. And it said it’s not how many things you start, it’s how many things you finish. It seems relatively obvious, but that’s not the way I was acting. I had many things going on, but after that it’s like there’s one main thing I’m doing at times.

[46:19] So when John Hennessy and I wrote a textbook, that was the main thing. When I was department head here, that was the main thing I did. I would do some other little things there. And John Hennessy, he wrote a kind of career advice book based on his presidency. And one of the things he said in there, you’re only going to be remembered for the five or six things you’ve done in your life, not for the hundreds of little things.

[46:44] So to give yourself a chance to have some things you’re really proud of, it’s better to concentrate on a few of them, hoping that some of them will turn out to be a big deal rather than scatter yourself to many things. But if you’re interested, you can. Yeah, if you look for life lessons, David Patterson, first half century, you can see the whole list of. I think there’s 16 lessons altogether.

Ryan:

[47:11] You mentioned that you didn’t want to reflect back on your life and feel like you didn’t have enough family time. Yeah, I’ve— I don’t think I’ve ever heard anyone say the opposite. Why do you think that is? Why is it that everyone looks back on their life and they never regret a lot of family time? I imagine there’s got to be at least one person that says, “I spent too much time with my family; my career suffered.”

David:

[47:39] Yeah, well, what’s, what’s, it’s pretty philosophical. I mean, what’s life all about? What’s success? Right. You have to figure out what that means for you. I mean, if you have, I don’t know, if you have financial goals of being a millionaire, a billionaire or something like that, and that’s how you judge your life. Okay. Good luck.

[48:04] You know, it’s pretty hard to make it. It’s pretty hard to do, but I think it’s the... When I was finishing my PhD, I read this book by Studs Terkel called Working, where he interviewed all these people in his careers, and they looked back at what they liked and what they didn’t like, what they felt about their careers, and what I got out of it. The people who worked with people like ministers or teachers or doctors felt really good about what they do with their careers.

[48:30] And the people who did more ephemeral stuff, like technology things or airplanes or something like that, are long gone, didn’t feel as good about it. It was the people that they worked with that they really cared about. And I went out with a retired engineering dean here, and he— and to a meeting who I knew, and he said, “You know, Dave, as I think my career, it wasn’t the projects, it was the people that I worked with that mattered.”

[48:54] And I thought I knew that from a long time ago. So that’s, I mean, this is kind of senior persons offering advice. I think you’re going to care more about the people you’ve worked with, the people you’ve helped, will be a bigger deal. That’s part of, one of the other things about personal happiness is they studied happiness. Psychologists used to just study crazy people, but they started like, why are people happy?

[49:17] And they know what the reasons are. Have a job that you like, have friends and family. Helping other people makes you happy. They know this. Having something kind of either a religious side of it, it doesn’t have to be a formal religion, but contact with nature, the grandeur of nature, but the list of things you need to do to be happy is well understood.

[49:42] And our world is filled with unhappy billionaires. Right. If money was the thing that made you happy, why are these people, very wealthy people, so mad about things? So, yeah, this is me passing on advice.

49:59 — Courage and optimism

Ryan:

[49:59] In one of your talks, it said what worked well for me, and it was kind of some reflections. And one of the things in there I thought was unique and interesting. You mentioned that courage was a big part of your career, and I don’t hear that too often. I was curious why you say courage is so important in a career.

David:

[50:19] Yeah, I think that’s, I mean, that might be partially my personal makeup, but I was kind of the youngest kid in my class and kind of small. It took me a while to grow despite age, so I was always small. But my parents encouraged me to go out for wrestling. And wrestling gives you physical self-confidence because you spend years doing that. I did it in high school and college. And so I think partly technically, having courage to do things kind of goes along with the advice is fortune favors the bold.

[50:59] That goes. That’s advice is 2,000 years old. It’s hard to figure this out. Helen Keller wrote, even trying to play it safe, you still get caught. So it turns out you might as well. You might fail no matter what. And if you take a big chance, you can succeed. If you don’t take the chance, you probably won’t succeed if you play it safe. So fortune favors the bold. And I think it takes courage to do that.

[51:28] I think also it just, for me, intellectually, I feel like if there’s something not right, I need to stand up and confront it. And I think that kind of, ironically, comes from the wrestling side of my personality, where if I see something, somebody getting picked on or something like that, I’m going to stand and try to stop it. And I feel that same responsibility. Intellectually, if people are making bad arguments or doing something, we need to stand up and do it.

[51:57] And I feel good about that. The cautionary part about that is, because I guess one of my senior faculty members saw this nature of me, and he said one of the sayings is friends come and go, but enemies accumulate. This is an old saying. So if you think about it, you kind of, people you went to high school with, while friends, you kind of forget. But somebody who you really dislike, you never forget that you dislike that person.

[52:22] So standing up when it’s important, but be careful when you make enemies because they’re going to stick around for a long time.

Ryan:

[52:29] When you say something’s gone bad, technically, do you mean someone was incorrect?

David:

[52:35] Yeah, when they’re weak, either politically or technically, when it’s a weak argument. Right. I think of this, I really like there to be a marketplace of ideas, and we hone the ideas by arguing them. And so if it’s a specious argument, even if a person is a leader of a company and it just doesn’t make sense, I feel it’s kind of the responsibility.

[53:03] It’s better for the company if somebody stands up and points that out than to just let them get away with it. And then it’s a little bit confrontational. But as long as people all agree that this is for the greater good, we’re gonna, we need to get the right ideas out there. And so let’s argue about the ideas just to see, polish them to make them stronger. I think that’s important in science and engineering and kind of in life too.

[53:36] There’s a lot of stuff going on right now in the country that is worrisome. And I certainly stood up and wrote op-eds about things that I think are wrong and need to be corrected. And if people are afraid to do that, it’s hard to be optimistic about the future. If people are afraid to stand up when there are wrongs and try to stop them.

Ryan:

[54:02] You also mentioned optimism in the talk, and you had this story. I wonder if you’re willing to share.

David:

[54:08] So I would say in engineering, it’s hard. It’s hard to know, right? But I think you need to be kind of optimistic or positive, have a positive outlook because so many things could go wrong. And then my personal story that illustrates this goes back to high school when I’m 16. I’m dating this very attractive girl, and I screw up my courage and ask her if we would be exclusive. At the time, the phrase we used was going steady.

[54:35] And she looked at me and said, and, you know, she was 16. She had dated other guys and thought we were pretty young. And she said, “Well, Dave, you’re such a nice guy, I don’t know how to say no.” For me, as a logical person, a no sounded like a yes. And so I hugged her and said, “Great.” And so she, in her mind, thought, “Well, I’ll let him down gently later.” But we’ve been married 59 years now, and she hasn’t let me down yet.

[55:04] So that was a case where optimism paid off.

Ryan:

[55:07] I think everyone that hears about a healthy relationship for that long might wonder how you did it.

David:

[55:13] I used to tell people, if you go to weddings, the marriage vows are really great, right? But nobody can remember their wedding vows. I used to say, remember your wedding vows, but nobody remembered that. So we boiled it down to nine magic words, and it’s just three sentences. And they start: “I was wrong, you were right. I love you.” Okay?

[55:35] Those are the nine words. And this applies to both partners in a relationship, not just one partner. But, yeah, if you can say them all, and no substitutions— I was wrong. You’re right. You’re a jerk. You know, you can’t do that. If you can remember those nine words, that can help you have a long relationship, like my wife and I have.

55:56 — Advice for his younger self

Ryan:

[55:56] And then last question for you: knowing everything you know now from your career, if you could go back to yourself when you had just entered the industry and give yourself advice, what would you say?

David:

[56:09] I mean, I think when I got here, because the imposter syndrome. I was a UCLA graduate student, and suddenly I’m a UC Berkeley professor. So that just doesn’t seem like— That was very intimidating. But after a while, I just thought, well, I’m probably not going to get tenure, so I should just have a good time. So I think I already had the right attitude about it. I think that first year, I think it was very stressful while I was trying to handle the imposter syndrome and be a UC Berkeley professor.

[56:40] But I think after that, I handled it pretty well. I did all the things with the kids and stuff. So there’s a version of that question is, like, is there anything I would do over again? There’s one thing I would have. I was chair of this, of the architecture community, ACM SIGARCH, as it’s called. And they have an annual conference of the year. And I was in, this was in the 1990s, I think I was the chair.

[57:06] And what I wasn’t aware of is that at these conferences, there were men who were harassing young women at this conference. I just didn’t think people like young people, people like me, nobody would do that. Only an idiot would do that. That can’t possibly be happening. But it was happening, and I wish somebody had said something to me about it, because I would have straightened it out.

[57:33] Any man would have threatened his life if he were to do that. Today, the only comforting thing is Sarita Adve, who’s a famous computer architect. She said she also was not aware that that was going on. It became clear later, you know, five or 10 years later, it became more clear that this was going on. And there are mechanisms. Sorry, but that’s the one thing I wish. You know, if I could go back in time, I would have figured that out, and I would have straightened men out who were doing that, and they wouldn’t.

[58:05] That would have stopped. I believe that would have stopped them.

Ryan:

[58:08] Yeah. Thank you so much for your time today. I really appreciate it.

David:

[58:12] All right. Thanks for the interview.

Pretty surreal to get to talk to him. He explained some of the key concepts but also it was interesting to hear the stories behind what we learn in the textbooks.

Also, I have a ton of content recorded that I’m working on editing. Several Turing Award winners and programming language creators. I learned a lot during the latter since I basically talked to them as if I was a student curious to learn about programming languages. Excited to share these episode with you all!

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:34 - Why his work broke the law

08:39 - How people did encryption before

18:51 - The crypto wars

26:22 - The story behind Diffie Hellman key exchange

36:48 - Signatures vs key exchange

43:05 - RSA patent wars

48:08 - Why inventions happen at similar times

50:29 - What he worked on after cryptography

57:31 - His thoughts on death

59:40 - Advice for his younger self

Transcript

00:34 — Why his work broke the law

Ryan:

[00:34] I saw your initial work in cryptography was potentially breaking laws, or it was kind of in this gray area where the U.S. National Security Agency was kind of not super happy with your work, and there was some conflict with the government. Could you explain what the field of cryptography was like at the time and its relationship to the government and how you got into the field?

Martin:

[00:57] Cryptography is the study of codes and ciphers for keeping information secret. When I started to get interested in this area in 1968, I was at IBM Research just after finishing my PhD. They’d hired Horst Feistel, who you may have heard of, who was the father of IBM’s work in this area and really started the unclassified research in cryptography. So I started there. And then I realized when I was teaching at MIT from ‘69 to ‘71 that I might actually be able to do something.

[01:32] I won’t go into the details of that right now. And I did it in my own time because I didn’t think I was breaking any laws by doing it. I didn’t think anybody could make that case. But I realized that there was a part of the government, the U.S. National Security Agency, that would be very concerned about this. And then it was as our work really became visible that they started saying we were breaking the laws.

[01:59] And that’s when I looked into it more carefully. We got a letter in July 1977 from a guy who worked at. We determined he worked at the U.S. National Security Agency. He wrote from his home address in Maryland, which is a good indicator that he works at the U.S. National Security Agency. To the Institute of Electrical and Electronics Engineers, which is the main electrical engineering professional society, saying that as an IEEE member, he was concerned that they were breaking the law by publishing certain papers.

[02:31] He never mentioned me by name, but I had an article in almost every issue that he mentioned of the IEEE Transactions. The IEEE wrote back to him, copying me. They didn’t copy me as Martin Hellman, troublemaker. They copied me as a member of the Board of Governors of the Information Theory Group, which was then publishing most of these papers. And so it’s a funny thing that when people start to talk about cryptography, they talk in code all the time.

[03:01] The NSA was maintaining I was breaking the law by publishing my papers in international journals. The ITAR, the International Traffic in Arms Regulations, which I’d been unaware of up to that point, defines anything cryptographic as an implement of war. And I wasn’t exporting an implement of war, which would mean you need a license from the State Department. I was exporting technical data from their perspective on implements of war.

[03:27] And so that’s why I was breaking the law. So I took the letter to Stanford’s general counsel at the time, John Schwartz. He said if the laws interpreted that broadly, he thought it was unconstitutional. But that’s only his legal opinion. It had to be settled in a court of law.

Ryan:

[03:43] I mean, when you got these warnings, did it deter you at all, or what was your immediate reaction?

Martin:

[03:49] I kind of fell into this at first with Whit Diffie, and I thought that the 56-bit key size of DES, the Data Encryption Standard, was a mistake. We realized that you could break it with exhaustive search. Today, AES, the Advanced Encryption Standard, has a minimum 128-bit key size, which is much, much bigger than a 56-bit key size. Two to the 128th is much bigger than two to the 56th. So we wrote letters.

[04:20] We thought that they’d change it. It was cheap and easy to change it. And after six months we realized that we had a political problem, not a technical problem. And then we had to decide whether to back down or not. And we went forward because at that point I was invested in this. And also I’m from the Bronx, as I mentioned to you earlier, and I’m a street fighter. Not with my fists, I got beat up a lot, but I’m a street fighter with my mouth and my mind.

[04:45] And they picked the wrong person, basically. I wasn’t going to back down.

Ryan:

[04:51] What could have gone wrong? I mean, would they pursue you with lawyers, or would...

Martin:

[04:55] Oh, I could have gotten killed.

Ryan:

[04:57] You could have gotten killed?

Martin:

[04:58] Oh, yeah, not necessarily by them, but maybe by the GRU, the Russian equivalent. I mean, I wasn’t just pissing off the NSA, I was pissing off the Russians, Soviets.

Ryan:

[05:07] Why would they be pissed off?

Martin:

[05:09] Oh, we and the Soviets sold our World War II surplus cryptographic equipment to third-world countries. We’d rather that they were able to break it, and they’d rather that we were able to break it than no one was able to break it. So my mother called me up. My mother was still alive. She died in 1984. And she called me up and said, “What are you doing? You’re going to get yourself killed.” She was really upset.

Ryan:

[05:35] Okay, so you get issued the warning, and then you go to the general counsel at Stanford. Then what happens?

Martin:

[05:42] This was July 1977, in I think October. Early October, yes, it was October. There was an IEEE symposium on information theory at Cornell University. And I had two papers there. One with Ralph Merkle, who deserves, I believe, a lot of credit for inventing public-key cryptography, as you probably know, and one with Stephen Pohlig, which really. Stephen and I have a paper which is really the RSA system, except it’s mod P instead of mod N.

[06:12] It’s modular prime number instead of modular composite number. We realized that you could do it mod N, but we didn’t have public-key cryptography then. Anyway, Stephen and Ralph and I had papers. And John Schwartz said that he strongly recommended that I give the papers instead of the students. I was going to have the students give the papers. And so I went to the students and I told them, look, if you want to give the papers, that’s okay, but Stanford’s not sure they can defend you, whereas it’s clear they could defend me.

[06:42] And I feel very comfortable going forward with Stanford’s financial resources. And the students initially bravely said that they would give the papers. After a week they came back to me. Their mothers were beating on them like my mother beat on me. And they said, “Okay, you give the paper.” So when it came time for each of those papers to be given at Cornell, I went up to the podium and I said, “I had the student come up with me.”

[07:09] And I said, normally the student would be giving this paper, but on the advice of counsel, and everyone knew what I was talking about, I will be giving the paper. And I want you to consider, in every way but legally, the words coming from my mouth as if they’re coming from his. And so the students got more credit that way than they ever would have if they gave the papers by themselves.

Ryan:

[07:29] It sounds like you had a lot of opposition at the time. Why did you still pursue it?

Martin:

[07:34] Well, my colleagues all told me that I was crazy to work in cryptography. And they had two reasons, one of which was the U.S. National Security Agency has a multibillion-dollar-a-year budget, and they’ve got a decade’s head start. How can you hope to discover something they don’t already know? And my attitude was, I don’t care what they know. It’s not available for commercial use. Even if I only develop things that they know, it doesn’t matter.

[07:57] And yet we developed things that they didn’t know about, which is a whole other thing. GCHQ, the British equivalent of the NSA, has claimed that they invented public-key cryptography a little bit before us. Not a lot, by the way. Just around the same time. Except they never had anything on digital signatures. They never had anything that allowed my phone to accept a software update and to use a secret key to sign it, which Apple has, and a public key in the phone.

[08:26] So even if someone takes the phone apart and gets the public key, that doesn’t tell them how to sign future software updates. And GCHQ had nothing on digital signatures, only on the privacy aspect.

08:39 — How people did encryption before

Ryan:

[08:39] Prior to the solutions you came up with, how did people encrypt it? How did people encrypt it?

Martin:

[08:46] Encrypt?

Ryan:

[08:47] Yeah. Encryption messages.

Martin:

[08:49] They didn’t. No, actually. NSA, GCHQ, GRU, all these foreign United States and foreign intelligence services were sucking up huge amounts of unencrypted data. It was only mining companies and banks that used encryption, and they used very bad encryption.

Ryan:

[09:07] What about during wars and stuff? Sending messages that they didn’t want other adversaries to be able to read.

Martin:

[09:16] You’re talking about military use.

Ryan:

[09:17] Yeah, exactly.

Martin:

[09:18] Well, that was where the major use had been, in the military. And one of the things I have a talk on the evolution of public-key cryptography. And I start off by saying, I love that. People call it revolutionary. Don’t stop saying that. But by the end of this talk, you wonder why it took us so long rather than how we ever found it. And they were almost like big arrows pointing: Go here, go here, go here.

[09:43] And one of them was Whit and I had come up with the idea of a trapdoor cipher. That was a cipher that was impossible to break unless you knew trapdoor information that went into its design. We’ve never been able to develop such a cipher, but we realized that was a possibility. And that would be a general’s dream, because he could use it. If he knew the trapdoor information, he could use it securely against his adversary in the war.

[10:10] But his adversary, if they captured it, couldn’t use it securely because he knew the trapdoor information and could break it. And from there to public-key cryptography as a minor step.

Ryan:

[10:19] I know there’s this famous machine. I think it’s called the Enigma machine. And Turing was involved in that. That’s some sort of encryption mechanism.

Martin:

[10:29] Basically, it’s a World War II. It’s the main German field cipher of World War II, the Enigma machine. It was gear-based. And encryption is a special-purpose form of computation. And computation has gotten a hell of a lot better. We do, I don’t know, I’m 80 years old. So it’s 16 periods of five years. We can do about maybe 10 to the 14th, it’s not quite 10 to the 16th times as much computation for a dollar today as we could when I was born at the end of World War II. I was born in ‘45.

[11:01] So Enigma, what was the primary computing device of World War II? Gear-based adding machines. What was the primary encryption device? Gear-based encryption machines. Today we can do not only computation much better, we can do encryption much better. In that case, it substituted electricity. You pressed the letter on a keyboard, it generated an electrical signal that went through a sequence of rotors, as they’re called, which transformed it into another letter that lit up.

[11:31] And so you’d set up the key, which was which rotors to use and what order to put them in, and some other things. And then you’d type out the message on the keyboard, and you’d read off the enciphered message on the lights. And Alan Turing, who you pointed out in The Imitation Game, which was the major movie of like five years ago, Alan Turing figured out how to build a primitive form of computer to break the Enigma machine.

[11:59] Now, the Germans knew Enigma was breakable. They never thought that the Allies would build a computer to break it. And so the Allies were reading German encrypted messages almost as fast, maybe faster than the Germans were. And that’s what was different. And as they knew Enigma was breakable, they never realized that. They never thought that we would build a machine like that. And it’s interesting, Alan Turing was hounded to death in the 1950s in spite of his wartime activities.

[12:27] And this is covered in The Imitation Game. In that movie, he was hounded to death because of his homosexual tendencies, or more than tendencies. I mean, he was homosexual. Today we wonder how our parents, grandparents could have been so uncivilized as to do things like that.

Ryan:

[12:47] You mentioned in that talk on the history of public cryptography, there’s this. Everything is pointing toward these directions. What did you mean by that?

Martin:

[12:57] Well, I mean, the trapdoor cipher was pointing us toward public-key cryptography. And yet a trapdoor cipher makes perfect sense because almost everything in cryptography involves trapdoors. People usually think of public-key cryptography as a trapdoor cryptographic system. But even a cryptographic system is a trapdoor. And this is fundamentally related to a question called P vs NP or not in computer science.

[13:26] Are there any problems that are easily checked that are hard to solve? That’s basically what that means. If there are any secure cryptographic systems, then there are problems that are easily checked that are hard to solve. For example, one-way function is the simplest form of trapdoor. This is a function that’s easy to compute but hard to invert. And this figures importantly in cryptography and blockchains, among other things.

[13:57] We’ve all taken trapdoor quizzes where the professor gives you an hour to solve the problem. At the end of the hour, he says, “Pencils down, papers in,” and he says, “Oh, we have a few minutes remaining. Let me give you the solution and convince you it’s right.” That’s a trapdoor quiz problem. It’s a primitive form. And there the professor has in mind a particular method for solving it, whereas you have many methods.

[14:23] And a real trapdoor quiz problem would work like this. The professor would say, here’s a one-way function. I’ve generated an X, here’s the Y that comes out. You find the X that comes in after a million years goes by. He says, papers down, pencils in. He says, oh, by the way, in the few seconds remaining, let me convince you. Let me give you the solution and convince you it’s right. What does he do?

[14:46] He takes X, he puts it through the one-way function, he gets Y. And you know that he had the right value of X, and yet you could never find it.

Ryan:

[14:55] When I imagine you kind of competing or butting heads with the NSA, I can imagine one solution for them might be to try to recruit you to their side. Did they ever try to recruit you?

Martin:

[15:07] Yes. Early on, before we had public, before we had any good results, I’d go to conferences and I’d give talks on cryptography, which in hindsight were very primitive. And NSA people with name badges that said Department of Defense, which was the simple substitution cipher for NSA, would always ask me. They explained they were at NSA and they’d love to hire me as a consultant because they needed new blood.

[15:32] And I said, I’d love to know what you know, but only if I can publish my papers independently. And he said, of course not, which I knew was the answer. And so I never took any classified consulting contracts, et cetera, until 1995. There was a National Research Council committee called CRISIS. It’s called the CRISIS Report. Cryptography’s Role in Securing the Information Society, which comes out as CRISIS.

[16:02] And that was about 1995. And the question was, were U.S. government regulations helping national security or hurting national security? We concluded that in many ways they were hurting national security. And we had a former deputy director of the NSA on the committee. We had a former Attorney General on the committee, Benjamin Civiletti, who had been Attorney General under Jimmy Carter. We had people like me who were privacy advocates, but who had come around and started to understand how the NSA viewed things.

[16:34] We had Ray Ozzie on that committee, who was the chief software architect at Microsoft. When Bill Gates retired, he did Lotus Notes. And we reached unanimous conclusions. And one of the most important conclusions we reached was that the classified briefings. I did take a classified. I didn’t get paid for that, but I did have a security clearance for that and intelligence coins, which I’d never taken before.

[17:04] But I was retiring at that point, and I figured it didn’t matter. And it was important for me to be able to, say, get past the people who said, “If you knew what I knew, you’d think differently.” And there were people in the unclassified briefings who said, “If you knew what we knew, you’d think differently.” But we concluded, and it’s in our report, which you can get free of charge on the National Academy, National Academy’s website, that the classified briefings helped fill in details, but they did not change our fundamental conclusions.

[17:39] And that was one of the most important conclusions we reached. And yet people said, if you knew what we knew, you’d think differently. And yet that was not true.

Ryan:

[17:47] When they were trying to recruit you, I imagine it would have been very advantageous for them to classify your work.

Oh, yeah, they did. I mean, when you turned down their offer, I imagine they would have had to compensate you handsomely to kind of go to the.

Martin:

[18:04] I don’t. We never got that far. And by the time we had a fight on our hands, it was too late. Basically, I’d committed to see this thing through. And when I realized that my life might be in danger, I might go to jail, although I didn’t think about those possibilities very much, and I didn’t think they were real, although they may have been. I felt like I was committed and I couldn’t back down.

[18:35] I mean, what would you do? I kind of fell into it. It’s like a friend of mine who was a helicopter pilot in Iraq. He went through ROTC in the late 90s, he said, to pay for his education. There were no wars. He said, why is everybody calling me a hero?

18:51 — The crypto wars

Ryan:

[18:51] When I was doing the research, I kept seeing this mention of the first crypto wars. What are the crypto wars, and how did they play out?

Martin:

[19:00] The first crypto war was the one we’ve been talking about, which occurred in the late ‘70s, early ‘80s, where NSA threatened to throw me in jail. My life may have been in danger, things like that. And that was over two things. It was over the freedom to publish papers in international journals, which has now been established. And it was over the key size of DES, which is something that people today know almost nothing about.

[19:24] As I mentioned before, it was a 56-bit key size. And Whit and I did a quick calculation that you could probably break that for $10,000 even with 1976 technology, 1975 technology. And if we were wrong, Moore’s law would, if we were off by a factor of 10, an order of magnitude that would be erased in five years’ time because Moore’s law was advancing the state of computing by an order of magnitude every five years in those days.

[19:54] So that was the first crypto war. It was over the freedom to publish and the key size of DES. The second crypto war, which people don’t really remember, was in the ‘90s and Clipper Chip was a big piece of that. This was the idea that there should be an escrow service, that the government would allow strong encryption, but it would maintain master keys somewhere. And if they got a court order that said that they were able to get into something, they’d be able to do it.

[20:26] Well, this sounds great, and it was great from certain points of view, but there were problems with it, like in the National Research Council Committee, the CRISIS Committee that I talked about. We wasted a lot of time talking about key escrow. And then we realized, I may have actually said this, although I think we came to it as a whole. Look, there are major problems with key escrow. How is it going to work internationally?

[20:49] Who’s going to hold the keys when someone’s in France and someone’s in the United States, or someone’s in Russia and someone’s in the United States? So what we said in the report is, we said it very nicely, that we don’t see how to solve many of the problems with public key with key escrow. And the U.S. Government should experiment with it, and if they came up with a solution, come back to us, and they never did.

[21:14] That was the second crypto war. And Clipper Chip was a chip that had a key escrow built into it. Basically, the third crypto war, which some people may remember, occurred about 10, 15 years ago. It was over things like the San Bernardino Apple iPhone. There were terrorists who committed acts, and they had an Apple iPhone, and the FBI wanted to break into it. FBI, not NSA, wanted to break into it. And they asked Apple to give them the key.

[21:48] Apple does not have a key. Ron Rivest is one of the authors of a report called Keys Under Doormats. If you build what they call a backdoor into a cryptographic system to allow access. And that was the third crypto war. It was really a repeat of the second crypto war, the key escrow with a different name. And it’s really putting keys under doormats because if Apple can recover one key, they can recover any key.

[22:16] And they’re going to be asked repeatedly. And there’s a danger that if that information gets out there, that all of Apple’s devices become insecure. So how do you do it? We don’t see how to do it. It’s unfortunate, but there is no way to give access. I’d love to give access to the U.S. Government when it had legitimate reason for doing it. I would love to withhold that access from the U.S. Government when it has an illegitimate reason for doing it, which it sometimes does, and from the Russian government, which also would use it illegitimately.

Ryan:

[22:46] You mentioned DES, 56 bits, was not secure enough. Why would the government want fewer bits?

Martin:

[22:53] Oh, easy. The government wanted fewer bits because they didn’t want a publicly available standard that they couldn’t break. They figured that there was a crude form of trapdoor that Whit and I made an estimate in ‘75, and I refined it when NSA, actually NBS, the National Bureau of Standards, but it was two guys from NSA that we were always communicating with, who had moved over to NBS. We estimated that 2 to the 56 is roughly 10 to the 17th power.

[23:28] That’s 100,000 million million keys. We estimated that you could build a search chip, even with 1975 technology, that would search a million keys per second, a microsecond per key. And we then said, you wouldn’t just build one of these, you’d build a million of them. And now you’re searching a million million keys per second. And how long does it take to search 100,000 million million keys? 100,000 seconds, which is about a day.

[23:54] It’s roughly 80,000 seconds. We estimated that the cost of searching a 56-bit key size was roughly $10,000 per solution in 1975. We were probably optimistic, but as I said, even a factor of 10 optimism would be erased within five years. The crude form of trapdoor was, if I build a machine like that, I can’t keep it fully loaded. I don’t have roughly 60 problems a month to keep it fully loaded. The U.S. National Security Agency has 60 problems a month to keep it fully loaded.

[24:29] And they have the $20 million to build the machine. I don’t.

Ryan:

[24:36] So they would retain access to privileged information through superior computing resources was their hope, and snoopiness.

Martin:

[24:47] The problem is you and I might want to snoop on one problem a year. How do we do that? Do we wait a year to get a solution? No, we want it quickly, but then it’s sitting idle most of the time and our cost goes way, way up.

Ryan:

[25:00] With modern public key cryptography, anyone can securely message anyone else, and no one can snoop. But that also includes the bad guys as well. What are your thoughts on, I guess, the devil’s advocate that says, why do you need to hide something if you have nothing bad to hide?

Martin:

[25:23] Well, if you want to put all your banking information out there in the public, if you want Apple to sign software updates in ways that bad guys can do, yeah, there’s no problem. But we do have reasons for being secure. We don’t live in a world where we trust everybody yet. And so there’s a fundamental trade-off. You cannot make strong encryption and give it only to the good guys and not to the bad guys.

[25:48] It’s like cars. If cars had been invented in the classified literature, the government might say, “This is great. We can catch bad guys, we can fight wars, and we can always win them because we have tanks, we have cars, we have things like that.” And they’ve got horses. And now imagine Whit and I invent a car 50 years ago in the unclassified literature. They’d be up in arms. We wouldn’t see ambulances, we wouldn’t see commuting, we wouldn’t see vacations that people could take.

[26:16] There’s a fundamental trade-off. It’s there with cars, and it’s there with cryptography as well.

26:22 — The story behind Diffie Hellman key exchange

Ryan:

[26:22] So I wanted to talk about the obviously the big invention that you had, public-key cryptography, the Diffie-Hellman key exchange algorithm. What’s the story behind you inventing this Diffie-Hellman, and maybe Diffie-Hellman-Merkle key exchange algorithm? Whit showed up on my doorstep, almost literally speaking, in the fall of 1974.

Martin:

[26:49] He had been traveling around the country. He’d worked at the AI Lab, the artificial intelligence lab here at Stanford. And he’d done some work on cryptography. He wanted to do more. They could not support it. So he took a small inheritance that he got from his mother, and he traveled around the country. And if you work in AI, if you’re known, there are people that will put you up in their garages, in their homes.

[27:12] They’ll feed you. Maybe John McCarthy lives up the hill. And Whit was a good friend of his. And there was a high school student living in his attic, I think, who was from Cambridge. And I asked him why he didn’t just go to the MIT Artificial Intelligence Lab. And he said he didn’t like their politics. I don’t know what that means. So Whit traveled around the country. And when he was at IBM Research, a secrecy order had descended on them just about this time.

[27:40] I’d been there a few months before. They told me they couldn’t tell me very much. They told Whit, when he came through, the same thing. But they told him one thing additional: “Oh, when you’re back out at Stanford, look up Hellman.” So he called me in the fall of ‘74. And we set up maybe a half hour, hour meeting, max. And it went through the night. They came back here, he and Mary Fischer, his then girlfriend, now wife, then wife.

[28:08] She’s passed away since then. And we had a real meeting of the minds. It was amazing. And so Whit and I started working together in the fall of ‘74. The Data Encryption Standard came out. In March ‘75, it was announced. We came up with the idea of public-key cryptography around then. And we did not know about Ralph Merkle at the time. Ralph was an undergraduate and later a master’s student at UC Berkeley.

[28:37] And he came up with half of public-key cryptography. He came up with public-key distribution. And I have his paper in which he. In the fall of ’74, we didn’t know about him then. He was taking CS244, computer security. And he had to do a term project. And he proposes two term projects. One is the privacy half of public-key cryptography. And the other is something much more mundane. And I have the professor’s handwriting in blue scanned.

[29:06] I’ve scanned this across the top. That idea number two, the mundane idea, looks much better than idea number one. Maybe because his description of idea number one is so muddled. But Ralph had major problems. So he drops the course. The professor says, “See me today about this.” Ralph, instead of seeing the professor, drops the course and goes and does it on his own. He then submits a paper to CACM, the primary Communications of the ACM, the primary journal of the ACM, and it’s rejected.

[29:40] I have the rejection letter. Susan Graham, who was the editor who rejected it based on a referee’s report, writes, “It bothers her that there are no references in the paper. Has no one thought of doing anything like this before?” The answer is no. Now, he still sort of had references. Ralph didn’t know how to write a paper at that point. I helped him rewrite the paper, and it was later accepted, but it was actually submitted a little before ours.

[30:09] Whit and I came up with public-key cryptography. Ralph came up with public-key distribution. We eventually learned about one another. Afterward, I bring him here in the summer of 76, and I talk to Ralph and I say, have you ever thought of coming to Stanford to do your PhD? And Ralph says, I can’t afford it. I said, yes, you can. How about you making it Berkeley as a TA? And I said, I pay you roughly the same as an RA here at Stanford, and your tuition would be covered.

[30:37] So he came to Stanford. He did his PhD under my supervision, supposedly, although we really worked together.

Ryan:

[31:31] It seems like this cryptography space was not so well resourced. I mean, Diffie is kind of going couch to couch to.

[31:39] To kind of support himself on this. Ralph’s also kind of doing this on his own, fully his own initiative, and people aren’t really supporting him throughout. Is that, was that common in cryptography at that time?

Martin:

[31:52] Yeah, I told you. All my colleagues, and it’s not an exaggeration, told me I was crazy to work in cryptography. And one of their reasons was NSA has a huge budget and a multidecade head start. One of them, Jim Omura, who passed away about a year, two years ago, he was a professor at UCLA. I mentioned him to you earlier. Jim told me I was crazy. And the best ideas often seem crazy ahead of time. So I was at Tom Kailath 10 years ago.

[32:20] I was at Tom Kailath’s 80th birthday celebration. He won the National Medal of Technology and Science, I think given to him by President Obama for his work keeping Moore’s law going for 10 years. According to the former dean of engineering at Stanford at the time, Jim Omura is standing six feet away. I motioned him over. I said, “Jim, tell this woman what you told me when I first started working in cryptography and I just won the Turing Award, the top prize in computer science for that work.”

[32:47] Jim said, “Oh, I told Marty he was crazy.” I knew he would do that because he’d given me permission to quote him on this. The best work often appears crazy a priori—GPS, which we use daily. Brad Parkinson, who won the top prize from the IEEE for that work, says that the Air Force thought GPS was crazy initially. High-speed Internet access. I won’t go into details there. And I’ve spoken to a number of Nobel laureates, and almost all of them had the same reaction from people that I did.

[33:22] One of them, I’ll tell you one story. Louis Ignarro, who won the Nobel Prize in physiology or medicine, I think, in 1998, told me that the dean of his medical school came to him and said, Louis, why are you doing this crazy stuff? We hired you because you do good work. Crazy stuff that won him a Nobel Prize.

Ryan:

[33:43] It makes sense. But I guess the unique aspect is I think a lot of people would receive that pushback and everyone thinks they’re foolish, and they wouldn’t go for it. What is it that gave you the confidence to continue when everyone was saying this is foolish?

Martin:

[34:04] Two reasons. One is I got beaten up as a Christ killer as a kid. And that’s a little bit of a joke, but not totally. As a kid, we moved to an Irish Catholic neighborhood. I’m Jewish. We moved there when I was four and a half years old. I went to my parents and I said, “I want the pretty tree that the other kids have, the Christmas tree. I want the presents under the tree. I want to go to the same school as the other kids in the neighborhood.”

[34:27] St. Nicholas of Tolentine Parochial School. I was telling my parents I didn’t want to be Jewish. And so, in self-defense, I adopted the attitude of who would want to be like anybody else? That had a very simple answer. Me. I would have given my eye teeth to have been like everybody else. But in time, I came to believe my own bullshit. And so when my colleagues said I was crazy to work in cryptography, instead of scaring me off, it actually attracted me.

[34:58] So that’s one reason. And the other reason, I think it runs in my family. I have an uncle who in 1940, with his wife, a Jew, took trains across the country with bicycles, bicycling through national parks. I mean, who but a crazy person would do that? I come from a crazy family. We’ve done crazy things. And this was a crazy thing to do.

Ryan:

[35:23] When you put out that paper in 1976, what was the problem you were trying to solve, or what was guiding your research direction at that time?

Martin:

[35:33] Well, it started as trying to develop a theory of cryptography. And Jim Massey, who was the editor at the time of the IEEE Transactions on Information Theory, of which I was on the board of governors, as I mentioned, Jim invited me to write a paper on that. I mean, this was beginning to get some traction. And I asked if Whit could be included. And he said absolutely. And so Whit and I were working on this paper.

[36:03] We had several drafts. Then in May 76, I came up with what is now Diffie-Hellman key exchange. And I included that. I threw that into a paper I’m giving in June 76, a month later at the IEEE Symposium on Information Theory in Ronneby, Sweden. Jim Massey‘s there, of course, and he says, you get that into the paper, I’ll have it out in the November issue, which he did. Now, the November issue, Whit is fond of pointing out, did not come out until February 1977.

[36:31] Was usually late, but that’s how it worked. And Ralph, unfortunately, as I said, had his idea rejected, his paper rejected. So his paper did not appear until 1978, even though it was submitted slightly before ours. I see.

36:48 — Signatures vs key exchange

Ryan:

[36:48] I think in this conversation you mentioned key exchange, also signatures. It seems like there are these components of a full cryptographic system. Could you explain each of these?

Martin:

[37:02] Key exchange is how do you and your bank exchange a key to protect your banking transactions, to use a modern example, with somebody listening on the Internet, and so use public key cryptography to do that Ralph Merkle had a puzzle method. Ralph Merkle had a puzzle method where he generated a sequence of puzzles and you solved. Your bank would solve one of them and it would then use that key. And you could quickly tell which key it was using.

[37:33] But somebody else had to solve half the puzzles, on average, before it could do it. And so it took a lot more effort on the part of an opponent. I’ll explain Diffie-Hellman key exchange very briefly. And that is only key exchange. It’s not yet signatures. You and I want to exchange physical messages. I want to write them out to you and pass them to you. But my wife, who is not supposed to see them, is sitting between us and has to hand them to you.

[38:06] So what do I do? I put my message in a strong box. I put a lock on that strong box. I’d like to tell you the combination to that lock. But if I tell you how to open it, I’m also telling my wife how to open it. So I don’t tell anybody how to open it. I pass it to my wife. She can’t open it. She passes it to you. You can’t open it. You put a second lock on the strong box. You then pass the double. You don’t tell me the combination.

[38:31] You don’t tell Dorothy the combination. Only you know the combination. You pass it to Dorothy. She can’t take either lock off. She passes it to me. What can I do? Take off my lock, leaving only your lock. I pass it back to Dorothy. She can’t take off your lock. But when you get it, you can. You get the message inside. That’s basically how Diffie-Hellman-Merkle key exchange works.

[38:55] Now, what’s critical about this is that I made the strongbox big enough for you to put a second lock on it. If I hadn’t done that, if I’d only made it big enough for one lock, you could have taken the strongbox that you got and put it in a bigger strongbox. But now there’s a problem. When I get it, I can’t get inside to take my lock off. It has to be what’s called commutative. And everybody knows what commutative means, although they may have forgotten it.

[39:20] Addition is commutative. Three plus five is the same as five plus three. It doesn’t matter which order you do the operations in. You get 8. 5 minus 3 is 2, 3 minus 5 is minus 2. You get a different answer. It’s not commutative. Subtraction is not commutative. What I had to do was find a commutative one-way function, although I didn’t know that at the time. The function I used is a commutative one-way function.

[39:47] It’s exponentiation and modular arithmetic. It doesn’t matter whether you first raise alpha to the x1 power and then to the x2 power or raise it to the x2 power and then to the x1 power. You get the same result. You get alpha to the x1 x2; multiplication in the exponent is commutative. And we did this over a finite field where exponentiation is not a smooth function, which would be easy to invert. It jumps all over the place.

[40:15] But it turns out it still works that way. So that is public key exchange, public key distribution. Digital signatures are more complicated. That’s something that Whit Diffie came up with. It’s called a public key cryptosystem. And then RSA, Rivest, Shamir, and Adleman came up with the first instance of that. There you have a public key and a secret key, and it doesn’t matter which order you operate on them. Whether you first use the public key and then the secret key or the secret key and then the public key.

[40:42] You get the initial result, they undo one another there. If I use my secret key, I can sign a message because there’s no privacy. But I send the encrypted message to you using my secret key. You use my public key, which you get from a public file, to verify it. That’s how my phone works. It’s got a public key built into it. Apple knows the secret key. Apple can sign software updates. People can take my phone apart and get the public key.

[41:13] But that doesn’t give them the secret key that allows them to sign software updates.

Ryan:

[41:18] I see. So in that case, Apple is signing their updates to your phone.

Martin:

[41:24] Right.

Ryan:

[41:25] So I also was reading about symmetric versus asymmetric, and what you’re describing sounds like asymmetric.

Martin:

[41:31] Yes. Asymmetric cryptography uses a public key and a secret key. It’s asymmetric. Conventional cryptography uses the same secret key to encrypt and decrypt. And that requires a courier, which is what was required before public key cryptography. If you were a general in another division, I could send you a key. I would send a messenger with a key locked to his wrist. And when you got it, you could open it up and get the key and then you and I could use a radio channel to communicate very cheaply and very fast.

[42:05] But you can’t use couriers to communicate keys between a bank and a client.

Ryan:

[42:11] Yeah. So I saw modern systems. It’s almost like multiple different mechanisms where there’s this asymmetric key exchange at the beginning to establish the connection. And then that gets you that key symmetric thing.

Martin:

[42:26] Exactly. It’s just like I described. First, Apple signing the software update. They don’t sign the whole thing. They only sign a hash. In the same way, we could use a public key cryptosystem like RSA to exchange messages, but it’s too slow. So what I do is I send you one message, use the following key in AES, the Advanced Encryption Standard, and then we use AES very quickly to exchange messages. And that’s the difference between asymmetric encryption, which we use at first, where I use the public key to encipher the message and use the secret key to get the key, and then we use a symmetric system to very quickly communicate afterward.

43:05 — RSA patent wars

Ryan:

[43:05] I was reading about RSA versus the Diffie-Hellman key exchange, and it seems like there were a lot of patents or something like that. Patent wars. What’s the context behind that?

Martin:

[43:18] I didn’t know how patents worked when we wrote the first patent on public key cryptography. If I’d known we could have covered RSA, we would have made a lot of money. Basically, RSA sold their company for $250 million. We made nothing, virtually nothing, from our patents in cryptography. There was a patent fight between RSA and us, MIT and Stanford, or between their licensees. And basically MIT won that fight.

[43:55] And I was pissed at RSA for a long time, and I was pissed with Jim Bidzos, the president of RSA Data Security. And around 1990, around 2000, sometime around there, I realized it was inconsistent with my approach to life to be pissed at RSA. They’d won. The fight was over. And so I approached Jim Bidzos and I said, look, Jim, I told him that, and I said, let’s be friends. Let’s bury the hatchet. And we essentially have.

[44:24] And friends are better than enemies. I’m not sure, but I think Ron Rivest might have actually nominated Whit Diffie for the Turing Award. Now, he wouldn’t have done that if he didn’t think we deserved it, but he wouldn’t do it if he was pissed at us. And friends are better than enemies. That’s not why I did it. That’s not why I became friends with them. But again, it worked out very well.

Ryan:

[44:48] How did they win the patent war if your ideas came first?

Martin:

[44:54] I remember I told you I didn’t know how patents worked. It’s only the claims that matter. And so if I’d known that, we could have written a claim that would have covered RSA easily, but we didn’t. And so the patent was written very badly. Stanford didn’t want to invest a lot of money in this patent, so it had a law school intern write the patent instead of a patent attorney. We made a lot of mistakes.

Ryan:

[45:23] You mentioned friends are better than enemies. Yeah, a lot of people would agree with you, but I also think most people wouldn’t be able to get over losing a $250 million outcome. How did you kind of get over that and establish friendship?

Martin:

[45:43] Well, some of it is in my genes, but a lot of it comes from my wife, basically. My wife and I have been married 59 years last March, and we were madly in love when we met. We followed society’s rules, and we developed a toxic relationship. Ten years later, my wife was ready to leave me, but I didn’t know it because I had blinders on, the way many husbands do. And fortunately, when she met me, she decided I was the one.

[46:12] And 10, 15 years after we’re married, roughly 50 years ago, she says he’s still the one, although life with him is impossible, and life with her was no picnic. So she went around looking for catalysts, ways to improve our relationship, and she eventually found a group. I won’t go into all the details there. I tend to do that. That worked on the international and the interpersonal at the same time.

[46:39] It was founded by Professor Harry Rathbun, who was a professor here at Stanford, born in the 1890s. So he’s no longer alive. I knew him late in his life, and that’s how I. It was based on the teachings of Jesus, which was a problem for me as a Jew because it was okay not to go to synagogue, which I didn’t do, but it was not okay to study the teachings of Jesus. That was traitorous. But eventually, Dorothy dragged me to enough meetings that over a year’s time, I came to see that these people, Creative Initiative, as the group was called at the time, knew something I had to learn if my marriage was going to survive.

[47:17] And I surprised myself by being willing to do things that seemed crazy to me. The most important things were accepting ideas that Dorothy had that seemed crazy to me, that weren’t crazy. Because what happened when she had an idea that seemed crazy to me? I treated her like she was crazy. What did that do? It drove her crazy. What did that do? It convinced me I was right, that she was crazy. Kept the whole cycle going.

[47:43] By the way, the same happens internationally. We treat countries in ways that they don’t like. They react in ways that seem crazy to us. We treat them like they’re crazy, and it keeps the whole cycle going. So that’s how I came. And so it’s based on the Gospels. And while I’m not a Christian, I see Jesus as a Jewish reformer rather than as a Christian messiah. I view myself as a follower of Jesus.

48:08 — Why inventions happen at similar times

Ryan:

[48:08] When I was researching the discovery that you had, it seems like all of a sudden many of the similar discoveries were happening all at the same time. So, for instance, you mentioned Ralph Merkle and us. Yes.

Martin:

[48:22] Oh, and GCHQ claims that they invented it just a couple of years before us, but they only have half of it, which is, if they’re right, which is the privacy part. They didn’t have anything on digital signatures, but they claim everything.

Ryan:

[48:36] Right. And then there’s also the MIT folks.

Martin:

[48:38] The MIT folks. Yeah. So I have a theory about that. I’m going to tell it as a joke, but there’s more to this joke than I think is just a joke. There’s a muse that whispers in our ears. There’s a muse of poetry. There’s a muse of calculus who whispered in Newton’s ear and Leibniz’s ear about the same time. There’s a muse that whispered in Ralph’s ear about the same time that she whispered in our ears.

[49:05] Most people don’t pay attention to this muse because she sounds crazy. A few people do. And so that’s why I think there’s something in the air. I mean, it’s not necessarily a muse, but there’s something in the air that comes to people.

Ryan:

[49:20] But why didn’t it come 50 years earlier? Or how come it seemed like they all came very similar? I noticed. I interviewed Barbara Liskov as well, who did a lot in data abstraction and modularity. And there also, it was like on the West Coast and the East Coast, without even communicating, they had the same discovery. Very similar.

Martin:

[49:46] I think my joke might actually have something to say about that. But also there’s something that goes on technologically. We didn’t have the computing power to do public-key cryptography. If someone had come up with it 50 years before, it would have been a nice idea that couldn’t be implemented.

Ryan:

[50:00] So there’s a logistical part to this, which is just the tools weren’t there, and once they were there, it kind of inspired the right thinking.

Martin:

[50:10] Yeah, but calculus, I mean, why? That occurred to Leibniz and Newton about the same time. Oh, and Darwin and someone else thought of evolution about the same time. So, I don’t know. It is mystical, and maybe we should treat it as that. Even though I’m a scientist, I believe in the mystical side of life.

50:29 — What he worked on after cryptography

Ryan:

[50:29] There’s a cryptography work that you’re doing. And then later in your career, I saw this rethinking national security, and I was curious how you got into this, I guess, area, this body of work. And what’s the problem you’re trying to solve?

Martin:

[50:46] Well, the problem we’re trying to solve is simple. We’re going to kill ourselves. I mean, right now, I estimate that a child born today has probably worse than even odds of living out his or her natural life as a result of nuclear weapons all by themselves, without climate change, without AI, without any of this other stuff.

Ryan:

[51:05] What are you talking about with this AI threat?

Martin:

[51:07] Well, there’s debate on that. Geoffrey Hinton, Yoshua Bengio, who won the Turing Award for their work in artificial intelligence, think that AI may actually kill human beings off, something like that, because it’ll say, “Why do I need these stupid people?” Whereas Ed Feigenbaum and Raj Reddy, who won the Turing Award 30 years ago for their work in artificial intelligence, have both told me and given me permission to quote them.

[51:38] So I’m not giving any secrets away that calling AI an existential threat is ridiculous. It’s science fiction. I don’t know who’s right, but I do know we need to build a more cooperative world for a number of other reasons, even if not that one. So why not solve that one? At the same time, we’re likely to build AI into our nuclear command and control system. Oh, my God, what a mess. Right now, I’m working on a bill.

[52:04] It’s H.R. 3564, and we have 25 on paper, 24 co-sponsors. The bill is so bad it’s passable, but so good that it’s a game changer. Why is it so bad that it’s passable? It has an exception for launch on warning. If our warning system shows a bunch of ICBMs coming our way, the President doesn’t need a second opinion to launch our nuclear weapons. He can do so all on his own. There have been mistakes in our warning system, so I don’t like that.

[52:37] But that’s why it’s so bad. It’s passable. This makes it easy for people to get on board. Most people don’t realize that the president can launch a nuclear war all on his own. Right now, a president could be awakened at 3 a.m. in the morning during a crisis, too drunk to legally drive a car, asked what to do, he might say drunkenly, nuke him. And right now, theoretically, the military’s supposed to do that.

Ryan:

[53:02] I didn’t consider that AI could be coupled with the nuclear bombs too. I guess AI could.

Martin:

[53:07] Oh, it’s likely to be. I mean, we have this problem that we have just minutes of decision time. Do you not think we’re going to use computers to help us there?

Ryan:

[53:18] Looking back on your career, being at Stanford during the growth of computing, I imagine you had a lot of opportunities to work with other famous folks in the industry. For instance, Don Knuth.

Martin:

[53:33] Don Knuth is a good friend.

Ryan:

[53:34] Yeah.

Martin:

[53:35] Don Knuth doesn’t use email. I think he does, but whenever I want to reach him, I have to call his home and talk to his wife, Jill. That’s the other story. Stories that I have John McCarthy at AI Lab up the hill, where Whit stayed there, by the way, when we were working on public-key cryptography because John was away and Whit and Mary were taking care of his daughter, driving her to her writing lessons.

[54:03] And so Whit just walked down the hill to talk to me. But John McCarthy, there’s a meeting at the faculty club maybe 45 years ago. Bob Floyd, who many of your people will know, who’s a famous— he died, but a famous computer scientist here at Stanford. John McCarthy comes in. Bob Floyd’s in the meeting. He goes over to Bob Floyd. I say, hi, John. He doesn’t pay any attention to me because everybody knows that I.

[54:30] I/O is a waste of time. And so he’s not going to waste time on I/O. So he has a very rapid exchange with Bob Floyd and he leaves. Well, I’ll tell you another thing. I’m finishing my... It’s 1968. Several months early in ‘68, I thought, who am I to think I can make an original contribution to knowledge, which is the definition of a PhD thesis? I’m thinking of dropping out of the program over spring break.

[55:01] I basically solved my thesis. It’s that quick. I go to Tom Cover, who’s since died, my advisor and very famous information theorist. And I go to Tom and I say, I just have barely enough units, but I have enough units to meet the course requirements for the PhD. But I don’t have enough units to meet the PhD requirements. I’m going to have to take units of research if I work at IBM Research. Would you give me credit for my units of research?

[55:34] Because my wife was pregnant with our first child then. We’d been married roughly a year, year and a half. I was concerned about money. He says, sure. And so I go to IBM Research, Yorktown Heights. Tom wants to have me come teach at Stanford, which I’ve done. But he says, “You really should leave for a couple of years because Stanford.” I sometimes joke that I had to leave for several years to lose the taint of the Stanford PhD.

[56:04] Why is that? Stanford was worried about inbreeding. If they hired me, I was just going to be doing research like Tom Cover. And they don’t need two of them. They need somebody different. And so I went away to IBM for a year because my thesis broke very suddenly. And I then taught at MIT for two years before coming back on the faculty in ‘71. And this seemed like just a stupid hoop I had to jump through.

[56:26] But it actually turned out to be very important because when I was at IBM, Horst Feistel, whose name many people may recognize, he was really the father of IBM’s research in cryptography. He was hired in ‘68. He was in the same department as me. I didn’t work in cryptography, but I had lunch with Horst, and he told me some of the amazing things that got me started. And then when I’m at MIT, Peter Elias, whose name many people today will not recognize, but he was one of the original contributors to information theory.

[57:00] Peter gives me a paper by Claude Shannon, whose name your audience probably will recognize, written in 1949. I’m sorry, published in 1949 in the Bell System Technical Journal, connecting information theory to cryptography. Which is when I realized that, oh, I’ve already done a PhD in information theory. Maybe I can do something worthwhile in cryptography. So that stupid hoop I had to jump through was actually very important because when I got back to Stanford, I started working in cryptography, among other things.

57:31 — His thoughts on death

Ryan:

[57:31] I think at the beginning of the conversation, you said something quickly that you had thoughts on death. And I was curious, what are your thoughts on death and how does it impact you?

Martin:

[57:44] And I got an email from somebody at The New York Times about a month ago saying that he’s working with my obituary, and it made me macabre, but he was wondering if I could read it over and if I have any comments. And so, the two things are that I’m 80 years old, so my older brother died just after he turned 80. My mother died at 70. My father lived to 98. I hope I’ll have more years, but if I don’t, that’s okay.

[58:10] I’ve had a great ride. But the two things that concern me about dying are the people I’ll leave behind, who I think are dependent on me but probably aren’t, and the work I do because very few people are working on the nuclear issue, the growth of humanity as a whole to save itself, that we’re headed for disaster. Very few people realize that. And very few people put it in terms of a process of change.

[58:38] We can’t stay where we are. We’re going to kill ourselves, we’re going to die. We can’t jump to where we need to go. The world is too dangerous. But we can get there via a process of change. I’ll tell you one other thing. Humanity is going to die. I’ve come to this realization. I mean, it’s clear. I mean, we might last a million years, but at some point. We might last a billion years, but at some point the sun’s going to burn out.

[59:02] Maybe we’ll move to other galaxies and we’ll find ways to cheat death for a while. But eventually humanity is likely to die. But if humanity were to die now, it would be an infant. It would be infant mortality. It would be really sad. If we’ve lived a full life, that’s something else. If I had died when I was a child, people would say, oh, what have we missed? If I die at 80, people will say, some people will be saddened by it, but.

[59:31] But they’ll feel like I’ve lived a full life. We need to save humanity from an infant death. We’ve only been around about 100,000 years.

59:40 — Advice for his younger self

Ryan:

[59:40] With all the experience that you have now, if you could go back to when you had just graduated college and give yourself some advice, what would you say?

Martin:

[59:49] If when I was just graduating college and I was interested in saving the world, which I was not, I might have gone up to the top of a mountain to a guru and asked him what to do. Imagine what you’d say. You’d expect him to tell you, work for the UN or something like that. Imagine what you’d say if he told me, forget about saving the world, which was not a problem because I didn’t think about saving the world.

[01:00:13] Go out and become as famous as you can, make as much money as you can, come back in 10 years, and I’ll tell you what to do. That would have seemed like a detour, but it was actually the shortest distance between two points. Because 10 years later, when I was 30, 35 years old and I was interested in saving the world, I had a reputation, I had money, and I had to screw up to get where I am. I had to not be concerned with the world to become concerned with the world to be able to do something, to do what I can do about it.

Ryan:

[01:00:40] Awesome. Well, thank you so much for your time today. I really appreciate it.

Martin:

[01:00:43] You’re welcome. And thank you.

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

00:41 - Asking him a popular Leetcode question

03:54 - Doing better than the popular optimal solution

08:26 - Fine grained complexity

17:00 - A severe strengthening of P vs NP

24:38 - SAT problems and solvers

34:51 - Hot takes on famous open questions

46:57 - Simulating space with time

01:01:02 - Why he solves hard problems

01:02:35 - How to pick good research direction

01:07:14 - Technical book recommendations

01:08:31 - Advice for his younger self

Transcript

00:41 — Asking him a popular Leetcode question

Ryan Peterman:

[00:41] Okay, I want to start by asking you the most popular LeetCode question. So the question is 3SUM: given a list of numbers, we want to find three numbers such that they sum to zero.

[00:58] And so what are your thoughts on the brute force solution for this? We can start there.

Ryan Williams:

[01:04] So the obvious brute force solution takes, if you’ve got n numbers, N cubed time, just try all the triples of numbers, sum them up, see if they sum to zero. There is a faster solution. So one way to get an order N squared time algorithm for 3SUM is to first start by sorting the numbers. And then you go through the numbers one by one. Say you’re looking at a number A, and you want to know, is there a B and a C in the rest of the list whose sum with A is going to be zero?

[01:45] Okay, so the way this works is after you sort the numbers, you do what’s called a finger search. So you put the finger from your left hand on the minimum element and a finger from your right hand on the maximum element. So you start there and you check, okay, are these my B and C? Right? So you add them, min and max, and check if adding that with A gets you zero.

[02:17] And if you’re lucky, then you’re done. But typically you’re not lucky. And so this sum of the min and the max is either larger than your target value minus A, or it’s smaller. If it’s larger, then you need to decrease the larger number. So you take your right finger, which is sitting on the maximum element, and you move it to the left one slot. So you decrease the larger one. All right?

[02:47] If the sum is smaller than your target, you need to take the smaller number and make it a little bit bigger. So you move your left finger, sitting on the minimum, over one slot. Okay? And you keep doing this. You keep checking whether your left finger and right finger are pointing at a solution. And if they aren’t, then you adjust it. If they do, if they ever do sum up to exactly what you want, you’re done.

[03:14] And so after each comparison, right, one of your fingers moved, okay? If the fingers ever cross, then you don’t have a solution. There just can’t be a solution. And so the number of times you move your fingers in total is like N. So you have order N solution for finding that extra pair. And you do this for each of the numbers A, okay? So then you get an order N squared solution overall, you do it N times.

[03:46] Each finger search takes order N time.

Ryan Peterman:

[03:50] And that is the popular solution.

Ryan Williams:

[03:53] That’s the popular solution.

03:54 — Doing better than the popular optimal solution

Ryan Peterman:

[03:54] A lot of people know when we’re in these algorithmic LeetCode interviews, and I know a lot of your research is kind of about pushing lower bounds. So maybe we can start that conversation off by asking: can you do better than N squared for this?

Ryan Williams:

[04:10] Yeah, you actually can do better than N squared. And this is not at all obvious. In fact, it stems from taking this finger search idea and pushing it in a different direction. So what you do is you take your sorted list, okay, and you break the sorted list up into little groups of contiguous elements. So let’s say your little group is like log n size or square root log n. It’s like a really small little group, okay?

[04:42] So you’ve got either n over log n groups total or n over square root log n groups total, depending on how you break up your groups. And then the idea is you’re going to perform the same kind of finger search, but you’re going to set things up so that you’re comparing two pairs of groups. Your finger’s always pointing at an entire group. So the left hand and right hand are pointing at two groups.

[05:08] And you want to know if there’s a 3SUM solution in that group. And you can set up a kind of fast data structure to check a small group, okay? This data structure will take much less than the number of elements in the two groups squared. So you set up some kind of fancy data structure. And because you set your group size so small, it’s like a preprocessing that you do over all the possible inputs you could send from a pair of groups.

[05:40] And so you have some data structure, and it will, let’s say it takes you \(n^{1.5}\) time to prepare this fancy data structure. But now when you’re looking at a pair of groups, you can look up the answer much faster than what finger search would have taken. I guess finger search through a group of length \(g\) and another group of length \(G\) would take about \(O(G)\) time, and you can do actually faster by this kind of lookup, this kind of table lookup.

[06:08] I think it is kind of like you take this list of length n and you kind of shrink it into like N over group size number of things. And these are more complicated objects. And then you do, and now you’re trying to speed up the check over these small, complicated objects for like, should I move my finger to the right? Is there nothing in this group? Would finger search just go straight through this group or not is basically what you’re asking.

Ryan Peterman:

[06:45] So the unit that you’re operating on is not a single integer, it’s a group.

Ryan Williams:

[06:49] Yeah, it’s a group of them. So you use some kind of table lookup. Well, it’s much fancier than a table lookup. Actually, it goes through some other model called the linear decision tree model. So it’s like in some weird model where you can actually get a faster 3SUM solution. You can get it into the 1.5 solution. It’s a really interesting and sophisticated solution.

[07:11] But what I want to emphasize is that it starts from the finger search solution and sort of figuring out how to process finger moves faster, sort of do preprocessing so that finger moves can go faster.

Ryan Peterman:

[07:26] Yeah, I saw the time complexity of this. It’s N squared divided by log n divided by log log n, divided by all raised to the 2/3. What is there any intuition behind that? I mean, that’s just crazy.

Ryan Williams:

[07:40] So there are several algorithms of this kind, and they all work by doing some modification on what I was talking about because you can sort of reduce to a different model, like a different kind of lookup table, a different kind of set of tricks. And maybe there are some savings you can do here and there by sort of compressing things a little differently. So yeah, there are several algorithms that beat the n squared running time bound, and they all, to my knowledge, kind of work in a similar type of way.

[08:14] They’re taking this n-squared time algorithm, finding little ways to preprocess and then optimize based on the preprocessing, like make finger searches faster and things like this.

08:26 — Fine grained complexity

Ryan Peterman:

[08:26] Yeah, a lot of your research is on this topic of fine-grained complexity, or kind of lowering lower bounds. So maybe you can explain what is lowering lower bounds.

Ryan Williams:

[08:40] The idea behind fine-grained complexity is we have a variety of problems, canonical problems, that we teach to undergrads. We have canonical algorithms for these problems. These algorithms have resisted any major improvements in decades. And so we wonder, are these algorithms optimal? And what does the theory of optimality look like in terms of time complexity? So what if we just focus solely on the time complexity of a problem, like the fastest algorithm that will solve that problem?

[09:22] What does complexity look like then? Because P versus NP is not about time. I mean, it’s about time complexity. But on a coarse-grained level, where P is just polynomial time, that polynomial could be n to the 10, n to the billion, whatever. And so showing that something’s not in P is showing that it needs some superpolynomial amount of time. Whereas here we are concerned with there’s a canonical problem, it takes N cubed time.

[09:53] With some very elegant canonical algorithm, we want to know, could you do any better? Could you improve that exponent to n to the three minus epsilon for some epsilon? And then you ask, well, suppose I have a problem over here and it has a quadratic time algorithm, and I want to know if I can improve that quadratic time algorithm by a little bit. Then you start asking questions like, well, suppose I improve this algorithm by a little bit.

[10:25] Can I improve this algorithm over here by a little bit? And this is naturally a notion of reduction, like saying that I want to have some reduction from problem A to problem B, so that if I can improve the algorithm for problem B just a little bit, then I can also improve the algorithm for problem A by just a little bit. This actually leads to a different notion of complexity. You can even take an NP-complete problem and a P problem and reduce the NP problem to the P problem, and the question still makes sense.

[11:00] So, for example, you could talk about the Subset Sum problem, okay? So the Subset Sum problem, you’ve got n numbers and a target value, and you want to know if there’s a subset of those numbers that sum to a particular target value. Okay, now you’ve got 2^n possible subsets. The obvious algorithm takes 2^n time. Okay? But you can actually do better than this. And the way you do better than this is to reduce to a polynomial-time solvable problem.

[11:41] So you can get an algorithm which runs in square root of 2 to the N time. For the Subset Sum problem, you can avoid enumerating over all the possible subsets in a substantial way. And this is, in fact, known as commonly used in cryptanalysis by, I guess, a meet-in-the-middle type approach. So people do this sort of thing all the time. The idea is you partition the set of all the numbers into two halves, like n over two, n over two.

[12:16] You enumerate all the subset sums on the two halves. So you have 2 to the n over two possible sums for the first half, two possible sums for the second half. Then you want to know, is there a number from the first half, from this huge list, plus another number from the second half, this huge list, that sums to the target. Now this is the 2SUM problem. This is really nothing more than a 2SUM problem, which you can solve by sorting and binary search.

[12:51] And this is a reduction. We have shown how to solve a Subset Sum problem, which would normally take 2 to the n time, in square root of 2 to the N time, an NP-complete problem, by reducing it to a problem like 2SUM. The obvious algorithm there takes n squared time, trying all the pairs of numbers to see if they sum to a target, and using an n log n time algorithm for that. So fine-grained complexity can relate problems that would not be relatable at all in the traditional P vs NP theory.

[13:28] Like, one problem should be complete, the other problem’s not, so they should not have a polynomial-time reduction between them in general. Right. But if you just look at the time complexity and you focus on, okay, I have an algorithm, 2 to the n algorithm, is it the best possible? And then I have an n squared algorithm, is it the best possible? And then you can relate the two problems, and this is a general phenomenon that you can relate problems that look like they should have nothing to do with each other.

Ryan Peterman:

[13:58] So you talked about reducing a Subset Sum to 2SUM, but Subset Sum is arbitrary integers that sum to the target sum, right?

Ryan Williams:

[14:11] Yeah. So the idea is, nobody said I had to use a polynomial-time reduction or something like that to reduce one problem to another. So what happened? The trick was I took this Subset Sum problem that had n numbers and then I blew it up to an instance of this 2SUM problem. But that 2SUM problem has about square root of 2 to the n numbers. Now I can solve 2SUM in linear time, so solving that instance gives me a square root of 2 to the n time algorithm for the original problem.

[14:49] But yeah, in the meantime, going from one problem to the other, I blew it up. But by blowing it up, I’m able to improve the time complexity of the obvious algorithm for Subset Sum.

Ryan Peterman:

[15:01] I get it. Okay. So the reduction, it’s kind of like if you solve the Subset Sum, you have some time complexity, and if you translate it to the other problem, you lose a little bit of time complexity, but less than the aggregate.

Ryan Williams:

[15:17] So all you want to make sure is when all the dust is cleared and settled, you want to be able to say, look, if I can improve the obvious algorithm for 2SUM, then I can improve the obvious algorithm for Subset Sum. And that’s what this thing achieves, because I know how to get a faster algorithm for 2SUM. I can get one for Subset Sum. So you just want your reduction between two problems to have this property.

[15:43] If I can improve one problem by a little bit in running time, I can improve the other problem by a little bit.

Ryan Peterman:

[15:49] In one of your talks, you mentioned preserving magic between.

Ryan Williams:

[15:54] Right.

Ryan Peterman:

[15:54] Okay, so this is that.

Ryan Williams:

[15:55] Yes, this is exactly like preserving magic because once you see the 2SUM solution, it’s not so magical anymore. But imagine that you didn’t know about sorting and binary search and the like, and someone just says, find a pair of things with a certain property and there are N things. And you’re like, well, all the number of possible pairs is about N squared, so maybe it’ll take me N squared in this particular case, because they’re numbers and you’re summing them.

[16:28] There’s an n log n time algorithm. It is a surprise when you first see that. No, you don’t have to try all of the pairs of numbers. There is a shortcut. There is a clear shortcut that lets you find a pair much faster. And then you can use that surprise, or magic, if you will, and get something for Subset Sum. Get an algorithm for Subset Sum that avoids trying all of the subsets.

17:00 — A severe strengthening of P vs NP

Ryan Peterman:

[17:00] So I understand one of the driving motives for pursuing this, I guess, lowering of lower bounds is the Strong Exponential Time Hypothesis, or SETH. Could you explain that and its significance?

Ryan Williams:

[17:18] SETH is like a severe strengthening of the P vs NP question. So P vs NP is asking whether the SAT problem has a polynomial-time algorithm or not.

Ryan Peterman:

[17:37] Right.

Ryan Williams:

[17:38] And SETH is basically saying that for the SAT problem, you cannot solve it much faster than 2 to the n. So there’s no 1.999 to the n time algorithm for every string of nines. There is no 1.9999 to the n time algorithm, to say the hypothesis totally precisely. It has to do with the k-SAT problem. And you’re looking at clauses of length k for arbitrary k, but those details don’t matter.

[18:21] So much. It’s a canonical NP-complete problem. SAT is solved all the time. In practice, it’s extremely useful for verification. Nowadays it’s an engine for verification. So it can be solved fairly well in practice. However, in the worst case, we still don’t know how to solve it significantly faster than 2^n. So the hypothesis that it needs, say, 1.9999^n time for all strings of n is a very strong exponential time hypothesis.

[19:00] And so it’s stronger than P versus NP. It says, no, no, no, it says not superpolynomial. It’s actually darn near the end time that you need.

Ryan Peterman:

[19:09] Right. And so do you think that hypothesis is true? And why or why not?

Ryan Williams:

[19:15] I think I’m on the record as not believing this hypothesis. Yeah, yeah. Why don’t I believe this hypothesis? Well, I started thinking about this hypothesis maybe already as an undergrad, but certainly starting in grad school. Early in grad school, I was thinking about this. So before it was even called SETH, I guess that shows how old I am, I was trying to think about how to solve this so-called CNF-SAT problem faster than 2^n.

[19:52] And well, at the time there were a number of other NP-complete problems that had faster algorithms, like Subset Sum. So I thought, well, there’s not, I mean, what’s so special about SAT? If all these other problems have faster algorithms, why not SAT as well? If you restrict to the 3-SAT problem, this is where you have an AND of these clauses. Each clause is an OR of three variables.

[20:30] Some of the variables may be negated. You want to know if there’s a way to set all the variables to make all the clauses simultaneously true. There is a faster algorithm for that, but this is a more general version of SAT. So at first I just thought, well, there’s no good reason to think in a lower bound. These other related problems have upper bounds, so why not? But then over time I would have different attacks on SETH, like trying to refute it, always trying to refute it in different ways. These attacks would fail in some completely catastrophic and ridiculous way.

[21:13] They would have no chance of actually solving the original problem. But by sort of staring at my failure and trying to think, well, there’s something interesting happening here. What can I do with this? There’s something interesting, yeah, it doesn’t refute the Strong Exponential Time Hypothesis thing. What does it do? So by trying to pivot and figure out, okay, what can I do with my failure, I was able to solve a variety of other problems instead.

[21:47] And so after a while, I realized that the truth value of SETH to me is almost irrelevant because if I believe that it’s false, then I get good ideas. I get good ideas. And so by trying to think about, okay, what would an algorithm that breaks 2-SAT look like? What could it look like? I sort of force myself to think in a different way. I have to discard other natural algorithmic possibilities because we know they won’t work, and I have to think in a different direction.

[22:32] And so because it kind of sends my brain in a different direction, sends me thinking a different way, it’s very useful for research. I mean, even though I still haven’t refuted it or whatever, it’s very useful for me to believe that it’s false operationally.

Ryan Peterman:

[22:55] I believe this is a minority opinion, right? Why would they go against it?

Ryan Williams:

[22:59] I mean, I think, for example, Russell Impagliazzo, a good friend of mine who helped propose this. I mean, he always emphasizes to me, well, this is a hypothesis. We explicitly did not name it a conjecture. We wanted to sort of put forth some lower bound that would get you to think about it, like something that’s maybe a little more controversial than the other types of things like P vs NP or whatever, or other things that people more normally believe.

[23:34] So, hypotheses which are at the edge of our understanding can be enlightening to think about, like where we truly don’t know what the answer might be based on our intuition. So this is, I guess, one reason why it was proposed. But one reason why you might believe that SETH is true is because believing it implies a lot of other lower bounds for you. Conveniently, because you can reduce the SAT problem to a bunch of other problems that seem totally unrelated, like edit distance, various pattern matching problems.

[24:18] They have natural polynomial-time solutions. If you can improve on the algorithms for any of those, you would improve the one for SAT as well. You would get something better than 2^N. So believing in it sort of makes a convenient worldview. It shows that all these different textbook algorithms are indeed optimal.

24:38 — SAT problems and solvers

Ryan Peterman:

[24:38] We’ve talked about SAT, or we’ve mentioned SAT so many times in this conversation. I know there are so many forms of that problem. What are all the different forms? And I know there’s clause width, also this idea of depth, too.

Ryan Williams:

[24:51] The most common representation of a SAT formula is a conjunctive normal form, so-called CNF representation. And this is what modern SAT solvers get as input. They get their file in so-called DIMACS CNF form. And this is just every line of my file. I give you a list of variables, possibly with negations, and each one is a clause. And I’m supposed to take the OR of those variables or negations. These are variables or negations.

[25:30] They’re often called literals. Okay? So I take an or of these literals, and the width of that clause is the number of literals in it, okay? And I’m supposed to take the and over all those lines, each line in my DIMACS CNF file. So it’s an and of a bunch of ors, and each or has some small number of literals in it, call it k. So usually the width is called k. And so the k-SAT problem is to find an assignment to all the variables that satisfies all the clauses.

[26:09] When each clause has width k or at most K, it could be smaller. So that’s the most popular version. That’s what SAT solvers churn on. And that’s what is behind SETH. That’s the representation there. But there are other ways to represent a Boolean formula. You could just simply represent it as some arbitrary expression made up of ors and ands and negations. It could just be some arbitrary expression with nested parentheses and all that mess.

[26:51] You could ask, given a formula in this representation with a bunch of variables, is there a way to set the variables to make this true? That’s Formula-SAT. You could also look at circuits of bounded depth, as you mentioned. So there is this class of circuits that people study called AC circuits for alternating circuits. It doesn’t mean alternation in terms of electricity; it means alternation in terms of ors and ands.

[27:28] So these circuits are made up of ORs and ANDs, in layers. So the CNF representation is a special case where I have an AND of ORs, like an AND of a bunch of clauses and ORs of the literals. But you can go further. You can have an AND of OR of ANDs of variables with negations and things like that. And so these are constant-depth AC circuits. And because the idea is you only have some constant number of layers of these ANDs and ORs.

[28:05] And you can look at the SAT problem on circuits like that as well. For example, those are two other versions that people look at.

Ryan Peterman:

[28:13] Yeah, SETH is on k-SAT. And I saw on 2-SAT, 3-SAT, 4-SAT, 5-SAT, there exist solutions that are asymptotically better than 2 to the N. So I guess the larger K can be, the more difficult the problem.

Ryan Williams:

[28:33] That’s the intuition. That is the intuition.

Ryan Peterman:

[28:36] I’m curious, have you ever plotted that curve? Does it drop off exponentially, or...

Ryan Williams:

[28:41] Yeah, yeah, yeah. That’s what’s so interesting about the current state of the art in k-SAT algorithms. As K increases, all of them, all of the different types of algorithms you might try to run, they all approach a 2 to the n exponent. Like as K grows and grows and grows, they get 1.99, 1.999, and so on. And yeah, it drops. In other words, it goes toward two pretty quickly, actually. So we understand how the exponent behaves pretty well for the known algorithms we have.

Ryan Peterman:

[29:24] And then for something like 3-SAT, what is the intuition behind speeding up an exponential time search?

Ryan Williams:

[29:32] Yeah, so for 3-SAT, let’s just look at a single clause. Okay. A clause that’s got three variables in it. Okay. We know that if we set all those three variables wrong, it’s going to be false. Okay. So we have to avoid one of those assignments. Okay, well that means that there are seven out of the eight possible assignments. So there’s three variables, 2 to the 3, eight possible assignments.

[30:01] Seven of them could be a satisfying assignment. They could be part of a satisfying assignment. We don’t know. But one of them is definitely not. So one easy way to see that 3-SAT can be solved in less than 2^n time is just take any clause, try one of the seven possible assignments and plug them in, and then recurse on the remaining formula. Now let’s think about what we did. If we were just trying all the possible 2^n assignments and we would like plug in one of eight possible assignments for each of those three variables.

[30:43] And so we’d have seven recursive calls. Well, instead, because we’re clever and we looked at the clause, we have seven recursive calls, and that’s the difference. So we reduced by three variables at the cost of seven recursive calls, as opposed to eight. And this gets you a slight improvement. This gets you about 1.92 to the N. Something slightly better than to the N. Okay, but you can do better than this.

[31:17] But this is sort of like the idea you try to look at ways to plug in variables that will force constraints so you can rule out a large portion of the possible assignments.

Ryan Peterman:

[31:30] When I was thinking about circuits and the different widths and depths, I don’t know if this is an unusual question, but it reminds me of neural nets. But the operators are different and the space of the literals is different. So instead of booleans, it’s maybe floating points. And so it just made me wonder about the algorithms that you might apply on a neural net. Is there analogs between these two spaces?

Ryan Williams:

[32:01] Yes, yes. If we look at, say I want to model a neural network, so I want to compute, say it’s still a Boolean function, but I want to do it with a neural network. So I want to use, let’s say ReLU or sign activation functions or what have you. There is a slightly more general gate that we can use instead of ORs and ANDs that turns out to basically be equivalent. So if instead of using ORs and ANDs, we use a so-called majority gate, which outputs one if and only if at least half of its inputs are one, using this and negations, we can actually simulate neural nets, like the usual types of neural nets that you think of with the usual types of activation functions.

[33:03] So if they have a constant number of layers of neurons, we can get a constant number of layers of majority gates and negations. So this is so-called TC circuits for threshold circuits.

Ryan Peterman:

[33:19] Yeah.

Ryan Williams:

[33:19] So once you allow threshold circuits, you can start to model neural networks still using Booleans. We’re still looking at Boolean inputs though. Yes. So once you allow your input space to be larger and have floating points, then you can prove a lot more in terms of lower bounds. You can find things that take depth 3 in the neural net that can’t be done in depth two and so on. So yeah, once you go past that and you start looking at just arbitrary real domain, it becomes a totally different picture from a discrete domain.

34:51 — Hot takes on famous open questions

Ryan Peterman:

[34:51] One topic I thought might be fun to go over is you wrote this paper about the likelihoods of these various conjectures and complexity theory.

[35:00] And I pulled a few of these that were kind of minority opinions, or maybe less common takes. Curious to hear your rationale. Okay, one of them, the well-known one, P not equal to NP, or P vs NP, you assigned an 80% confidence that they’re not the same. Yes, and I think most people say much higher confidence. So why would you assign such a low confidence that they’re not the same?

Ryan Williams:

[35:32] It’s interesting because I think I originally had something like 75%, but then my college classmate Scott Aronson was like, how dare you? Kind of. He sort of called me out. I’m like, okay, fine for you, 80% fine. I guess my point is that we really don’t understand polynomial-time computation as deeply as we think we do. And there are surprises, like all the time, in the power of algorithms. There are very few surprises in terms of lower bounds.

[36:13] When we are able to prove a lower bound, typically it’s something we very much expected to be true. But it was hard to prove. Somehow we pulled it off, we got what we expected to be true. But all the time in algorithms, people are finding algorithms where it’s just surprising. Just wait, what? How do you get something that fast? Right? So this just happens over and over.

[36:47] When I was younger, when I was first thinking about P versus NP, I had an intuition for what should be. And what I’ve understood over the years is that my intuition for what should be is often just wrong. And I’m having to revise my intuitions all the time. So when something like this happens often enough, you start asking yourself, what do I really understand? Do I really understand P versus NP?

[37:26] I mean, I understand that the statement, right? It’s just one of those problems where somehow it is not so difficult to make formal, to write down mathematically, but to actually know what the answer is is just orders of magnitude more difficult than it is to phrase the problem. And complexity theory in particular is littered with statements like this, where the space of algorithms is just that vast.

[38:01] So if you just keep getting surprised over time, you’re like, well, what do I understand? Maybe it was just misplaced confidence.

Ryan Peterman:

[38:10] Okay, what about this one? So EXP not equal to NEXP. Or would you say NEXP?

Ryan Williams:

[38:16] Oh, NEXP. Yeah, X versus NEXP. So this is like the exponential time of P versus NP for EXP not equal to NEXP.

Ryan Peterman:

[38:22] Or NEXP, you gave it a 45% chance. And if this is the P vs NP equivalent, but for exponential time, why is it so low?

Ryan Williams:

[38:39] Oh, because exponential time algorithms are even more powerful. Did I really say 45%? I mean for NEXP versus EXP or NEXP versus coNEXP?

Ryan Peterman:

[38:49] Yeah, NEXP not equal to EXP, 45%. It’s in this table.

Ryan Williams:

[38:55] So in other words, I believe NEXP equals EXP more than I believe they’re different. Right? So, yeah, let me try to explain why. So you can think of the NEXP vs. EXP question as some special case of P vs. NP where instead of looking at the arbitrary SAT problem, I’m looking at a SAT problem which is extremely compressible. So there’s a really small little computer that is exponentially smaller than the length of the instance, and it just outputs the character on the line number and the column number for the DIMACS CNF, like the CNF file.

[39:44] Okay? So it’s like an extreme compression of some file. So it’s like you zipped it down to something like exponentially smaller than its original length. Okay, so it’s like some super compressed, extremely highly regular SAT instance. So I give you that and I ask you, when you unpack this thing, decompress it, is the result going to be satisfiable or not? And I want you to solve this in time polynomial in the decompressed representation.

[40:20] Okay. So the point is that this is SAT, but in some very special case where the thing is extremely structured. So the idea, one conjecture for why SAT solvers work in practice, like one, I mean, this is, I mean, conjecture may be overkill because, I mean, this is just. This is not even a well-formed mathematical statement. So one hypothesis for why SAT solvers work in practice is because the real world is highly structured.

[40:58] The real world is governed by physical laws that are not random, they’re not arbitrary. From a very small number of rules, we can recreate so much of science. So what arises in practice from designs of hardware and things like this are often extremely compressible. They have to be extremely compressible. And so maybe it’s true that every sentence which has a highly compact representation can just be solved efficiently.

[41:35] This is the idea of whether in P vs NP that when it’s really, really structured like that and super compressible, there is some advantage. It’s not like something completely random. And since it’s not like something arbitrary, it’s, in fact, very, very special.

Ryan Peterman:

[41:51] The other one is 80% likelihood on NEXP equal to coNEXP. And you wrote, “Why would a self-respecting complexity theorist do that?” Yeah, I was curious why that’s such a contentious statement.

Ryan Williams:

[42:08] So NEXP versus coNEXP. Let’s first talk about NP versus coNP. So coNP is like the class of complements of NP-complete problems like UNSAT, like checking whether something is UNSAT. Now from the time-complexity point of view, there’s no difference between checking SAT and UNSAT. You can always flip the answer from the complexity point of view. If I ask you, does coNP equal NP? What I’m asking you is could you prove to me that a formula is unsatisfiable with a short proof when it’s satisfiable?

[42:50] I can give you a short proof. I can just give you the satisfying assignment, you plug it in, check that it works. But if it’s unsatisfiable, if no assignment works, we’re saying for all assignments the formula is not true. Can you flip that to an existential statement and say, oh, there exists this little proof that makes it work? So people don’t believe that NP is equal to coNP, and in fact NP different from coNP implies P different from NP.

[43:21] But so this is the exponential time version of P vs NP. So it’s coNEXP versus NEXP. The reason why I think these are likely to be equal is that if a little birdie sat on a NEXP machine’s shoulder and gave it a little bit of advice about what the coNEXP thing is doing, then the NEXP algorithm can actually solve coNEXP problems. And so let me explain, let me explain why. What’s the little birdie?

[44:02] What the heck is the little birdie saying? So because NEXP problems can run in 2 to the n time and 2 to the n squared time and things like that, running an exhaustive search over all possible inputs of length n is no problem for NEXP. So what a little birdie can do is say, okay, suppose I want to verify that this particular instance, let’s say we can talk about an UNSAT, but some compressible UNSAT problem or something.

[44:38] Suppose I want to prove that this compressible UNSAT instance is a yes. Okay, how am I going to do that? With NEXP, the little birdie will tell me the total number of inputs of length N which are a yes. Okay, so it will just tell me some string which says, “Here’s the total number of inputs of length N. You gave me a length-N input. Here’s the total number of inputs of length N that are a yes.”

[45:09] Okay. So this advice, this little bird’s advice doesn’t take very much to encode account. It’s like order in bits to encode a count of things. So what does the NEXP thing do to prove a coNEXP thing? What it does is it guesses the things which are a no. So I’m trying to prove UNSAT. So UNSAT means yes, SAT means no. So the NEXP thing guesses those things which are no.

[45:45] The no things it can answer, right? If it’s a SAT thing, it can just guess the answer to each of the no’s. Okay, so it guesses the answer to each of the no’s, it verifies all those answers, and then it checks the number of things it guessed is what the birdie told it. Once it’s done that, all the no’s have been covered, so everything else must be a yes. So it can actually prove a yes by just exhaustively finding all the no’s and ruling out any other no’s.

Ryan Peterman:

[46:21] But the big question in my mind is, where do you get the little birdie?

Ryan Williams:

[46:24] Where do you get the little birdie advice from? Yeah, yeah. So, yeah, so this I’ve studied. Yeah, this is what the little birdie gives you. And it seems to me that it’s possible that this little birdie itself can be constructed in NEXP. And if so, then we’d just be done. In NEXP, you figure out what the little birdie would tell you and then use that to just flip the answer. So, I guess let’s sort of guess all the things which are no.

[46:55] So what remains must be a yes.

46:57 — Simulating space with time

Ryan Peterman:

[46:57] And we talked a lot about time complexity, and you mentioned a little bit this advice, I guess, kind of space complexity. And I know you had a major result relating space and time complexity. You’re basically simulating time complexity with space complexity, but lower than it’s been done prior. Could you explain what it was before your breakthrough result and then maybe the intuition behind your breakthrough result?

Ryan Williams:

[47:25] In general, the problem is the following. I give you an algorithm that runs in time T, and I want to know, is there another algorithm that uses space much less than T, uses an amount of memory much less than T, and still solves the problem completely, still completely simulates the thing perfectly. One intuition for why you might think this question just can’t be solved.

[48:01] For some problems, there’s just no way to improve on the space. If you think of a lot of problems in dynamic programming, let’s say I have some logic circuit that I want to evaluate, and all the gates are provided to me in a row, and all the wires sort of flow from left to right, and I start with information on the left. I want to compute the information on the far right, and all the bits are flowing left to right by wires.

[48:36] The natural way to evaluate such a circuit is you start with, say, the inputs on the left. For each gate in turn in the line, you look at its inputs. Its inputs have been determined. There are some bits. You use that to compute the value of that gate. You pass the values of the output of that gate forward. But if that circuit has T gates in it, it will take about T time to solve, but it will definitely also take about T space in general.

[49:10] Right? Like the circuit could be wired up in some wild way, and there just might not be a way to save space for an arbitrary circuit. But already in 1975, people were studying this kind of question and finding counterintuitive answers to it. So Hopcroft, Paul, and Valiant, based on work of Paterson and Valiant, showed that time T algorithms, at least in this so-called multi-tape Turing machine model, a very powerful model, can be simulated in space t divided by log of t.

[49:54] It’s like you get some space savings, but it’s only a log T factor. Okay. And the way this is done is quite counterintuitive. Even though there’s only a log factor, it was pretty shocking that development was extended to random access models of computation later and more general models of computation. So, in the late 70s and early 80s, it was known for pretty much any reasonable model of computation that time T can be simulated in space about T over log T.

[50:42] But there was a hidden, maybe not so hidden, gotcha. In the space-efficient simulation, it needs an exponential amount of time to run. So there’s a time-space tradeoff. Okay. If you really want to save some space, you got to blow up the time by a lot. Nevertheless, yeah, it was kind of commonly conjectured that this T over log T space was about the best you could do and that you were probably not going to get T to the 0.

[51:17] 9 space or something much more efficient. So, yeah, it was a big surprise to me that you can actually put time T in space about square root of T. Again, there’s an exponential running time just to give the full caveat out there. But it’s still very surprising. This holds for any kind of time T algorithm, including something that might be outputting something pseudorandom, something from cryptography.

[52:00] It’s not at all obvious that every such process could be compressed to only need square root of t space and still get the job done, still compute whatever function was being computed.

Ryan Peterman:

[52:13] I mean, I know it’s probably super involved, but if you could just, at a high level, what’s the trick? How’d you do it?

Ryan Williams:

[52:19] Well, the trick for me was to read James Cook and Ian Mertz’s paper on tree evaluation very, very carefully, and just know the landscape around P versus PSPACE and know what Hopcroft, Paul, and Valiant did. Yeah. But I can give you a very high-level idea of kind of what’s going on and how what they did is useful. So Hopcroft, Paul, and Valiant, the way they were modeling space-bounding computation was in a particular way that seemed pretty general at the time, but turned out to be restrictive in ways that we just didn’t anticipate.

[53:10] So the way they thought of it was I’m gonna take certain, I’m gonna break the computation up in little pieces, and I’m gonna write pieces of the computation, little bits, into the memory, but I’m only gonna do that over blank space. I mean, this is something that sounds natural, right? So I’m gonna erase pieces of memory and then I’m going to overwrite that blank space with a piece of memory.

[53:43] So I’m being very destructive in a certain sense. But this is a natural thing you do, right? If you want to replace, swap something with something else, you often just erase. But there are ways to swap without erasing, right? So there’s a common little trick that is taught in CS courses. So if you require everything to be written into a blank register, then if you want to swap the contents of two variables like X and Y, then you’ve got to have a temporary register.

[54:23] You move one into the temp, you erase it, you move Y into there, and so on. Right. But if you don’t want a temp, you can achieve the same thing with just XORing the registers bitwise, or if you’ve got numbers, you can add and subtract. Okay. In three instructions, clever instructions, adding, subtracting, or XORing, you can actually swap the contents of two registers without needing a third. Okay.

[54:54] This is kind of the starting point for thinking about, well, why does it matter if you’re always writing into erased memory? So what James Cook and Ian Mertz showed at a very high level was they were studying a certain problem called Tree Evaluation Problem, whatever that is. And the problem had an algorithm where you had a little stack and you were always sort of popping and pushing on the stack, but you were always writing computation contents into erased memory.

[55:42] Okay. What they realized was that if you allow computations to XOR bits of memory into existing memory, then you can save a lot of space. So if you’re really, really careful about how you XOR things, you can basically recover what’s in your memory without storing all of it at once. You sort of offload things to computation, and you XOR on top of things very, very cleverly. You can get nice cancellations of things you don’t want and keep around things you do want.

[56:18] Yeah. So that is a high-level idea of how this stuff works.

Ryan Peterman:

[56:24] And then going to square root, is it just an extension of that, or is it completely different?

Ryan Williams:

[56:29] So the way it works with square root is square root just happens to be kind of like the optimal tradeoff in this Tree Evaluation Problem business. So what you do is you break the computation into square root of t time intervals. And each time interval has about square root of t steps in it. And what you do is you give a particular way of simulating this thing so that you’re only kind of holding about a constant number of blocks of these time intervals in memory at any point in time.

[57:09] Like you’re only holding a small number of these time intervals, records of time intervals, in memory at any point in time, which is entirely not obvious how you would do it, but it’s some sort of sweet spot to set the square root of T. It’s like the minimum setting of tradeoff. Say I want to break the computation into intervals, and the intervals have a certain number of steps. If I set it to be square root of T, then the number of intervals and the number of steps in each interval is about the same.

Ryan Peterman:

[57:44] So I mean, that was a long-held result. I mean, you mentioned it was 1975, that’s maybe almost 50 years. If you come up with something like that, and I guess you’re writing it out, you’re thinking through, and then you see it, what is that moment like?

Ryan Williams:

[58:00] So I’ve been around long enough to have been deceived by myself many, many times. So, yeah, I guess the first two or three times I thought about this, I just thought, this is another one of those ideas that can’t possibly work. There’s no way. There’s just no way this works. So I would just kind of leave it and then come back to it sometimes when I was bored of whatever else I was working on.

[58:35] It was a pretty slow process of convincing myself that this could possibly be true. I thought there was either a bug in what James and Ian was doing somewhere, or there was a bug in my interpretation of what’s happening. I thought there had to be a mistake for a long time. And the only way I got over that was just writing it down over and over and over in different ways, sort of writing and rewriting and writing and rewriting and adding more detail and then maybe finding a different way of explaining it and erasing and writing something shorter and just sort of re.

[59:23] Explaining it to myself over and over and over. And even then, when I submitted it to the STOC conference where it appeared, I wasn’t entirely confident that it was correct. I was just exhausted from thinking about it for so long and just thought, maybe someone else will find the mistake for me. I got at this point, I was just desperate.

[59:49] I had actually sent it to two colleagues that I trust privately and asked them, “Can you help me find the mistake? Or whatever? Can you help me understand this?” And one of them just said, basically, they just didn’t read past the abstract. They’re like, “I’m not. I’m sorry, I’m not going to.” I’m like, they just didn’t believe it, period. Just like me. I mean, they didn’t believe it.

[01:00:17] And another one said, after a long time, “Well, I didn’t quite follow it, but there was a footnote that you put, like, in the bottom of some page. After that, after that footnote, then I began to believe it.”

So then what I did was I just took that footnote and elaborated it in a later revision, sort of made it what I called the warmup, because I was like, yeah, I’ve got to do. I’ve got to write this thing in a way that is airtight so that other people will actually believe this.

[01:00:56] Because, yeah, it took me a long time to get used to it, to believe it. Yeah.

01:01:02 — Why he solves hard problems

Ryan Peterman:

[01:01:02] Wow. What motivates you to solve these hard problems? I mean, what keeps you driven? Because you kind of sound like you gotta just bash your head against the wall, and maybe you get there, maybe you don’t.

Ryan Williams:

[01:01:20] I try not to bash my head against the wall. And if I’m going to do it, it’s gonna be a comfortable wall. It’s gonna be one that’s high-end and luxurious or something. I’m gonna enjoy the process, is what I mean. If I don’t enjoy the process of really grinding and trying to understand something, I’m not going to do it. So I think, if anything, one thing that I like, I like to involve myself in working on problems where the grind is actually joyous and fun.

[01:02:07] Yeah. For the other things, they’re just mainly opportunistic. They’re mainly me just taking something new that I see and fully integrating it with everything I know and following everything to the logical conclusion and just seeing what happens. And not trying to get emotional, trying not to whatever, just trying to follow everything one step after another. Yeah.

01:02:35 — How to pick good research direction

Ryan Peterman:

[01:02:35] How do you pick a good research direction?

Ryan Williams:

[01:02:37] The best kind of research direction, which is very hard to come across, is a direction where you’ve set yourself up in a way that you can’t lose. I have a hypothesis H, and one of two things is going to happen. Either I prove H is true, or I refute H, prove not H. What I would like to have is a situation where if H is true, then good things happen. If not H is true, good things still happen.

[01:03:16] Other good things. I like to look at things where H. Yeah, it’s a win-win kind of. If you can find opportunities like this, this is important. I think often I’m not looking at a specific problem, I’m looking at a method. I’m looking at the technique. I’m looking at not the specific proof, but the space of ideas. And I’m trying to understand what else can be done in this space of ideas.

[01:03:54] So often I solve problems just by taking some idea and putting it somewhere else.

Ryan Peterman:

[01:03:59] Do you have a concrete example of where you’ve pursued something knowing that if you succeed, good. If you succeed in the other direction, also good.

Ryan Williams:

[01:04:09] I have some particular research program for which, if it materializes, would actually show that something called the orthogonal vectors problem can be solved in nearly linear time. Okay. Now, if that’s true, then the SAT problem can be solved in about the same time as Subset Sum. It could be solved in like square root of 2 to the N. So this would truly break SETH in a radical way.

[01:04:43] Okay. And I did a lot of work in the past showing how if you can improve on the running time of SAT, then you can somehow use that to prove circuit complexity lower bounds. You can take an algorithm for analyzing circuits that’s nontrivial and interesting and turn that into a limitation on what those circuits can compute. Okay, so this hypothesis, maybe I won’t exactly say what it is, it’s a pretty technical statement, but the point is that if the hypothesis is true, then I get this fantastic algorithm for this orthogonal vectors problem.

[01:05:34] I get this algorithm for SAT, I get circuit complexity lower bounds. From that I get to somehow prove limitations on what circuits can do if the hypothesis is false. I can use that hypothesis to actually show another circuit complexity lower bound of a different flavor. So regardless of whether or not the hypothesis is true or false, I’m going to make progress in complexity theory. I’m going to prove a new limitation one way or the other.

[01:06:04] Right. So sometimes, I mean, this can be difficult to do, but usually what has happened instead of something so clean is that I have, I read about some idea or whatever, I try to apply the idea, I read about some magical algorithm, I try to apply the magical algorithm to solve something like SAT. It doesn’t work, but I look at my approach, I stare really hard at it, I try to pivot, I try to just extract what I can, and then I get some other type of algorithm.

[01:06:41] I mean, this is essentially how I proved the circuit complexity lower bounds that first got me a job at Stanford was I was trying to solve SAT faster with some algorithm. It didn’t work, but then I realized that that algorithm worked for a large class of circuits, including ones we didn’t know lower bounds for. So then I used that to prove a lower bound. Yeah. So I mean, this is just a general principle that I’ve had.

01:07:14 — Technical book recommendations

Ryan Peterman:

[01:07:14] What would be your book recommendation if someone wants to learn more about complexity theory?

Ryan Williams:

[01:07:19] Yeah, so it sort of depends on how deep you want to go. There’s Avi’s book. Yeah, Avi’s book is really nice. If you’re looking for something a little more gentle of an introduction, I would say you could read the early chapters of Lance Fortnow’s The Golden Ticket, trying to imagine what a world would be like if P equaled NP. I like that imagination exercise that Lance did. On a more technical level, if you’re looking for something slightly more technical, you could look at The Nature of Computation by Mertens and Moore, I think.

[01:08:05] So this is still not very technical, but it is a textbook, right? Yeah. And then, of course, Sipser’s Introduction to the Theory of Computation is a fairly concise and very well-written textbook. Yeah.

01:08:31 — Advice for his younger self

Ryan Peterman:

[01:08:31] Last question for you is, if you could go back to the beginning of your career, knowing what you know now, what advice would you give yourself?

Ryan Williams:

[01:08:38] So I guess one thing that I did by accident, which I think people should keep in mind, is that you don’t need permission to work on very tough problems. In fact, the tougher the problem, like in complexity theory, there are all these problems where nobody has a very good clue of what to do beyond a few simple structural results. So that kind of levels the playing field a bit.

[01:09:15] And yeah, you just, you don’t need permission to think about these problems. You don’t need anybody’s say-so or whatever. I mean, that’s one thing that I would like younger people to keep in mind, that this knowledge is open to the world and it’s open to you. And you can just go learn it and think about it. And yeah, you don’t need anybody’s permission, especially not mine.

[01:09:43] Yeah. Another thing I think is to avoid inertia in the sense that if you don’t think about and reflect, where am I going and what am I doing? You can just end up coasting in a certain direction. And I think it’s important for people to sit down and truly reflect and think from time to time. Okay, if I keep going in this direction, is this going to lead to a place that I want to be?

[01:10:27] And this sort of advice is good for all aspects of life, really. If I keep just allowing things to be the way they are, am I going to be okay with that, or do I need to do something? Do I need to? So it’s like little interrupts in your life and reflection, just sort of like, okay, do I need to be coasting here? I think in research for me, I was always reevaluating, like, okay, what did I do last year and what did I do the year before, and could, you know, like, what do I know now that I didn’t know then?

[01:11:11] And, am I progressing? I think that sort of self-evaluation is crucial when you’re in grad school because once you’re in a PhD program, there are no more easy metrics to gauge how good or bad you are doing. And the truth is, there just isn’t such a metric. So all you can really do is evaluate your past self with your present self and compare and contrast to see if you’re making progress with whatever it is you want to do.

Ryan Peterman:

[01:11:49] Thank you so much for your time, Professor Williams. I really appreciate it.