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

Ryan Williams:

[01:11:52] Yeah, I appreciate you having me here. It’s been fun. Thanks.

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

Timestamps

00:40 - Origin story

06:04 - The front page of Hacker News

14:35 - Why he chose Rust

20:10 - Full codebase migration from Zig to Rust

28:40 - LLM generated code and open source

35:34 - Performance optimizations

44:54 - Optimization with AI and combating slop

01:02:08 - Learnings as an eng starting a company

01:17:55 - Top technical talk recommendation

01:18:56 - Advice for his younger self

Transcript

00:40 — Origin story

Ryan:

[00:40] What was the space like when you were first getting into building these dev tools? Why did you think it could be better?

Charlie:

[00:51] Before I started Astral, I was at a computational biology company, and I was the second engineer. I had no bio background and no ML background, and so I was building all the software systems to do machine learning, and that was all Python. So I was learning Python. Then we had some Go and some Rust, and so I just worked across lots of different ecosystems. And I think Python, at the time when I was in that position, we were trying to do a lot as a small team.

[01:22] So we had a very, I mean, not compared to large code bases, but we had a comparatively large code base. And it was really a small group of us that were software engineers trying to serve the rest of the team, whether they were machine learning researchers or scientists. So I had kind of worked across a bunch of different ecosystems, seen a lot of the tooling, and now I was working on Python, and we kept trying to get lots of leverage out of the tools, whether it was the type checker or the linter or the package manager. Things were scaling up.

[01:50] We were a small team. We wanted to have really good static analysis, really good tooling, and we kept running into limitations around it. I mean, I think there were some. I kind of looked at the Python ecosystem, and I just didn’t see the same amount of experimentation that I saw in other ecosystems, like in the web ecosystem. There were a lot of things going on that seemed pretty crazy, and there was a very intense focus on.

[02:19] I don’t know about very intense, but there was more of a focus on performance. And that started with esbuild, which was in Go, and then you had SWC and Rust and then Bun and Deno and all these other tools that came around. And this idea that you could have native tooling for JavaScript became very accepted, especially as applications became bigger and people were doing more and more stuff on their machine.

[02:47] And that wasn’t really happening in Python. And so that, to me, was kind of like the key question, was like, why can’t we have that? Because I was seeing all this stuff that was happening in web, and I had done some Rust, I’d done some Go. I’d seen these different tool chains and how they work, what the experience is, the user experience mostly in those cases. And then I saw Python, and it was like we had a smaller set of tools.

[03:13] There were lots of interesting ideas from other ecosystems that I didn’t see represented. They were really all written in Python. And so that to me was kind of like the interesting question. And it was sort of like the first thing I asked when I started working on this, when I released Ruff. The title of the blog post was something like, “Python tooling could be much, much faster.” And for me it was really like, this is a hypothesis.

[03:42] Could Python tooling be much faster? And then I built a prototype, and that prototype was like, yes, I think it could be.

Ryan:

[03:49] You wrote a post kind of exploring mypy or publishing your results using mypy. And the date on that, nine days later, you published the post. That one that you mentioned, it could be so much faster.

Charlie:

[04:03] No, that’s funny, I didn’t even realize that. Yeah, those were so close together.

Ryan:

[04:06] Did you build that proof of concept in those nine days?

Charlie:

[04:10] Yeah, I wrote that blog post about basically type checking at scale because I was trying to think of what are things that I learned that people haven’t written much about. And then I started with building a linter because I thought it would be much easier. I think it actually is a lot easier than building a type checker. We’re now building a type checker and we have a type checker. And so I can say that I think building a type checker is much harder.

[04:35] But I started with a linter because I thought it would let me prove a lot of the same ideas, but in a smaller form factor, like building a startup or just building a tool. You want to try to get something into people’s hands that they can actually use and that actually proves out value as quickly as possible. And also that lets you iterate very quickly. And a linter weirdly ended up being kind of the perfect form factor for it because it has a pretty simple core.

[05:07] But then you have tons and tons of rules. And so it’s extensible in a lot of different ways. But people can get value very quickly from a small core plus some number of rules. And so we were able to get something out there and then iterate and ship more rules and more functionality, and people could use it alongside other tools. It was useful immediately, which I think is extremely helpful. As opposed to something like.

[05:34] I mean, actually, the type checker would be a good example. A type checker that’s like 75% done isn’t very useful. Same with the package manager. These things have to be. I mean, there are ways, I think I would challenge those as blanket statements. But the point is it’s harder to ship something iteratively that’s still useful to users. And I think that’s one of the key properties and actually building momentum as a tool or something else.

06:04 — The front page of Hacker News

Ryan:

[06:04] When you posted that writing, what was the reception?

Charlie:

[06:07] I mean, the blog post itself, I published it and then it was on Hacker News and it got tweeted about a lot, and it just created some amount of excitement and interest around it. And those things, I mean, especially being on the front page of Hacker News, I have a lot of thoughts about. I mean, it’s certainly not. It’s like some percent luck and then some percent skill, and it is like a helpful thing but not a requisite to success.

[06:42] And it also doesn’t guarantee success just because you got something on the front page of Hacker News. It’s great if you can, but there’s a lot of randomness to it. I do think, though, that maybe a couple things. So one, after that happened, some people started actually paying attention to the project. And so I really tried to capitalize on that, basically by being very engaged. And so when people would file issues, I would aggressively try to acknowledge the issue as quickly as possible, fix it, and ship a release.

[07:19] If you can do that within one day, it’s a very, very powerful loop. You gain supporters and create more momentum around the project. And there were also a couple high-profile people in the ecosystem that started paying attention to the project, like Sebastián Ramírez, who does FastAPI and a bunch of other things. And he’s been a great supporter of our projects too.

[07:41] But early on he was like, “Oh, this is interesting. I’d like to use it.” And I was like, I basically asked myself, well, what would it take for him to use it? And then I just tried to do all those things. So I tried to capitalize on that.

I think the other is, though, I do think a lot about developer marketing, and it’s sort of like a dirty word or like a dirty expression. I think a lot of engineers want technical products and tools to just win on their merits.

[08:13] The best technical solution should just be the one that wins and grows. But I actually, I mean, I have this sort of stupid hypothesis that there’s all these, like, thousands of really amazing projects on GitHub that basically don’t know how to market themselves and so never get discovered and never go anywhere. And I don’t actually know if that’s true, but it’s sort of how I feel about a lot of technical work, where it’s like, it’s actually worth looking at a project like Ruff.

[08:44] And when I think about what to put in the blog post, or this extends to what to put in the README or what to put in the. You don’t need a million emojis and a million screenshots of everything. What you need is, okay, someone’s going to land on this page and I have 10 seconds to get them interested in what I’m doing and help them understand why it might matter to them and why it’s useful. And so that’s the key idea that I try to bring basically to everything.

[09:17] I mean, it’s a little bit depressing because it’s like, okay, I only have 10, but people really don’t have. This is the attention economy, right? It’s the same thing with a blog post. Ironically, I used to look at a lot of the OpenAI blog posts when I was at Spring and we were doing machine learning in bio and we were trying to publish material to explain what we do. But we had all these interesting insights.

[09:44] We looked at the OpenAI blog posts, especially the DALL·E ones, the older ones, and we were like, wow, that’s an amazing blog post. Because if you read none of the text, you still understand what they did and you’re still impressed by it. If someone just goes on the page, they leave with an impression and they have some understanding. And I was like, wow, that’s a really amazing thing. And so when I write blog posts now, I.

[10:07] I’m like, if someone just lands on this page, I have to be prepared for the large number of people who will only read maybe the TL;DR, maybe look at the first image, maybe read the headline. Some people will read the full thing. And so I should care painstakingly about every word and everything it says, but most people will read almost none of it. And so, again, sorry, it’s a little bit depressing, but I do think it’s worth thinking about your audience and how do you.

[10:33] How do you explain to them why they should care about what you’re doing in a way that’s honest and genuine, not deceptive? But you do have to think hard about how do you communicate why something matters to people.

Ryan:

[10:46] Very quickly, could you give an example of what you did in your case?

Charlie:

[10:51] I think for Ruff specifically, we had a really good graph of the benchmarks that we put in the blog post, and that went viral. It was on Twitter and that was a priceless graph, basically. Sorry, not in terms of monetary value. I just mean in terms of attention. Right. It was like, oh, that’s really obvious what’s happening there. I think graphs of benchmarks can be a really powerful thing.

[11:19] All benchmarks are bad and wrong in some way. And so there’s a lot more to say about that. But I do think having a visual hook that explains to people why they should care and what something is, and having a really strong tagline. I would have to look back at what we had, but we were like, okay, we’re going to be compatible with your existing stuff and much faster.

[11:44] And that’s kind of it. And it’s like, okay, well, if it’s compatible and it’s much faster, I was like, why should you care? It can be orders of magnitude faster and it’ll give you the same experience. You try to convey that as quickly as possible.

Ryan:

[11:58] Right. And even the, I mean, that blog post header, I mean, Python tooling could be much faster. Should be much faster.

Charlie:

[12:07] It’s a little bit provocative, I guess. Yeah. I mean, I’m pretty against clickbait or trying to be misleading in anything that we do. You basically want to balance creating, effectively communicating the most interesting pieces to people, but you have to do it in a way that you believe is true and authentic. You could lie about a bunch of stuff and post interesting things that are clearly provocative.

[12:38] But I don’t know, to me, that’s just. Why would I ever do that? That’s such a losing battle.

Ryan:

[12:44] What do you think about that graph? I don’t know if the... I see this a lot, though, where the axis is not zeroed.

[12:53] So it’s all within the range of 50 to 60 chart crimes.

Charlie:

[12:58] Yeah, I wouldn’t do that. Yeah, yeah. I do think benchmarks are pretty complicated and controversial, though, and maybe most people don’t even see this controversy. But I do, because it’s just very hard. Performance is very nuanced, and you have to think about, okay, with caching or without caching. Those are pretty different. Or depending on the project that you’re running on, the performance characteristics will be totally different.

[13:36] And we see this in uv. This is really hard because sometimes uv is really fast, but sometimes your package install is actually bottlenecked on a C build that’s totally out of band, and it’s like, okay, well, so how do you accurately capture all of the different scenarios? I mean, it’s sort of impossible to accurately capture all of the different scenarios, but it’s also a disservice to users not to try to communicate to them the importance or a real representation of what the difference in performance will look like and why does it matter?

[14:14] And so you have to balance those things, which I think is actually quite hard. And a lot of people tend to get it wrong. And maybe we’ve gotten it wrong a few times too. I’m happy to accept that. But I do think it’s more complicated than people think. But it’s also, I think, a huge disservice not to include some way to try to convey to people quickly what things feel like.

14:35 — Why he chose Rust

Ryan:

[14:35] I think one of the things I’m most interested in is, you mentioned that graph. I see that graph and the engineer in me is like, how did you make it so much faster? And one of the things in the tagline is Python dev tooling written in Rust. And so I guess one of the first things I’m curious about is why did you choose Rust and what are the pros and cons of that?

Charlie:

[14:57] I would say I largely chose Rust for that project because of hype. I don’t think at the time I was that informed about a lot of the technical trade-offs between those different ecosystems. And I hadn’t really done a lot of systems programming. So the honest answer is I was seeing it in a lot of places, and it was growing a lot, and people said it appeared to be sort of an accessible way to write.

[15:24] My impression was that it was an accessible way to write high-performance software. And so I started for that reason. In hindsight, I think it was an amazing decision, and I absolutely would not do it differently. And I think it was the best choice for what we’re building now. I have a lot more experience writing Rust, but it is funny because I do sort of think that if I had tried to write this in C or C++, I think I probably would have given up, because even now I find those ecosystems much more intimidating.

[16:08] Hard to access, hard to learn. I have often felt that one of the great or underrated advantages of Rust is basically the tooling, because you drop in and you use Cargo, and that’s how you do everything. And if you clone it. This isn’t always true, but there are exceptions as projects get sufficiently advanced. But it’s. If there’s a crate out there that we use and maybe I want to submit a PR to it, I’m extremely confident that I can clone it and figure out how to run and build it without having to do any work.

[16:44] Being able to just clone and run cargo, run or cargo build or cargo test, that’s actually really amazing, especially for someone like me who was new to systems programming and I didn’t want to have to figure out my whole C tool chain and build system, all this stuff. Rust was opinionated about all of these things. And so there were a lot of things that were hard to learn, but I was allowed to basically, I was allowed to spend my time focusing on the things that actually should be hard to learn, as opposed to all the other, basically all the bullshit that you don’t want to spend time on, like how do I get this thing to actually build and run?

[17:24] I think it has been an extremely good bet for us. It’s scaled very well with the project. And I mean, we at OpenAI too are like, we use a lot of Rust and they’re betting heavily on Rust. And then, you know, me as someone who builds software, builds developer tools, like tries to build software for people to build software, I’m very bullish on Rust. It’s grown enormously and I think it will actually just keep growing enormously at the same time.

[17:57] I said this at the start. I’ve never been someone who’s super dogmatic about ecosystems. I think that all of those ecosystems have lots of redeeming qualities. I think what’s happening in Zig is very interesting, and I wish I had more time to go deep on it and develop more nuanced opinions about what it does better. I’m sure it does a bunch of things better than Rust, and I’m sure there are things for Rust to learn from that ecosystem.

[18:20] Similarly, people have a ton of success building stuff in Go. I think that’s great too. I think all this stuff is great. But I have loved using Rust and I have complaints about it. But I view those complaints as things that we should improve, especially as the way we build software changes.

Ryan:

[18:38] With LLMs, it sounds like you’re saying C and C++ today. You would not consider them because their tooling is insufficient. But Zig, Rust, and Go are all some spectrum of trade-offs or different things.

Charlie:

[18:56] Yeah, I mean, I think a lot of people would disagree with me, but I don’t really understand why unless there are very specific technical reasons or you’re working with existing software. Basically, I don’t really know why I would start a net new project in C or C++. I certainly would not at a personal level. I guess if they’re like the ecosystems you know really well, then it makes a lot of sense to do it.

[19:26] But if I was a new programmer looking to learn systems or if I knew those languages equally well, I guess I just don’t understand why I would do that, which I’m sure I’ll get roasted for, but I just don’t really care now. I actually care about a lot of things that Rust gives me that I didn’t care about as much before, like memory safety. I don’t think I even understood or cared about what memory safety was when I started working on Ruff, to be honest with you.

[19:49] And now I think it’s a pretty amazing thing. I want to build things that are safe, that don’t crash on users, that are really fast, really performant, that don’t have to make compromises, basically. And I feel like I can do that in Rust. And so for me, I don’t know, it’s kind of like the perfect language. I mean, it’s not the perfect language, but it is my favorite language to use right now in today’s world.

20:10 — Full codebase migration from Zig to Rust

Ryan:

[20:10] It’s not unreasonable that you could almost completely transpile or convert your existing codebase into any language of your choice. Like I saw, I think it was on Bun, I forgot. I think it was Zig to Rust. Yes, like all in one go. So if you studied some other language and you thought it was better, you could totally rewrite everything from Rust into, I don’t know, Zig or Go. Would you ever consider doing that for the dev tools that you’ve built, for instance?

Charlie:

[20:47] Yeah, it’s such an interesting time to be building software because things are changing. This is not a novel comment, but things are just changing so fast. I didn’t really program with agents at all until Christmas, like December break, basically of this year or of last year, rather. And that’s really not that long ago. I mean, I was using Cursor and stuff, but I wasn’t like now. I haven’t edited code in an editor in a very long time.

[21:16] Everything I do goes through Codex and even if it’s small edits, I’m just prompting and it’s completely different. And that’s not that long of a time, right? And so I don’t know what it’s going to look like in six months. Hard to say. But the reason that I mentioned that is, I think Bun doing that rewrite, it’s like I wouldn’t do that right now, but I’m actually glad that they are pushing that.

[21:50] They are experimenting and pushing the envelope of what’s possible. And they’re doing it in the face of a lot of criticism. And it will be interesting to see how it plays out for users because I think a few different things I thought about is, oh, reasons not to do that. One is, okay, maybe you don’t understand the code anymore, right? If the code got completely rewritten, then as a human you may not understand any of the code anymore.

[22:17] And that can be a big problem. I think there are mitigating factors around that, which are, they tried to do a very direct transpilation, quote unquote. I mean, it’s not exactly a transpilation, but they tried to do very one to one. And so that hopefully helps with understanding all the abstractions. If they’re building so heavily with agents, does it even matter? To what degree do they need to understand different parts of the code?

[22:41] I actually don’t know the answer to that, which is where everything’s changing so quickly comes from. It’s actually a little bit hard for me to say right now how much that actually matters anymore. If they did transpile the whole codebase, how well do they need to understand things at different levels of abstraction? They should. It’s actually a very, I think, complicated question. So one reason is how well will you understand the code?

[23:05] That’s a confusing thing. The other is you’re kind of trading, when you do a rewrite like that, you’re trading known issues for new unknown issues. Imagine you merge that and it closes 50 open issues on GitHub. In a literal sense, okay, that’s great, but you may have now caused 15 new issues that didn’t exist before, that you don’t know about, because even a great test suite is only an approximation of your program’s correctness.

[23:41] There’s Hyrum’s Law, which is like anything—I’ll get the phrasing wrong, but the gist is basically any implementation detail in your software. Someone eventually comes to rely on that. And so even things that aren’t encoded as behavior become part of your API, whether you like it or not, which is a scary thought. But basically that means that even if you pass your whole test suite, there’s probably lots of behavior that was implicitly encoded in your program that’s changed.

[24:11] The unfortunate thing is you end up pushing that onto users. They are the ones that have to run into that and then report it and figure out what went wrong. That’s my main area of concern. With an automated rewrite, I actually trust the models enough that I would consider allowing them to do it. But the scarier thing for me is basically what’s the impact for users and how do you roll that out safely?

[24:33] So I don’t know. It’s kind of a... We’re not going to, like, we don’t have anything planned to do that for any of our own projects. But it is an interesting question. I mean, I think maybe the third piece that I do think about, especially right now, where everything’s changing so quickly and there’s basically the spectrum of how you write software has gotten way wider. This is a terrible analogy, but there’s so many different ways to build software now.

[25:05] There’s the true Andrej Karpathy definition of vibe coding, where you’re like, don’t look at the code at all. All the way to don’t use LLMs and blah, blah, blah. There’s a lot of different stuff in between. And I actually think that right now I have pretty different approaches to different projects in terms of what I do. I built a tool last week that was. It’s basically personal software. It’s like a custom Rust linter to help us enforce certain things in our projects that I’ve always wanted to enforce but didn’t fit into existing tools.

[25:45] And I didn’t read any of the code. GPT-5 did the whole thing, and it’s like, okay, I can have a really different standard for that than uv because that project, we are the only users. It’s easy to tell if it’s correct or not. Not to go too deep into the weeds on what the project does, but we know if the output is incorrect and there’s no other users. uv is relied on by millions of engineers and every single company.

[26:21] And so it’s like we want to be really careful about what we ship there and how. But there’s a lot of room right now, I think, for exploring how we build software. You do have to be careful. What project are you working on, and what responsibility do you have to users? And that’s not meant to be a subtweet on what Bun did. It’s just how I think about how do we want to push the envelope in different places.

Ryan:

[26:45] Right. I mean, to me that just reminds me of the pre-LLM tradeoff navigating, I guess, the risk of the code change and how much you verify it. Because if it’s not risky, it’s an internal dev tool that only you and I are using. Maybe I just ship it with, I just say stamp it, don’t worry about it. It’s not going to break anything. But if it’s the critical thing that’s blocking customers from checking out or something, maybe we have two people reviewing it, and there’s a lot of checks in that part of the codebase.

[27:22] So it feels like the similar spectrum is just now there’s a new level of trying less, which is not just a human doesn’t even interact with it. You just ship it and maybe you just stamp it, and no one ever even looked at it.

[27:40] Whereas before, at least to have written it, a human would have had to.

Charlie:

[27:45] Yes, do it. Yeah, yeah, yeah, yeah. I mean, I think. Well, okay, a lot of reactions to that. So, one, I guess, the other thing I would just say quickly about Bun is, sometimes I go over to their repo and it’s just so different than our repo. And it’s very interesting to look at because if you look at basically the number one contributor, it’s the RoboBun bot, and sometimes you’ll click on PRs by humans and there’s, like, human accounts talking back and forth.

[28:14] But it’s clear that all the comments were written by agents. And you’re like, wow, this is very interesting. And so I look at that, but my perspective on that is basically like, okay, I’m glad that people are like that. They are experimenting with different ways to build software. I don’t know that I’m ready to do that. But I do think that basically a lot of things are going to change.

[28:34] And I think it’s very interesting to be experimenting. So I’m glad that they are experimenting with things. Sorry, is my conclusion there.

28:40 — LLM generated code and open source

Ryan:

[28:40] Do you block if people are just submitting full agent stuff on your repos?

Charlie:

[28:47] We do, yeah. So we have an AI policy now, which isn’t intended to be anti-AI, but it’s really intended to. Because, I mean, we develop very heavily with LLMs. That is true, but it’s more intended to be like, how do we retain useful contributions while filtering out net negative interactions from the repo? Because a contributor coming in and posting a comment that their agent wrote, and then we ask them a question and then they just paste the agent response back.

[29:31] There’s very little value in that. We could just ask the question to the agent. And so we want to retain the things that are useful from human contributors, which is insight, ways to reproduce the information we would need to plug it into our agent. Because there’s no point in just having a conversation with an LLM on a GitHub issue. It doesn’t really do anything for us. Our policy is roughly, you need to understand what you’re pasting in or what you are submitting, which sounds like a low bar, but it’s not.

Ryan:

[30:13] How do you police that?

Charlie:

[30:15] If we can’t tell and it is agent-written, then I guess that’s fine, right? But at least right now there are just lots of tells: being way more thorough than a human would ever be, including way too much detail, way more formatting, using terminology that a human wouldn’t use, inventing random jargon, tons of links. I guess the broad sign would be putting in way more effort in ways that aren’t necessary, in a way that a human wouldn’t. It’s almost always agent-authored.

[30:51] But it’s been, yeah, it’s been challenging. I mean, I think the hard thing, Zig has a much more strict LLM policy, which is like no LLM-written code or no LLM-assisted code at all in the project, which is very different than us. I mean, all of my PRs now are LLM-written, right? LLM-written. And they had a blog post about this idea of, like, they called it something along the lines of contributor poker, where it’s like you’re kind of trying to place bets on contributors.

[31:19] Historically, in open source, when a contributor came around, they might be new to the project, but they could show signs of promise or they’re really engaged or really interested, and you give them feedback, they take the feedback and they fix up their PR, and then the next time they put up a PR, they’ve learned from that feedback. It’s the same way as mentoring a new engineer who joins your team. It’s like they learn from feedback, it compounds, they get better, and then they can actually mentor someone else in the future.

[31:46] You’re making investments in people. In a way, it’s the same for open source. It’s like you want to—I thought about this law historically. It’s like you want to invest in good contributors who are going to grow to help others and be maintainers in their own right. That’s kind of gone for PRs, especially those that are written by agents, because people don’t really learn anything. Someone can put up a PR that’s written by an agent, and you leave comments, and then they take your comments and put them into the agent, and then update the PR, and then merge it, and it’s like there’s no compounding feedback.

[32:19] And so I actually do understand that perspective. A lot of the contract between maintainers and contributors is pretty different now. And relatedly, again, not a novel insight, but the cost of putting up a plausible PR has gone to zero, while the cost to review and vet a plausible PR has remained the same and is very high. Especially for the projects that we work on, where I’m not trying to overstate it, they’re just hard projects.

[32:55] Ty is our type checker, probably hardest project I’ve worked on technically to get a change merged because of the complexity in the architecture, but also the problem space. It’s just very, very hard. If someone puts up a plausible PR to Ty, it might take them two minutes, and then it could take us an hour to understand it. And so it’s created very poor dynamics in open source. And I don’t know how we’ve solved that.

[33:25] I think it will continue to get worse until hopefully it gets better in some way. We find ways to solve this, but it’s certainly something we’ve experienced in our projects.

Ryan:

[33:36] Right. It sounds like review is becoming more and more of a bottleneck for that Bun rewrite. Do you know if it was human? Like, humans read that code, or that was just kind of...

Charlie:

[33:46] No, I don’t think it was human reviewed.

Ryan:

[33:48] So it’s just yolo rewrite the whole thing.

Charlie:

[33:51] Yeah, I mean, in a way I think they did have. And I’m excited for, at least at time of recording, quote unquote. Jared hasn’t published the blog post yet, which is like. I mean, he keeps making jokes about how the blog post is taking way longer than the rewrite. But I’m actually really interested in the blog post because I think they did have a pretty sophisticated approach to how the rewrite worked, which will be interesting to read about.

[34:17] It wasn’t just they had one prompt that was, “Rewrite this in Rust.” They tried to have, at least my impression from looking at the PR, was there were actually different phases of the rewrite, and each file had to go through a couple different phases that had ways to validate whether it was correct or not. The answer is no, though. I don’t think a human was reading significant amounts of that code.

[34:42] It’s just not possible.

Ryan:

[34:43] Basically, what if we both agreed today that Zig was objectively better than Rust, and then someone on your team said, I can do this rewrite into Zig. Would you block it?

Charlie:

[34:58] I think I would block it. I don’t know whether I’d be right to do so, but I think we as a team aren’t there yet. And maybe we will get there, and that’s how we will feel eventually. But right now, I think we just feel like there’s still a lot of value in deeply understanding our code and our tool chain and the ecosystem. And so I would say we don’t want to do that, but it might depend on the project.

[35:03] I don’t know.

35:34 — Performance optimizations

Ryan:

[35:34] All the things that you built, they’re like an order of magnitude faster than what was available at the time. How much of a difference did Rust make on that graph?

Charlie:

[35:45] I think it depends a bit on the project. I think in a rough lot of it was just Rust. And then over time, I think we’ve improved on that a lot because you can even look at the history of the project. Hopefully no one, hopefully this is still true, but basically over time the project gets faster and sometimes that regresses. But maybe I’ll put it differently. You could write Ruff in a couple different ways, all in Rust, and they could have really different performance characteristics.

[36:30] So that’s just to say that I generally think of Rust as the floor, or the baseline performance that you get is going to be significantly better. But you still get a lot more out of thinking deeply about performance and design. If you take the same program in Rust and in Python, the exact same implementation, to the closest approximation you can get, the Rust one will be faster, but you can then take that program and you can probably optimize it.

[36:58] Another 10x. I don’t know about 10x, but my point is, even within being written in Rust, there’s a ton of room for how to make things more performant, how to write really performant software. And again, when I started working on Ruff, part of my goal was to learn Rust. And so I did write a lot of bad code, which is fine. I shipped something out that was really helpful to people, but it’s gotten a lot better, I think, over time, and we’ve made it more and more performant.

[37:26] I think in uv, there was more sort of architectural innovation beyond just being in Rust, especially because uv. So as a package manager, you’re doing a ton of I/O and downloading files over the network, unzipping things, writing them to disk, moving them around. The linter doesn’t have to do as much of that. I mean, it has to read all your files, but there’s not a huge amount of I/O. The package manager is mostly I/O, and then you’re trying to do things very efficiently.

[38:01] So there, it was more. I mean, Rust was important. But I do think that in uv, there are more architectural things that we did, or ways that we thought a lot about performance. The design of the cache is very, very intentional and makes it so that repeated installs of the same package on your machine are near instant because of the way that we lay out the cache and the way that we install from the cache into your projects.

[38:34] It basically means that if you’ve installed a package before, installing it again is extremely cheap, both in terms of disk space and time. And so that’s a very different design than any of the other Python package managers had. So, again, it kind of depends on the project. I do tend to think that whether you’re writing code in Rust or in Python, there’s always room to be thinking about performance.

[38:59] You can always make things faster or slower. Even if you’re writing in Python, you can still make things much, much faster by thinking harder about performance and design. So it’s some mix, but it depends on the project.

Ryan:

[40:01] Over the course of the project, do you have a top few things that were implementing the project that were technically challenging or most interesting to you?

Charlie:

[40:11] I really like this optimization that Andrew on our team, who goes by BurntSushi, he’s the author of ripgrep and a bunch of other things. He’s a really amazing engineer. He did this really cool optimization around how we represent versions. It’s pretty cool. I mean, basically, if you think about resolving and installing a very complex Python project, it turns out that we have to parse and create lots of versions, as in 1.

[40:11] 0.11.0.2 version objects within the program. We end up parsing and creating a lot of those. And it turns out that actually allocating that memory was expensive given the scale, the number of times we were doing it. He came up with a representation where we can represent 90-something percent of versions with a single u64 integer. So it’s just way more efficient. And the benchmarks around that and the implementation were very cool.

[41:12] It’s like one of the coolest PRs I’ve read. I think in Ty, which is our type checker, there’s a lot of very interesting performance work that’s happening, especially to make it incremental. So Ty is designed to be a type checker and a language server. The whole system is highly incremental. The idea there is if you’re in a text editor and you open up one file, you don’t necessarily want to have to type check your entire project, all your dependencies, every file in the project, just to get analysis for that file, because you don’t need to.

[41:55] So how do you make that work? That’s sort of like, that would be lazy. You want to be lazy. But the other piece to that is if you have a file open and you edit it, or you have two files open, you edit one of them, you only want to recompute exactly what you need to recompute. You don’t want to have to go and retype check the entire code base again, especially because maybe you’re working on a big project like PyTorch, and it’s like you have two files open, you edit one of them, you don’t want it to like, and then you save.

[42:22] You don’t want it to take two seconds to retype check the project and give you new analysis. So the whole system is built around queries, which is pretty interesting. This is more of a macro design thing, but we built it on top of a framework called Salsa, which is also what rust-analyzer uses, which is the popular Rust language server. And now we’ve intentionally or inadvertently become very large contributors.

[42:53] But the whole system is built around that, which has been very interesting, architecturally interesting.

Ryan:

[42:58] So it’s lazy. So it doesn’t type check the whole codebase. And it’s incremental.

Charlie:

[43:02] Yeah, the incremental part is the thing that’s hard because you kind of need a way to basically model a dependency graph of everything that’s happening in the code. And so then when you change something, we want to just flow the data back through all the different pieces, only the pieces. Yeah, so that took a lot of work, but it has come together, and I’ve been doing a lot of optimization lately with Codex because it tends to be very good, especially at micro-optimizations.

[43:41] And in Ty in particular, we also need to think a lot about memory, not just speed, because if you work on a very large project, you don’t want it to take many, many, many gigabytes just to run your language server. Ideally you want it to be relatively efficient. So I spend a lot of time now kind of continuously optimizing memory usage and performance, and I can just set a goal that’s like, try to reduce Salsa memory by like 1% on this project.

[44:11] And you can’t do these things that you might try to do. And it’s very good at just coming up with very reasonable things. And so I don’t know, I find that very cool because it’s kind of like you can almost have continuously. I won’t say self-optimizing, that’s a bit grandiose. But you can kind of be continuously just optimizing your software.

[44:35] So I’ve been enjoying that a lot. But most of those are trying to find ways to represent things that take up less memory, or trying to come up with, sometimes it’s trying to come up with broader redesigns to fix pathological performance.

44:54 — Optimization with AI and combating slop

Ryan:

[44:54] That one optimization with the version numbering and seeing that you can limit it just to a u64. If you think back to some of these more creative optimizations that were done, that was in the human era. Do you think if you just ran Codex and you’re like, hey, just don’t break things but lower, do you have faith that it would come up with that? Or is that kind of a step above what?

Charlie:

[45:20] That’s a very interesting question. If you just, at least in my experience, if you use these things to reduce memory or improve performance by some moderate percentage, it will typically come up with things around the edges as opposed to larger redesigns or reconsiderations. But you can get to those larger redesigns if you prompt and collaborate with the agent. If you ask, well, should we be thinking a bit bigger about why we have to represent the data?

[45:51] This way, you can get to bigger ideas. That might be an idea that you could have gotten to with prompting if you were like, okay, let’s start by profiling and figuring out where we’re spending a lot of time. And then maybe it would eventually come back to you and say, we’re spending a lot of time in version parsing and version drop and version allocation, blah, blah. And we’d be like, okay, well, how could we represent these more compactly?

[46:17] And we’d probably start by finding micro-optimizations in the representation of, well, this field. You combine these two fields, save a few bytes, blah, blah, blah. But I think if you kept pushing it, it’s possible it would get there. But that’s not the thing it’s going to come up with by default. Mitchell Hashimoto, who was one of the HashiCorp founders, works on Ghostty. He had a post that was insightful.

[46:42] I thought last week or this weekend about a renderer he wrote where it was a really terrible renderer. I’ll probably butcher the tweet, but it was a really terrible renderer. And then he hadn’t intentionally. And then he had an LLM optimize it and it made it 10 times faster. And he’s like, great. Actually, no, my handwritten version was 100 times faster. And it’s like, if you’re not using your brain to think about from first principles, how fast should it be and how should the system work?

[47:10] Then you just ship all these accumulated. I won’t necessarily call it slop, but it’s like you just ship these things, and you’re like, yeah, oh my God, I made it 10 times faster. But really it should be 100 times faster. And so I think it shouldn’t be controversial. There’s still a lot of room for using your brain. But I do think it’s like, I struggle with this stuff a lot. I mean, I’m changing how I write software a lot.

[47:36] And I’ve had people on my team because I’m using agents a lot and also was, to some degree, trying to push our team to use agents more. I mean, some of that for me came from a place of we build tools for software engineers, and a lot of our users are now using agents. And so if everything good that we do— that’s an exaggeration, but if everything good that we do comes from understanding our users very well and how they work, then we should probably be using agents so that we understand what it’s like to build software with them, so that we can build better tools for our users.

[48:14] That was part of my motivation, and part of it was just kind of seeing how it can change how you work. And I don’t know. I think I’m shipping a lot more. But it has been a difficult process. I’ve had people on the team tell me, which I think is great that they tell me this, but they’re like, “Oh, it used to be the case that whenever you put up a PR, I could review it pretty minimally because I had a lot of confidence in it, in your work.”

[48:43] And now it’s like, when you put up a PR, I actually have to review it really closely because you’re not writing anymore. It’s like the agent. And I was like, wow, that’s very interesting. They’re completely right, which is. And the same thing happens to me. It’s like, if I go to sleep and then wake up in the morning and look at one of the PRs I put up, I’m like, wait, this is terrible.

[49:02] You know what I mean? It’s like, you can. It’s just. It is easy to trick yourself into basically believing work that isn’t at the same standard as what you would do before. And I don’t think. I think we have. We don’t really know what to do with that. And I’m kind of learning, getting better. And I mean, this was. I think I’m doing a lot better job now than I was in probably, February or something, where I was like.

[49:28] I was just fully agent killed. And I’m like, now I’m a little bit more like. But so my point is, that was a powerful moment for me when someone on the team said that, and I was like, wow. You’re right. And I see that in other people’s work too. It’s not just limited to me, but it really does throw a lot of things on their head.

Ryan:

[49:50] If you generate pure slop, that’s easy, but I think there’s this gray area where you generate partially AI slop, or it’s acceptable, but it’s not at the bar that you used to have. What are the tactics that you’ve used on the team that have worked for combating this kind of gray area? AI slop.

Charlie:

[50:12] I’d like to get to a world where we’re not here, and I don’t know if we’ll ever get there. I’d like to get to a world where if you put up a PR and it’s all green, then the odds of it getting merged are extremely high. Right. Because that would mean that you have automated verification for most of what matters. And we have a lot of that in our projects, and we’ve tried to add more over time, and I think it’s helpful in Ty especially.

[50:42] We have tons of benchmarks that run under Valgrind through CodSpeed on every PR, and that includes memory. So we benchmark memory usage and simulation time and wall time on every PR. And then we also have a really big suite of ecosystem tests. So basically every time you put up a PR, we run before and after on a bunch of projects in the ecosystem, and then we create this report of the diff of all the diagnostics, like the errors that got removed and added and everything.

[51:19] So we have, over time, we’ve tried to do more and more. These are important. Honestly, even before we had agents, we basically couldn’t build without these things. But the point is, I want to have more automated verification and try to get better at that. And that includes things too. Like, we basically assume now that anyone on the team that puts up a PR has already run that through Codex Review, probably several times.

[51:49] And that’s basically an assumption. I mean, we could automate that process, but Codex Review is just an agent reviewing the code and double-checking.

[51:56] Yeah, it’s just running Codex and then just doing slash review.

[51:58] That’s it. Yeah. It’s not that fancy. I mean, it’s not. Sorry, it’s not that sophisticated. But it’s just like because now it’s like, if a contributor puts up a PR, that’s the first thing that we do because it tends to find good things. Basically, I think one bucket is: how do you create more automated systems that just help get things, make sure things are right.

[52:28] And that also includes things like trying to improve your AGENTS.md file over time. If there are things, if there’s feedback you’re giving in a review that the agent’s not respecting, try to find a way to help the agent learn that, even learn skills. We have some shared skills on the team, stuff like that. None of this stuff is very sophisticated, by the way. It’s pretty simple. The other piece is how do I make sure that I put in the work to ensure that I’m creating a good PR.

[52:56] And so for me, that’s like, I really should understand, again, it sounds like a really not. It really sounds like a low bar, but I should understand each line in the PR. I know it’s crazy, but also I do try to review each PR myself in the GitHub UI. This is something I’ve always found really helpful. If you actually just open up your PR and click files and read through it as if you were a reviewer, you tend to find things that you would miss if you were just looking at your local diff.

[53:34] I find that very useful. And then the other is trying to encode skill. I guess this is a little bit more in the first category, but trying to encode in skills things I’m consistently getting wrong that the agent is getting wrong. A recent example would be I found that I was often getting feedback on PRs that was of the form, this condition here, this if statement, what case is this intended to catch?

[54:07] Because if I commented out all the tests pass, and so I was like, okay, I should probably have a pass before I put up any PR where I have the agent go through and check: are these conditions still relevant, or are they left over from a prior refactor or something else? So I don’t know, I’m still learning, but those are some of the things I’ve been doing. Yeah, again, I think it’s a pretty hard time to be building software, but I felt for a long time where I had a fear that AI was going to make us more productive, but that programming would be, like, a lot less fun.

[54:44] Because I just love programming. And I was like, oh, now I’m gonna have to spend all my time reviewing code and prompting this idiot agent that keeps getting things wrong but ultimately is probably more productive. I actually feel way better about that right now than I did a few months ago. And I don’t exactly know why. I think it’s because, well, I think the agents getting better and the tooling getting better and me getting more comfortable with it is one factor.

[55:21] I think the other is I’ve grown to appreciate more of the kinds of things that working with agents has unlocked. The cost of running an experiment is incredibly low. There’s so many things I’ve wanted to try or questions I’ve wanted to answer that I can now answer almost instantly. Sort of a dumb example. In uv, everything is snapshot tested. So basically all of our testing is effectively running uv and verifying the output.

[55:56] That’s how we test basically the entire program. And so that means, and we have a lot of tests. That means we have a lot of test output. And the test output is... it actually ends up in the test files. So we have Rust files. We have a file called lock.rs that tests all our uv lock tests. It’s all our uv lock tests. And it’s very, very long in part because it has all the lock output snapshotted in the test.

[56:21] And I was like, what if we stored the snapshots in separate files? Would that somehow make our compiles faster? Because then you don’t have—technically, that’s like Rust code. And so it’s like, would that all disappear and would that make our builds faster or blah, blah, blah. And I’d always want to do that, but it sounded like to do that experiment as a human would be extremely painful because you have to convert all of those tests.

[56:48] And I just had an agent do it in the background while I did a bunch of other things. I got a bunch of data on it, and the answer is no. But it’s a little bit more nuanced. It actually does have a good impact. If you’re just iterating on the snapshot outputs, you no longer have to recompile your program at all because the outputs are stored somewhere else anyway.

[57:08] That’s the thing that makes a difference on you. But my point is, I’m just running experiments like that all day, trying things that used to be hard, used to cost a lot to. To answer the work of then going from that to production. There’s still real work there, but. So I think one piece is the tools and the agents getting better. The other is things that I just wouldn’t have been able to do before that I can now do incredibly easily.

[57:37] And then the third is, I think I’m more and more realizing that a lot of the value I get from building software is not retained because some of it is thinking hard about it. It doesn’t have to be typing out the code, but it’s thinking hard about the layout of a data structure. A lot of it is merging a PR that causes a user issue. I get a lot of satisfaction from actually fixing and improving something.

[58:01] It’s not necessarily just from typing out the code. I do feel for people a lot who feel like they’re losing something by working with agents, because I do feel that myself. But I feel better now than I did a few months ago about, like, what it’s like to work as a software engineer with agents.

Ryan:

[58:23] You mentioned in one of the performance optimization examples, you said if you just unleash Codex, it kind of does these local optimizations, and it’s very good at that. But it’s not great at some of the, I mean, today it’s more human ingenuity of system-level optimizations. And it kind of reminded me of this tweet that you had. You said, “I’m slightly concerned by how much garbage I would be churning out if I was trying to use these tools without significant software engineering experience.”

Charlie:

[58:56] Yeah, I remain concerned about that. Yeah.

Ryan:

[59:00] It reminds me, and similar to what Mitchell Hashimoto said in that tweet, there’s a very big difference between Codex, go and do this, versus you are wielding it like this tool and you’re kind of prodding in the right direction.

[59:18] Yeah. I was curious your thoughts on that because it seemed like it went pretty viral. And I think a lot of people are thinking about that.

Charlie:

[59:24] Being a great software engineer is more useful than ever. I don’t think it’s still the case that the people on our team who have the strongest engineering skills are the most effective, even at using agents. And it’s funny because there’s a lot of talk about token maxing. I don’t know if you’re familiar with this.

[59:54] Right. Yeah. The idea of, should you have a leaderboard? For example, this is getting tweeted about a lot: companies that have token leaderboards. It’s like, how do you create some terrible incentives to just use as many tokens as possible? And it’s funny because that does get tracked. Or sorry, there’s not a leaderboard. But token usage is something you can look up, for example, internally. I mean, and it’s interesting to look at because I don’t care who on the team is using the most tokens.

[01:00:23] And there are people on the team who are like, “I’m actively trying not to care about that, like being where I am on the token leaderboard,” which I think is great. I don’t care. They should just do a great job, and that’s fine. I don’t care if they use a lot of tokens or not. But it is interesting to look at the token leaderboard because some of the people on the team who are most productive are using a lot of tokens.

[01:00:47] There is a correlation. I’m not saying it’s causal, but I do think that a lot of great engineers are able to use agents very effectively and hopefully to multiply their skills. So I do think it would be really hard to be an early career software engineer right now. And I’m not spending that much time with early career engineers right now. Just based on it, at Astral, we’re just a very small team, and we tended to hire very senior.

[01:01:21] But it’s sort of hard for me to think about, what would we, like how would I learn, basically? What would the iteration loop be? I would be learning from Codex, I guess, as opposed to the other way around, basically. I mean, a lot of the time I’m actually instructing Codex and trying to correct it and providing a safeguard on it or Opus or whatever you’re using. And so, yeah, I think I just don’t know where you would get.

[01:02:02] It would just be way too easy to fall prey to a lot of the bad things that happen when you use agents.

01:02:08 — Learnings as an eng starting a company

Ryan:

[01:02:08] You built this proof of concept in Rust, and it was really well received. But why did you start a company around it, and how did the raising go and all of that? What was the motivation there?

Charlie:

[01:02:20] Yeah, yeah. So I left Spring. I was actually convinced to leave by a friend who, a very close friend who left Meta around the same time. And he was like, we should start a company together. And I was like, okay, fine. I mean it wasn’t quite that simple, but. But I did. I laughed. And then we kind of went into the idea maze of what do we want to build? We went into it not knowing what we wanted to build, and we spent a bunch of time exploring the Venn diagram of ideas.

[01:02:55] There were things he was interested in that I thought were not interesting and vice versa. And there was some stuff in the middle, and we spent time exploring the stuff in the middle. But then in all my spare time I was working on developer tools. Because that’s what I thought was really interesting, and it wasn’t quite like a fit for him, basically. But around then I was working on Ruff. I was working on a couple other projects that you can see in my GitHub that are like, I don’t know, probably not as interesting, but they were like.

[01:03:23] I was experimenting with lots of different things at the time. I was pretty interested in WebAssembly. I wrote a sort of CI/CD toolkit in TypeScript. It’s sort of like you wrote pipelines in TypeScript and it transpiled them to Docker. And I was like, oh, this could be cool. I don’t know. I was building a lot of stuff. And at that point in time I decided I wanted to start developing relationships with investors, but that I wasn’t ready to raise money because I didn’t know what I was actually going to build.

[01:03:54] And so my thinking was I’m going to try to get connected to some people who like to invest in this kind of stuff, with an eye toward reaching back out to them in three to six months and being like, hey, we had a great conversation, now I’m working on X. So that was my thinking. So I got connected to a couple investors who invest in software infrastructure and developer tools, and I had some good conversations.

[01:04:19] And then the problem is things just can move really quickly. And so I didn’t actually expect to start raising so soon, but I effectively got convinced. And at the same time, Ruff was growing a lot. And so I effectively got convinced that there was enough there to start a company, which is a very interesting process. I was like, I don’t quite know how this becomes a company, but I was effectively convinced that there was enough there to build a company.

[01:04:43] Which is interesting by the investors. Yeah. Which I’m grateful for. The other thing I was convinced of was, which is funny, is if I hated it, I could stop in like six months. It’s like if you decide it’s not for you, you could give the money back. The investor said that. Yes. Which I actually think was brilliant because, like, I was probably never going to do that, but it did make me feel like there was less pressure.

[01:05:14] So, sorry, very weird roundabout details, but basically I was working on Ruff more full time eventually. And then it was kind of, I would say, collaborative with the potential early investors, where it was like we would just have long conversations about my ideas, and then it basically became clear that it was like, there’s enough here. And I wrote out kind of a product roadmap, which honestly a lot of it stayed true to what we ended up building, what we’ve ended up building so far at least.

[01:05:47] And from there, it basically became like, yeah, we want to fund you. Here are the terms that we would do. And I was like, oh, wow, okay, so I guess it’s happening. So it was just interesting. And I had never done anything like this before. I mean, I was just an IC software engineer my whole career, and then suddenly I was like starting a company. And it’s funny because I actually think the decision to go all in and start the company wasn’t that stressful.

[01:06:22] I actually think a lot of the stress came later as the company started to succeed because at the beginning I kind of had nothing to lose. But then as the company started to succeed, I was like, oh wow, the company’s kind of working. What’s going to happen from here? And I had a team of 20 people who were depending on me. And so I don’t know, just for me as a founder it was like, I’m pretty risk averse, but I actually found that starting the company was an easier, it was an easier decision than maybe some of the stressful things that came later to navigate.

[01:06:59] But it happened very quickly and sort of unintentionally and in a symbiotic way with investors, which I hadn’t really anticipated.

Ryan:

[01:07:09] I didn’t expect the investors, because I thought the founders were hungry for the fundraising and go, please fund me. But the investors were like, I think it can happen a million different ways.

Charlie:

[01:07:19] And actually, I mean, we did three fundraises. We did a C to Series A and a Series B. We actually never even announced the Series A or the Series B. They were, I mean, they were announced in the acquisition blog post. But we sort of complicated. It’s like we basically just never got around to it, and why don’t you guys publish it?

Ryan:

[01:07:44] Because isn’t that good marketing for talent?

Charlie:

[01:07:46] It’s good marketing, but basically there kept being reasons that we wanted to wait a little bit. And to me, it always felt like a lot of work, and then I was like, it just never honestly felt like the most important thing because we were building a lot of stuff and the company was going well, and I was like, we don’t need the marketing. We did finally plan to announce it, but then we got bought, so it didn’t happen.

[01:08:12] Each of those fundraisers was preemptive, basically initiated by investors, which is fortunate because the company was going well and people wanted to invest. But it was also just a funny position for me to be in, I guess. I think I was just always a little bit conservative, and I wasn’t super aggressive about trying to go out and raise money.

[01:08:47] But we were lucky enough to be building things that people really had a lot of confidence in or had a lot of belief in.

Ryan:

[01:08:52] That probably gave you a lot of negotiating leverage because one of the best positions you’d be in is that you’re willing to walk away, you don’t need it. And by definition you didn’t even come there to begin with. They came to you and they said, please take the money.

Charlie:

[01:09:07] That’s true. Yeah, yeah. I wouldn’t say I’m a great negotiator, but yeah, I guess at least I had a strong hand. But we were very lucky with investors. We had amazing investors, super supportive and really, really aligned with how I wanted to build the company. Never any conflict, never any pressure to do anything specific, just support. And maybe the only thing, maybe the only piece of consistent feedback is that I could have been more aggressive and.

[01:09:42] But I don’t know, in terms of scaling, growing, and doing. But I liked the way that we operated, and yeah, we just had such good experiences with our investors too. So I felt lucky about that because it can easily go the other way.

Ryan:

[01:09:55] I imagine if someone invests, there’s a promise of future revenue. But how does this company make money? Because you guys give away your software for free, right?

Charlie:

[01:10:05] Yeah, we launched a commercial product in, like, August of last year, and it was sort of—it was called Pyx. It was kind of like a hosted counterpart to uv. So a lot of our, a lot of uv users, will purchase a private registry software instead of using the public registries, either for security or maybe they need to publish their own private artifacts, things like that. And we basically built our own private registry that had some first-class support for uv.

[01:10:37] And it let us solve a bunch of problems that we saw in our issue tracker around users using other solutions. Also let us build something really fast because we vertically integrated the client and the server. There were special things they could do to be really fast and really easy to use and all that. And we spent a while selling that, and our revenue actually grew pretty well. I mean, it wasn’t like, I think in this era of AI, you’re constantly hearing about fastest company to go to 100 million in revenue and things like that.

[01:11:10] It didn’t look like that, but we were definitely able to sell this to some big enterprises. And the cool thing was we had a very good, because we built the open source and everyone was using our open source, we had a really good funnel. We had a small number of extremely high quality customers, is the way I would put it. So the general idea for how we wanted to make money was to keep building open source and the tooling. The tooling remains free, open source, entirely noncommercial.

[01:11:43] And then we build software that’s kind of like the natural next thing you need when you’re using our tooling. So if you’re using uv, there are likely problems we can solve for you with a private registry. And then the funnel is people using uv, they have these problems, and then we sell them the registry. And the registry was meant to be one piece of a platform of a bunch of different things.

[01:12:03] We sell like a Python cloud. So that’s what we were building towards. I mean, part of the cool thing about the acquisition is we’ll be able to take parts of that platform and make it basically freely available. Like we did just as an example. A big part of that was we did a lot of, like, in Python, there’s a big part of the community that uses Python with GPUs like PyTorch. And then there’s like a whole ecosystem around PyTorch of software that kind of builds against PyTorch.

[01:12:44] And that’s for a variety of reasons. The ergonomics around that are not great. It can be kind of hard to work with, hard to install. The right version depends on the GPU that you have and what version of CUDA you have installed and all this stuff. And so we kind of tried to solve that in a certain way where we built our own distribution. You could think of it kind of like in the sense of a Linux distribution.

[01:13:11] We pre-built a lot of things like that that all worked together and made that available to customers. And so now we can actually take that and just make that freely available to everyone. Because we’re no longer, we no longer are trying to build an independent business. We’re just trying to build great tools that grow a broader ecosystem. So, I mean, more to come on that. But that’s been kind of like one cool thing that I’m excited about.

Ryan:

[01:13:34] As a first-time founder, especially with the engineering background, was there anything that was a surprising learning or something you would share with someone if they were an engineer and they were going down that founder path?

Charlie:

[01:13:48] There are so many different ways to do it. I’m actually not a huge fan of people giving startup advice in general because so much of this industry is survivorship bias. You could give the exact same advice. You can go to two talks and people give you two incredibly successful founders give you completely contradictory advice, and you’re like, I don’t really know what to do. And I tend to view that as you’ve got to figure out what’s true to you.

[01:14:16] And so there’s all these decisions you have to make: in person versus remote, right? Have a principle and stick to it. Either one can be great. We built the whole company remotely. It went super well. It was great. Do I think there are benefits to being a person? Of course. Would I have been able to hire the team that we put together if we were in person? Absolutely not. And so there are trade-offs to all these things.

[01:14:40] You just have to be principled and figure out what resonates with you. And there’s a million of those decisions that you have to think through. I feel fortunate in a lot of the ways I got to run the company. I tried to spend very minimal time fundraising and with investors, and I tried to optimize for investors I really trusted, as opposed to trying to talk to a billion different investors and pit them all against each other to get the best terms.

[01:15:07] My goal was always to find a partner that I really trust and get good terms, and then move quickly. Spend as little time on fundraising as possible. And so think about what you care about and focus on that. There’s no right answer to a lot of this stuff. I got a lot of advice to get a cofounder when I first started the company, and I basically ignored that. I mean, well, sorry, I did ignore it because I didn’t get a cofounder, I guess.

[01:15:32] For me, I kind of knew they were right probably, but I didn’t really have someone in mind. I didn’t want to force it, and so I just didn’t. And over time, I felt like it would have been helpful to have someone that’s kind of in the trenches with you in the same way. But you find other ways to compensate for it. I don’t know.

[01:16:01] I lean on my wife a lot, probably more than I should. Probably more open with my employees than I otherwise would be, which I think can be good or bad. But it’s like, I share a lot with the early team, especially when I need advice on things. Try to build a network of other founders, especially here in New York. I have a pretty good group of.

[01:16:22] There’s like six or seven of us who. We try to get dinner twice a year. Doesn’t sound like a lot, but everyone’s busy. Yeah, yeah, yeah. And that’s been a really helpful support system. So you just find other ways to compensate. But yeah, it’s. I don’t know. There’s no. I really don’t. I really think there’s not one right way to do it. Yeah, and it extends everywhere.

[01:16:49] I mean, also, everyone on X is talking about, should everyone in your company be working seven days a week? This kind of thing. And it’s like, I don’t know, we just built a very different company and we were able to do it. That was not. I mean, I work basically all the time, and that’s a choice I made and that I’m very happy with.

[01:17:13] But I don’t expect people on the team to work all the time. And I want it to be a company where you can be highly, highly successful working normal hours, but also where you’re rewarded for your output and your performance. And I try to keep all those things in sync, but again, there’s no one right way to do it. Other companies, that is their culture and that’s what they want to do.

[01:17:38] And sure, whatever. If that’s what you sign up for, just make sure that you’re honest about what you’re doing. So I don’t know, I just think figure out what you care about and, in my opinion, don’t focus too much on how you think you should be doing things. Think about how you want to be doing things and what actually fits with how you want to work.

01:17:55 — Top technical talk recommendation

Ryan:

[01:17:55] What’s your top book recommendation, whether technical or maybe something that helped you as a founder?

Charlie:

[01:18:01] I don’t read a lot of technical material. I have definitely watched a few talks that were very influential to me, which is a little bit different.

Ryan:

[01:18:10] What are those talks?

Charlie:

[01:18:12] The Zig creator, Andrew Kelley had a really good talk about data-oriented design that I learned a lot from. I mean, even apart from learning things, it sort of inspired me to look at software quite differently. And so I think about that talk a lot. Yeah, things like that. It’s really good. Yeah, it’s about. Well, I haven’t watched it in a while, so I’ll probably mess it up, but it’s like a lot of it’s about basically design decisions they made in the Zig compiler and just thinking about memory and allocation and all this stuff.

[01:18:44] And I was like, I watched that when I was pretty early in my career of systems programming, and I was like, wow, these people really care about what they’re doing. And I was like, that’s cool.

01:18:56 — Advice for his younger self

Ryan:

[01:18:56] Yeah. And then last question is, if you could go back to the beginning of your career, right when you graduated college, what advice would you give yourself, knowing what you know now?

Charlie:

[01:19:07] I don’t know, it’s so hard to give myself advice without feeling like I have all this hindsight bias. I mean, I think, I guess there are some things where I’d basically tell myself that it is the right decision and I shouldn’t worry so much. But it’s hard to know how that would have played out if I did it a thousand times over. But for example, I think when I left school and I went to work at Khan Academy, part of me was definitely like, wow, should I be taking more of a big tech job, and am I gonna really regret not having that experience?

[01:19:38] The Khan Academy pay was good, but the big tech pay was certainly better. And I was seeing my friends get huge bonuses and all this stuff, and I felt sort of insecure about whether I should be doing that. And I think it actually, in the long term, really paid off. I mean, maybe it would have been great, but the experience I had was really what I wanted, and I thought I made that decision for the right reason.

[01:20:06] So I think some of these things are, I don’t know, everything happens for a reason, you know, and it’s like, have some faith in what you’re doing for the right, you know, for the. If you’re making decisions based on principles, I think it can work out.

Ryan:

[01:20:24] When we started this conversation, you said the reason you got into what you got into is because you tried all these different ecosystems and you had a broader perspective. Imagine if you went to Google and you just kind of used Google‘s closed thing, and then you might not have had the same insight.

Charlie:

[01:20:43] Yeah. And I think about this with Spring, too, because Spring, I was there for four and a half years, and then I left, right, as they decided to do a pivot, and then they ended up joining Genentech. But we had set out to build this kind of crazy drug discovery company. We were focused on aging, and it was all with computer vision. It was very, very ambitious what we were trying to do. Yeah, yeah.

[01:21:10] And then afterwards, I was like, oh, the company didn’t have the huge exit or the huge. We didn’t achieve all of our dreams. Did I waste all my time? And ultimately I was like, no, because I learned by being an early employee, seeing all these stages. I learned so much about how to run my own company and also all the technical learnings that I rolled into my own company. So, again, I feel weird giving this advice because everything has worked out really well, but I feel like there are moments in time where I sort of doubted some of my career decisions.

[01:21:44] And then in hindsight, you can only connect the dots. Looking backwards, everything kind of added up to finding the thing I really love, which is building tools and feeding into that.

Ryan:

[01:21:55] Awesome. Well, thank you so much for your time, Charlie. I really appreciate it.

Charlie:

[01:21:58] Yeah, thank you. No, it was super fun.

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

Timestamps

00:33 - Skills frontier labs need

08:45 - The difference between AI research and engineering

21:41 - Domains that matter for the frontier

30:50 - Marketing yourself to frontier labs

35:13 - Concrete steps engineers can take

38:29 - Overview of pre-training areas

47:23 - Jeff Dean spot bonus story

50:14 - Favorite Gemini war story

58:59 - Advice for his younger self

Transcript

00:33 — Skills frontier labs need

Ryan:

[00:33] You wrote this post that was titled “How to Land a Job at a Frontier Lab”. What are the skills that are kind of in demand in Frontier Labs? Maybe we can talk about the shape of the work.

Vlad:

[00:49] There’s quite a range of different things that Frontier Labs require at this point. LLMs are artifacts that are connected to research and product in ways that machine learning really hasn’t been as connected to before. And so it really touches on so many different things. The goal of my post was to propose just a couple tangible directions in which labs could require a certain set of skills, not to be fully exhaustive.

[01:24] And really the ones that I dive into have to do with kernel development and low-level engineering to improve the runtime for these LLMs in practice. And so that was a particular skill that I see voracious demand for across all the different Frontier Labs and among different projects within the labs. So that seemed like a very sharp one to call out as an overall need. And so specifically, whenever we’re doing a research project that involves changing the architecture for the neural net in a particular way, or rethinking how we might do serving to do better KV caching or something like that, again, across the stack, you just need to be able to implement these new techniques in efficient ways.

[02:21] And the inner loop of all these different changes is creating software artifacts that can function at large scales with high throughput, low latency. And this is just fundamental work that’s tied to classical backend engineering thinking. So yeah, it seemed like a very open thing for people to specialize in.

Ryan:

[02:46] My friends that work at OpenAI and Anthropic have told me, there’s a distinction between an applied org and the research org, and I was wondering if Google DeepMind has a similar distinction and if you could speak about what that difference is.

Vlad:

[03:03] So we have different focus areas and, for instance, within Google DeepMind, there’s a team that focuses on how we can use our Gemini LLMs to better inform Search results. And so that might be in some way an applied version of the LLMs. But I am hesitant to make a very sharp distinction here because there’s so much actual hard research that has to go into this kind of level of product integration. Specifically, for the one I mentioned, quite a lot of work goes into making sure that these LLMs are factual and can cite sources to have very precise, grounded answers.

[03:53] Assessing the quality of these sources to make sure that you’re not referring to anything that’s sarcastic or a joke. This is, I guess, a good example of how even in product-specific applied AI verticals, you’re still doing research. That being said, there’s definitely what I would say is very classical LLM research teams, pre-training, post-training. These are things that are still standalone teams inside of Google DeepMind that are focused on what I would say is creating SOTA models.

[04:30] Pure research. Again, the caveat is the pure research that we do. The extent that it matters is the extent to which we can realize it. And so we’re just as responsible with delivering these models and making sure they train stably and actually being like the SREs of sorts for the training run to make sure that the model training is going smoothly as we are for coming up with the recipes to make these LLMs.

[04:59] And you can’t separate those two roles. It’s really crucial to wear both of those hats. So yeah, I think you can draw up a spectrum between research and applied. But no matter what, in today’s world, I think everyone needs to be fluid across that spectrum.

Ryan:

[05:19] I noticed there’s also another spectrum of software engineer to pure AI researcher. And how do you think of that spectrum? Software engineering versus AI researcher roles.

Vlad:

[05:31] So I guess in my case specifically, I think a lot of what we do and a lot of the new techniques that we develop, the groundwork is laid in infrastructure investment. So I can walk through what my team does a little bit more detail later. But one of the verticals is distillation. And in order to do distillation, it’s some way of transferring the knowledge or some form of statistics about the underlying dataset through a teacher model into the student model to make the student model better than if it hadn’t ever seen these auxiliary statistics from the teacher.

[06:21] When you’re talking about statistics derived from a massive LLM applied to trillions and trillions of tokens, you’re talking about a level of FLOPs investment that is millions and millions of dollars. And that in turn means that you have to be able to think through how do you optimize the system to be as efficient as possible? Because every operation that we’re performing is multiplied by such a large factor that every second counts, every byte of storage counts.

[07:00] And quite a bit of that work is good old-fashioned software engineering. In particular, the infrastructure for distillation has evolved through maybe three to four generations. At this point in each one, we’ve taken a step back, looked at what kind of research methods we’ve been applying for distillation, holistically thought about how do we broaden what the infrastructure is capable of. And there’s definitely a couple discrete points where rethinking the system design of how we perform distillation enables us to do research on distillation methods much more quickly.

[07:49] And so it’s this kind of investment that, okay, this four-month or whatever rewrite of our distillation infrastructure then results in a dramatically new understanding of distillation scaling laws that translates to really strong models. So it really requires just work across the stack. And I can’t imagine that we would have gotten results like Flash 3.0 without having made those distillation infrastructure investments that are at the end of the day things that started with a good old-fashioned design doc and thinking about what the right abstractions are for generating these teacher statistics, coming up with the right storage system for them, thinking through what could support the reading and writing across multiple different data centers at this scale.

[08:42] Really classical distributed systems problems?

08:45 — The difference between AI research and engineering

Ryan:

[08:45] Yeah, I mean it sounds like there’s a lot of software engineering backend infra-type problems given just the scale of the compute at this point. It still feels like though at some point in that spectrum there’s some crossover where there’s these new skills. Like somewhere where if you had, you took an arbitrary backend engineer and you placed them to, I don’t know, adjust the model architecture or something like that, is like a bit of a jump more than the infra work.

[09:16] How do you see that distinction?

Vlad:

[09:18] Yeah, so I think there is a crossover point in terms of doing research where research is an endeavor where the payoffs become a lot higher risk, higher reward. And we have this notion of kind of research taste, which is some high-level intuition about what path you should be proceeding through the DAG of the multiple different milestones that you need to accomplish in a particular project.

[09:51] In some sense, we can view software engineering projects through a similar DAG, where you have all of these intermediate artifacts that you want to hit in a software program to get to the final result. But in the software engineering case, the DAG is more or less deterministic, where you build one service, then a different service, then a third service, and you figure out your storage infrastructure layer first, that kind of thing, and you can just make monotone progress.

[10:19] But in the research case, you have to kind of explore this DAG, which is now stochastic, because some of the nodes, which might be some research ideas or some aspect of getting to a final goal, may or may not work out. And I think that requires a bit of a mindset shift. And that kind of mindset shift takes a while to learn, and it takes specialized skills to learn. This would be the kind of skills you pick up in a PhD, for instance.

[10:49] One succinct way I could put it, there’s a really excellent post by this professor Jacob Steinhardt, and I love to frame a lot of the research work that I do in this way. And it’s research as an MDP. So MDP here. Markov decision process. Again, we have this high-level idea of a stochastic dependency graph between different milestones in a research project where you might need to have a certain kind of result or prove a certain kind of theorem before you get to a certain kind of conclusion.

[11:24] Similarly, for a machine learning research project, you might need to have this and that featurization working before you can get this and that ImageNet accuracy or something like that, expanding those nodes in this graph. It’s this stochastic endeavor where these approaches may or may not work out. And whether or not one works out opens up a set of new possibilities for you. The approach that you might have in the software engineering case, where you could fully write out, here are all the paths to the goal across walking this graph.

[12:01] What’s the shortest path to your goal? That approach is not optimal in the research case because if all of a sudden the transitions between the edges in this graph become unreliable, and some of the nodes you might not even be aware of, it might be a hidden MDP, then the way that you might approach this problem would really differ. And in particular, you have to factor in the success rate and the time investment that you’re going to be putting into these different research ideas, as well as a priori estimating what those different rates are.

[12:41] And that’s a very different exercise than writing up what the design for your software engineering project might be. And it’s this skill set of building an intuition of how likely an approach is to work out without having yet done that approach that I think people often correlate with this research taste notion, but that’s exactly the one that you need to build up in order to properly traverse this MDP for the research projects and just generally the nature of the research work.

Ryan:

[13:12] It sounds like you’re saying that there’s a lot more uncertainty. I’m still trying to get a sense of the nature of the work. If you threw this backend engineer into a team that’s doing research, what are those concrete examples where they fall short?

Vlad:

[13:34] I think the very first thing that comes to mind is having the right context for the research landscape in which you’re operating. So quite a bit of research work involves almost this kind of. You have to take on this very humble viewpoint of there’s been quite a lot of investment in related work in the past and until I know the sum total of humanity’s bleeding edge in this topic, I’m definitely not going to be able to further that bleeding edge.

[14:15] So building up a solid understanding of past work in a particular area and doing that related literature review is maybe the first thing that I would imagine people might stumble on: having read and having the skills to effectively traverse the historical citation tree for a particular topic. Because you don’t have the time to read all of these different papers, you need to build up a sense of what are the high-value papers and what are the ways in which I can assess if a paper is worth reading without fully reading it.

[14:52] That’s the first thing that comes to mind as the skill that people need to build up. Even to be able to read these research-level papers. You have to have a background in machine learning and some computer science, and depending on the paper and depending on the domain, there might be all sorts of prerequisites in terms of the underlying math and coursework that you would want to have to properly understand.

[15:21] So that’s quite important to be able to have a deep understanding of what methodology is available, because you really won’t have a lot of hope of improving upon the methodology if you don’t understand what’s there already. So I think I mentioned earlier, one of the things that my team works on is distillation. In order to advance our understanding in distillation for large language models, you have to have a good understanding of what we’re trying to do with LLMs.

[15:59] Just to give a cursory overview here, the name of the game for LLM research is, especially in pre-training, scaling laws. And so what are scaling laws? People focus a lot about this power law structure and the fact that you have this and that exponent, but what matters is less so the functional form. What matters is, for a given recipe of scaling up your LLM, as you invest more and more FLOPs into the pre-training run of an LLM, you have to be able to predict what the final test loss of this LLM is going to be.

[16:39] And why do we care about this question? Why do we care about predicting what our generalization error is? In the classical machine learning world, say we’re trying to win ImageNet, we have our test loss, which is our classification error for 1,000 different classes, and you run your VGG or your ResNet proposal to get that classification error. That’s an estimate of how well that model does at classifying among those thousand classes, various different images.

[17:15] We can estimate how good our method is going to be by taking a validation set. And then whenever we have an architecture idea for a neural net, we just train it, and then we do a bunch of validation set runs, and we get a cross-validation error that is itself an estimator of our final test error. In this way, you can just iterate on different ideas through this process. But what’s different in LLM world is every single time you go up for a pre-training run, you’re about to put in more FLOPs into this run than you’ve ever done before.

[17:45] So it’s in some sense like a one-shot version of this ImageNet problem. You never get to see the full ImageNet training dataset. You have to practice on MNIST and then CIFAR and then maybe based on those, you try to come up with a method that just works right off the bat on ImageNet. If you were to just do that by itself, as I’m sure many people have tried, certainly when I was learning how to do all of those different things, you get something, it works really great on MNIST, it maybe even works on CIFAR, and then all of a sudden it breaks on ImageNet.

[18:16] You’ll find out that things don’t just generalize easily across scale like this. And so much of what we do for LLMs is coming up with recipes, where a recipe is this function that goes from number of FLOPs you’d like to train on to a training routine for this LLM. And if you can couple this recipe with a prediction rule that can predict accurately what your LLM accuracy is going to be, then you’re able to make decisions about how to improve your recipe because you can use that prediction.

[18:49] That is a ton of context on what LLM research looks like in general. But that’s an understanding that we got to, that we even thought was feasible thanks to so much initial LLM scaling work that we’ve seen across the Kaplan paper, across Chinchilla. Since those two papers, there’s been a lot more work in terms of what other factors are there beyond number of params and number of tokens that you train on that influence your prediction accuracy, like number of unique tokens, for instance.

[19:28] But I would say those two foundational papers for LLMs, those are informed by an even longer line of different scaling works going back to, say, the original GPTs. And then Google has had a ton of scaling work across its PaLM papers. This is just a set of works that have informed that viewpoint that I described earlier, that you kind of just need to build up by having gone through that literature review yourself.

Ryan:

[20:01] If you were, for instance, if you were trying to pick someone that was going on your team, and the way that you would judge their fitness to help you push the frontier is their understanding of the frontier, including the existing literature, which requires all these prerequisites. I think you called it mathematical maturity in your post.

Vlad:

[20:23] Yeah, so I think it’s easy to read and understand those papers once you have mathematical maturity. So I guess the ones I mentioned in particular, nowadays they’re table stakes, so I would expect candidates to be familiar with them. I think the general skill set is being able to dive into a paper of that level and then understand it, being able to take a research idea from a paper and implement it yourself. That’s just a very important skill set to be able to have.

[21:06] We get all sorts of different ideas presented. They might not all directly apply to our domain, but if you can deeply understand them, then you can iterate on them and you can improve them inside our domain. And so when we assess people who can work with the mathematical concepts in these machine learning papers, that’s, I guess, the key skill there. That would be evidence that you can go pick up this arbitrary paper and see to what extent these ideas carry over in the Google setting.

21:41 — Domains that matter for the frontier

Ryan:

[21:41] This probably won’t be exhaustive, but I’d be curious to hear other domains that maybe people could dig into to see what kind of matters in frontier AI research. So you’d mentioned distillation. You also mentioned kernels. It sounds like kernels are helpful everywhere, but are there other areas that come to mind if you were just rattle off areas that are not necessarily exhaustive?

Vlad:

[22:05] One thing that I think is quite powerful is actually programming language research. So by looking into how we can create abstractions at the programming language level, we can facilitate kernel development. I think ThunderKittens is a really good example of this. Coming up with an abstraction that allows you to write kernels through four functions instead of arbitrary globs of C code allows you to move really quickly in developing algorithms that fully utilize hardware.

[22:42] At that point, it’s not about the PL research itself, it’s about having a passion for these kinds of programming language abstractions and working with low-level hardware people who are interested in and will try to work with CuTe DSL. This kind of thing, where there’s a lot of hardware-specific domain-specific languages. One other thing that comes to mind besides PL and scaling law literature would be reinforcement learning literature.

[23:17] So in particular, ever since RLHF, I think we’ve seen that deep RL algorithms like PPO do have a place in production systems, and there was a time where that was in question. But now it’s pretty unanimous that we see these kinds of algorithms applied to real production systems. And the theory behind that, you kind of have to start with the basics for reinforcement learning and work your way up to the myriad value-based methods and policy gradient methods that we have today.

[24:00] That’s another domain that I think is just a very rich literature tree to crawl. And then for more of the backend engineer folks, beyond just the kernels themselves, there’s I think a pretty fun overlap between distributed systems and optimization work, where figuring out how to design neural net training algorithms that allow for training across many GPUs. There’s all sorts of fun challenges between asynchronicity, how up to date your gradients are, how pipelining affects the staleness.

[24:43] All of these system choices that you could make in your training algorithm design will impact convergence and the final quality of your neural net. And those are things that can be analyzed independently of the LLM setting and have been for a while, especially if you’re more infra inclined, then having a good understanding of how those different algorithms work is a really good place to start.

Ryan:

[25:09] Do you see any difference between the demands of the different Frontier Lab? So, for instance, if someone wants to work at Google DeepMind, is there a particular area that you see Google DeepMind cares about more than Anthropic? For instance, I think in terms of the skill set, it’s probably pretty similar.

Vlad:

[25:24] Yeah, I think there’s maybe differences in business strategy and the set of offerings that’s a function of the specialties of the labs and the kind of different customers that the labs could have. But I would say that there’s quite a lot of overlap between the labs in terms of what people look for. And when I posted my post, you would see people from both OpenAI and Anthropic saying, yeah, we agree with this advice.

[26:04] And so I think that’s just a little bit of evidence towards that.

Ryan:

[26:09] I think one reason for the huge demand for wanting to go closer to AI research is because people are thinking, oh, software engineering is not going to be as important in the future. Is there a similar thought when it comes to research where LLMs are also going to handle a lot of that work as well? So there’s no reason to favor AI research versus software engineering.

Vlad:

[26:34] So I think the research skill set is going to become increasingly important. So I would say being able to handle stochastic components in the planning of your work is just going to be a larger and larger part of how we approach our jobs. Figuring out how to leverage AI in whatever thing you work on, which doesn’t even have to be software related, is just an important muscle to start building right away because these components aren’t deterministic.

[27:09] And thinking about how do I construct systems around these LLMs to do my job more effectively, that’s going to be the thing that sets you apart in the future. And I think that’s true no matter what you’re going to be doing. Look, I think there’s FUD everywhere, especially with some of the approach to marketing that some people have in terms of AI. It’s FUD that is being intentionally leveraged. And so I feel like people should really just focus on themselves and trying to be more productive themselves.

[27:42] I don’t think that AI is going to replace all of our roles. And so the reason for that is that one of the important aspects of what we do as humans in an organization, which is really this web of trust from this organization that is this pool of resources and this pool of people that manages these resources. One of the important things that we do is we allocate those resources towards certain goals.

[28:15] And even when we can accelerate our execution, there’s an element of making decisions around how we allocate these resources that will always be something that needs to be attributable to a human making that decision. That’s simply because you can’t hand off blame to AI. So we at this point have LLMs that really deeply understand law, and they could review your contract for you or something like that, but they can’t represent you in court because they can’t be disbarred.

[28:53] And so that’s, I think, a really sharp way that I might describe, okay, this is why the legal profession will go on, even though LLMs are really good at recalling precedent, is you want to have someone who is responsible, who can validate the output of AI to perform legal work more effectively for you rather than hand off your legal defense to an LLM.

Ryan:

[29:25] Yeah, I think the FUD was actually the original motivation for your post.

Vlad:

[29:30] Yeah, I really think that the mindset that people should have is a constructive one. And so there was a tweet that I saw, I think by Deedy, that was like some long-form fear mongering about AI permanent underclass or something like that. And it’s easy to get stuck in that loop. But I think the important thing to think about is that we all have agency over our future and we can start investing in skills that matter for tomorrow, today.

[30:09] And that’s really the only thing you should be doing, right? Worrying about it is not going to help you. And so part of why I wanted to write this post is in response to that, because it was something that I could see echoed. I gave a lecture at Princeton a while back, and a big question that came up is, how do I work at Google DeepMind? And it’s something that just when people find out what I do, that’s the top question people ask.

[30:41] I figured it would be helpful to add a little bit more constructive direction to the discourse here.

30:50 — Marketing yourself to frontier labs

Ryan:

[30:50] One last thing on the post because if you think about getting a role, there’s obviously the skills, and we talked a lot about the skills and your fitness for the role, but there’s also kind of the signaling for that role and what is kind of valued. If you were to be marketing yourself to one of these Frontier Labs, what signals matter most?

Vlad:

[31:13] Actual evidence that you’ve created something of use to other people along the line of kernels. Right. You can take any of the many open-source LLMs that we have and optimize them. You don’t have to make them better. In every case, you could show that, oh, I have an improvement for this and that setting. It doesn’t even have to be something that speeds up the model. On GPU, there’s all sorts of open-source stacks like vLLM.

[31:43] There’s a lot of other things that you can do besides accelerating the LLM inference on device. The serving stack that surrounds LLMs is a very sophisticated distributed system that has to maintain this KV cache memory and deal with all sorts of load balancing and request queuing and very common problems for backend servers. These projects are always looking for help. So contributions to vLLM or SGLang or demonstrations with TensorRT, they have, I think, a distributed system called Dynamo that allows for disaggregated serving where you could show that you made a project using these components, you improved these components.

[32:34] That would be an extremely positive signal for any candidate that I’m looking at and a very welcome contribution to open source, I think.

Ryan:

[32:44] Also, a lot of what we said is kind of assuming the path of external hire into Frontier Lab, but a lot of these Frontier Labs have large organizations that aren’t necessarily doing the cutting-edge Frontier work. So let’s say, yeah, for instance, I mean, Google DeepMind versus let’s say there’s some infrastructure eng that’s working on Search and they have the backend skill set, maybe not as much domain context, and they try to internal transfer to Google DeepMind.

[33:16] Does any of your advice differ in that kind of case for an internal transfer versus someone who’s coming from external?

Vlad:

[33:23] There’s someone who I worked with closely on the search side who actually did transfer to my team, Nate Lintz, and he’s amazing, and now he owns so much of what we do on my team in terms of inference, co-design for Flash and Flash-Lite. And I would say he’s a really great example of this, where his approach was, how do I help my product area adopt this technology as effectively as possible?

[34:00] So I think there’s definitely, if you’re in an organization that isn’t directly generating these models but in some way trying to leverage them, there’s a very big gap in terms of applying these LLMs effectively, serving them effectively within your organization, and becoming someone who does that really effectively not only creates a ton of value in terms of the specific business need for your org, which will definitely elevate you in your org, but it’ll also be the case that you’re going to just naturally become the partner that we work with on the research side to make sure that our models are effective within your org.

[34:51] So at that point, you may or may not want to transfer. Definitely, if you transfer, we’d be happy to work with you. But at that point, I think you’re already doing something that is cutting edge, which is integrating this new technology into a real product that people use. And so, yeah, that’d be my advice there.

35:13 — Concrete steps engineers can take

Ryan:

[35:13] Towards the end of this post, as we leave this topic, you had the concrete invitation because I know you were hiring. Do you want to say what that was?

Vlad:

[35:23] Yeah, so I was just trying to think of, how do I put my money where my mouth is? How do I demonstrate, look, this is a good way to show that you have at least some evidence of the skills that I called out as important: intent, mathematical maturity, grit. And so I listed out a couple of exercises that demonstrate some initial knowledge of scaling laws, some willingness to get into the weeds engineering-wise in terms of implementing a real transformer, and sort of willingness to pick up the kind of bread-and-butter math that we use every day to size these LLMs.

[36:07] And I won’t recall the full list of the exercises that I expected here, but if you do the detailed handwritten version of The Scaling Book exercises and send me a video of yourself doing them, along with the transformer exercise on my post, then that’s something. If you can work in the New York office, I would love to interview you. Quite a few people reached out to me about that. I actually already have had a couple submissions, and we’re proceeding with the loop with those people.

[36:41] So yeah, it’s quite a bit of work. But impressively, I got a response within, like, I think, a week of posting. So it’s definitely doable. Yeah, I mean, I don’t have unlimited headcount, so the offer’s on the table, but I can only hire so many people. The good thing is, though, that is such a strong sign of self-development that not only is this something that you should be doing for its own sake regardless of whether or not you will get a job at Google DeepMind specifically, but I think it’ll be something that lets you basically prepare for interviews in other places.

[37:27] Certainly, if you reach out to me with these exercises completed, even if I do all my hiring, there’s tons of people who I know who are hiring as well, and I’d be happy to refer people as well.

38:29 — Overview of pre-training areas

Ryan:

[38:29] On the next topic, I saw you’re the area lead for pre-training on Gemini, and I just thought it might be interesting to hear you give kind of a high-level overview of what pre-training is in your words and maybe what are the high-level challenges in the area.

[38:45] We can talk about that.

Vlad:

[38:46] Yeah, so there’s quite a lot of work that we do in pre-training as an area lead for it. The specific things that my team is responsible for delivering include the Flash model, the Flash-Lite model. These are models that get used for AI Overviews and AI Mode in the search bar, as well as some other 1P models that are used by different orgs like ads and YouTube. Besides this, we’re also key technical PoCs for the Google-Apple partnership, and so we do technical work there.

[39:25] Those are the actual product-level deliverables from my team. Beyond that, we do research to make sure that these deliverables are SOTA. And also we do general pre-training research that contributes to the pro series model as well. And the nature of the research I would say generally breaks down into three different verticals. There’s distillation, which I mentioned earlier. There’s what I like to call inference co-design.

[39:58] So creating neural architectures that are efficient to run inference on. So coming up with the network topology, the shapes of the matrices that the matmuls use inside of gating and linear layers for this transformer, as well as the attention shapes, num heads, that kind of thing. So that is effectively utilizing the hardware that you’re serving on. And then the final pillar here is new quantization methods.

[40:32] And so quantization is just something that’s been near and dear to my heart that I’ve been working on the research side for ever since I joined Google. And it really changes what’s feasible for the first two. So that’s why furthering the state of the art in terms of how you can compress models is also a very important pillar in the research that my team does. Generally, quantization refers to reducing in some sense the size that the neural nets take up in order to represent their weights.

[41:11] So typically, a neural net, when you’re training, it is represented as a series of numbers that make up the matrices inside of the neural net that are stored in FP32, 32-bit floating-point weights. It turns out that when you do these computations, you don’t need all of that extra precision to still maintain the quality of your neural net. And you can, with pretty simple methods, reduce the precision at which you store these weights down to four bits.

[41:44] So all of a sudden, this huge range of numbers that would take this FP32 to represent something that gets you down to seven digits of precision can, with somewhat high fidelity, still be represented well by 4-bit ints, which just cover this tiny range of minus 8 to 7. And it’s kind of a miracle that you can do this. But what’s even more of a miracle is that you can apply these kinds of quantization transforms to the runtime activations that the neural net processes.

[42:27] And as soon as you do that, the actual math that you’re performing, because you’re taking much smaller operands to your matmul than what you were doing before, the amount of electricity that it takes to compute the neural net drops significantly. And what’s interesting is that 99% of the total cost of operation for AI hardware comes from the power that it takes to run these chips. If you can do these operations, you could just make neural nets run more cheaply, run more efficiently.

[43:02] That helps in terms of serving more requests and helps in terms of latency. So the name of the game for quant research is how do we push the frontier beyond this 4-bit range?

Ryan:

[43:16] There’s this take that I see on Twitter all the time, which is just talking about MFU, and someone who’s not in the space, or model FLOPs utilization, someone who’s not in the space. They see a number in the low tens and they think, wow, they’re wasting all of those GPU resources. I was curious if you could just clarify that for people why a low MFU, or I guess naively low, is actually not low at all.

[43:42] And maybe also explain what MFU is.

Vlad:

[43:44] Yeah, so when we compute MFU, you want to divide the actual number of FLOPs that the neural net is performing here by the total number of FLOPs that the accelerator could have done in the time of your request. And so in some sense, this is giving us the percent of time that we’re usefully utilizing the FLOPs rate of the accelerator. And to get to 100% MFU, you would just need to be fully utilizing the matmul unit of whatever accelerator you’re doing here.

[44:20] So it would just have to be doing a bunch of matmuls in a loop without reading any memory or doing any other operations. That’s not a very useful computation in practice. Neural nets have to apply activation functions or do attention or write intermediate outputs back to HBM. And all of those different operations will require utilizing the memory bus or utilizing vector processing units. Or simply they might be mathematical operations that the underlying hardware performs more slowly than it might perform a matmul.

[45:06] And so all of those things contribute to not running at the full speed that the processor is rated at. That’s why you might not see 100% MFU all the time, is because part of the time your neural net was reading and writing to memory, or part of the time it was doing an operation that fundamentally runs slower than certain other units on your device. I think quite a bit of this inference co-design work that I talked about earlier is across all of the different capabilities of the chip.

[45:44] So communication to other chips, memory bandwidth, the speed at which we can read parameters from memory, FLOPs, of course this can be matmul FLOPs, this could be FLOPs for processing vectors. So things like doing activations, all of these have different rates in the hardware, and a given computation isn’t going to match the natural hardware’s rate of each of those operations. So when you design a neural net, you want to be able to choose shapes for this neural net that fully saturate all of those hardware units to get you as high of an MFU as possible when you are doing inference here.

[46:32] What makes this more than just an algebra problem is that those choices translate to different quality outcomes when you actually train this neural net. The process of this kind of inference co-design is how do we come up with neural architectures that scale predictably, have a good prediction, so are high quality and still make the MFU as large as possible during inference. This kind of joint optimization is what makes inference co-design really fun.

[47:06] And also this kind of evergreen problem because as the hardware changes, all of those relative constants of FLOPs to memory bandwidth to communication bandwidth change. And those will have different implications for what the optimal neural net shape should be.

47:23 — Jeff Dean spot bonus story

Ryan:

[47:23] On another topic, Google has this idea of a spot bonus where someone can give you a one-off lump sum of money as a thank you for good performance. And I saw on your resume that Jeff Dean, the legend himself, gave you a spot bonus. And if you can tell that story, I’d love to hear. Why did he give you a spot bonus?

Vlad:

[47:46] Yeah, so that one actually was at the very beginning of the Gemini program. He gave out his spot bonus to people who hopped on and launched the first version of Bard. And I had a very small contribution to a very, very large project at the time. I helped with SFT for one of the first versions of supervised fine-tuning for one of the first versions of Bard that got released, like, right? The biggest lesson out of that experience was, at that time I was just doing pure research in Google Brain, and I was super focused on just how do I maximize the number of first-author papers at NeurIPS, ICML, ICLR.

[48:38] And I remember distinctly thinking, I had this instinct of like, oh, should I just keep my head down and try to write more papers? Luckily, at the time, my manager, Rohan Anil, really encouraged all of us to get involved in this space, and that was just the right motivation that I needed to roll up sleeves, do a bunch of hyperparameter tuning and engineering work to get this model running on some really old TPUs, to get some extra cycles in for SFT attempts.

[49:25] That very small initial engagement that was recognized by Jeff Dean, I think, blossomed into more and more investments on the LLM side by me and ultimately led me to where I am today. So, yeah, I would say it’s less so about how much that SFT helped the initial release. And it’s much more about recognizing that there’s quite a bit of work, some of it not glamorous, some of it just hyperparameter tuning and golfing the XLA compiler to make your program fit in a certain memory amount that contributes to a wider business goal that is really quite important for getting involved in very high-value projects.

50:14 — Favorite Gemini war story

Ryan:

[50:14] You’ve been working on Gemini for a while now, and because it’s a top priority, there have to be some incidents or war stories that you’ve been involved in. So I’m curious, what’s your favorite war story when working on Gemini?

Vlad:

[50:30] So I think my all-time favorite would have to be Flash 2.0. So this one was quite a challenge and a very long journey to get there. But one of the main things that we were optimizing for, which Flash 1.5 established, is this category of very fast, low-latency model that’s still quite good. And in particular it has to be fast because it’s used by Search to serve responses in AI Mode very quickly.

[51:25] Because of that, for Flash 1, eventhough at the time we knew about MoE models and how they increase capacity. And so I think one thing that came up was, okay, we sure would like to use this new architecture, but it’s difficult to just simply switch to an MoE. Because what happens with an MoE is it uses a lot more parameters in general. And because it uses more parameters, it takes up more HBM. These chips that we serve on have a finite amount of HBM.

[51:55] So you have to shard the MoE across multiple different chips. So if you have whatever N experts, then you might shard it across N chips or some factor of N. What this causes is a lot of communication in the middle of the model. When you have a token that needs to be routed to an expert, and that token might live on the first TPU, but it needs to go to the last TPU, that’s a lot of communication that you’re inducing in the forward pass.

[52:26] So the latency of this operation increases dramatically with N. And the challenge with MoEs is they increase N. So that kind of really bottlenecked this approach. And one interesting thing that happened was we definitely knew about pipeline serving for a while. It’s just in the dense case, it never really ended up mattering. I distinctly remember a very early conversation I had with Sholto about it, and Sholto’s like, oh yeah, you’re so FLOP bound and so pipelining is just not gonna change your prefill profile.

[53:07] And then he was right. I tested it out and then abandoned the idea. But what’s interesting is I had a very small team at the time. And one of my reports, Geng Yan, had a very nice idea. He was working with Rahul Arya and a couple folks from the Israel team at Google, and that was to apply pipeline prefill to MoE. Pipelining is a technique where instead of parallelizing those end-machine experts across those end machines, you parallelize layers across those end machines.

[53:45] So instead of on a particular layer, you have to route tokens from machine to machine. Now one layer does the computation for one subset of your pre-fill request and then hands off the processed tokens to the next machine to process the second layer, and then the third layer and the fourth layer. And all of the experts can then stay resident to a single machine or a smaller set of machines. So what this does effectively is it changes the communication pattern from something that required a lot of token exchange on every single layer to something that actually can be hidden behind other computation.

[54:28] Because you can do this pipeline pre-fill across different parts of your request. So while layer two is working on the first thousand tokens of your request, layer one on the first chip is processing the second thousand tokens of your request. So it was a way of breaking this HBM constraint by moving layers across the machines rather than moving experts across these machines. And because of that, the communication overhead has gone down, and all of a sudden MoE latency looks really attractive.

[51:25] Now, the Gemini 2.0 report says it’s an MoE series of models, and the thing that made that possible is, or one of the things that made that possible, is this serving-time innovation. Dwarkesh and Reiner have an amazing post about exactly this optimization that you can write up in the algebra of The Scaling Book. And it’s just a wonderful example of how this kind of change can have really dramatic implications on LLM quality.

[55:41] What really made Flash 2.0 rewarding is this giant MoE decision. It sounds like a small technical decision at the time, but people were really worried about whether or not the latency of this MoE would actually be reasonable. Luckily, I was able to run a very transparent technical process to get to the bottom of this. And by the end of it, we made the right call, but then we had to train it. This was a bigger model than we’ve ever trained before at the Flash scale, and we knew this would be the right call.

[56:18] But it was just going to be 40 days of grueling work for a really, really small team. We probably had five people on the rotation for training this model. I remember all of us just kind of rotated day by day, handing off all of this SRE-style work of keeping the training job alive, which at the time was a very interactive thing because you had to make sure that everything was moving stably, that you had tuned data iterators that aren’t slowing down your job, that if there’s a gap in the data somewhere or an indexing issue, you had to really quickly put up a fix because it’s wasting all of this GPU time.

Ryan:

[57:05] What about at nighttime and on the weekends?

Vlad:

[57:08] So, yeah, I think for those 40 days, we did not do a lot of sleeping. We had to do these dual shifts across the Paris office and Mountain View. And the thing that made it so rewarding was when this model came out around the same time DeepSeek-V3 came out, and the Wall Street Journal put out this article that was this giant red scare article about how China’s going to take over AI with open source models.

[57:39] And I remember my friend sent me a screenshot of this table of the LMSYS Chatbot Arena leaderboard, and all the way at the top right you’ve got ChatGPT and DeepSeek right behind it. And like, oh, DeepSeek was trained for whatever few million dollars, and they’re right there. And then my friend was like, oh, Gemini is so behind because they had a version of, I think, Flash 1.5 Pro or something in that table at the very bottom.

[58:15] Then I looked at it. It’s like, oh, that’s really interesting. I was just looking at this leaderboard because we just released a model, and it definitely doesn’t look like that when you go to the website. So it turns out there were some elided rows on the Wall Street Journal article. And so now if you go to that article today, you can see what at the time was the state-of-the-art model, Flash 2.0 Thinking up in the top right corner, way far ahead of DeepSeek-V3, might be messing with the open source narrative that they were trying to publish there. But it was a really important accomplishment for the team.

58:59 — Advice for his younger self

Ryan:

[58:59] Last question for you is if you could go back to yourself when you just graduated college, I guess, undergrad, and give yourself some advice, knowing what you know now, what would you say?

Vlad:

[59:11] You gotta chase the problems that people are facing in the world today. Go after the challenges that people see in everyday life, and don’t be afraid to tackle a smaller part of this problem or maybe a more menial sounding part of this problem. Even if it’s not fancy research, math, or something like that. Trust that by working on what’s important, even if it’s a smaller part of a larger project for what’s important, you’re going to get to see what really matters in terms of moving the frontier forward.

[59:54] And it’s this kind of humility, maybe, in your problem approach that you should really be chasing. That’s one piece of advice. I think the other bit that I would give, maybe as professional advice, perhaps, would be be the kind of coworker that people would want to see succeed. And so what I mean by that is there’s this conception of workplace psychopath or Machiavellian leaders or whatever, people who will do anything at all costs to get the results they want, and they might be able to squeeze people to get some short-term gain.

[01:00:45] But having interacted with a variety of people professionally for so long, what is interesting to me is there have been a select few. One in particular is probably a very dear friend and mentor of mine, Todd Lipkin, who first got me into computer science, that are just so kind and people that you can learn from, someone that I can follow and be successful by following, that just genuinely inspire me to want to help them succeed.

[01:01:33] And so in particular, if you are the kind of person who helps people succeed in their projects, comes up with projects that can leverage other people’s complementary skills in ways that help them shine, people will notice that people will want to contribute to projects that you come up with in the future and, in general, will want to support you going forward. And so people can get really cynical thinking about the game theory of how to interact at work.

[01:02:10] But I found that this kind of more amicable approach generally creates this deep sense of collaboration and willingness to help that is so important to get very large projects that require multiple people and multiple skill sets over the line. And so, yeah, I think if I could give any kind of interpersonal feedback or professional feedback or whatever to earlier version of myself, it’s to be that guy, is to be the kind of person that other people want to see succeed.

Ryan:

[01:02:51] I love that this advice combats the cynical advice. And I also love that your original post combats the doomer, permanent underclass stuff. So, yeah, thank you so much for your time. It was a lot of fun. Really appreciate it.

Vlad:

[01:03:05] Thanks for having me, Ryan.

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

Timestamps

00:39 - What functional programming is

09:18 - Downsides of functional programming

10:53 - Specialized hardware for functional programming

21:47 - Haskell is useless

25:59 - Rust vs C

28:26 - Haskell vs OCaml

35:26 - Side effects in Haskell

44:26 - Type systems

57:30 - How the Haskell compiler works

01:04:35 - Why Haskell is talked about more than used

01:09:07 - Avoiding success at all costs

01:11:12 - LLMs and programming languages

01:13:57 - New programming language design

01:15:59 - Should students continue to learn programming

01:22:33 - Why Excel is is 2nd favorite programming language

01:25:04 - Advice for his younger self

Transcript

00:39 — What functional programming is

Ryan:

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

Simon:

[00:57] Functional programming is about programming with values instead of mutation. So in a conventional imperative programming, computation proceeds by, if I want to add up the numbers between 1 and 100, I have a mutable cell containing a running total. And then as computation proceeds, I keep adding to my running total. So there’s a cell that changes its value over time. Computation proceeds step by step.

[01:23] There’s a program counter. Now, that’s very unlike mathematics. If I say three plus four times seven, you don’t think of a mutable cell that changes its value over time. You think, well, three plus four is seven, seven times seven is 49. Just the answer is 49. So, in a sense, it’s more declarative than imperative. Another way to think of it is it’s more like what a spreadsheet does. In a spreadsheet formula, if you put in a cell, you’d say, in A1, you put the formula =A2 * A3 + 7.

[01:55] Well, then that’s just the formula that is evaluated. And you expect to compute the values of A2 and A3 automatically before computing A1. It wouldn’t make any sense to compute A1 from the old values of A2 and A3, right? So, and there’s no notion of a program counter. There’s no notion of do this and then do that. It wouldn’t be sensible to say equals print X plus 3, because who knows when or even whether that cell will ever that formula will ever be evaluated.

[02:23] Now, the surprise is that it is possible to do useful things in such a limited language. When I learned programming, I learned it by writing machine code in which the fundamental mode of computation is registers and program counters and mutation of registers as you go along. And memory, like, computation and mutation seem to be inextricably interwoven, right? That’s how computation gets done. So it was a surprise to me when I learned that, well, it is possible to do useful things with functional programs.

[02:56] I still remember that amazing revelation. Now, in fact, one way to look at it is this: right back in the late 1920s, early 1930s, Alan Turing was doing a PhD in Princeton under the supervision of Alonzo Church. Now, Alan Turing, as we all know, invented the Turing machine, which is fundamentally about mutation, right? It has a little tape, and you can read things from the tape, and then you write back new things onto the tape, and it has an immutable program.

[03:30] Now, Alonzo Church at the very same time, was working on something he called the lambda calculus, in which there’s no mutation. The lambda calculus is like the essence of functional programming. Programs execute just by reduction. Now, so these were two different models of computation. You might ask, what can you compute with a Turing machine? And what can you compute with a lambda term? And the astonishing thing that turned out, which is completely nonobvious, is that anything you compute with a lambda term, you can compute with a Turing machine.

[04:02] And anything you compute with a Turing machine, you can compute with lambda calculus. So that means that the two are identical from the point of view of their computational power. Big surprise to me. Okay, so they’re equally powerful. And then the question is, which might you want to choose? As I say, I started life from my baseline of imperative programming. Of course, that’s the way you write programs.

[04:26] And functional programming is a kind of weird, anomalous, rather nerdy, academic thing. But I became hooked on the idea that by excluding side effects by default, i.e., imperative programming has side effects by default. By excluding side effects by default, we could make programs that are easier to write, easier to maintain, easier to reason about. And then the question is, what are the practical obstacles?

[04:53] Is it slower? Is it less convenient, and so forth? So, in effect, I’ve devoted my research life to exploring that hypothesis. The wonderful thing about being a researcher is you can take something which, at the time back in 1980, functional programming was very nerdy, geeky, academic. But I was allowed to spend my professional life just saying, what would happen if you took that one idea, programming with values, and just ran with it?

[05:23] Where would you get? And I think we got somebody somewhere pretty interesting. I don’t want to say that it’s better fundamentally, because after all, Haskell on that journey started with functional programming. Then we learned how to mix functional imperative programming together in a way that we might talk about later, right? So it’s not really an either-or; it’s more of a both-and in the end. But my position now is, as I often say, when the limestone of imperative programming has worn away, the granite of functional programming will be revealed underneath.

Ryan:

[05:57] And why do you say that?

Simon:

[05:59] Well, functional programming is the language of mathematics. That’s how we fundamentally think about things when we want to be formal. Indeed, if we want to reason about and say, what does this imperative program do? We have to wheel out a lot of mathematics and Hoare triples and so forth. But that’s all in the world of maths, which is just functional programming. Functional programming is just mathematics brought to life and made executable.

[06:22] So you might wonder, I suppose you may be saying, well, isn’t imperative programming just enough? And I think that there you have to just look at the broad sweep of things. I think what’s happened is that from the world of functional programming, lots of ideas have got adopted into the imperative arena, right? So they grew up over here in functional programming, and then they have been adopted by the imperative programming thing.

[06:54] So you might think garbage collection, you might think lambdas, you might think language integrated query, you might think about lots about type systems, polymorphism and static typing, tons of that. So at least it has been an intellectually interesting experiment that has been a very fertile laboratory in which to grow up ideas that can infect the mainstream. Now my instinct now is that we should start from functional programming and do imperative programming where necessary.

[07:24] I think probably the mainstream is we should start with imperative programming and sort of add bits of functional programming where possible. And I’m not going to say that they’re wrong to do that, just to say that I think it’s a pretty interesting dialogue. Now you do have to think very differently about the act of programming, right? You do have to rewire your brain quite a bit. But just let me.

[07:46] This is something we might want to come back to. I said easier to maintain. As programs get old. Think of a 10-year-old program, right? If you have a piece of 10-year-old code written by somebody who’s long since left your company that mutates some more or less global variables, then you might be a little bit afraid about, oh, and there’s other bits of code scattered about that also read or write those global variables, then you might be a little cautious about making modifications, right?

[08:16] Lest, oh, if I put these two things, if I do B and then A instead of A and then B, maybe the global variable that I read somewhere deep inside the code no longer has the value that it was expected to. So reading and writing shared variables that are visible outside the scope, sort of somewhat global variables, is a form of coupling between bits of code that is very invisible, very invisible.

[08:44] So functional programming forces that to become visible. It forces it into the open, and by the act of forcing it into the open, that strongly encourages a style of programming in which you don’t have such interactions because they are painful to manage. So it encourages a style in which programs execute in modular boxes without interacting. Now, every imperative programmer would want to do that, but I want them to do that in a provably secure way so you can know that these programs don’t interact, rather than just say I’ve done my best.

09:18 — Downsides of functional programming

Ryan:

[09:18] Then I guess on the flip side, what are the downsides of a functional programming language?

Simon:

[09:25] Oh, well, it can be very tiresome and inconvenient, right? So you’re somewhere deep in the, you know, a subroutine of a subroutine of a subroutine of a software stack, and you want to reach out and, I don’t know, grab the time of day. Oh dear, that’s a side effect. But we’re in a pure functional language, the time of day. And indeed there’s a good reason, because everybody else higher in the stack is assuming that if I call this function, apply to, you know, seven, it will give me the same answer if I call it again, apply to seven.

[09:56] But if it could interrogate the time of day, certainly it might give a different answer, right? So a simple thing as I was asking for, the time of day, invalidates a whole set of assumptions and so is not by default allowed at all. And that can be inconvenient because all you say, look guys, all I want to do is get hold of the time of day. Don’t give me grief. And so every functional programming language, including Haskell, provides you with a little trapdoor.

[10:21] Haskell‘s is called unsafePerformIO, and it says, trust me, I’m going to do something that has side effects, but you can pretend there weren’t any. All right, so it’s called, it is literally spelled unsafePerformIO, with a long name that has unsafe in the title, so that you, the programmer, are taking on the obligation to make sure that what you’re doing is okay. Whereas in imperative language, everything you do could be unsafePerformIO-ish.

10:53 — Specialized hardware for functional programming

Ryan:

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

Simon:

[11:20] Well, I did. I now think it’s probably a bad idea. But back in 19, when was John Backus’s Turing Award lecture? I think it was 1978 or thereabout. What was it called?

Ryan:

[11:34] Can Programming Be Liberated from the von Neumann Style?

Simon:

[11:38] That’s it. Now he was saying two things. Firstly, the designer of Fortran, a quintessentially imperative language, was saying, guys, we should do functional programming. That was what the talk was about. And he introduced a language called FP for functional programming. It was a very particular, somewhat idiosyncratic functional programming language. But there it was. So that was rather amazing, right?

[12:06] This was 1977. He was saying, guys, give up on imperative programming. Just do functional programming. Here’s how you do it. But he also said in the same lecture, we might imagine designing new hardware to execute this new kind of language. So if you like, we’ve got Turing machines, they give rise to register machines and microprocessors and so forth. Maybe lambda calculus. Perhaps if we designed a machine from the ground up to do lambda calculus, it would look different.

[12:37] So that was, of course, very exciting. And similar kind of thinking led to an actual commercial machine called a Lisp machine. That was a piece of hardware that was designed by Symbolics to execute Lisp programs. Lisp is a mostly functional programming language. And so, at the time, I was in my early 20s. We were thinking, oh crumbs. What would a piece of hardware look like that was primarily designed to execute functional programs?

[13:06] Would it have a different kind of instruction set and architecture? So the nearest we got to it actually was, although there was a big strand of work then that was called the MIT Dataflow project. So dataflow languages, functional languages, they’re definitely the same kind of category, right? And so MIT had this great group led by Arvind called the MIT Dataflow Group. And they designed, in the end, a machine called Monsoon that was specifically designed to execute dataflow programs, that is, functional programs.

[13:39] It was based on a token store and matching, and tokens flowing around and getting matched up and executing. You might imagine data flowing, going through a graph, when 3 arrives at a plus node and 4 arrives at the other input of the plus node. Bam. You could fire that plus node, right? And the hardware did all of that. At a similar kind of time in England, my colleagues Thomas Clark, Joe Stoy, and others built something called the SKI machine, SKIM.

[14:07] There’s a paper about this in the FPCA conference. And SKIM was designed to execute SK combinators. So at the time, David Turner’s written a lovely paper in which he described how to take lambda calculus programs and translate them into SK combinators. So you can read about that in my book. It’s a very simple translation. You can give the whole translation in half a dozen lines, but then you have this mess of S’s and K’s, and S and K reduction is very, very easy.

[14:40] So it’s like the machine code of functional programs.

Ryan:

[14:45] What is a SK combinator? Just for context, there are three combinators,

Simon:

[14:50] S, K, and I, and they have simple reduction rules. Here they are: I of X equals X, KXY equals X, S X, Y, Z is X of Z applied to Y of Z. End of story. That’s all so very simple, right? So now all I’ve got to do is take my lambda, translate it into a giant tree of SK combinators, right? S applied to K applied to I of 3 and S of Z of just a huge tree of S’s and K’s, right? Now simply apply the rewrite rules I gave you, and that is program execution.

[15:25] It’s rather astonishing that that can execute arbitrarily complicated programs, but it can. Don’t you think that’s rather amazing? Now, I can take an arbitrary Haskell program and could translate it into lambda terms, and I could translate those lambda terms into S and K. Very simple transformation. And I can just write those, run those three rules, and it’ll produce the output of the Haskell program.

[15:47] That’s pretty amazing. And indeed, there is an implementation of Haskell that uses exactly this. It’s called MicroHs, and my colleague Lennart Augustsson has built it. And its execution mechanism is SK combinator reduction. And if you sit in MicroHs, you can ask it to show you the S’s and K’s that it produces. If we had a shared screen, I could probably show you. So, long story short, then the SKI machine was designed to take SK trees, big trees of S’s and K combinators, and just execute them directly.

[16:21] So it was built in hardware and it ran perfectly well, reasonably fast. Now, why didn’t this catch on? Why don’t we have functional programming machines? I mean, at the time it was a big idea. We even had a conference called Functional Programming and Computer Architecture. FPCA was right there in the title of the conference. But slowly we became aware that what was really happening is we were doing at runtime what we could do instead at compile time.

[16:53] And that is always a bad idea. Imagine an interpreter for, I don’t know, Pascal or something, or for Java. We can compile Java to bytecode and we could interpret the bytecode, right? So then we’re doing something at runtime. At runtime, the interpreter is looking at the bytecode, saying, dispatching to say which instruction, blah, blah, blah, right? Now what does JIT do? It takes a sequence of bytecode and says, oh no, no, I’m going to take that sequence of bytecode and compile it to a sequence of machine instructions that, when executed, will do the same thing much faster because it can take advantage of bytecode sequences, for example, to say if you swap and then swap, it’s a no-op or something like that.

[17:44] So what, in fact, it turned out is this whole SKI business, and any other, and indeed dataflow machines also were simply doing at runtime what you could do better at compile time. We were building an interpreter in hardware. So don’t build the interpreter in hardware. Instead, build a compiler that translates your lambda term into a sequence of machine instructions that, when executed, will behave as if you had done this reduction business.

[18:15] And then you might think, well, machine instructions for what machine? Well, from a practical point of view, it was very hard to compete with Intel, right? They were just spending bazillions of man years on making x86 go faster, and Arm likewise. So we can leverage all of that work by compiling into their instruction set. But even if you say you are God, you are the chief executive in Intel and can tell them to add new instructions or computation mechanisms to support functional programming.

[18:48] What would you add? Not very much. Little bits to do with garbage collection, barriers, I think, and such like, but nothing major. So, in other words, I think the whole build hardware to execute functional programming directly thing turned out to be a mistake. Inspiring mistake, fun mistake. I had a great time. But a mistake. It’s better to build a compiler.

Ryan:

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

Simon:

[19:40] And indeed, that was the dataflow machine. The MIT Dataflow machine was all based on that idea. So you throw the whole graph into the token store and just run all the nodes that are runnable.

[19:51] But that’s incredibly fine grained. You’ve got to imagine this big tree of a million nodes, and your processor is sort of wandering around over it, doing little things in parallel. There’s a lot of memory traffic going on there. And if these little threads are operating on the same bit of tree, then there’s synchronization costs. So very, very fine grained parallel computation like this turns out to be impractical, or not impractical.

[20:18] You could do it, but it’s very slow. So the dataflow people, their history, if you look at the history of the MIT Dataflow project, they started with micro parallelism. Every individual instruction was a separate parallel computation that might take place, and the token store would match it up. And then they built more and more compiler technology that grouped these things together into larger units.

[20:42] So they expanded from micro threads of single instruction threads into 10 instruction threads or 100 instruction threads. Right. But even that never really caught on. So you’re right though, that if I say in a Haskell program E1 plus E2, then I can do E1 and E2 in parallel. And GHC does support you in doing that. But nowadays, rather than expecting the compiler to do that automatically for every subexpression, you can spark a computation. You say E1 par E2, and that says do E1 and E2 in parallel.

[21:17] There’s a project at Carnegie Mellon for a strict power, a strict language called ML that has a very good variant of Parallel ML going in a similar way. So essentially, we’ve moved away from the dream of automatically getting parallel, very, very fine grain to the programmer. We give the programmer clues about where it’s a good idea to do parallelism, and still the compiler will try not to fork two tiny grains.

21:47 — Haskell is useless

Ryan:

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

[22:26] And then you’re placing programming languages on this two-dimensional graph. And I think you started by putting C as very useful, but it’s incredibly dangerous. And then you put Haskell on the polar opposite side. You said it’s useless, but it’s very safe. What are the least safe and most useful languages? And why do you place them there? C, for instance.

Simon:

[22:52] Well, yeah, so let’s see. In C, you program by mutation. So it’s unsafe in the sense that any function can mutate any variable at any time. It has a lot. You pass pointers around a lot, and functions mutate the memory pointed to by those pointers. And moreover, typically they can mutate it anywhere. There’s no array bounds checks or anything. So it’s kind of like super unsafe. And in fact, and this is demonstrated by the fact, can you imagine all of these exploits that we get every day, right, that Mythos is discovering in huge numbers?

[23:24] But why is the Internet so insecure? Primarily because all of our software infrastructure is written in unsafe languages. If we’d written all of our Internet software and operating systems in Haskell or maybe in OCaml or ML, 99% of all these exploits would be removed by construction. It’s like we’ve built a boat out of paperclips and we’re surprised that it’s leaky.

[23:55] I mean, you shouldn’t build boats out of paperclips, right, because they have holes in them. You should build it out of a secure substance, right? But then it’s too late. So we spend incredible amounts of human ingenuity and effort patching the holes in our boat built of paperclips. It’s tragic. It’s tragic how much effort and ingenuity and money has been lost and waste of resources just because we wrote our computational infrastructure for the world in an insecure language.

[24:25] That’s what I mean by unsafe.

Ryan:

[24:27] I mean, are there not vulnerabilities? If I wrote something in Haskell, there’s gotta be some new type of.

Simon:

[24:34] Of course there are vulnerabilities. I just said 99%, I didn’t say 100. If I write a Haskell program that says receive message, if the message says tell me everything, then spit out my entire database in reply, no language can stop you doing that, right? But if you look at the program and it doesn’t have any such things, right? So, I mean, nothing can prevent you against high-level attacks to insecure programs.

[25:03] Or, I mean, another example might be deadlock, right? Services, no matter how securely written. If A waits for B and B waits for A, deadlock. Sorry, no. And no language is going to stop you doing that. You might hope for some high-level verification tools, but it’s like surely if you’re trying to do something hard, like prove that that doesn’t happen, you want to have a foundation that is, you know, in which you’ve got some bedrock to stand on.

[25:34] If you’re standing on sand and trying to prove some advanced property, it’s very, very difficult. But good point. I’m not talking about 100% security. Absolutely not. But how many exploits are based on buffer overruns or pointer manipulation that’s gone wrong? If you couldn’t have a buffer overrun, you couldn’t do pointer manipulation gone wrong. Those bars just wouldn’t exist.

25:59 — Rust vs C

Ryan:

[25:59] So, I mean, C’s maybe half a century old now. What about more modern versions of those lower-level languages like Rust?

Simon:

[26:09] Much, much better. Much, much, much better. Right. If we rewrote all of our software infrastructure in Rust, things would be way, way better. I’m not actually even sure whether Rust has array bounds checks built in, but suppose. But it must have the ability to promise that you’re not indexing out of bounds. I don’t quite know quite now, but if you compile all your code with that switched on, you are in a way better situation, way better.

[26:37] So yes, this is not just functional programming. But you did ask about why I thought C was an insecure, unsafe language.

Ryan:

[26:44] If we imagine that graph, there’s the upper right quadrant, which is useful and safe, and you described that as nirvana in the video. And I guess maybe over time, I mean, C is somewhat really unsafe, really useful, yes.

Simon:

[27:01] So C, Rust has moved along the axis from useful but very unsafe to stay useful and become safer. Now, Haskell started life as being very safe but useless. So it’s worth just rehearsing that because in the first version of Haskell there was no I/O. The only Haskell program was a function of type string to string. It’s functional programming, after all; it could do I/O. All it could do was take a string and produce a string.

[27:31] So obviously that’s not very useful. It’s a little bit more useful. A language that is very, very safe and completely useless is no-op, that does nothing ever, very safe, but very useful. Haskell was a bit better, right? At least it lets you apply a function to a string and get back another string. So, of course, we then worked on how could we do I/O in Haskell in a safe way that will lead to monads and stuff, but just as the, you know, we’re moving from C horizontally to go safer and safer, but staying useful.

[28:09] So from Haskell, we’re moving sort of vertically to get more and more useful without stopping being safe. And nirvana is when we sort of meet up, right? But the point is not to say one is better than the other, but just to say that we both seek things that are useful and safe.

28:26 — Haskell vs OCaml

Ryan:

[28:26] When I think of functional languages, I guess in the mainstream, or what people are kind of thinking about, I hear Haskell. I also hear OCaml. How do these two programming languages compare if someone was trying to pick a functional language to work with?

Simon:

[28:41] So OCaml is a strict language that is called by value. So when you say F applied to 3, 4, it’ll add 3 plus 4 and then call F to get 7, right? In Haskell, if you say F of 3, 4, it’ll build a little suspension that says, well, if you ever need this three, four, you can evaluate it, but maybe you’ll never need it. And then it calls F. That’s a lazy language. So because OCaml is strict, it has a defined order of evaluation.

[29:11] So if you say F of 3, 4 and a second parameter, 8, 9, it’ll evaluate 3 plus 4 and then 8 plus 9 in that order. So it makes sense to say you can say F of print hello, print goodbye, right? Because you get hello and then goodbye printed. So once you have a defined order of evaluation, then it’s pretty easy to incorporate I/O, right? Even though it’s, quote, a functional language, OCaml allows you to do I/O without saying unsafePerformIO or anything.

[29:47] In fact, it has a defined order of evaluation, and it’s perfectly kosher to do that as a sort of unintended consequence of being called by value. It was also, by default, impure. Now, good OCaml programmers won’t use many side effects, but OCaml doesn’t prevent you. Haskell prevents you. Why does it prevent you? Because if we’d allowed you to say F of print hello, comma, print goodbye, those would be thunks, right?

[30:18] Not yet evaluated. Right. So if F happened to evaluate its first argument and then its second, we’d print hello and then goodbye. If it evaluated its second and then its first, we’d print goodbye and then hello. If it didn’t evaluate either, we wouldn’t print either of them. That doesn’t sound very good if you want to control what I/O is happening. Laziness forced Haskell to stay pure. Strictness allowed OCaml, which grew out of the ML tradition, by the way.

[30:45] ML is another functional language that predated Haskell. It was always strict, and it always had I/O by default. It wasn’t a goal. But that’s just the way it worked out at the time. Nobody thought about it. It was just obvious.

So that’s a big difference between OCaml and Haskell, right? Is that now, then, since then, they’ve both grown up. Haskell‘s gained sort of monads. OCaml’s gained lots of fancy type systems.

[31:13] Some of them look at how Haskell and OCaml have learned from each other. OCaml has got an interesting effect system recently and a whole lot of new extensions. It’s an absolute hotbed of innovation at the moment. OCaml. So I view OCaml and Haskell as kind of siblings. Brothers and sisters, right? We love each other, we learn from each other, we compete with each other, all of the things that siblings do, but they’re not the same, right?

[31:37] So siblings don’t say, I’m just better than you. You shouldn’t exist. We say, let’s enjoy our life together. And that’s what it is. That’s the way it is.

Ryan:

[31:44] You describe the laziness and the strict. And as a programmer, my initial thought is I would like to control the order of execution, and when I say print X and then print Y, I want it to happen that order. Otherwise it would be a little unintuitive. What is the main benefit of laziness?

Simon:

[32:05] Why is laziness good? Well, John Hughes did this rather well way back, in 1980-something. He wrote a paper called Why Functional Programming Matters. And one of its main theses was that lazy evaluation lets you compose programs in a particularly modular way. So imagine a program that is, I mean, his classic example is a program that plays chess, right? So one thing you could do is you could imagine building a tree of all possible moves, starting from the position we’re at.

[32:38] It would be a very, very big tree. It would be too big, because first of all I compute the tree and then I’d start deciding what move to do. It couldn’t possibly do that because the tree of all possible moves has more nodes in it than the number of protons in the universe. So let’s not do that. Now, if instead you could build the tree, having got this tree, supposing you had it, you could then walk over the tree saying, ah, let me do some minimaxing, and seeing, oh, this looks like a good position.

[33:06] Let me go this way. I could explore the tree right now, then. So in OCaml, then you would have to put the tree generation and the tree exploration in one function, right? In Haskell, with lazy evaluation, you can generate an infinite tree, and then the explorer that prunes the tree and explores just the bits of it that are necessary is completely modularly separated. I can build a different generator and a different pruner.

[33:36] They’re just completely separate programs. So lazy evaluation is very powerful glue that lets you glue together two programs that you’d like to be distinct. Strict evaluation forces you to merge them together.

Ryan:

[33:53] Yeah, this reminds me, so in Python, for instance, they have the idea of a generator where you could lazily retrieve things.

Simon:

[34:01] Every strict language, every serious strict language has lazy evaluation in it. They’re called iterators or generators, and so does OCaml. All right, but in Haskell, that’s the default. Now instead, in Haskell, so this is a bit like, again, the two are converging on the middle, right? Haskell, lazy by default. But you can make things strict. You can put in exclamation marks to say, please evaluate this before the call, right?

[34:29] Or the IO monad to say value. But that’s a more brutal strict annotation. So in Haskell, you can make things stricter. In OCaml, you can make things lazier. So it really boils down to what’s the default? We both want to have a mixture of the two. And then it becomes a bit cultural. As to which you prefer, I don’t know. Some people sometimes ask me. They say, well, well, if you were designing Haskell again, would you make it strict by default with really good support for laziness?

[35:02] And I often say, well, I might. Yeah, that does seem attractive because frequently I found myself cursing laziness as an implementer. But I strongly suspect that 10 years after that I’d be thinking, man, if only it was lazy by default. Oh, when I said strict by default, I would definitely mean strict, but pure, right, no side effects.

35:26 — Side effects in Haskell

Ryan:

[35:26] A few times in our conversation, you’ve mentioned the word monad, and it seems like it allows us to do the side effects. And what is a monad? And how does it help us do side effects and preserve ordering?

Simon:

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

[36:23] So print 3 has type IO unit. It does some I/O, namely printing 3. GetChar has type IO Char. It does some I/O, namely reading a character from standard input and returns a character. All right? Notice that’s different from just Char. So quotes x quote has type Char. It’s just the character pure, right? GetChar, the I/O-performing operation, has type IO Char. It does some input output and returns a character.

[37:03] Okay, the do notation lets you combine together I/O performing computations. So if you could say do and then you say x left arrow getchar; putchar x, then that x left arrow getchar says run the getchar computation and get me the character. Call it x. The putchar x says run the putchar computation to put x, and we combine them together with the do notation that combines two computations to make one I/O performing computation.

[37:45] But these things are completely first class. That’s what’s new about monads compared to just make it into C. x left arrow, getchar semicolon, putchar x. That’s a computation whose type is I/O unit. Let me give it a name, so I can say let foo. We type I/O unit equals that do. Now I can pass foo as an argument to something. I could put foo in a data structure. I could return foo as a result; it’s a value just as much as three or plus in particular.

[38:21] For example, I could say do foo, foo that takes foo, uses it twice each time. Do foo; semicolon, foo says do foo and then do foo again, right? So I’ll read a character and print it, and then read a character and print it again. So these values of type I/O for some type T are first class values, right? In C, I can’t take X colon equals 3 semicolon, you know, Y plus 4 and pass that as an argument to something and expect it to happen wherever it’s used, right?

[39:01] It’s not a first-class value.

Ryan:

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

Simon:

[39:26] Oh, because. Because we are lying. But look, if your function has type int to int, can it do any I/O? No, no. If it has type int to I/O int, it could do arbitrary I/O. So yes, so it’s nice. Pure int to int function or dirty int to int function. So you may say, perhaps you’re about to say, that’s a bit of a blunt instrument. Either completely pure or completely dirty. Right. It gets you an awfully long way.

[40:02] But nevertheless, it would be cool if you could say, oh, I am effectful, doing reading of files only. Right. So, in the type, you’d like to say, what kind of effects can it have? Can it throw exceptions? Can it spawn new threads? So you’d like to enumerate the effects this computation could have. Right. That would be cool. That’s called an effect system. And there’s a bazillion programming language papers about effect systems.

[40:44] And it turns out that you can indeed, in the type system of Haskell, and indeed OCaml is rapidly becoming the same. You can express not just all or nothing, does it do I/O, game over, but rather which particular effects does it do, including no effects at all? That’s pure. Right. A good place to start is a library called Bluefin, which my colleague Tom Ellis has designed. It’s a very nice take on how to do effect systems in Haskell.

Ryan:

[41:17] I guess the purity comes from that. This dirty stuff is signaled through the type system.

Simon:

[41:25] Correct?

Ryan:

[41:26] Okay, so we can do it. But here it is. And be aware.

Simon:

[41:31] Yeah, and because you have to thread, you know, because the type system gets in your face, you were trying to map, say, no, map says I apply a function to every element of the list. Well, so it has type A to B to list of A to list of B. If you want to apply an I/O performing function, so the function you’re applying has type like int to I/O of character, you could map that over a list, but you just get a list of I/O of chars that hasn’t done any I/O yet.

[42:03] Right. You want something that says, take a list of IO chars and perform those actions one at a time. So I want a function that goes from type list of IO char to IO of list, and you might want to perform all those actions top to bottom, or maybe bottom to top, who knows? That’s what this function of type. Yes. So you could do it in various ways. So sometimes it gets in the way. Right. You say, oh, shit, can’t I just use Map?

[42:34] Well, in Haskell, no, sorry, you’re going to have to do a little bit more work to tell me in what sequence you want your effects to happen. Because by default, Haskell does not specify sequence. So, adding monads to control effects does get in your face a bit. And that’s the tax we pay. In effect, that’s part of the big experiment that Haskell is doing: to say, suppose we upfront say we’re willing to pay that tax.

[43:04] How many followers can we get? And the more. But I will note that monads have infected quite a lot of other languages. Like F# is definitely a call-by-value impure language. And yet F# had these workflows that were definitely monad. And monads have appeared in Scala and in many other languages. So something that’s very monad-like has appeared lots elsewhere. It’s been a very unifying concept.

44:26 — Type systems

Ryan:

[44:26] And so I kind of want to ask you, maybe just even on the highest level, what is a type system, in your words?

Simon:

[44:35] Okay, so what does a type system do? It lets you reject silly programs upfront. So if I have a function that adds one to things and I apply it to a character or to an I/O computation, that’s going to fail at runtime, right? Because I can’t add one to a character. Or maybe you overload plus. Maybe I reverse a list or something. If I’ve got a list reverse function, and I give it something that just isn’t a list, then it’s a bit silly to allow that and only fail at runtime.

[45:13] So fundamentally, type systems are about rejecting at compile time programs that you do not want to run because they will fail at runtime. Okay, now, we’ve had static type systems for a long time, going back to Pascal and earlier. But simple type systems are annoying because they get in the way. Imagine a function that reverses a list. In Pascal, you could write a function that reverses a list of integers.

[45:46] But if you wanted to reverse a list of characters, sorry, you can’t. That function that reverses a list of integers, it has type list event to list event, so you can’t apply it to a list of characters. Game over. You have to write another copy of the code with a different type. That’s a bit annoying. So what are we going to do? We need polymorphism. We need a more powerful type system. We want to give reverse the type for all a list of A to list of A.

[46:18] So that upfront says, I work for any type A. You give me a list of integers. Fine, I’ll produce a list of integers. You give me a list of characters. Fine, I’ll produce a list of characters. Notice that’s much better than just list to list. I want to keep the fact there’s a list of integers so I know if I apply, when I look inside the list, I know I’ve got an integer. But also if I just list the list, I might get back a list of some completely different type.

[46:43] But I know that reverse returns a list with the same type of things, right? So parametric polymorphism, super valuable, right? If you want a size of type system, it must have parametric polymorphism. The message is, if your type system is too simple, it gets in the way. Very important lesson, because it means that we cannot really say a type system is useful or not unless we say which one, because we know that weak type systems are very inconvenient.

[47:16] It must at least have parametric polymorphism. And that is another idea that was born in the world of functional programming. It was born in ML, incidentally, Robin Milner’s famous dictum: well-typed programs don’t go wrong. ML was the first, I think, the first parametrically polymorphic functional programming language. But generics in Java and object-oriented programming more generally is exactly the same idea, right?

Ryan:

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

Simon:

[48:03] Yeah, okay, but so now you’re into a whole more complicated world, right? So as soon as you say class, you’re talking static type system again, right? So object-oriented programming is another approach to polymorphism. So in an object-oriented language, we say if we have a Ford that is a car and a car is a vehicle, then anything that works on vehicles should also work on cars and should also work on Fords.

[48:32] So the code that we write for cars works unchanged for vehicles and for Fords. Okay? Now that’s a form of polymorphism, not parametric polymorphism. That’s what you might call object-oriented polymorphism or subtype polymorphism. Okay, so now we have polymorphism in the sense that the same code, the same executable code, actually the same machine instructions work on values of different types. Okay. In both cases, both reversal lists, same machine instructions.

[49:08] Code that works on vehicles works on things on Ford. Same machine instructions, right. Okay. That’s what polymorphism in general means. Parametric polymorphism means this for all. A list of a to list of a stuff. Subtype polymorphism means if it works on vehicles, it works on any subtype of vehicles. Okay? Now the interaction of the two, which you get by adding generics to an object-oriented language, is pretty complicated.

[49:36] Oh, and by the way, adding side effects as well. And so your question involving classes and superclasses and so forth is smack in that complicated world. I’m not sure it’ll be very fruitful for us to get a lot more details of the type system sorted out to know what to say. But at this very high-level overview, the big point I’m trying to make is weak type systems get in the way.

[50:04] Type systems are meant to reject programs that will go wrong. But my function that reverses a list of integers, it will also reverse the list of characters. So it’s tiresome to be told, no, that is a bad program. I want to be able to write that it has type, for all a, list of a to list of a. So the idea of making the type system more complicated is to say programs that you want to run, you can still write in your static type system.

[50:29] Now you might say, well, blimey, if that’s all, why don’t we just get rid of the static type system altogether? Now we could run all of those programs, but the trouble is, you can run too many programs now. You can run programs that will crash at runtime, and that’s very, very, very bad. And we all know the costs of programs that crash in deployment, that you could have crashed before you even started to run them, before you even ran your first test, right before you even linked it into an executable.

[51:00] That’s really good. But the biggest benefit of a static type system, in my humble opinion, is maintainability. If you have a program written in, I don’t know, Perl or Ruby or Lisp in its basic form, and it was written 15 years ago and the original author has left, and all of the people who were involved at the time it was written have left, then that program is very difficult to maintain, and it becomes almost immutable.

[51:31] Nobody dares change it anymore. What they do is, it’s an immutable piece of software, and you do stuff around the edges to impedance match what you really want to do to this now immutable blob. Now of course you have lots of tests, so test-driven development, I’m totally with it, I’ll develop all of that. But still, GHC, for example, is itself written in Haskell. It’s 35 years old, and yet I do large-scale systematic refactorings of it fearlessly because the type system keeps me safe.

[52:02] In fact, often what I’ll do is I’ll change a few types and then start compiling, and then a sort of wave of changes propagate through, forced by—I just get type errors. So I know what to do. The thought was that I’ve changed the representation of this data structure a little bit. I’ve added a field to this data structure. Where in the entire compiler might that field be read, written, or freshly allocated?

[52:27] I can’t imagine how anybody maintains 30-year-old software and makes large-scale changes like that. Without a type system, it’s unimaginable. So for me, the benefit of type systems is maintainability. Oh, and designability. Right. So I often write the types of my programs up front. The data types are super perspicuous. Novices say it’s a bit like writing the classes of an object-oriented language, right?

[52:55] But if you have no types, no classes, nothing, just I don’t know, S expressions, types are my design language. They’re the way that I start writing my designs.

Ryan:

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

Simon:

[53:34] Just use stronger, I think there’s no benefit to weaker.

Ryan:

[53:39] Just off the top of my head, one thing I think of is there is a set of programs that will work but don’t satisfy the type system.

Simon:

[53:49] Oh, yeah, that’s why.

Ryan:

[53:51] But those are. I mean, I don’t know if they’re good. That’s subjective.

Simon:

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

[54:32] Okay? Parametric polymorphism is a big step in that direction. Other type system innovations are a big step in that direction. But there will always be some programs that would run perfectly well that the type system rejects. Imagine a tree that contains integers at every node. But if you are 17 deep in the tree, or 34 or 51, if you’re in a multiple of 17 deep, the integers can be characters instead, or the integers all turn out to be characters, right?

[55:17] Now, you could write a program that generated such trees, and you could write a program that consumed such trees, knowing that every 17th layer we switched characters. But most static type systems would make it pretty hard for you to accept that program. And yet it will run. Now you might say, “Oh, but I really want to write that program, guys. Don’t get in my way.” Well, then we should provide a way for you to bail out into dynamic typing, right?

[55:49] What I’d like to do is say, okay, so if all else fails, then at least you can, as it were, pair up a value with its type representation. There’s one reason we don’t want to interpret an integer as a double precision float, for example, is that they don’t even have the same representation, which is just nonsense. One possible way untyped languages let you do this is to tag every integer and every double precision float.

[56:14] With the fact I’m an integer, I’m a double precision float. But that has a lot of overhead. So one merit, I think it’s not the biggest single merit, but it’s a major merit of static type systems is you have no tags. You know that if it says it’s an integer, it’s going to be an integer. You know that if it’s a double precision float, it’s going to be a double precision float, right? But if you’re not sure, maybe we could make a way to make a pair of a type representation.

[56:42] And this value, the type representation, is now like a runtime tag. It’s like a little runtime data structure that describes the type. And then in your program you could say, now I want to say, oh, I’ve got this type dynamic. We’ll call this pair a value of type dynamic. Now when I want to take a value of type dynamic and treat it as a character, I want to say, ah, look, look at the type dynamic.

[57:04] See if it says it’s a character. If it is, return the character. If not, crash.

Ryan:

[57:08] Right?

Simon:

[57:08] Runtime failure. That’s fine, you can do that. So Haskell has good support for dynamic typing where necessary. So my story would be static typing should expand to carry as much as possible, and where you absolutely cannot do it, sorry, then use dynamic typing. And we provide facilities to support that.

57:30 — How the Haskell compiler works

Ryan:

[57:30] One thing I wanted to talk with you about is the compiler. How does GHC work on a high level?

Simon:

[57:37] So GHC takes a string like any other compiler. The source code of the program parses it, and then it type-checks, it figures out, is this a type-correct program? Then it converts it to lambda calculus. Now Haskell, the Haskell AST, the original source tree, has 50 different data types, 50 different kinds of nodes, some of which have 30 or 40 different variants. So it’s a really big, diverse, complicated data structure.

[58:15] The AST lambda calculus has this variant of the lambda calculus. It has eight WANDA data, maybe two or three data with eight constructors. So it’s like taking a gigantic language and squeezing it down into a tiny one. And that tiny one we can then optimize, right? That’s what the optimizer works on. So the front end does parse, rename, type check, desugar into lambda calculus. That’s the front end. The lambda calculus particular language is called GHC Core language.

[58:52] I’m quite proud of it because it’s been very, very stable. It’s 35 years old, and it has barely changed since birth. That’s amazing, right? Because Haskell has changed a lot. A lot. So almost all of the innovation in Haskell has been in the front end. Very little in core. Now the back end, the core optimizer, has changed a lot too. But all of the changes that were useful there would have been useful 30 years ago.

[59:25] Right. So they’re two completely separable things. So I’m quite proud about that. Core then. We do a lot of core-to-core passes that simply take core programs. We’ll use core programs, lots and lots, long pipeline. Then we convert it to C, which is a prototypical imperative language. Think of it as a portable assembly code. So that bit is meant to be platform independent. So it’s simply. That’s the compiler that takes.

[59:54] Remember I said if you take lambda calculus and compile it, that’s that step. Right. I want to compile the lambda calculus into machine instructions, really. But I don’t really mean machine, I mean portable machine instructions. That’s called C. Then I want to convert C into actual machine instructions for various platforms. And there we could either do that directly with the native code backend or go via LLVM.

Ryan:

[01:00:18] Interesting. I’ve never heard of C. Why not just go directly to it? I would have thought maybe assembly or something like that.

Simon:

[01:00:25] Well, because. What happens in assembly? In which processor? Please?

Ryan:

[01:00:30] Oh, I see. I guess it’s the. I would have thought the lambda calculus part was already portable.

Simon:

[01:00:36] So you just. It is, yeah. You could go straight, but, but, but. So there’s work to go from lambda calculus. You could go all the way to x86, then throw all that away and now go from lambda calculus to PowerPC. Oh dear. I’ve just duplicated a lot of work by going from lambda calculus to C-- and then from C-- to x86, x C--. We’ve avoided duplicating the work that went from lambda calculus to C--.

[01:01:05] When you see that, it’s pretty obvious, isn’t it? You got to. You want to make the platform-specific bit as small as possible. You would like to have, as it were, a generic architecture, one that can do addition and has a program counter and a stack and so forth. That’s all C--. It’s just a portable assembly language. And then you say, oh, the nitty-gritty of whether you have double-precision add and set, the floating-point bit here and there, that.

[01:01:31] Well, that’s platform specific. The core is itself statically typed, but in some ways it’s surprising because no other compiler has this property. No other production compiler by core is statically typed. I don’t just mean that the initial program was type correct. I mean that a core program, you could run a type checker on that. I might say, why do you need to? Because after all, if GHC is correct, it started with a type correct core program because it came from a type correct Haskell program.

[01:01:57] Assuming the desugaring was right, and all the optimizations, if they’re right, will generate a type-correct Core program. So why do you need to type check Core to discover bugs in GHC? Now, these are serious bugs, right? If you ever take a type-correct Core program and an optimization pass produces a type-incorrect Core program, what will happen if we don’t have the type checker for Core? We’ll generate machine code, and we’ll run it, and we’ll get a segfault.

[01:02:29] Now we have to backtrack from a particular test program that now crashes all the way back up the pipeline. Up the pipeline, up the pipeline, up the pipeline. Oh, it was this pass of GHC that was faulty. That’s super hard to do because you’re getting out GDB on some runtime failure. That is an indirect and perhaps distant consequence of the fact you just generated a type. You just made a.

[01:02:56] You had a bug in the optimizer. So it is amazing to have a type checker for Core. Now, why does nobody else do this? Well, it’s because their intermediate language, typically, and this I really am talking typically, because I know of no other compiler that has this property, none. Production compiler, typically. Then they’re complex syntax trees decorated with all sorts of pragma information and things hanging onto it here and there.

[01:03:27] There’s no type checker for it at all, and there’s no hope of one. So I’m very proud of the fact that Core is statically typed. And I also think it’s a. The most delightful thing is that the way that it is statically typed, it is an implementation of something called System F. So System F, when I said lambda calculus, lambda calculus, as Alonzo Church had, it was untyped, had no type system at all.

[01:03:55] But Girard defines something called System F, which is a statically typed lambda calculus, a rather powerful one. And GHC Core is essentially System F. So he literally adopted something from the nerdy theoretical computer science, logic community, logic of mathematics community, and adopted it directly in a production implementation. So I’m very proud of that. I think GHC Core is. And the fact that we can do we have 35 years worth of development that has not just not been impeded, but actively aided by statically typed intermediate language is really a big marker in the ground.

01:04:35 — Why Haskell is talked about more than used

Ryan:

[01:04:35] Watching all your talks, reading everything, one of the interesting data points that you brought up was that Haskell is talked about more than used. When you compared Stack Overflow volume and actually GitHub volume, like who’s actually using the programming language, why do you think that is?

Simon:

[01:04:55] So Haskell embodies one key idea: immutability changes everything. There’s a quote from Pat Helland’s talk that I think you also looked at or read. So it says programming with values changes everything about the way you think about programming. It’s just mind changing. It’s not necessarily better, but it is different. And so Haskell takes that idea and runs with it. Everything is driven by that one idea.

[01:05:23] Everything else is incidental. In the early days, that meant we just said, well, guys, suck it up. We’ll keep changing the language, and if it breaks your program, too bad. So it is a bit peculiar and therefore also it felt a bit academic because initially it was really not very powerful. It was taking the key idea, but you couldn’t do very much with it. We talked about that. Right.

[01:05:44] So over time, GHC and Haskell in general has become more and more powerful. The type system has become less and less in your way and more and more useful. All the obstacles that make functional programming harder become better. The compiler generates faster code, it can browse faster and so forth. So it has become less peculiar. So we’ve become more and more taking into account the needs of our users.

[01:06:12] But in a way, the sort of cultural heritage is we never give up on the one core principle. We’re just not going to give you unrestricted side effects. Sorry, you want to say unsafePerformIO and put up with the consequences. So we’re going to stick to one core principle and then we’ll do lots of work around the edge to make that better. Right. So that does limit our community somewhat. Right?

[01:06:34] It does mean you really have to think in a different way. Immutability changes everything. That means you’d have to think a different way about programming. Maybe you don’t want to think in a different way. That’s fine. Then don’t use Haskell.

[01:06:44] So in a way, we started from a very small user community, a very sort of pure and nerdy one, and growing larger and larger. But all slowly, slowly, while all the time maintaining faithfulness to this core principle.

Ryan:

[01:06:58] I thought that was very unique about Haskell because I feel a lot of the other programming languages are user-centric. I mean, if people want something, they work on it, they add it, whereas Haskell feels more principled. Or it’s all starting from these ideas. And if you don’t satisfy these ideas as a user, yeah, well, that’s fine. For instance, in one of your talks, you mentioned somewhere that there was a release of the compiler where if a file wasn’t type-correct, then the compiler would delete the file.

Simon:

[01:07:37] Oh, wait, it reported the error message first.

Ryan:

[01:07:39] Yeah, it reports there. But I thought that was absurd. I mean, very hostile, I guess, to the. I mean, well, if you’re type safe, no problems. But.

Simon:

[01:07:49] Oh, it was a mistake, right? It was a bug; it wasn’t deliberate, and it only happened, you know, how did the bug get out? Because, of course, if it always did that, we’d have noticed. How did it get into a release? Well, it was because it was only on Windows and only when you compile a module that was not in the current directory. But at that stage, our users were very forgiving. And, you know, somebody wrote to us and said, well, by the way, Simon, you might like to know that, you know, GHC does this, but, hey, don’t worry about it, you know, I just copy all my files somewhere else before I compile and then I copy them back.

[01:08:21] So, of course, those days are long gone. We pay a lot more attention to our users and have much more rigorous CI testing than ever we did. Right. So that’s a story from a long time ago, but it’s a good cultural story because it suggests that we care about our users very much, but we care about users who want, in their hearts, want to be principled. We’re trying to appeal to. One of the things I like best about Haskell is people often say, I just enjoy writing Haskell.

[01:08:48] Right. It’s fun, right? My boss doesn’t allow me to because it somehow doesn’t fit with my production shop. But for me, I would go for it. I love writing this stuff. Every time. Every time. Yeah, that’s very rewarding to me.

01:09:07 — Avoiding success at all costs

Ryan:

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

Simon:

[01:09:21] Oh, yeah, this was just a little play on words. It was in a retrospective on Haskell. I gave an invited talk at POPL a long time ago, probably 20 years ago. So it’s a little play on words because you can read it as either avoid success at all costs. And that’s what we’ve been discussing. Success at all costs means compromise your principles in order to satisfy your users or think that you’re satisfying users, give them what they say they want, if we build it, they will come kind of deal.

[01:09:55] So avoid success at all costs. Or if you parenthesize it the other way, it says, avoid success at all costs, at all costs. Avoid success. And that’s saying, that’s a little joke. But it says if you’re too successful and have too many users, it becomes more difficult to make changes. And we experience that right now. So I devote many, many more of my personal cycles to backward compatibility issues than ever I did.

[01:10:28] I’ve devoted hundreds of hours and hours, well, days and days, weeks and weeks in the last year or two to the following: what seems to be a very simple property. If you can compile a program, a package, a whole program with GHC 10.0 and we release GHC 10.2, you should be able to compile that same package unchanged with GHC 10.2. Seems reasonable, right? After all, 10.2 should just be better. But no, GHC has never had that property, and making it have that property has turned out to be very, very time consuming.

[01:11:05] Previously we just never cared. Then we started to care, but thought it was a lot of work, and now we’re investing the work.

01:11:12 — LLMs and programming languages

Ryan:

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

Simon:

[01:11:34] I think it may be the best thing that’s happened to statically typed languages for a long time, because as we’ve been discussing with a static type system, you cut down the space of programs that the LLM can generate because it is perfectly capable of running the compiler and saying, “Oh darn, that was a bad program, better fix it,” right? So a zillion iterations get done behind the scenes, whereas in an untyped language, the first one it coughed up, you’d have had to run it against a test suite or who knows what, but it dramatically tightens up that cycle.

[01:12:11] Right. So I think that statically typed languages are a huge boon for LLMs because it’s too easy to. And programs are just strings, right? It could just generate the next plausible word.

Ryan:

[01:12:31] Away if there’s a slider on, I guess, the strength of a type system. And the other side of the week, what do you see as the absolute strongest type systems among programming languages?

Simon:

[01:12:43] Oh, Haskell. I think Haskell is exploring the bleeding edge. There is an exception, which is that module systems are a... And in particular, sort of functor-style module systems are explored much more deeply in the OCaml world and in the Haskell world. We’ve essentially never gone there. But otherwise, I think Haskell‘s right up there. Now, of course, a language like Scala is also as... So Scala has almost everything Haskell has, I think, not quite, but it also has subtyping and object orientation.

[01:13:24] So that’s a lot more complicated. A lot more complicated, I think. And they pay a price for it. I think Martin Odersky would agree that they pay a price for it. So in complexity, it’s probably more complicated than Haskell‘s, and maybe in terms of power. So maybe I should have said Haskell and Scala are the two leading Haskell, Scala, OCaml, perhaps I’ll just put them in an equivalence class for now.

[01:13:52] They’re not strictly comparable. They all have things which they’re more powerful than the others, probably.

01:13:57 — New programming language design

Ryan:

[01:13:57] What do you think are the important problems to solve in the future of programming languages today? What are the unsolved problems in the domain that are top of mind for you?

Simon:

[01:14:08] I think it’s actually hard to identify, to say, here’s a problem we want to solve, let’s try to solve it. Well, I think another way to tackle it is to say, what are interesting new languages out there that are exploring very different parts of the design space? And there I think I do have a candidate. So the language that is my day job. I work for Epic, and we’re designing a programming language called Verse.

[01:14:31] Now, Verse is a very exotic language. It’s really a functional logic language, so it’s yet more expressive than Haskell. It has a path-? type system, but a very different one to Haskell‘s. So if you like, the way I think of it is like this. If you look at C and Fortran, they look pretty different if you’re an imperative programmer. But if you look at them, if you zoom out still, you can see functional languages.

[01:14:56] Then C and Fortran are pretty close together, along with object-oriented languages. They’re all in a clump, right? And then there’s some functional languages, Haskell and ML. I know OCaml and Scala out here. If you zoom out still further, then the imperative languages and functional languages altogether, and Verse is way out here, right. So Verse is exploring a very new point in the design space.

[01:15:19] But just like functional programming back in 1980, it seems sufficiently interesting and cool and unusual and weird that it’s worth exploring. Right? So back in 1980, nobody would have said, we’re definitely going to do functional programming and it’s going to be useful for practical applications. They said, that’s pretty weird. By all means, give it a try, guys. And that’s kind of where I am with Verse.

[01:15:40] One difference is that back in 1980 we were purely academics, and now, Verse is being developed by Epic Games, so we got much more muscle behind it than was behind functional programming to begin with. So we’ll see. It’s a very interesting intellectual endeavor, adventure, I should say.

01:15:59 — Should students continue to learn programming

Ryan:

[01:15:59] Yeah. I think a lot of people, like students, are maybe worried about AI or studying computer science. Would you recommend people learn how to program today, given that AI is starting to write reasonable code now?

Simon:

[01:16:13] Oh, yeah, yeah. So I think people are right to be worried in the sense that I think there’s going to be considerable dislocation, right? Because if you were in the Industrial Revolution, then lots of people lost their jobs as spinners and weavers, and it wasn’t easy for them to get a new job in the new economy. Now, the new economy had, in the end, had more jobs, but there was.

[01:16:36] If you were one of the people who just lost their job, that was not a happy place to be. From our perspective, you know, from an Olympian perspective of a few hundred years later, we think, well, it’s just a blip, right? If you’re part of the blip, not a problem. So I think people are right to be worried. We don’t know how things will shake out. I’m actually optimistic that in the medium term, if we don’t destroy ourselves with some truly existential thing.

[01:17:00] But from an employment market point of view, I’m optimistic that in the end we’ll just be in a higher place, that AIs will just be a bigger power tool. I mean, everyone likes using compilers, right? We don’t like machine code anymore. Compilers make us more productive. Maybe LLMs can make us more productive. That’s what I hope. I sort of believe, modulo dislocation effects. Now, should we teach children or even undergraduates how to program?

[01:17:31] So I think still yes. And the reason is because one way to say it is copilots who need pilots. I think Copilot was quite a good title that Microsoft gave their tools because it encourages you to believe it’s your partner, not your boss. If LLMs spit out a pile of goop and we literally do not understand what it does, we just try it and it kind of works. That might be okay if we’re just throwing up a quick visualization.

[01:18:00] It might be less okay if the quick visualization is going to drive our policy choices about us a nation, whether to go into lockdown because of COVID or if this program is going to run my aeroplane or train signaling system. So now those are extreme ends of the spectrum from quick and dirty things. It really doesn’t matter if it doesn’t work, but it kind of does a lot of the time, absolutely fine too.

[01:18:27] This is a 30-year code base. It’s going to last a long time. I really want to make sure that it’s like putting new stuff into GHC. If somebody sends me a pile of AI-generated code to put into GHC, I’m not going to put it in unless I’ve reviewed it or somebody’s reviewed it. Because in 10 years’ time, I’m going to want to change that code. How do I even know what it does? If it’s simply a magic incantation that somebody’s done that kind of worked on the test they did, but maybe won’t work in deployment, that’s no good.

[01:18:51] So I really want long-lived, maintainable code to be well reviewed. Sorry. So. And to do that, I need reviewers who can write code, who know. Let me mention one other perspective. If you think about what every child should know. When I think about what every child should know about computing, I would include binary and bits, not, just as for physics, I would include atoms and molecules. Now it’s not that in real life anybody manipulates atoms or molecules or takes decisions which are based directly on their knowledge about knowledge, but somehow knowledge that all matter is made up of atoms, you know, constituted of a finite number of elements that atoms.

[01:19:38] That knowledge underpins everything we understand about the natural world. If you literally have never been told that, you are sort of emasculated as a citizen, let alone as a scientist. So if you literally do not know that everything is composed of bits, that words and music and text and LLMs and everything is all just bits, I think you’re crippled. So I want every child to learn, you know, it’s like I want you to learn the bottom.

[01:20:07] It’s all bits, nothing else. It’s all just bits. I even have a talk. The talk is called Bits with Soul. It’s so easy to grab for. It’s a talk I gave to an audience that was not a computer science audience at all. It was a completely lay audience ranging from 14-year-olds to professors of quantum mechanics. Pretty difficult audience to address. And it was meant to be about codes and coding and bits.

[01:20:33] So it tries to get at the essence of why I think it’s important that every child, every person, every human being should understand something about the computational universe that surrounds them and that is founded in bits. Now, just to develop the analogy a bit further, I would then say, and it also, I think, I want them to also know about programming programs. I want them to know that computers fundamentally execute by following machine instructions blindly.

[01:21:00] Right. That is not magic, it’s not hocus pocus, it’s just remorseless and very dumb. Right. It’s incredibly empowering then. And also to learn the basics about how neural networks work. In the same talk I explain how a one neuron neural network works, and that’s enough. Then it’s actually true to say, not distorting, but that’s to say ChatGPT is just a trillion of those wired together, and astonishingly, that very simple.

[01:21:32] So all ChatGPT is, is a trillion floating-point numbers and a lot of floating-point arithmetic. That helps you make sense of a question like, can ChatGPT have feelings? Well, it gives you, I mean, of course that’s a philosophical question, but it informs your discussion about if you know that all it is is trillion floats and a lot of floating-point arithmetic. That’s all, nothing more.

[01:22:02] Anyway, sorry, long answer to your question, but so I... So yes, basic programming, absolutely, yeah. Becoming fairly skilled in how to use, you know, Django framework, maybe not so much maybe. I think one thing that LLMs are very good at is knowing the arcane and complicated APIs that many of these frameworks present when there’s just 10,000 functions you’ve got to know.

01:22:33 — Why Excel is is 2nd favorite programming language

Ryan:

[01:22:33] You mentioned somewhere someone asked you, you know, what’s your favorite programming language? And obviously Haskell‘s got to be number one. Yeah, but for your second favorite programming language, you said it was Excel at that time. Why was Excel your favorite programming language?

Simon:

[01:22:49] Oh, because it’s the world’s most widely used functional programming language. The formula language is a functional language, isn’t it? Doesn’t have any side effects. You program entirely with values. So the formula language of Excel is a functional programming language, a very weak one. It doesn’t even let you define new functions. And it has a very limited collection of data types, namely just flat arrays and numbers and strings.

[01:23:17] So when I was working for Microsoft, I took it as my war cry to say, let’s take that idea. Excel is the world’s most widely used functional language by three orders of magnitude. And oh, it’s the most widely used programming language by three orders of magnitude, not just functional language. Excel is used by many, many more programmers, users, domain experts than any imperative language.

[01:23:51] Imperative language is a few million users. Excel, hundreds of millions of users. Even if you just restricted users who are using formulae. So how can we delight those users? Answer: take ideas from functional programming and use them to make Excel’s formula language more powerful. It took me 20 years, but Excel did finally add Lambda to Excel. Look it up, there are blog posts about it and many YouTube videos about it.

[01:24:25] So you can now program in Excel using full lambda as Alonzo Church originally defined it. You can write anything, because lambda is computationally complete. You can write any computation in Excel now. It would be a bit slow, but you can. And much more practically, you can take formulae that previously you just copy-pasted here and there and wanted to make reusable, wrap them up in a lambda, and now you can just call the lambda.

[01:24:53] And now it is a proper grown-up functional language that is Turing complete. Just search for Excel LAMBDA, those two keywords will get you lots of raw material.

01:25:04 — Advice for his younger self

Ryan:

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

Simon:

[01:25:15] All of these people who you see very successful wandering around, looking as if they’ve made it, I guess you might class me among them. Now, they are all just making it up as they go along. They feel insecure, uncertain, not sure what to do next, not sure what their next steps are, not sure what next big problem they’re going to tackle, unsure about whether what they’re doing is going to be successful or not.

[01:25:40] And so all of their confidence is, I mean, they project confidence. Maybe that’s partly a life skill, but often they’re not. And so the fact that, in those days, of course, I felt very not confident. I would say, since all of these successful people are making it up as they go along, it’s fine for you to be as well. And they’ve been lucky. Moreover, they’ve been lucky. They’ve had.

[01:26:08] But if you want to be lucky, you do need to put yourself in a position where accidents can happen to you, and that means taking risks. So if you want to be lucky, you need to put yourself in positions where lucky things could happen.

[01:26:28] And that means taking some kind of risk. So if you’re very conservative and never take any risk, then it’s very unlikely that the accident that is life transforming will happen. That’s a balance, of course. But it means that accidents are not so bad. And of course, dying is bad. But lots of accidents may change your life in a way that might be surprising to you, but turns out to be not so bad in retrospect.

Ryan:

[01:26:50] Awesome. Well, yeah. Thank you so much for your time. I really appreciate it, Professor Jones. We will.

Simon:

[01:26:54] Nice talking to you. Thanks, Ryan.

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

Timestamps

01:08 - P vs NP

14:51 - What if you relaxed correctness

25:38 - Why NP complete problems are equivalent

30:33 - Space vs time complexity

43:06 - Why people use SAT solvers

45:53 - Randomness is a resource

55:48 - Randomness depends on computational power

01:21:20 - Zero knowledge proofs and their significance

01:38:30 - Quantum computation and why it matters

01:56:24 - Math vs computer science

02:08:16 - Major breakthroughs and his experience

02:12:31 - Advice for his younger self

Transcript

01:08 — P vs NP

Avi:

[01:08] Well, in the simplest way, and I will talk at a high level, we are interested in various problems in life, in all sorts of problems: mathematical problems, scientific problems, medical problems, personal problems, intellectual problems. We are in the business, in computer science, of solving problems by computers. Now we would like to somehow classify those problems that we can solve, to know what we can know.

[01:43] The problems we can solve are the things we will know, we will understand. There are all these problems that we want to understand. There are many of them, and there are problems that we can understand but can’t solve. In a very basic way, the first class is NP. All the problems we want to solve are really NP problems. It’s a class of problems, and a subset of it is the problems we can solve.

[02:13] They are the problems we can currently solve, but we are interested in all the problems we can solve in principle. The question of P versus NP is whether we can solve all the problems we want to solve, whether we can know everything we want to know. This is basically about the limits of our knowledge. Of course, I have to justify why these classes, which are mathematically defined, are actually captured by the intuitive meanings I’m giving them.

[02:52] P is very easy to justify. What we can solve is what we can solve in our lifetime using whatever we have, let’s say all computers that we have using efficient algorithms. Problems we can solve are problems you see in our apps, in our phones. If there’s a navigation app, it means somebody invented an algorithm that’s efficient enough to solve any shortest path problem between any two places in any kind of map. All the problems we want to solve are NP problems.

[03:32] What is NP? NP is a class of problems in mathematical definition, problems such that we don’t know whether they are easy or hard to solve. But if somebody hands us a solution, then we can easily check that indeed it is a good solution. Now, why are all problems humanity is interested in of this nature? You can think there’s no limit to what we may want to know. But I claim that essentially, in any human endeavor, if you are embarking on any problem, if you really seriously want to solve a problem, the least you want to know is that when you hit upon a solution, you will recognize it as a solution.

[04:19] Why would you ever start looking for something if you will never recognize it as what you looked for? So you think mathematicians are looking for proofs of theorems? Certainly, if somebody gives a proof and writes a paper about it, we can verify it. If a scientist wants to explain data about the planets or about bacteria or whatever, they want to develop a theory. So that’s what you are searching for in this case.

[04:54] And yeah, again, scientists write papers about their theories. They have to be consistent with the data. We have a way of recognizing that this is a good solution. Engineers are usually tasked with creating something, like a bridge or a phone, under some constraints. It can be monetary constraints, physical constraints, all sorts of limitations, such as what you can use but not this, and so on.

[05:24] But anyway, if an engineer designs something, whoever gave them the task can look at it and say, “Well, you violated some constraints,” or “No, it’s good, you really delivered what we were looking for.” So I’m giving you examples. I mean, I can give many more. Detectives are supposed to solve crimes, and we know from detective books they eventually provide solutions. So these are examples of very fundamental human endeavors that encompass almost everything I can think of in all of them.

[05:58] What people are searching for has the property that when a solution is found, it is easily recognized. Repeating in the beginning, NP are all problems that we can honestly say we really want to solve. NP are those that we can solve. If they are equal, then everything we would want to know, a cure for cancer, anything you can imagine, can be just the very fact that a solution can be easily recognized, which would imply that it can be efficiently found.

[06:38] That means that we can know everything we ever want to know. It’s a fundamental question about human knowledge.

Ryan:

[06:44] So I know this is one of those Millennium Prize problems. There’s a million-dollar prize if you can provide a proof for this. I can imagine you could prove that they’re equivalent. You could also prove that they’re not. If you had to guess when and if a proof comes, which direction would your intuition say it goes? And why?

Avi:

[07:07] I think that my intuition, and that probably holds for almost all members of the theoretical computer science community, is that they are different. I think there are several reasons for that, and I will already tell you now that they are not that convincing. One is the intuition that most of us have that finding something is really hard and just checking that it’s there.

[07:37] If you lost your keys or your phone and have no idea where to look, but if somebody points out, “Oh, you left it on the windowsill,” you might say, “Ah, yeah, I did.” We have this experience from life that finding something is typically a harder task than just checking that it is what we look for. Another reason is that real NP problems occur all over the place. They occur in optimization, in logic, in other aspects, in mathematics, and in verifying that algorithms, protocols, and security systems actually work.

[08:22] All sorts of. In this generality, these optimization problems that are NP problems, maybe NP-hard problems, people try to solve for completely egocentric reasons to make their company richer. There are thousands of these, and they manifest themselves in many different forms. Over the last 50, 60, or 70 years, people have seriously looked for algorithms for these very different ones and couldn’t find any.

[09:02] This may seem like there’s no such solution. Getting a bit more technical, NP problems, NP-complete problems in particular, seem to require search over an exponentially large space, like all the possible solutions to some system of equations. Somehow, a solution is about having a general method for cutting down this exponentially large search space into searching over something much smaller in a clever way.

[09:48] And this should apply to all these problems. So that would be equal. And people don’t think that there is such a way. But as I said, these are intuitions that are maybe pretty strong. And I think that’s the only, tomorrow somebody finds an efficient algorithm for NP-complete problems using some new idea that nobody ever thought of.

Ryan:

[10:22] That would change the world. In software engineering, we use algorithms all the time, and they often have these very satisfying properties where the solution we use takes something where the brute force is much larger down to something that’s polynomial time or something very reasonable. But in all these NP problems, it’s pretty unsatisfying that the best we could do is brute force.

[10:55] Am I understanding that correctly?

Avi:

[10:57] Yeah, you’re understanding it perfectly correctly. I think that maybe what you are getting at is that NP-complete problems are, a particular NP-complete problem is really a family of instances. I mean, you want to find a Hamiltonian cycle, some Traveling Salesman Problem through some map. There’s this map and that map and this network and other network. And there are many, many instances when we talk about an algorithm for them.

[11:32] Typically, we say an algorithm is efficient if it’s efficient and correct on all of them. In software engineering and many aspects of optimization in real-world problems, the instances are a much more restricted set. They come from trying to verify a particular protocol or, I know, protein folding. If you want to think about the biological example, the way it is phrased as an NP problem is that you want to minimize the energy of a system under various constraints that have to relate to the chemistry of the various molecules and atoms that appear in the protein.

[12:25] And this kind of optimization problem one can easily prove is NP-hard. Nevertheless, our body folds proteins all the time, extremely efficiently. Now why is that? Of course, I don’t really know why that is. But it would seem that evolution designed proteins in such a way that this, you know, folding them, only them, we don’t have that many proteins. There are not exponentially many proteins in the body.

[12:57] There are only a few that may be more prone to efficient energy minimization. More generally, I think in software engineering, at least in verification and testing, you often want to check that something meets the specifications. You usually translate it into a satisfiability question of Boolean formulas. The formulas that you get, the instances that you get out of these have some structure, and maybe for them, various greedy approaches or clever methods can be applied.

[13:38] Not just greedy, but clever and efficient methods work. In other words, making it short. Instances that come up are not the worst-case instances. We have many examples of this that we can actually prove. For example, early on it was recognized that the Simplex method, which is an algorithm to solve linear programming problems, on the one hand, requires exponential time for the worst-case system of inequalities.

[14:16] But in practice, it seems to run in linear time. Evidently, the set of linear systems that we tackle in real life has some extra structure that allows this particular algorithm to solve them efficiently. Of course, today we know an algorithm that’s efficient for all linear programs, but it’s much more complicated, and I don’t know how much it’s used in practice. But the Simplex method is very simple to run, and usually, it works.

14:51 — What if you relaxed correctness

Ryan:

[14:51] You mentioned protein folding, and that’s an interesting one because it’s an NP problem, but it was solved to an acceptable extent. When I was reading about it, I found that it wasn’t solved for 100% of cases. It provides a solution and a confidence score, but it doesn’t give you the answer that is 100% accurate and fully computed. So when you think about these NP problems, what if you relaxed the criteria of being correct?

[15:27] Could the asymptotic complexity be less than the exponential that we’re talking about?

Avi:

[15:33] Yeah, it’s a very natural and good question. So in the protein folding, you are talking about AlphaFold, which is an algorithm or heuristic that was learned from existing proteins and works very well on instances it didn’t see but are still proteins coming from the body. Even if it did perfectly on these, that would still be following the discussion I mentioned before because the instances it is trying to solve come from real life and probably have extra structure that allows efficient solutions.

[16:13] But you are right that one of the things that people naturally do when they cannot solve an optimization problem exactly because it’s NP-complete or NP-hard. Maybe I should say NP-complete and NP-hard problems are those problems in NP that are as hard as all problems in NP. If you solved one efficiently, you solved all efficiently. If you prove one hard, then you prove all of them hard. So they somehow capture the complexity of the class.

[16:46] The Traveling Salesman Problem is an example. Portraying folding in this framework of energy minimization is one, and Boolean satisfiability and so on. Okay, so you want to optimize something, and it’s NP-complete or NP-hard. That’s a sign that you shouldn’t try to find an algorithm that works always. But one thing you can do is an approximation. That’s a very natural relaxation. You don’t want the optimum.

[17:16] You are willing to live with a factor of 2 from optimum or 10% from optimum or some factor away from optimum. NP-completeness was discovered in the early 70s. In the early 90s, there was a breakthrough called the PCP theorem. The PCP theorem allows you to argue hardness of even approximation problems. For example, you can show that satisfiability of Boolean formulas—it’s not just, so you want to, let’s say, find an assignment to a bunch of constraints, let’s say Boolean constraints, let’s say on three variables, for simplicity.

[18:06] So you want to satisfy all of them. The relaxation would be okay, I want to satisfy 90% of them, or as good a fraction as I can if I cannot get 100% of them. The PCP theorem, one way to phrase it, and suddenly one of the major consequences is that we know that you cannot even achieve a very good approximation. To illustrate how tight this understanding is for some problems, when there are only three variables per constraint, if you just guess at random the values to the variables in the assignment, you will satisfy 7 or 8 of the constraints.

[18:55] This is because each particular constraint, usually the disjunction of three variables, will be true with probability seven-eighths. So if you randomly assign values to the variables without thinking or looking at the formula, you can satisfy seven-eighths of them. The PCP theorem, along with a significant strengthening by Johan Håstad, tells you that if you want to satisfy seven-eighths plus epsilon, that’s already NP-hard.

[19:30] So we know today to argue the difficulty not only of finding the perfect solution, the optimal solution, but even how close to optimal you can get for lots and lots of problems, large classes of problems, in particular constraint optimization problems, you know, of the type of satisfiability.

Ryan:

[19:56] So even if you solve just the slightest epsilon for any trivially small epsilon, it’s just as hard as doing.

Avi:

[20:06] It’s as hard as finding the optimum source.

Ryan:

[20:09] You mentioned NP-hard, NP-complete, and P. I know there are other complexity classes. Maybe you could give some more context on the whole space of complexity classes.

Avi:

[20:22] Yeah, so I’ll just remark that we have a zoo of complexity classes. In fact, there’s a website called the Complexity Zoo, which has in it hundreds and hundreds of complexity classes of all types. The website was started by Scott Aaronson. Once we realize that there’s a whole zoo out there, we want to know the relationship between these classes. Okay, so what is the point about these classes like P and NP?

[21:02] We want to classify problems by the amount of resources they take. So P (polynomial time) is a class of problems that can be solved in an amount of time that relates polynomially to the size of the data. Of course, you expect that as the data grows, the instance grows, and you’ll spend more time. But if it’s linear time, quadratic time, or cubic time, you say, let me call it at least theoretically efficient.

[21:35] And NP, you classify not the time to solve, but the time to verify a solution if it was given. You want this to be polynomial time. So it’s very different. But first of all, there are many more time functions than just polynomial, exponential, and doubly exponential. And you can go to finite, and one fundamental result, starting with Turing’s paper, is that there are problems that are simply unsolvable by computers.

[22:16] So really, the first complexity class is a class of solvable problems, decidable problems. Turing shows that these are not all problems. There are natural problems that are not decidable at all. But time is only one resource, and we are interested, both from practical and theoretical reasons, in lots of other resources. Memory is a costly resource, and we want to minimize the space invested in a computation.

[22:47] In problems with several parties, you are interested in the amount of communication exchange, not the internal computational effort that they exert themselves, but how much. If you talk to a satellite, you want to minimize the communication. You can think about energy; there are plenty of other resources, like parallel time. How much can you speed up the computation of a problem if you work on it not with one computer, but with n computers?

[23:21] If your data is of size, then does it allow it to solve it immediately? Or maybe it doesn’t help at all? Complexity classes classify problems according to how much resources they need. There are many of these, and one important part of that is a major theme in the methodology of complexity theory. Coming with it are attempts to understand complexity classes as problems that relate to each other, even if you don’t know their complexity.

[24:02] So, for example, NP is a class, and we don’t know the complexity of all problems in this or NP-complete problems. We don’t know whether they are all easy or hard, but we do know we have efficient algorithms to translate one into the other. It’s not obvious that if you want to solve a satisfiability problem, you don’t know how. But you have an algorithm to solve Sudoku problems, not just three by three, but also four by four. If you had an efficient method to solve Sudoku problems, P equals NP, because you can efficiently take an instance of satisfiability, the Traveling Salesman Problem, or factoring integers, and from the solution of the Sudoku problem, you can translate back and get the best solution for your original Traveling Salesman Problem.

[25:04] So we are interested in efficient reductions between problems whose complexity we don’t know, but we want to relate them to each other. We build some kind of partial order of the hardness of different problems. There are really, you don’t want to know how many problems we have summarized for constraints that real-world technology may impose or cause for. Some are naturally arising mathematically because they are interesting.

25:38 — Why NP complete problems are equivalent

Ryan:

[25:38] You mentioned that these NP-complete problems are all equivalent in some way. What’s the proof to equate a SAT solving problem to a graph coloring problem or something like that? Are they all similar in nature? Are they kind of bespoke to the problem you’re going to and from?

Avi:

[25:59] That’s a very good question. You will find that in most of these, they call them reduction algorithms to translate one problem to another. Most of them are relatively simple, but not all. I talked about the PCP theorem before, showing that approximation is hardest is very highly non-trivial. But most NP-complete problems prove equivalence, like between graph coloring and satisfiability. This goes both ways; they are both complete.

[26:32] So it goes both ways. It is simple. The first one was the satisfiability problem. The original papers of Steve Cook and Leonid Levin, defining NP-completeness and proving that NP-complete problems exist, both focused on this. The first problem they proved complete was satisfiability. Why is this so? Why can all these other problems be reduced to satisfiability? The reason is really that computation is local. Computation is local.

[27:10] I mean that if you think about your computer, your laptop, or any computational device, usually it manipulates bits by some local operations. You look at these two registers and you add them, or you take these two bits and exclusive OR them or AND them or something, and you do a sequence of simple operations and you arrive at a conclusion. This locality can be translated to a bunch of constraints or what would be a consistent sequence of states of your machine.

[27:48] If you look at the time evolution of any computation, memories in some states and in another state change locally. If you could guess, and that’s the NP part, if somebody provided you the table of computation, you could check that it’s consistent by writing a bunch of local constraints or some conjunction of very few variables all over this table of computation and write down a satisfiability problem.

[28:25] I want this to be true, this to be true, and this to be true for some assignment. What the assignment has to satisfy should be a table like this. All these constraints should be satisfied, should be true, and it has to be consistent with the input given, right? Some of the inputs have to match the first time zero content of the machine. This locality allows for many of these translations.

[28:56] If you realize this, you will quickly find a reduction from coloring to satisfiability. It’s also not clear why coloring is an evolution of computation, but it starts already with local constraints. You want a few colors and that every constraint is satisfied. In some cases, it’s even easier. But the reduction from any NP computation—that’s what NP-complete means. Anything in NP can be translated to satisfiability.

[29:29] NP is just a computation of a Turing machine, say only that you don’t know what the computation is. If somebody guessed it or showed it to you, then all you need is to verify this verification is local. And that’s the source of many simple NP-completeness reductions. Let me give you a really simple example. Why is factoring integers reducible to satisfiability? Because if I gave you factors of an integer, you could just multiply them and check that they equal the input.

[30:15] This multiplication is a simple algorithm, right? I mean, we know how to do it from second grade or something.

30:33 — Space vs time complexity

Ryan:

[30:33] You really, the factors you mentioned, time complexity and space complexity. Intuitively, in software engineering, we often trade those off for each other. Is there general theory on that, on how these two trade off?

Avi:

[30:50] Yeah, we have all these questions. They are natural questions for complexity theorists. How do two resources relate to each other, and can they trade off? Or maybe you can minimize them both at the same time. It depends on the problem. There are problems for which we know results, like multiplying time and space. It has to be at least the square of the length of the input. So you can either do it with very small space, like logarithmic space, but you need to pay maybe quadratic time.

[31:32] And if you want linear time, you have to pay linear space or close to linear space. There are results of this type in various models of computation. That’s another thing you play with. Not all of them are equivalent in principle, but if you care about exact time or exact space, they are not equivalent. So there are problems for which there is a trade-off. There are problems where you can solve them in linear time and logarithmic space.

[32:05] One very important general result that is the breakthrough from last year is a result of Ryan Williams. I’ll tell you what it is, but first, I need to describe what we knew about time and space. There’s a clear inequality, right? If you run in time T, you will never use more than space T, because you will never visit so many cells or registers in your machine. So space is at most time. Fifty years ago, Valiant, Paul, and Pipin improved this a little bit.

[32:41] They said that if you run in time T, there’s an equivalent computation that will do this in slightly less space than T over log T. That was a big result. The running time, of course, will blow up. It will be very, very expensive time-wise, but at least you can save on space a little bit. This was believed for almost 50 years to be the best you can do. In fact, we had arguments that in certain models, in stylized models, models of computation, you cannot improve that.

[33:19] I will not describe this restricted model, but in some way, natural restricted models, you cannot beat this. What Ryan Williams found out last year is that, in fact, much better can be done. Any computation that runs in time T can be simulated by another algorithm that uses only the square root of T space, far less than before. The algorithm is quite sophisticated and uses an earlier result of James Cook, the son of Steve Cook, known for defining NP-completeness, and Ian Meltz, which was an essential technical ingredient.

[34:07] But anyway, there’s a really interesting way to save space. A very non-trivial way to save space. Again, this algorithm will run in a lot of time, but at least you have a sense that the two parameters are related in a highly non-trivial way.

Ryan:

[34:29] Is this for a general problem?

Avi:

[34:31] General problem for Turing machines? Okay, it may not work on random access machines or.

Ryan:

[34:37] Yeah, what’s the trick? If you could explain intuitively, or is it too deep to explain?

Avi:

[34:45] It is really technically explaining it. It’s too deep. But I’ll give you a much earlier result which indicates that really mysterious things can be done in small space. Again, it’s probably over 40 years ago, people discovered the following. Dave Barrington discovered the following really interesting phenomenon. So suppose all you want is to count. I give you a sequence of bits, and you want to count.

[35:20] Say you want to know whether there are more zeros than ones, like the majority problem. Who wants the vote, zeros or ones? Okay, well, you can count. You can just add them up, and this takes logarithmic space; it seems the best you can do. You want to count up to N. To represent N takes log N bits, right? Any number between 1 and N takes log N bits. It seems essential. It turns out that there’s an algorithm I have to define exactly how it works.

[35:58] I will not define exactly how it works, but it solves this problem. In constant space, it seems like you can count arbitrarily high. All you need is access to whatever bit you like, whenever you like. I want the 17th one, I want the 81st one. If you can have random access to the bits, even if you have constant space, you can tell whether there are more zeros than ones or ones and zeros, regardless of how long the input is.

[36:33] The trick is that somehow you use noncommutative algebra. Noncommutative algebra is not something everybody’s familiar with. I mean, we usually put the cars behind the horse and not in front of the horse. It matters. In software engineering, we do this before that; it’s very important that the order of things matters. So you can think about applying permutations one after the other.

[37:10] If I rotate a circle and then take a mirror image, it will give me the... So these are two permutations, right? I mean, say I have endpoints in a circle. I can shift it by one, or I can, let’s say, flip it around some diameter. There are two permutations, and they don’t commute. If I first flip and then rotate, I’ll get something else than if I first rotate. Think of all the points as colored, so they don’t commute.

[37:45] Barrington is using permutations to encode the bits in the input, specifically permutations of size five. When he sees a one, he may rotate, and when he sees a zero, he flips. The non-commutativity of these operations allows him to carry out a general formula, a formula of ANDs, ORs, and NOTs. Any formula of some size S enables him to simulate the ANDs, ORs, and NOTs in this formula through rotations and flips of these five-sided pentagons.

[38:45] And so just to remember the configuration of this pentagon, you need five bits, right? So you need constant space. How this captures the computation, I can tell you one more sentence. Maybe it will not be clear to everybody, but these non-commuting things allow you to do the following type of operation: do a rotation, do a flip, then rotate back and flip back. This is called the commutator, and it can simulate an AND gate.

[39:33] I can. It’s too much to describe in words without how it does it. But there’s a very famous analogy, which is a riddle that captures this NP-complete problem. You want to hang a painting in the following way: you have a painting, it has a string connecting the two sides, but you want to hang it not on one nail, but on two nails.

[40:08] Okay. There are two nails on the wall, and you can do with the string whatever you want. The property you want is that if the two nails are there, it’s hanging, and everybody’s happy. If you pull out one nail, it doesn’t matter which, the picture falls to the floor. How would you loop the string around these nails so that this happens? Clearly, this is an AND gate or an OR gate. Right? If one... Yeah. And this has to do.

[40:43] I mean, if anybody finds a solution, they realize what non-commutativity I’m talking about. It’s a nice fiddle. Anyway, this type of trick, where you can really do this type of result in small space, is something you wouldn’t imagine possible. It’s a striking example. When I heard this result for the first time, I was a postdoc, and somebody told me, and I just didn’t believe it was possible.

[41:18] You cannot count arbitrarily high with. The trick that Cook and Mertz have in their algorithm is a solution to a natural problem in much less space than you would think. It uses some sense tricks of this nature.

Ryan:

[41:44] If you’re counting arbitrarily large, that is information. You’re saying maybe the intuition is that information is encoded in the sequence of operations.

Avi:

[41:55] It is encoded. Of course, you are not delivering the final count. You just say whether there are more zeros than ones. If you have to write it down, and if the answer takes some number of bits, then you need this number to write it down. If you have a decision problem, say like yes or no, like are there more zeros than ones? Then you can do it for any size input in constant space.

Ryan:

[42:26] That’s incredible.

Avi:

[42:28] Pretty incredible, yeah. And by the way, this highly applicable result used in cryptography in fundamental ways is used in various places, and it’s an extremely useful result here. Unlike the Ryan Williams result, if you have a formula of size S, you can do it in constant space. The time of this algorithm does not blow up really a lot; it’s just quadratic. So it’s quadratic time.

[43:00] So this is something actually doable, useful, efficient, and magical.

43:06 — Why people use SAT solvers

Ryan:

[43:06] We talked about the equivalence between these NP-complete problems. In practice, a lot of people solve other problems using SAT solvers. I would have thought that would be less efficient, though, because you have to translate it and then you’re doing it in almost like a different problem space.

Avi:

[43:25] Yeah, you usually also enlarge the instance. In translation, you enlarge the instance. So what your question is, why do people use SAT solvers? I would say that there’s no problem other than satisfiability that people thought so hard about really optimizing the heuristics that efficiently work on many instances. There are very clever ways in which you can try to start. I mean, you are not going to guess all the N bits, but you want to start by guessing some bits that seem more pivotal. If you like in dominoes, maybe when you set them to one value, they force many other values to be set.

[44:22] And if that happens, you cut down your subspace. There are many heuristics of this type and also more clever than this that allow solving such satisfiability problems if they have such structure. Again, in the worst case, it will not help you. There is, in fact, a conjecture that is much stronger somehow than NP-completeness, you know, NP-complete problems taking exponential time. It says that we don’t expect any savings.

[44:56] We expect satisfiability problems to require really true to some constant times N. It’s not going to be two to the square or N to the log N or something like this. The worst case may be hard, but people optimize attacks on many such formulas that somehow have all sorts of structural properties arising maybe in practice. I think that’s the main reason they are used. It’s also convenient.

[45:33] I mean, it’s very common. People do it for testing specifications that programs or protocols meet. The specifications are usually easily translated into simple constraints, and that’s almost a satisfiability problem.

45:53 — Randomness is a resource

Ryan:

[45:53] We talked about all the different types of resources in an algorithm, and in one of your talks, you said something where you consider randomness another resource for an algorithm. What do you mean when you say randomness is a resource for an algorithm?

Avi:

[46:10] In the early 70s, of course, randomized algorithms existed since antiquity, and everybody was tossing coins for a lot of reasons. Statisticians do sampling and use randomness. But when algorithmics, designing efficient algorithms, became big—once we had computers—people realized that it can really enhance all sorts of computation. For example, we had no idea how to test the primality of a number.

[46:46] And in the 70s, both Michael Rabin and Sulwin Slauson found probabilistic algorithms, which are fast to test primality. Okay, so what does it mean, a probabilistic algorithm? It’s an algorithm that’s allowed to make random choices. You can think that there is an internal little person or device inside that tosses coins. Of course, that’s not what happens. There’s no little person sitting in your laptop.

[47:15] So the question is, where do you get these random bits? It’s very important to stress that in all these probabilistic algorithms, the underlying assumption is that the bits you get are perfect. They are half, half each one and independent of each other. It’s like a uniform distribution on all possibilities. Now, where do you get this? I mean, where seriously do you get this? If you run a public algorithm on your laptop, since it doesn’t have this person inside tossing coins, it does something well.

[47:52] High-quality randomness of this type costs money, time, and memory. What do I mean by “cost money”? You can have a very cheap solution. You can just measure the thermal noise in your computer or use one of the Intel chips. You can measure Internet traffic and sample it, believing it’s random, and all of these things are used. You can do something mathematical, have some simple procedure that is actually deterministic, like a linear congruence generator or something like this, and believe it’s random.

[48:32] Or you can take the digits of π. It also looks random in some sense. There are many things you can use, but you don’t know they are random. If you want them to be random, one source— even this is not a perfect source— but we have quantum mechanics. People believe it works in life. It seems like a true theory of nature. There are all sorts of arguments about it, but let’s put them aside.

[49:01] They predict. If you measure photons coming out from some source and you measure their spin, whether it’s up or down, the prediction is that each one is half, half, and it’s independent of each other. That’s very nice. But if you are going to build this device, it’s going to cost you a lot of money, and let alone that it will not be perfect. But let’s leave this aside. Anyway, since you want high-quality randomness, you have some way of guaranteeing, I mean, you are running it really on your laptop.

[49:34] It’s not okay. The paper was written; we can test primality with a probabilistic algorithm. Now we want to run it. What do you use? It makes sense to ask lots of questions about randomness. What guarantees the quality of the randomness? Maybe you can minimize the use of randomness. By the way, another issue with randomness is that the outcome is a random variable, and it’s not always correct. Right?

[50:02] The whole point, in most of these algorithms, is that you just have some small probability of error. If you have a deterministic algorithm, there’s no error, so you also don’t like the error. Treating it as a resource is simply a convenient, complex theoretic way of saying how do we understand the amount of this resource we have to invest, or the number of bits we have to invest, their quality, and so on.

[50:30] So it’s almost automatic. If you think like a complexity theorist, how do we minimize for a particular algorithm, like primarily testing? Do you really need this? Do you need them to be independent? Maybe you can generate them in a, you know, maybe you need n bits, but you can start from squared n bits or from log N bits that are truly random and make from them in some deterministic way, a sort of pseudo-random sequence you can call it, which is a good name actually, that will, for the purpose of this algorithm, look as if it was random.

[51:13] If you could do that, you don’t need all these bits; you can use much fewer. This whole theory of reducing randomness, derandomization, and removing randomness is a huge field, and there are many problems and many ways of doing it. The story with primality is actually fascinating. I mentioned these two algorithms that were invented, and people were wondering about the deterministic algorithm for primality.

[51:45] It’s a problem that has been articulated already by Gauss in the most complex theoretic way you can. Back in his days, hundreds of years ago, and maybe 150, I don’t know, he was asking for an indefatigable calculator. Calculator, of course, is a person. But he wanted this to be efficient. That’s basically what he was looking for, a primality test for large numbers. Because they really wanted to know about numbers, maybe only a few tens of digits.

[52:23] They wanted to know whether the numbers are prime or not. There was no efficient algorithm. You can wonder about the Miller-Rabin or Solovay-Strassen algorithms; maybe you can use less randomness or structures, randomness that you can generate from fewer bits, but nobody has any good idea. Then, in the early 2000s, Agarwal, Kayal, and Saxena devised a different probabilistic primality test, and it’s different.

[52:55] So the analysis of randomness in it is different. Once you understand how randomness is used, you can say, “Ah, we don’t need to have totally independent bits. It’s okay if it has some structure.” They found, using number-theoretic methods, a tool to generate pseudo-randomness from very few bits. That’s how it works. Sometimes, deterministic versions of probabilistic algorithms are discovered simply by understanding how the algorithm uses randomness, analyzing the algorithm, and realizing it doesn’t use all that much.

Ryan:

[53:49] You mentioned a few times the quality of the randomness. How do you quantify the quality of random bits?

Avi:

[53:56] This is basically a question about what pseudorandomness is. The general answer is that it depends. You want to fool a particular algorithm, let’s say, for primality. You want the randomness to fool this algorithm; you want it not to notice that you switched from perfect randomness to something that’s really far less random, has far less entropy, but the analysis works nonetheless. For another algorithm, maybe you need a completely different type of pseudorandomness for it.

[54:35] There are a set of examples of algorithmic problems for which, when you look at the analysis, they are much simpler than this primality testing. It seems to use not the independence of all the n bits. You really need only every pair of them to be independent, or every triple. Spaces of random variables that have this property are much smaller. You can generate them from log N bits, and so you can fool them with this.

[55:08] So the quality of randomness is a phrase. I like that. The quality of randomness is in the eye of the beholder or in the computational power of the beholder. You really need it to be just as good as the tests that are applied to it. You just want to be completely pragmatic. You don’t care whether it’s random or not. You just care that an observer of a particular structure or particular computational power will not distinguish the pseudo-random distribution, which may have much less randomness in it than the perfect one.

55:48 — Randomness depends on computational power

Ryan:

[55:48] In one of your lectures, actually, you mentioned that, and you gave a good example. I was wondering if you could give the intuitive example of why randomness is a function of the observer’s computational power.

Avi:

[56:00] Yeah. So if you watch this talk, the example I give is taken from this fundamental paper of Manuel Blum and Silvio Micali. They tell you to consider three experiments, and the experiments go as follows. They are always between you and me. You are the observer, I am the cause. I have a coin on my finger, and I toss it. Just as it leaves my finger, you are supposed to predict what the value will be when it falls on the floor, like in two seconds.

[56:38] You have to immediately say, heads or tails, okay? Before you have to predict, before it falls. Well, this is the first experiment. And you know what I ask and what they ask? What do you think is a success, your success? What are your chances of predicting it? And the obvious answer is, you know, one half. You know what, how can it help? You know, what can you do? The second is when you sit there, but you have a laptop like you have now.

[57:10] And, yeah, what can you do? I don’t know how fast you type, but the coin will be on the floor in a second. The third experiment is where your laptop is connected to a Cray supercomputer, and the Cray supercomputer is connected to a bunch of sensors and cameras and whatever devices you want. They are all trained on my finger, okay? And so as it leaves my finger, the coin. This apparatus certainly is more than enough to calculate all the angular momentum of the coin and the distance to the floor and the humidity in the air and whatever parameter that completely determines its motion.

[57:57] In particular, how it will land in a split second, far less than the time needed. So the real point in this example is that the experiment, the random coin toss, did not change in all of them. It is the same what masses of people in math, physics, and philosophy have defined randomness in various ways. There are many definitions of randomness, and they all focus on this event, on the chronos or sequence of coin tosses.

[58:37] We in computational complexity theory, starting from this paper, don’t care about this event. The event stays the same, and all it focuses on is the observer. The only thing that changed in these three experiments is the computational power. We want to know how much entropy is in the coin. If you don’t have enough computational power, it seems to be full entropy. It’s half. Half. You don’t know what it will be; if you have enough computational power, you can predict it completely, and then it has zero entropy.

[59:12] So what changed is the observer. The observer is this algorithm we talked about before. Any test that’s applied to a distribution to test the quality of randomness, depending on the test, you want to make sure to use as little true randomness in a way that the observer will not notice. This is the source of many of the important theorems that show you can remove randomness or reduce randomness in probabilistic algorithms with or without assumptions.

[59:55] And really, they are behind this understanding that we have today. Randomness in algorithms is not as powerful as we thought. It’s like if you know that P is different from NP or you have a Traveling Salesman Problem that is exponentially hard or sustainable. If you know that, then in fact, I can give you a pseudorandom generator that will derandomize any. We know that under this assumption, we have what we call P equals BPP.

[01:00:28] Anything that has an efficient probabilistic algorithm also has an efficient deterministic algorithm. You just need to know that there is a hard function somewhere. Under what assumptions do we know P equals BPP? The very natural assumption is that one of these NP-complete problems, or in fact even problems in higher classes, requires a lot of hardware and requires exponential size circuits to solve. We believe that it’s like the P versus NP problem in strength, and you cannot count down the exponential subspace.

[01:01:14] And so maybe people are happier with this assumption, but this assumption about time complexity has no randomness in it. At first, it’s shocking that it’s actually related to the problem of removing randomness from algorithms. So that’s one fundamental connection in this hardness versus randomness paradigm. But we know even more. We know that it goes both ways. We know that if you are trying to remove randomness from some algorithms, if you can do that, then you’ve found the hard function.

[01:02:02] So there’s really an almost. It’s not an exact if and only if, but again, there are many variants of this. In some variants, if and only if it’s stronger, but we really know that it’s one or the other. Since it’s hard to believe that all these hard problems are easy, or the seemingly hard problem like P versus NP, we tend much more to believe the other alternative, which is that randomness in algorithms is weak and you can remove it.

Ryan:

[01:03:20] Is there an intuitive explanation for the relationship between problem hardness and randomness?

Avi:

[01:03:25] Yeah, there’s almost always an intuitive explanation for this. So what’s the hard problem? I give you the input. You are a limited computer. You are a polynomial time algorithm. I give you the input. Let’s say it’s a Traveling Salesman Problem, or you don’t know the answer. So there’s some entropy in the answer, right? In the same sense we discussed before, there’s some entropy, a tiny entropy, maybe exponentially small entropy, because if the input is random, maybe only a few instances are hard, and all the others you can solve. But at least you see a hint of a relationship between hardness and entropy.

[01:04:12] This, of course, is not satisfactory because we want half. We want the answer to be like a coin toss, not like a very biased coin toss. So we need to find ways to amplify this uncertainty for you. Amplify the hardness. We want not just that some instances will be hard, but since they are random instances, whether the answer is yes or no, for polynomial time, the observer will be half and half.

[01:04:46] It will not be able to gain an epsilon advantage over a random guess. For this, we developed all sorts of methods that amplify randomness. Now, this doesn’t solve the problem at all because I managed to take n bits of a random instance of a problem and manufacture one bit. That’s hard for you to guess. But I could have taken the first random bit I picked.

[01:05:20] What you want to do is the opposite. You want a method that will take a few and generate many. That’s a pseudorandom generator. The pseudorandom generator starts with a few truly random bits and generates many. For this, we need other tools. There’s something that I developed with Noam Nisan called the NW generator. I like to say that people say making the first million dollars is easy, and afterwards, you can make many more millions.

[01:05:57] You can think of it this way. The hardness in the way I describe it allows you to make $1 million. But once you can make one, there are methods to make many more, in fact, more than the number of bits you started with. But still, their quality depends on the hardness of the function you use. We still use this and your limitation of being in polynomial time. So you can also solve this hard instance.

[01:06:30] You build many instances from a short seed. You start from maybe a logarithmically long seed. You take many subsets of this, like N. You will need n of them. I ask you for the value of the solution to each one. Each one is hard, but we want to say that they are simultaneously hard. You cannot tell them apart. There is no correlation that you can detect between them, even though they are extremely correlated.

[01:07:00] So, we have methods to do that as well. The connection you embed, having a hard problem to a limited observer, means there’s some uncertainty about the answer. That’s the key. That’s a starting point.

Ryan:

[01:07:14] So when you say that the quality of the randomness is a function of the computational power of the observer, one thought that comes to mind is, imagine I have maybe infinite compute. Then nothing is truly random. Is that accurate to say? Like, you know, if I had infinite compute, the weather is not random. Nothing is random.

Avi:

[01:07:42] Okay. So it points to the fact that you have to really be careful about what question you are asking about randomness. If you want to apply this to probabilistic algorithms, then it’s really important that you are limited computationally. If you have infinite compute time, you will be able to distinguish a distribution with full entropy from one coming from a generator with low entropy.

[01:08:19] So you could do that. But one thing you cannot do with infinite compute is something that’s information theoretic. There are many other things we need to do with random bits than just run probabilistic algorithms. For example, we want to generate passwords for our cryptography for security systems. The very demand is that they are random, right? I mean, Shannon’s theorem tells you the quality of your password is as good as the entropy in it.

[01:08:58] So the notion of a secret rests on the true randomness of the bits. If I ask you to produce a random bit, or you ask me to produce a random bit, whether you have infinite computational power or not doesn’t matter. To generate this random bit, it has to be random. Your demand is not that it will succeed in some test; you really want the probability of heads to be half and tails to be half.

[01:09:34] Then this definition or this task of producing randomness is not related to your computational power. Lucky or unlucky, I don’t know. For us, many times we do have implicit or explicit tests for this randomness. You say, “I can break this system or something.” Then you can maybe use pseudorandomness. But if your very demand is to have a random event, then you need to produce a random event.

Ryan:

[01:10:08] I saw in my research that there are ways to create higher quality randomness by aggregating weaker sources. How does that work?

Avi:

[01:10:22] Well, it’s another theory I talked about before, the theory of pseudorandomness. There’s a whole different theory. They are related in nontrivial ways, but it’s called the theory of randomness extraction or randomness purification, maybe. And this is exactly what you asked about. We imagine that the world may not give us perfect randomness, but we have all these events we cannot predict, like the weather, various quantum phenomena, or sunspots. We cannot predict the stock prices, right? Otherwise, the market will be.

[01:11:04] But these are not, even though these are unpredictable events, they are somewhat predictable. I mean, the weather tomorrow is more likely to be similar to the weather today than the opposite. So there are correlations. If you sample this weather, for example, there are also biases. I mean, sometimes in the spring it’s more, or in the summer it’s more likely to be hot than cold.

[01:11:33] So there are biases and correlations. These are called weak random sources, and there’s a mathematical quantification of how weak they are. Basically, we talk about the amount of entropy in them. You have N bits; potentially, you can have entropy N, but maybe they were generated from a generator or they came from some source. It has some entropy in it, but you have no idea where. Maybe half of them are fixed and half of them are chaotic, and you don’t know which half.

[01:12:10] Maybe they are each half, three-quarters zero and one-quarter heads or tails, have a virus that also has lots of entropy, but not full. The correlations may be even more complicated. You can imagine all sorts of situations like this, and you mathematically model it by saying, okay, there are N bits. It’s a probability distribution of N bits which has some entropy, let’s say the square root of N.

[01:12:39] You don’t know where, and you want to use it in a probabilistic algorithm. So it’s a basic question: can we use physical events, weak sources coming from nature, maybe in probabilistic algorithms? It’s certainly not obvious. I mean, just feeding them to the algorithm as is is not going to work. There are very simple algorithms that will succeed on perfect randomness and will fail, making an error.

[01:13:14] But the theory of randomness purification wants to take this sample of n bits with some amount of entropy, which is not full, and massage it to create from it maybe a shorter string that is of higher quality. Ideally, it would be perfect random bits. So, ideally, you can imagine that if I have n random bits and I have entropy root N, maybe I can massage out of there square root N, or maybe just the fourth root of n bits that will be essentially uniformly distributed.

[01:13:59] Then if I have an algorithm that just needs this amount, that’s what I feel. Turns out you cannot do that; it’s impossible. But what you can do is not produce one string of length, let’s say, the square root of N, but you can produce N to the hundred of them, okay? And what you are guaranteed is that this randomness purification device is an official algorithm that takes any distribution with entropy in it and produces many blocks, polynomially many blocks, of the length roughly the entropy.

[01:14:41] What you would hope to be perfect and what you are guaranteed is that 99% of them are truly perfect. So you have many, 99% of them are as good as perfect. And there’s 1% that is bad. You don’t know which it is. But this already solves your problem because you can run your algorithm on each one of them and take a majority vote. Doing this is extremely complicated. There are many ways of doing it. There are variants of various assumptions you can make about the entropy.

[01:15:21] Maybe you have several weak sources that are not related to each other. There are various variants, and this theory is very well developed. But we know that the statement I made essentially is accurate. If you have one source with some entropy in it, you can generate polynomially many samples of the length of almost the entropy, and most of them will be perfect. So that’s as useful as having one.

Ryan:

[01:15:55] Yeah, I vaguely remember skimming a bunch of papers, and one of the papers had this figure with a two-dimensional array of numbers. I think they were drawing rectangles or something like that. Is that one of the ideas?

Avi:

[01:16:11] So it’s a notion of pseudorandomness, which is related to one particular variant of this extraction problem where you have several weak sources, not just one. One is the hardest because that’s... Yeah, but maybe you have a few that are independent, and each of them has some entropy in it. I think what you are referring to is this sum product theorem. I cannot draw the pictures of that, but you don’t really need to.

[01:16:45] So let’s just think about this problem. You have three sources of randomness; they are each weak, so each has just a little bit of entropy in it. All you want to produce is one source with somewhat larger entropy. You are losing the number of sources, but you are gaining entropy. If you can repeat this, you eventually get to full entropy. So that’s the idea. What combination of which sources would you take?

[01:17:17] It’s not obvious. And the solution? Yeah, there certainly is one. Maybe you mean this one. There’s a paper I have with Barack and Impagliazzo about this particular problem, and we are using a result in what’s called arithmetic combinatorics. I can explain it very simply. I think that we learn about addition in second grade and about multiplication in third grade, maybe. The only motivation for multiplication is that it’s a way to shortcut repeated addition.

[01:17:56] And that’s all we talk about. Then if you go to college, you learn that sums and products are the basic operations of fields. You can do it with integers, rational numbers, complex numbers, and finite fields. And so you remember these are the basic operations. But how do they relate to each other? It’s not clear. Maybe there are many ways to ask this question. But one way to ask this question that was suggested by Erdős and was solved for the first time by Erdős and Semerédi, and then in a much more applicable form we really need by Bourgain and Katzentau, said the following.

[01:18:38] Just think of a set of integers and add all pairs. So you start with, let’s say, K integers and add all pairs. How many new integers do you get? This you should think of as entropy increase. If you get many more somehow. So you have K integers. Well, it depends on what they are. I mean, if they are the first K integers and you add all pairs up, you get the numbers between 1 and 2K. That’s not much larger; that’s a factor of 2 larger.

[01:19:11] If you want to increase entropy, you want to get some power of K bigger than one. Of course, if you take a random set of integers, you’ll get K squared. They’ll all be distinct because K squared integers. So somehow you want to say, it would be great if, for any set, when you take all pairs, you group. But it’s not true. By this example of the interval, you cannot take sums; you can take products, but also products don’t always increase.

[01:19:48] If you take 1, 2, 4, 8, you take a geometric progression, you multiply all pairs, you just get twice as many as you started with. So that’s also not good. The magic in this sum-product theorem is that sums and products are orthogonal to each other. Somehow, if one of them fails to grow a set, then the other will grow this set. This is an amazing result. In this context, you think of the outcome of your sources as numbers.

[01:20:31] You multiply the first pair and add them to the third. You mix the sum and product. This guarantees growth. This is not obvious, but if you do this, it guarantees that you grow. The number of different values you get is significantly more than K. Maybe it’s K to the 1.5 or something. Entropy does increase, and that’s the source. You need to prove it. Distributionally, it’s not just the size.

[01:21:03] The entropy is not just size; it’s more than that. Anyway, this is behind one solution to one of the problems about purification. It does not solve the one source problem. For this, you need other tools.

01:21:20 — Zero knowledge proofs and their significance

Ryan:

[01:21:20] I saw that you had done some work in zero-knowledge proofs. I was wondering if you could explain what a zero-knowledge proof is. Maybe we can talk about its significance.

Avi:

[01:21:30] Sure, zero-knowledge proof. It’s pretty amazing that it became a household word. I mean, it was in the domain of theorists for a long time. The original definition of zero-knowledge proof came in a seminar paper by Goldwasser, Micali, and Rakoff, which also contains the definition of interactive proof. So even before zero-knowledge, they conceived of the notion that proofs don’t have to be written down like in mathematical papers.

[01:22:06] People can have a discussion, a randomized discussion, in which I try to convince you of something I want to prove to you. Something like, I know the proof of the Riemann Hypothesis, or I can solve this Sudoku puzzle, and we can do it interactively with the random. We are randomized. In particular, you, the verifier of my claim, are allowed to be randomized. So it’s like in randomized algorithms. But now there’s a prover.

[01:22:37] It’s not just an algorithm; it’s a prover, like in NP. Someone who knows the solution. But the convincing has this interactive form. This model was suggested in this paper and also in a paper of Babai, parallel at the same time from different motivations. Basically, it offers a generalization of the notion of NP. NP is just when I send you a message, and it convinces you; you verify it and it convinces you.

[01:23:09] Now, we allow an interaction and we allow a small chance because you are randomized. We allow a small chance that I will convince you of a false claim. But this error can be reduced, like in probabilistic algorithms. You want one in a billion? You can get one in a billion, whatever. Anyway, so there’s a notion of an interactive proof. In the Goldwasser-Micali-Rothblum paper, they suggested another notion of interactive proof, which is more restricted.

[01:23:46] You want to prove something, but the zero-knowledge proof means that you want the verifier to learn nothing, absolutely nothing about the proof except that it’s true. Now, this sounds really totally ridiculous. I mean, if you think about the last time you convinced somebody to change their mind about anything without providing them any knowledge, any new things they didn’t know, say, what are you talking about?

[01:24:17] Such proofs don’t exist for anything. There’s no zero-knowledge proof for anything. They were not thinking about convincing someone of a political opinion; they were thinking about cryptography. Of course, they’ve created the foundation of cryptography in many other papers, but they are imagining cryptographic protocols in which you have secrets. You use these secrets in your computation, and the protocol tells you to do things that, if you don’t, then you’re violating the protocol.

[01:25:00] So the others don’t want you to cheat. They want to make sure you perform the right operations on your secrets. For example, you are supposed to pick a public key by multiplying two prime numbers. If you multiply three or something else, then you are violating the protocol, and maybe security is not guaranteed. So I would like to convince you that the number I give you is actually a product of two primes.

[01:25:30] I certainly don’t want to give you the two primes. What I really want to convince you of is that I computed this number by multiplying two primes. You learn from this interaction absolutely nothing except that you are convinced with very high probability that I did multiply two primes and not any other number, and I didn’t do anything else that I shouldn’t. You can think about lots of other cryptographic protocols where people are doing things like multiparty computation, very complex things.

[01:26:06] They are confused with their secrets and don’t want to reveal them, whereas the others want to make sure that they did what they should. There are many applications for this idea. The only problem is that it sounds ridiculous because it seems impossible in mathematical terms. If someone came here and said that they proved P versus NP, I would want to see the proof and then tell me, okay, I’ll prove it to you in zero-knowledge proof.

[01:26:40] How can anybody convince me that they have a proof of P versus NP? I come out congratulating them and amazed by them, and nevertheless, I know absolutely nothing about the way they proved it. I just know that they did this. So it really sounds ridiculous. And yeah, certainly one of my favorite papers, maybe my favorite, is the zero-knowledge proof paper, which came a year later, co-authored with Omer Goldreich and Silvio Micali.

[01:27:17] Well, we showed that it’s not only not ridiculous, it’s universal. Namely, anything that has a mathematical proof also has a zero-knowledge interactive proof. Anything like P versus NP or that I multiply two primes, or anything that you can prove revealing your secret, you can prove without revealing your secret and be convinced beyond any reasonable doubt. So that’s possible.

Ryan:

[01:27:46] What’s the intuition behind that? Let’s say I have a proof for P versus NP, and we want to convert it to a zero-knowledge proof. How does that work?

Avi:

[01:27:55] How does this work? Well, first of all, it assumes cryptography. We assume we have some one-way functions. We assume that some problem, like factoring integers or discrete logarithms, or any number of one-way functions believed to be one-way, exists. One-way functions, if people don’t know, are functions that are easy to compute in one direction but hard to invert. For example, multiplying numbers is easy. Finding the factors of a number, which is the inverse problem, is believed to be hard.

[01:28:32] Of course, we can never know any hard problems. That’s the pre-first entry question. We don’t know, but we believe many problems are hard, and this belief is actually shared by the whole world because the entire world is using cryptographic systems that rest on this assumption. All electronic commerce assumes this. So, we assume we have one-way functions. One-way functions allow you to create basically garbled message commitments.

[01:29:06] I have a number in my head. I don’t want to tell you what the number is. It’s a number between 1 and 100. I can write down another number that looks like a random number to you. On the one hand, you have no idea. I claim this encodes my secret, okay? This commitment scheme, which is built very simply for one-way functions, guarantees two properties. A) You cannot tell what my secret is, even though you can see this other number I gave you.

[01:29:48] And on the other hand, I cannot change my mind about my secret. It really commits me to it. So I can later provide you with a certificate that I was thinking about 17, and I can only do it for 17. I cannot do it for any other number. In fact, a very simple example is really using factoring in some sense the product of two primes. This number commits to its factors.

[01:30:27] It uniquely defines its factors, right? The only problem is this is not exactly random products of primes. Yeah, but you can do it, so you can do this. Okay? So now that we have to take commitments, that are possible, that’s very important. I’m describing very high level; I’m hiding lots of things. Even the definition of zero-knowledge proof, the formal definition, is quite intricate. The intuition is obvious, and I said it.

[01:30:58] But actually, formally defining it is non-trivial. At a high level, I’ll give you some idea about how a zero-knowledge proof looks. Now we have to think about what theorems I am proving to you. It was very important for us to figure out what problem to think about. Even though today you can do it for others, we were thinking about theorems of the type where, in the graph, we can color it in three colors.

[01:31:27] It’s also a formal mathematical statement; either it’s doable or not, right? We simply focus on proving zero-knowledge claims of this type. The graph we both know, I claim I can color it with three colors. You don’t believe me. You want to be convinced of this fact, and you don’t want me to cheat you. You don’t want me to be able to provide an interactive proof. Moreover, I want it to be zero-knowledge.

[01:31:58] I don’t want you to have the slightest idea of what my coloring is or what anything you didn’t know before is. Okay, so roughly the way it works. The honor is proof for this particular set of claims that are certainly not all claims. They are very structured claims. We look like the following. We iteratively repeat the following procedure. I put commitments for the coloring on every vertex. I tell you, you know, I don’t tell you it’s green, red, or blue, but I put a commitment to one of them.

[01:32:38] On each vertex, you will choose at random an edge of the graph and ask me to open these two envelopes to decommit. You will check that the colors you see are in this set. They are not gray or orange; they are either red, green, or blue, and they are different. This should give you some slight advantage or support to the belief that maybe I’m not cheating you.

[01:33:13] Of course, it’s a very limited one because I can cheat you in some corner. We have to establish two things. We will repeat this again and again. We have to establish that it’s a proof, an interactive proof that I cannot cheat you. And we have to argue that zero-knowledge part. Okay, so let’s do one at a time. The correctness that I cannot fool you is very simple, is the following.

[01:33:49] If the graph is not three-colorable, whatever I commit for there is one place which is an arrow. Either it has the wrong color and not allowed color, or two colors are equal. You have some non-trivial chance of catching this with your random guess. It’s one over the number of edges. It’s not so small. It’s a graph with a hundred edges. It’s one in a hundred if thousands.

[01:34:16] If we repeat it, not a thousand, but 10,000 times, the probability that you don’t catch me in any of them drops exponentially to zero. So, of course, this establishes that I cannot fool you. The zero-knowledge proof is a more serious problem because if I keep using the same coloring, you will ask me about this edge and this edge, and then eventually you’ll know the coloring of all colors.

[01:34:50] Here’s something that’s really special to the coloring that is being used. If I have one coloring of the graph, I really have six because I can permute the names; I can replace red and green, and it’s another valid coloring. So what I do in each one of these iterations is not use the same coloring, but use a random one of these possible six. They are all legal, and I just use one of these six.

[01:35:21] What’s the advantage of this? When you open a pair of vertices under this distribution, one of the six, what you will see, if I do have a coloring—and that’s the only thing I want to stress—is that we only have to establish zero-knowledge proof if I really can prove the theorem. So if I do know the solution, the proof, I want to protect my knowledge. What happens when I reveal to you two of these colors on the adjacent vertices of the graph?

[01:35:52] It will be true in this distribution. When you are given two vertices, it will simply be two different random colors. This is what you get by all permutations in this experimentation. What did you learn from this? Nothing. You could have picked two random different colors. You didn’t need me for that. So you didn’t learn anything. In each iteration, you learn nothing. This is the idea of the proof.

[01:36:20] Well, this is the end of the proof that I can show there are zero-knowledge proofs for all graph coloring, three-coloring problems. What about all the Riemann Hypotheses and the P versus NP problem and factoring and all these other things? I want to claim to you and prove with zero-knowledge. Here it’s very simple. You use NP-completeness. This is an NP-complete problem. Anything that can be proved is really something in NP, right?

[01:36:52] This is the definition. So you reduce it to three-coloring, proving it in zero-knowledge. The main point about reductions in NP is that they don’t only convert the yes/no answer in a consistent way—if this is solvable, then this is solvable. But actually, if you have a witness, if you have a proof for, I don’t know, whatever, it will become a legal three-coloring of the graph you generate. So if you have a proof, you can also have the three-coloring.

[01:37:26] It’s very important that the reduction also provides translation not just between the instances, but also between the proofs. NP-completeness theory gives you for free that if you solve the problem for Hamiltonian cycle instances, you solve it for any. You can prove anything in zero-knowledge proof.

Ryan:

[01:37:47] So with the zero-knowledge proofs, you can never be 100%.

Avi:

[01:37:52] No.

Ryan:

[01:37:53] Okay, but practically, I mean exponentially approaching.

Avi:

[01:37:58] You can make the completeness 100%. Namely, if I do have a proof, you will be. Yeah, there’ll be no error in your proof. But there is a slight possibility that the graph is not three-colorable, and you will not catch me. You can make this exponentially small. You cannot make it zero.

Ryan:

[01:38:18] When I think of cryptography and one-way functions, there’s this idea of quantum computing that’s kind of changed complexity theory.

Avi:

[01:38:27] bit and big time.

01:38:30 — Quantum computation and why it matters

Ryan:

[01:38:30] And I wanted to ask your thoughts on how quantum computing, or that model of computation, is changing complexity theory. What are the big takeaways?

Avi:

[01:38:42] Okay, let me say what it is. First of all, quantum mechanics is a theory of nature that seems to be universally accepted. So, like with randomness, we can ask, why not enhance computers with this physical knowledge? We allow our computers to operate in the ways that quantum mechanics dictates, namely, manipulate bits in superposition using unitary operations, whatever this means.

[01:39:16] But according to the rules of quantum mechanics, really strange things happen. I’m sure many people know about the interference patterns. Basically, you are working with probability theory. With negative numbers, events cannot aggregate; they can only cancel each other. Okay, so it’s a model of computation.

[01:39:51] It’s a generalization of Turing machines. In fact, it’s a generalization of randomized Turing machines. It’s very easy to see that a quantum computer is at least as strong as a probabilistic computer. How do you see it? You just measure the quantum bit before you start. You measure them. This is what I mentioned about the photons in the beginning. If you have some basic superposition on a quantum bit, if you measure it, you get a random bit.

[01:40:23] So because of that, quantum computers are at least as strong as probabilistic computers. Okay, so it’s a model of computation. It was suggested in the 1980s. Richard Feynman, along with others, suggested letting algorithms use these quantum mechanical operations, mainly originally for simulating quantum systems rather than building bigger parallel systems, like we simulate other things, such as turbulence. I don’t know what the power of quantum algorithms is, again, let’s say running into polynomial time or efficient ones.

[01:41:08] Can they do more than efficient classical ones, deterministic or probabilistic? It wasn’t clear for a while. There were a few examples that were very stylized but were not for concrete natural problems we care about. Then in 1994, Peter Shor sort of created an earthquake or avalanche. He found quantum algorithms that are efficient, that factor integers and also compute discrete logarithms, the two most basic underpinnings of all security systems that exist.

[01:41:48] And this sets the world on fire. Right. So lots of people try to do a lot of things. Of course, people want to have these algorithms they implement; maybe they want to break other people’s cryptosystems. Since then, billions were invested by companies, by governments, by lots of people trying to build the technological infrastructure. This is extremely complicated. Holding bits in superposition is extremely complicated.

[01:42:25] These things are called noise. When people built classical computers like von Neumann, noise was one of the serious problems because the bits were really in vacuum tubes, and they had to contend with it. In fact, it built a nice theory of classical computers that have errors. They have to cope with errors; some of their components can be faulty. But today’s hardware has no errors to speak of.

[01:43:02] We don’t, there are error-correcting mechanisms, but we don’t need them for classical computing. Intel chips don’t have error correction in them. Hardware is very reliable. When you move to quantum, there is this decoherence noise in quantum mechanics. Everything depends on everything. The world can influence the computation in your laptop, and protecting from this is very hard.

[01:43:33] There are quantum error correcting codes, and that’s part of the solution. That’s only one of the problems. Just holding bits in superposition is hard, and there are many hard technological issues, and there’s progress on that. So this is one line of huge investment. The other line comes from cryptography because, of course, everybody should be worried. Forget quantum computers.

[01:43:59] If tomorrow, I mean really tomorrow, somebody finds even a classical factorization algorithm in polynomial time, I think there’ll be chaos in the world because nobody can do any transactions since most security systems still rely on factoring. Of course, we want to change this. We want to change the underlying assumptions of security. The whole revolution in cryptography was that we risk cryptography on computationally hard assumptions.

[01:44:38] And with this, we build all the wonderful public key systems and all the magical things you can do by assuming that players are computationally limited. But now, if the adversary is a quantum computer, suddenly they can break this assumption. You want to find other mathematical problems, computational problems that are somehow hard even for quantum computers. So that’s a whole field, this change in complexity theory and cryptography.

[01:45:19] There is an army of people who are just trying to invent problems. I maybe should stress one-way functions are easy to find. Most problems, most processes in nature are not easily reversible. You make an omelet from an egg. Reversing this doesn’t take the same amount of time; that’s the usual example of a physical one-way function. But trapdoor functions, like factoring problems, are what you can use to build public key systems.

[01:45:55] And that’s the most really basic thing for electronic commerce. We don’t know many. So we know this. I mentioned factoring and discrete logarithm. In the 90s, Itay and Roark created another type of trapdoor function from problems on lattices in high dimensions. I will not describe it, but it’s another problem. Then people refined and got a few more of similar nature. It turned out when Peter Shor discovered this, people immediately tried to solve other problems with quantum computers.

[01:46:31] In fact, even today we cannot solve too many other problems with quantum computers. These are special. The special thing about them is that somehow you can reduce them to finding periods in a signal. Periods are like fluorescence form. A Fourier transform turns out to be in exponential space. But you can somehow perform a Fourier transform with quantum computers using interference with lattice problems and problems related to it.

[01:47:02] Some call it learning with errors. Similar to this, to this day, nobody has found an efficient quantum algorithm for them. So there’s not even a theory. Forget building quantum computers; we don’t know how to solve them. The world is not just complexity theory. The whole physical world of security systems and also governments like the NSA is supporting or asking the world to produce assumptions that may be resilient to quantum attacks.

[01:47:44] And so this is a huge change. There is a major change in the interaction between computer scientists and physicists, which grew tremendously since its discovery. It’s rich in many ways that are not the influence of algorithmic thinking on physical theories, including today’s theories in quantum gravity, black holes, and so on. The impact is immense. We have new sources of problems, new models, and new complexity classes, et cetera, et cetera.

[01:48:19] And there’s a fantastic interaction. It’s also enormous complexity theory in that it turns out you can discover quantum algorithms and maybe then dequantize them in special cases. Like I mentioned factoring before, de-randomizing. Sometimes it’s a way, it’s a road to discover new algorithms. There are connections between problems. It’s extremely rich. But one of the most amazing consequences is that we, being what we are, make up models and study them.

[01:49:05] And the interactive proofs I mentioned before, it turns out that even before quantum, they were generalized to interactive proofs not with one prover, but with many provers, which seems weird but turns out to be very important in itself because it led to this PCP theorem. Then people said, okay, let’s allow quantum verifiers, quantum provers, and see what they can do. So one amazing result, which is about five years ago, is the acronym MIP* = RE.

[01:49:40] Of course, we have acronyms for all these complexity classes: MIP*, RE. You may have seen them, maybe you didn’t, and they look weird, but I’ll tell you what they say. It says that there is a really weird proof system with quantum provers trying to convince efficient verifiers. And it turns out, you know, you ask for which problems can they do it? Forget their own knowledge, just convince.

[01:50:12] And it turns out they can do it for the halting problem, for problems that are not computable. But things that are not computable are verifiable by efficient verifiers if the provers are quantum and they are entangled. It’s a weird proof system, very weird, but it does something that looks totally ridiculous. Things that are uncomputable by any classifiable component are verifiable in this interactive probabilistic sense by efficient verifiers.

[01:50:51] So what I like to say in talking about this is that it seems the best hypothetical reaction of anybody who hears this is, “Okay, you complexity theorists, you play in your sandbox and you build all these sandcastles and make up all these models that have nothing to do with anything just because you can.” Once you get weird enough, you get weird enough consequences.

[01:51:20] So one message which I think is very powerful is that this result has absolutely fundamental impact on mathematics and physics. It turns out that it implies, and this was already done in the initial paper, resolution of well-known conjectures in mathematics and physics. It turns out that, weird as it is, it’s a new mathematical technique to solve problems that nobody had any idea about. Famous problems, important problems that fields were dedicated to, are resolved by this result, by the techniques of this result.

[01:52:05] So you ask about the impact of quantum computing. The impact spans many generations with different motivations and developments, but all of them following the methodology of complexity theory, understanding the power of computational models, proof systems, and so on, has magically led to such a consequence. We are just at the beginning of this, right? This type of proof technique is now being explored and used, and there are more results using this type of technique to address long-standing problems.

[01:52:44] Pretty amazing.

Ryan:

[01:52:45] That’s incredible. Yeah, I mean, in complexity theory there are these Venn diagrams of all possible problems. The implicit assumption in this picture is that these are decidable problems.

Avi:

[01:53:02] Yeah, yeah.

Ryan:

[01:53:03] In some of these diagrams, there’s a little in the corner. Undecidable.

Avi:

[01:53:09] Yes, unreachable.

Ryan:

[01:53:10] Yeah, right. And it’s just, I can’t, I don’t even understand how you could verify an undecidable problem.

Avi:

[01:53:19] It’s a 200-page paper. It builds on ten years of understanding, which involves a lot of development in quantum algorithms and quantum proof systems, but also relies on techniques from classical proof systems related to coding theory and various algebraic methods used to prove, for example, the PCP theorem, as I mentioned. It’s a huge body of work, and on top of this, they wrote this 200-page paper in which they had to develop many more tools.

[01:53:56] And yeah, there you have it.

Ryan:

[01:53:58] Wow. I mean, when someone produces 200 pages of such complicated work that makes such an outrageous claim, how does that get verified by people?

Avi:

[01:54:12] I mean, it’s a very good question. This tool is for any mathematical result that is complicated. Of course, proofs of P versus NP and the Riemann hypothesis are generated very frequently, but some of them were generated by very serious people and took a long time to refute in these two cases. Others, like the Perelman proof of the Poincaré conjecture, one of the Clay Millennium Prize problems, was another one like that.

[01:54:53] And this took several years to verify and fix small bugs in. Books expositing this proof were written, and eventually, this particular paper is for some reason still in the referring stage of the Annals of Mathematics now, probably almost six years; it will be done. It’s robust in the sense that already new papers were written with this type of tools, in fact giving somewhat alternative proofs of the same statements and stronger statements in order to resolve other mathematical conjectures.

[01:55:29] But yeah, it’s a serious thing. In fact, the original paper had a bug, like the original paper with Fermat by Wiles. Fermat’s Last Theorem also had a bug, and it was fixed. This was very early on, just when it came out, and it was fixed very quickly. So any mathematical claim—your question is very important. In general, mathematics is a mathematical truth that is a social construct.

[01:56:04] That’s what mathematicians believe. Maybe we are moving into a world in which we have lean proofs. We have formal ways of writing proofs, and you can maybe formally verify them. But anyway, I think that this community is quite certain about.

01:56:24 — Math vs computer science

Ryan:

[01:56:24] Yeah, in complexity theory, it’s very mathematical in nature when I read the papers, but obviously it has implications in computer science. What’s the relationship between mathematics and computer science to you?

Avi:

[01:56:39] Well, the theory of computer science, my field, complexity theory and algorithms, is really lucky to have these two parents. It lives in both spaces. It is a mathematical field in the sense that most of what we generate are theorems and proofs in the mathematical sense. On the other hand, it relates to computation because the kind of questions we ask ourselves, the problems we are trying to solve, are partly motivated by trying to understand computation.

[01:57:19] So you can think of theoretical computer science very much like you can think about analysis, algebra, and topology. There are notions in algebra where you are trying to understand equations or systems of equations. In analysis, you are trying to understand, very generally speaking, inequalities and continuous spaces. Right? So there are these notions you are trying to understand. Computation is one of these notions where you are trying to understand what you can produce by an evolution of simple local steps through a given environment.

[01:57:59] The input can be a sequence of bits, or it can be the DNA of a person, from which you produce proteins using computation, or you produce a new baby using the evolution of a fertilized egg, or the weather. Computation is sort of everywhere, and we are trying to understand it in ways that are different as we care about resources—how much resources are exerted in any such computation. We are trying to model it, understand the algorithms, and let the underlying natural phenomena inform our understanding.

[01:58:48] So we live in both spaces. We have a lot of input of problems and models from industry technology systems and so on. And we have all the mathematics, so we have the rigorous side coming from and the aesthetic side, I would say, like creating models of proof systems because they are nice, because they are interesting, not because they are implementable necessarily.

[01:59:21] So this living in these two spaces is extremely beneficial to this theory of computation.

Ryan:

[01:59:32] You mentioned earlier that some people might have the perspective of complexity theory that it’s kind of solving problems for problem’s sake. I read in another interview you did that you were never motivated by application. My natural thought was, what motivates you to solve all these really tricky, complicated problems?

Avi:

[01:59:54] Okay, so let me say one thing about the beginning of your question. It says about solving problems. I think that what we do more, much more, is modeling things. Modeling things then gives rise to problems that you want to understand. So I think the modeling part in the theory of computation, modeling various forms of computation, is a large part of theoretical computer science and manifests itself in particular in cryptography.

[02:00:23] Well, there are models of adversaries in distributed computation. There are many. I think modeling, just asking questions, and creating definitions is a very central part of the field. It happens more than in mathematics, maybe because they are more ancient and definitions happened earlier. But I want to stress this; it’s a very important thing. For example, we discussed randomness, and our definition of randomness is totally different, which gives rise to very surprising and interesting practical theorems.

[02:01:06] Okay, now that we said that, what motivates me or what motivates other people? Of course, everybody has their own motivation. I am a product of computer science education. All my undergrad, grad school, postdoc, and everything were in computer science. I certainly regret not taking many more math courses because then I wouldn’t have to learn these later in life. But that aside, I think that the focus on computation, which is what computer science education gives you, is different. Different systems and different issues are, of course, algorithms in databases and algorithms in programming languages, and in fact, famous algorithms in other fields.

[02:02:02] There are models and algorithms. Computation is something that I’m interested in intrinsically. Over the years, I’ve realized that computation, you know, the field expanded to interact with all the sciences, and that computation happened everywhere in various forms, in physics, biology, and so on. It makes it a fundamental object of study. For me, given the way I was brought up, I guess it is particularly fascinating in itself.

[02:02:34] I know from experience that lots of the proofs we develop, not many, but probably with much higher proportions than in other areas of math, are impactful in the world, in real systems, in security systems, in blockchains, in the real world. But this particular side of seeing exactly how you translate your algorithm into a system or your zero-knowledge proof, I predicted when we came up with the zero-knowledge proof that this would never be implemented, because the protocol that I described more or less to you is very costly.

[02:03:20] I mean, you want to prove that I’m producing a product of two primes, and I convert it to a map, and then I do all this complicated procedure many times. It doesn’t seem that anybody would ever use such a thing. But yeah, I was wrong. I didn’t realize how motivated people can be and how important applications of zero-knowledge proofs can be in the real world, not in the theory of protocol design. They did simplify, maybe using more assumptions, different assumptions.

[02:03:54] There’s a recent breakthrough of a postdoc here, Ilango, you may have heard, because it gets some publicity in Quanta and so on, where he introduced into the assumptions of cryptography not just hard computational problems, but also things of the nature of Gödel’s theorem, that something is unprovable in some mathematical proof system like formal frameworks, whatever mathematicians use. Somehow using that, they can get zero-knowledge that’s non-interactive.

[02:04:28] You can get. Yeah, it’s an amazing thing. It gets richer. What I want to say is that, again from experience, I have 45 years of experience in this field, which has been fascinating. I mentioned to you in the email that there are extra benefits to this field. I think the community is amazing. Not just that it has so many brilliant minds, but young brilliant minds are entering the field all the time. It’s also very lively, interactive, and collaborative.

[02:05:14] Yeah, many of my best friends are also colleagues, so it’s fantastic. The theoretical understanding of many things that we may ask ourselves for aesthetic reasons that are mathematical, we generalize something for generalization’s sake, which may not have a counterpart in industry. In fact, Peter Shor‘s work on quantum algorithms raises the question, why do that? There are no quantum computers.

[02:05:49] Maybe let’s wait until somebody builds one and we understand why. So, no, the answer is no. You should try to understand whatever is natural for you to understand. This field has already, maybe it was not clear 40 years ago, but it is clear now that lots of theoretical understanding is not just a product of mathematical results, but because it is about computation, it is meaningful.

[02:06:25] I don’t know often enough in the real world. There are many other examples besides cryptography and quantum computing, including theory. The field has revolutionized coding theory mainly because of the PCP theorem tools needed for it. There are lots of examples, and this eventually went into systems, like memory schemes. Look, I’m interested in P versus NP.

[02:06:57] This is a question about impossibility, right? This is a problem. We still haven’t gotten closer to this, at least in the years I’ve been at it. We are not much closer to showing hardness for anything. We don’t know that multiplication is harder than addition. It’s a basic question. So this kind of question by itself is certainly not practical. I mean, it’s not clear. Well, it is a little clear because if you find R functions, maybe you can substantiate cryptography on a theorem rather than on an assumption.

[02:07:35] But anyway, there are questions in the field that don’t directly relate and will not directly relate to implementations of any system, but they are all part of trying to understand what efficient computation can do and what it cannot. Or when can you minimize resources of some type and when you cannot. And how do different problems relate to each other. This basic methodology of the field has created some wonderful edifice.

[02:08:10] And I would say that we are still in the embryonic stage of understanding computation.

02:08:16 — Major breakthroughs and his experience

Ryan:

[02:08:16] You mentioned a few times in this conversation that some people made a major discovery, which kind of broke some assumptions that were maybe 50 years old. Researchers make these advances, and I know in your career you’ve made a few as well. The time span between breakthroughs is sometimes decades.

Avi:

[02:08:38] a major discovery sometimes because a lot of

Ryan:

[02:08:41] people’s careers, like maybe if you’re just an engineer, you got your shipping projects every year. But in your case, let’s say you discovered P versus NP or something like that.

Avi:

[02:08:56] Yeah.

Ryan:

[02:08:56] How do you feel when you make those discoveries, those sparse discoveries in your career?

Avi:

[02:09:02] It’s great. Yeah, it happens. The big ones happen. The biggest, rarely I think of science—I mean realistically, science and math is a community of ants working. Most progress comes from these conferences, theory conferences, and folks, and then we have all sorts of satellite conferences. There are hundreds of papers in them, satellite, I mean, focused on concrete areas and learning theory equipped.

[02:09:33] So I know online algorithms. There are many, many thousand researchers working in this, I don’t know, maybe. And they are producing many papers a year. Most of my papers are, you know, we make a little progress in understanding something. Usually, it’s not a big problem; we discover a variant of a technique or we can strengthen a bound on some. I find this essential.

[02:10:05] I think this is true in science in general. Bigger understandings come more early, and they send a shockwave to everybody who learns them and uses them. But of course, those bigger understandings don’t have to be a resolution of 50 years of papers. It can be something that, when Barrington discovered his algorithm for counting that I mentioned, he was trying to actually prove that it’s impossible.

[02:10:39] And it was not like somebody asked this question; the answer was obvious. It’s impossible. Right? So when you have an insight of this type, it’s amazing. Whenever you realize something really new for you and for the community, it’s a phenomenal result. It’s rare. I tell all my students and postdocs that, yeah, it’s not, you know, you don’t work for the million dollar. The million dollar is nothing, of course, for some of these problems.

[02:11:12] But yeah, you work because you enjoy the practice of it. You enjoy thinking about the problems. In fact, most days in the life of a mathematician, unlike a systems person, you go in the morning, you come back in the evening, and you fail to do what you wanted to do. You just couldn’t. You just thought more. And I think that it’s really important. It’s not for everybody.

[02:11:45] Clearly, it’s not satisfying if this happens every day and every week. It’s not for everybody, but it’s for the people for whom this activity of trying to think, of throwing ideas, of failing, but learning from the failures, is meaningful. People don’t realize that often you learn. The fact that you failed is not just a wasted day. There is something that you gain from it, maybe subconsciously, that will help you later.

[02:12:17] So unless you enjoy this activity, maybe this field is not for you. Yeah, and then you see something, and even if it’s small, sometimes it’s very satisfactory.

02:12:31 — Advice for his younger self

Ryan:

[02:12:31] Last question for you. I think people in the field might be curious because you have so much experience. If you could go back to the beginning of your career when you just started becoming a researcher, is there any advice that you’d give yourself?

Avi:

[02:12:48] I think I was lucky enough not to think that I would change anything. I think I was lucky enough, and many people are lucky in this field because the field is so accommodating to young people. It’s completely leveled; there are no hierarchies. People would go to conferences and meet. I remember my first conference meeting Dick Harp, who was in the field and invented, you know, did all these NP-complete things.

[02:13:23] And I was a first-year graduate student, and somebody introduced me to him. He immediately asked me what I was doing, and I said I proved that some problem was NP-complete, and it was actually interesting. It amazed me. I was lucky to have phenomenal mentors as an undergrad. As a graduate student, I was lucky to have unbelievable collaborators over the years. You learn from all this.

[02:13:52] So it’s not very informative advice to tell people to be lucky. I think this environment exists. One piece of advice I give everybody is that in the early stages, they should work on things they enjoy the most. When you are discovering your talents as a researcher, one direction may be these are all problems. If you solve them, then you. But maybe those aren’t your problems; maybe it’s not your affinity to them.

[02:14:28] You have to experiment with the type of problems. It’s good to have a variety of areas and papers to read in these areas or problems to understand. It’s always good to start with a few to better understand your capabilities. Often, what you like most is what you are better at.

The conversation was a lot of fun and I’m glad a lot of his takes are refreshingly not “doomer” takes. Below are the top three takeaways I had from the conversation to save you time.

You can find the full conversation on YouTube, Spotify, Apple Podcasts. The transcript is on Substack if you prefer to skim.

Brought to you by:

WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code

Takeaways from the conversation:

1) Career advice for the AI era - His take was that software isn’t about syntax or algorithms. It’s all about conceptualizing problems and coming up with clean solutions for them. And to build that muscle takes experience. He urged that people shouldn’t stop exercising that muscle or you’ll atrophy be left behind. Use AI but also make sure you aren’t being passive in your learning.

The other major point he had was that using Claude Code isn’t that hard if you are a good engineer. The value isn’t in memorizing the details and learning all the latest AI tools. The important part is building things and solving problems that matter. He said you should just ignore Twitter for the most part and focus on what actually matters.

2) Fixing broken team incentives - The problem we discussed is when a team’s identity, mission and name all revolve around a system they own. What happens is these teams end up trying to protect the system rather than doing what is best for the company.

The example fix James gave is when he was at Dropbox, he worked on a huge migration to move off of AWS. The resulting team was named after the system they built. He went out of his way to rename the team the “Storage team” instead.

The reason this was so important is he felt that the direction of the team should be oriented around the problem they are solving for the company. Otherwise, imagine if moving back to AWS turns out to be better for the business. The team named after the existing system would have natural incentive to battle doing the right thing. He called this phenomenon “system bias”

3) Simple systems are the goal - To the untrained eye, simple systems can seem obvious but actually designing simple systems is much harder than building complex ones. And the key James mentioned is that simplicity reduces operational burden. Simple systems are easier to keep running and debug when they break.

I asked him for a concrete example and he shared how Dropbox managed the metadata for where files are actually stored. All they did was have a cluster of 1000 MySQL nodes that stored the block ID and its location. Many people would say it wasn’t sophisticated but all the alternative proposals would ruin observability and simplicity of querying this data.

The idea of complexity being incentivized in larger tech companies frustrated him. To him, the goal is to solve the problem not to check off the box for complexity.

I am really excited about some of the future guests that are coming on the show. I love the interviews with the people who have a piece of computer science history in them.

Also, I’ll have some AI research folks on soon too. Many people have requested I bring them on so people can learn how to future proof their careers.

Lastly, I interviewed an award-winning complexity theory professor from MIT and asked him some Leetcode questions. His optimal solution was asymptotically faster than what Leetcode says is “optimal”

Thanks for reading,
Ryan Peterman

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

Timestamps

0:53 - Systems work during his PhD

13:05 - Dropbox technical deep dive

21:57 - Why Dropbox migrated from AWS

36:40 - How to do massive migrations

44:31 - Simplicity vs complexity in promos

49:23 - What technical teams should be focused on

1:00:25 - Doing the right thing vs promo hypothetical

1:08:13 - Why he dipped into management sometimes

1:11:36 - Why you shouldn’t lead by example

1:23:23 - How to mentor Senior Staff+ engineers

1:27:30 - Career advice for the AI era

1:37:21 - Why he started his own company

1:46:05 - The most technically challenging work of his career

1:48:10 - How he got involved in Silicon Valley

1:52:16 - Career regrets

1:55:54 - Top technical book recommendation

1:56:36 - Younger self & permanent underclass advice

Transcript

0:53 — Systems work during his PhD

Ryan:

[0:53] Here’s the full episode. First off, your PhD thesis was huge. It’s 156 pages. I didn’t know theses were that long; I thought papers were maybe 10 pages or something like that. It’s its own book.

James:

[1:12] It’s very similar to Spanner ultimately. What’s funny is I did that work; it came out a little bit before Spanner, so I got a citation in the Spanner paper. But then Spanner came out, and everyone kind of forgot about my paper.

Ryan:

[1:27] You know, about the research. If you could kind of describe the problem that Granola was solving and how it solved it, those types of things. We can talk about that.

James:

[1:38] Yeah, absolutely. So my interest in my career has been two parallel threads. One has been abstractions in general, the idea about how to build simple models for complex problems. I find that a very difficult and intellectually stimulating design exercise—how to design APIs, basically. The other has been large-scale transactional systems. I’m a big fan of transactions. A transaction is doing a bunch of things at once, and I think transactions are just one of the most incredible abstractions we’ve invented because they allow us to manage probably the most difficult problem in computer science, which is concurrency.

[2:22] Granola was an algorithm for how to do distributed transaction coordination, particularly for transactions that I described at the time as one-shot transactions. I’m not actually sure if that was a standard term at the time or whether I made it up. A one-shot transaction means you send some code to the server and say, “Run this function, all these reads, all these writes on two, three, whatever nodes at once.”

[2:55] And how to make sure this commits atomically across multiple shards in a distributed system. That was my PhD thesis, and my master’s thesis was on Byzantine fault tolerance, a consensus protocol in the presence of malicious nodes. It focused on how to achieve agreement in state across multiple parties when there are malicious entities. I guess the most well-known work I did as part of grad school was on a paper called View Stamp Replication Revisited.

[3:27] And that was a paper on redefining a protocol called View Stamp Replication Revisited, which predated Paxos. It’s a very similar algorithm. Paxos, Raft, and View Stamp Replication are all based on virtual synchrony; they’re all basically the same thing. That was a paper I wrote at the time, which ended up being influential to a few really great companies like Tiger Beetle.

Ryan:

[3:53] You mentioned transactions, and I saw in the paper there’s this idea of an independent transaction. If I’m understanding correctly, a lot of the efficiency in a distributed system is lost by needing to get consensus and to vote for consensus. In your research, you found a way to avoid needing to vote to reach consensus. How did you do that?

James:

[4:20] Yes, I mean a lot of people think about performance maybe from the wrong angle because I think of performance as a factor of just this raw horsepower, how fast are your disks, how fast is your network, etc. No one has particularly faster disks or memory than anybody else. What really matters to performance in a large-scale system is eliminating points of coordination. So it’s how to allow systems to progress without having contention between parties.

[4:53] Where you’re basically reducing parallel throughput to serial throughput across large numbers of transactions. In Granola, we had this idea called an independent transaction. Again, that was the terminology at the time where there were two entities basically processing pure functions. They have independent state and they’ll both come to the same conclusion as a result.

[5:16] And all they need to do then is serialize those transactions. They have to decide if it was to happen atomically across multiple nodes, what timestamp should it get. Granola, the paper, was mostly about how to exchange these timestamps very efficiently. So, how to have multiple parties each propose a timestamp and then choose the maximum of these, basically so you could safely serialize the transaction.

[5:42] And there’s a lot more complexity that goes into this. But really the focus there was about how to maximize throughput in a large distributed system without resulting in the alternative, which is two-phase commit and two-phase locking. Two-phase commit with two-phase locking is basically the standard approach for when you want to have multiple nodes agreeing on the same thing, where they both agree to lock their state, not process any other data, and then commit a transaction.

[6:09] Two-phase commit can be quite low performance because you’re blocking basically the systems for the duration of the transaction. It can be high risk too because you are taking a dependency on another node; you’re basically blocked waiting for another node to return. And so that was what Granola was. Now, it’s funny you asked about Granola because I forgot about it.

[6:33] That’s so far in my history, I kind of forgot about that work. I even forgot the phrase “independent transactions,” to be honest. It’s great to hear you bring it up again. But I guess all this stuff does feed into all the work you do later on in interesting ways.

Ryan:

[6:48] When I think about distributed systems, I think about you’re at a big company and you got a bunch of machines. But when you were at MIT building this thing, how did you build and test it? Were there spare machines that the college had, or was this in the cloud?

James:

[7:05] Yeah, this was a long time ago. Now I’m showing my age. This is pretty early in the days of Amazon Web Services. We had a rack of servers in our office that we could use. I was fortunate enough to be at MIT where we could afford a rack. There was also a service called Planet Lab, which was a big communal set of nodes that academics could use to run tests. But Planet Lab was a communal system.

[7:34] And so it was continually having problems. It’s just a free for all. For the longest time, I would just sleep next to my desk and wake up whenever. Planet Lab was free. Because you need to run some benchmarks these days, you just spin something up on Amazon Web Services. But then I would sleep next to my desk, and I would wake up in the middle of the night or at random times and check Planet Lab status and then kick off a benchmarking job.

[7:58] Now this was right at the cusp of when, in some respects, Google ruined systems research. I say that with affection and respect to Google because before then, most of the research was coming out of academia. A lot of distributed systems research was done on smaller scales, and a lot of the value proposition was the ideas. So, like, hey, I wrote a paper, here’s an interesting new idea, and yeah, it’s all in theory.

[8:28] And so the value that came out of it was the idea. Around this time, you started seeing papers out of Google, Amazon, and these various companies where it wasn’t necessarily a paper about an idea; it was a paper about a system. Hey, I built this giant system, it has a whole bunch of features, some of which are interesting, some of which are not, and by the way, it powers Gmail or whatever. That kicked off a pretty interesting transition because at that point, program committees reviewing papers started to expect to see realistic benchmarks that, frankly, grad students were not able to produce at least at the time.

[9:08] I mean, I wasn’t running Gmail on my system, and I think it did, in some respects, obscure intellectual ideas. I’m more for papers about systems. But I think there’s also value in a paper about an idea. It’s not just, “We built this big thing, and it works, and it’s up to you to figure out what’s interesting about it.” Instead, it’s, “Here’s a new thing.” There’s a paper, an old paper just called Leases, where someone invented the idea of a time-based lock.

[9:37] And it’s just a paper called Leases. That was a cool era of systems research. I think a lot of it now has shifted towards industrial research, where people are building stuff for practical purposes. Whereas I think it’s hard for academia to compete on pragmatism. Academia is really a great place to do impractical work.

Ryan:

[9:59] When you look back on getting the PhD in academia, being enabled to completely explore an idea versus going into industry, maybe working on Spanner at Google or something like that, which path do you think would be better and why?

James:

[10:18] I think that’s a bit of a misconception a lot of folks have about PhD programs. A lot of students are high-achieving students in college, and they think that the PhD program is college. It’s like, hey, I like learning things, so I’m going to go do a PhD, but it’s not. A PhD is training to be a researcher, and for most people, they shouldn’t do that. If someone wants to be a professional software engineer, they probably shouldn’t spend their time training to be a researcher.

[10:46] But with a really important caveat, I think there’s a really interesting and challenging developmental experience you go through in the PhD program at a top university, at least. You reach a certain point in time when you have a problem that you’re facing that no one else in the world knows the answer to. You have a problem that you are the world expert on, and you can’t chat about it with folks, but you can’t ask your advisor because your advisor doesn’t know either.

[11:12] Right. So you face these difficult challenges where you can’t read a book, you can’t ask Claude. And so you’re forced to go through a quite difficult and, frankly, emotionally challenging experience of being unsure, being uncertain, and learning to think for yourself. I think that is really valuable for all engineers. I think that was really, really valuable in my career.

[11:39] I do see a lot of folks early in their career think that all knowledge comes from reading or absorbing it from someone else, or that there’s a right way to do things. But I think being in a PhD program or being faced with really demanding, open questions does train your mind to be comfortable with that discomfort. I feel a little bit lucky that I went through grad school without large language models existing because I had to deal with this uncertainty.

[12:15] There was no crutch to help me out, which I think was very valuable.

Ryan:

[12:18] So, I mean, a lot of, if you want to be a researcher, go do a PhD. If you want to build stuff, go build stuff. Since leaving academia, I’ve done a lot of work that I guess one could call innovative. It advanced the industry in certain ways and did novel stuff. But our goal was never research. Our goal was just to solve problems.

James:

[12:22] I mean, a lot of, if you want to be a researcher, go do a PhD. If you want to build stuff, go build stuff. Since leaving academia, I’ve done a lot of work that one could call innovative. It advanced the industry in certain ways and did novel stuff. But our goal was never research. Our goal was just to solve problems.

[12:47] And I think that’s the difference. In academia, your goal is to advance knowledge. In industry, your goal is to solve problems. I gravitate more towards just solving problems, and I find that a more comfortable environment within which to work.

13:05 — Dropbox technical deep dive

Ryan:

[13:05] Going to your time in industry, at Dropbox, you became the most senior engineer at the company. Looking through all the projects that you did, I had a series of just technical curiosities. I saw this idea early in your career about multi-homing, and I wasn’t familiar with that concept. What is multi-homing? What’s the problem it solves?

James:

[13:27] Yeah, I mean, multi-homing is the ability to have data in two locations, two homes. Multi-homing can be valuable for a variety of reasons. One is called primary-secondary or lazily replicated multi-homing, whereby all writes commit authoritatively in one region and get replicated to a secondary region. This is normally used for business continuity. One thing we did at Dropbox was to ensure that if the entire West Coast blew up, which hopefully wouldn’t happen, Dropbox would keep running because the data would be replicated in other regions, but with a window of vulnerability, with a window of time where there may be some data lost.

So that is, you know, that’s kind of primary-secondary replication or multi-homing. There’s something else called active-active multi-homing where there is truly an authoritative copy of the data in multiple locations. Basically, when you, for example, write to a system, you don’t externalize that write as having succeeded until it has landed in all the regions. For example, in the storage system at Dropbox, the block storage system, we truly had a multi-region replicated system where we could take down an entire region, say take down the region in Ashburn, Virginia, where everyone’s data centers are, and there’d be zero downtime for the company and the data was still safe in multiple regions.

[14:13] So that is kind of primary-secondary replication or multi-homing. There’s something else called active-active multi-homing, where there is truly an authoritative copy of the data in multiple locations. Basically, when you write to a system, you don’t externalize that write as having succeeded until it has landed in all the regions. For example, in the storage system at Dropbox, the block storage system, we truly had a multi-region replicated system where we could take down an entire region, say take down the region in Ashburn, Virginia, where everyone’s data centers are, and there’d be zero downtime for the company, and the data was still safe in multiple regions.

[14:54] I think multi-homing is something a lot of engineers aspire to work on because it seems like the right thing to do. But the reality is for most companies, it is not. Not because there’s very high cost, but because there are very high latency costs for this. The speed of light is fixed. If you have to synchronously write data across multiple regions in the United States, you’re going to have, say, 60 milliseconds in the commit path of your protocol, which for most applications is not tenable.

[15:32] So there is a lot of desire; a lot of engineering teams reach out for advice on how to adopt active-active multi-homing for their company. I would normally say don’t do it. Frankly, if US East is down, if Amazon is down that day, that’s okay. If Amazon’s down that day, your company will be down. That’s a shame, right? But by avoiding that complexity, you’re going to be able to move much faster and build a much better product.

[16:00] And so in my mind, systems are all about trade-offs and making the right ones. I would generally recommend most people do not make the trade-off to have partition tolerance or multi-region availability. Even though for a company like Dropbox, yes, that does make sense. When your job is storing data and you have several exabytes of it and hundreds of millions of customers, I think that’s when it starts to make sense.

Ryan:

[16:26] So it’s just another term for, I guess, data replication and having it available in other regions. I imagine also, I mean, the cost of storage is a concern. How many replicas would you keep for something like, let’s just say I stored something in Dropbox? It’s my document. Is that on the order of one or two, or are there multiple?

James:

[16:47] No, it’s on the order of many. Many. If you were to store a file in Dropbox, I modeled the storage to be, as we advertise, at least 12 nines of durability internally. The models look around 24 nines of durability. That means the data is secure with 99.9999% where there’s 24 nines. Right? Which means, at least according to the model, the universe will be extinct before any data is lost.

[17:20] And the way that is done is by a combination of what’s called erasure coding. Erasure coding is how you take several blocks of data and combine them together with an encoding scheme and spread them around in different locations. At that scale, at Dropbox scale, you’re taking things into consideration, like putting data in different racks, different rows of a data center because they’re on different power feeds.

[17:41] You’re taking into consideration different eras of hard drives and different manufacturers of drives because they could have correlated failure patterns and then replication across regions. So you could be looking at 27 fragments, for example. That doesn’t mean you’re storing 27 times the data. It’s kind of encoded in many regions. But the replication schemes get really quite sophisticated at that point.

[18:06] And we actually had our own custom encoding matrix we had developed. It’s called a Vandermonde matrix, where you take a bunch of data and combine it together to produce outputs. We would plug in some variables like how much do disks cost? How much does network bandwidth cost? Because there’s a trade-off. You can either store, if you don’t want to lose your data, more copies on more disks, or you can store fewer copies.

[18:33] Anytime a disk fails, you re-replicate it really fast. Re-replicating really fast costs disk cross network bandwidth. These kinds of variables go into this equation. It ends up being an extremely complex field of endeavor, but it’s kind of abstracted away into a part of the system that doesn’t leak into anywhere else.

Ryan:

[18:53] So with erasure encoding, my document in Dropbox is fragmented into a bunch of different chunks of data and loaded potentially from many different machines.

James:

[19:03] Yes, absolutely.

Ryan:

[19:05] I mean, the first thought I have is now I might be waiting there, and one of the 27 machines is slow, and I can’t look at the whole document. So how do you prevent against that?

James:

[19:17] It’s actually faster than not replicated. Because if you imagine, I’ll pick a simplified example. Imagine this is not the encoding scheme Dropbox uses, but to reconstruct a file, you have to read six out of nine fragments. So if you read six out of nine fragments, you can just ask all nine and reconstruct and return the data as soon as you’ve heard from the first six. It’s actually faster.

[19:46] And you can construct these encoding matrices such that it’s actually faster to have a ratio-coded data than not.

Ryan:

[19:53] I see. Okay. So you can oversubscribe, over-request, and then you complete on a portion of them being received.

James:

[20:01] Yes. Now in practice, it was a bit more complex than that. We’d often have a copy and a single disk to provide fast access. We’d often try to make sure that you could serve your data out of a region close to your home region. So we’d make sure that your data was mostly served with low latency. But if that region had failed, you could reconstruct it from the remaining regions. So there’s a lot of talk about building your own infrastructure.

[20:28] And you can save money by moving off the cloud. Almost definitely you can’t unless you have very small requirements, very fixed requirements, or very heavy investment. Because if you want to compete with Amazon, if you want to build a more efficient storage system than Amazon, you have to have a supply chain team that’s working with Western Digital and Seagate, constantly negotiating on prices of disks and buying shipments at certain times, along with capacity teams and data center teams.

[21:00] There’s a lot of work that goes into optimizing this because ultimately our desire was to use the disks to 90, 95% of their disk size to maximize storage efficiency. To put it this way, that was, you know, I guess a ballpark figure of a $1 billion project. And it was, as far as I know, the largest ever data migration in history at that time.

[21:28] And so, an extremely large engineering project with very high technical investment. Yes, if you have that scale and you have the engineering team to do it, and you’re willing to keep innovating, if you’re willing to keep optimizing and investing effort in it, then yes, you can do it. But I think the real— I mean, the cloud has been an incredible innovation. Most people are not experts at this, and most people should not be experts at this.

[21:55] Most people should focus on their applications.

21:57 — Why Dropbox migrated from AWS

Ryan:

[21:57] When you say that most people shouldn’t, my immediate thought was, one of the big projects you worked on at Dropbox was migrating away from Amazon Simple Storage Service. So why did Dropbox migrate away from S3?

James:

[22:12] Yeah, that was a desire at the company for a long time, from even before I was there. I started at Dropbox in 2010, and I spoke to Drew, the Dropbox founder, about this project. There was a desire to control the destiny of the company from a strategic perspective. At the time, this was before Dropbox reshaped itself as being more about collaboration.

At that time, it was in the file sync and share category. Owning the file system was really valuable to the company. Ultimately, we saved a huge amount of money. And this was before the company went public. We really drove massive cost efficiencies through the project. But it was hard, in a way that I think would be very difficult to emulate without a huge investment.

[22:36] At the time, it was a file sync and share category. That was the market sector, and owning the file system was really valuable to the company. Ultimately, we saved a huge amount of money. This was before the company went public. We really drove massive cost efficiencies through the project. But it was hard, in a way that I think would be very difficult to emulate without a huge investment.

[23:03] And I do think there is a benefit to an organization from having hard problems to solve. If you have a company with extremely hard technical challenges, you can attract engineers who like working on those hard technical problems. When they’ve solved those problems, they cycle off and work on different parts of the system. After we all worked, we had such a great team.

[23:28] It was a very, very small engineering team. After we shipped the storage system reliably, we all went off, and Jamie redesigned the sync protocol, the desktop client, and I worked on the file system and the distributed databases. There’s value to a business in having that level of technical investment. But it’s like having a baby; you have to raise the baby. You can’t just build a system like this and say, “That’s it, we’re done.”

[23:59] You own it, and you have to keep investing in it.

Ryan:

[24:03] Did S3 do any counter negotiation before you set out to leave them? Did they say, “Oh, we’ll cut you a deal?”

James:

[24:12] I guess I’m allowed to talk about this now. It was a long time ago. For the longest time, I don’t think they were particularly aware that this was happening. But the data center folks talk, and certainly it was noticed that Dropbox was buying up a lot of data center space. So yeah, we had, obviously at the scales that we were at, we were negotiating very good rates with Amazon Web Services.

[24:38] We weren’t paying sticker price. We were paying very, very, very good discounted rates. But at a certain point, they weren’t able to meet our cost efficiency because when we launched the system, it really was more efficient than Amazon Simple Storage Service. And that’s for a variety of reasons. One was that we were using kind of new experimental disks called Shingled Magnetic Recording. We were the first ones, I think, to use these disks at scale.

[25:02] And two, we had a very tight understanding of our workload. We were able to design the system specifically optimized for our workloads, whereas S3 has to design the system for everybody. It got to the point where Amazon would not have been able to offer us a more competitive deal because we had a more efficient system. I wouldn’t recommend another company do this right now, but I think at the time it certainly made sense for us as a company.

Ryan:

[25:28] Can you give an example of a tight understanding of your workload leading to something you could do that Amazon Simple Storage Service couldn’t?

James:

[25:36] Yeah, absolutely. So, for example, I know that, well, I’ll try not to leak any confidential data, right? But when you upload a file to Dropbox, there is a pattern of access. Typically, people access the file very quickly shortly afterwards because you’re sharing it with someone, or maybe Dropbox is processing that file to generate an image preview, and then it decays at a certain rate. We understand in general the average block size, and we also understand the access pattern.

[26:11] So we could do things like, at a certain point, we had these two clusters. One was designed for temporary storage that was kind of storage inefficient but access efficient. It was very cheap to read and write to, but it was inefficient to store. Data would get written to there first, and then in the background, it would get moved in bulk to this colder storage system. This cold storage was far more static.

[26:40] And so it was able to have more efficient algorithms and be written to in bulk. If it went down for writes, that was no problem because it wasn’t in the live path. We were able to trade off again; like systems are all about trade-offs. We were able to trade off the live data write path from the long-term read path. That was one of many examples where knowing the size of your data, where it’s accessed from, how frequently it gets accessed, and how long it takes to delete that data, you can really tune a system to your workload.

[27:13] You know, stuff like looking at even things down to knowing how much power to put in a rack. You have a rack of hardware; there’s a power distribution unit, a PDU. At the top of that rack, it has a circuit breaker which can handle a certain number of amps. We would have to figure out how many amps are required for that rack based on access patterns. There were times where we got it slightly wrong.

[27:37] There was a time when we got maybe a bad batch of hardware, and disks were failing too frequently. As a result, we were re-replicating the data more regularly. I was getting messages from the data center team saying, “Hey, we’re running the racks really hot right now.” That’s the level of optimization you can make when you get to that scale. But again, that’s multi-exabyte scale—million hard drive scale.

Ryan:

[28:03] Yeah. When I was reading about this migration, I saw somewhere in the migration you initially started with Go, and then the racks or something that you’re running on, the hardware itself was out of memory too much or requesting too much memory. And then you migrated to Rust.

James:

[28:20] So initially, the prototype was in Python, if you can believe that. To be fair, Python is actually pretty efficient for I/O. I think people give Python a bad rap for I/O-bound workloads. It’s pretty good at I/O, but obviously not great for concurrency, not great for memory management, and very hard to refactor. It was critical the system was correct. So we migrated everything to Go, and we built most of the storage system in Go.

[28:47] This is before Go was in general availability. We built the system in Go. Go’s a great language for concurrency, a great language for proxies. It’s really well designed for servers that move from one place to another. At a certain point, though, we would have, let’s just pick a number, let’s say a million. Let’s say we have a million nodes in the system, and every node has some amount of memory, some amount of disk, some amount of sheet metal in the chassis.

[29:18] Right. We would itemize all these things. You’d have a pie chart of how much money is spent on all the things. It would include items like sheet metal and screws. So you’re trying to optimize the storage. A big problem for us was the amount of memory these nodes were using. Not just the memory that we were using, but the unpredictability of it. With Go having a runtime, in a storage system, an out of memory error is pretty bad because if a node runs out of memory and restarts, that looks like a disk failure.

So that looks a lot like a disk has failed and has to be re-replicated. A batch of nodes running out of memory can lead to cascading failures throughout the system. I remember a time it was a band; it might have been De La Soul, I can’t remember. There was a band that released an album on Dropbox, which caused a big spike in load to a few files. It was very high bandwidth and it caused the machines to run out of memory.

[29:54] So that looks a lot like a disk has failed and has to be re-replicated. A batch of nodes running out of memory can lead to cascading failures throughout the system. I remember a time it was a band; it might have been De La Soul, I can’t remember. There was a band that released an album on Dropbox, which caused a big spike in load to a few files. It was very high bandwidth, and it caused the machines to run out of memory.

[30:24] So those machines, those disks oomed. As a result, no problems; the system went to try to recover that data from a whole bunch of other replicas. Now all of a sudden, you’ve taken one amount, one fire hose worth of load coming in, and you’ve turned this into seven fire hoses worth of load coming. Because now you have to do a more expensive reconstruction operation, right? So now you’ve 7x the load.

[30:47] And these are the kind of cyclical behaviors that can lead to something called congestion collapse. Congestion collapse is when workload to a system crosses a threshold where it all kind of collapses. Designing against congestion collapse is really one of the hardest parts of Magic Pocket, which is the name of the storage system. Ultimately, we switched to Rust for the storage nodes themselves.

[31:13] And this, again, this is before Rust was in GA. So that was a bit of a risky move. But we rewrote the switch to Rust, which coincided with getting rid of the file system entirely on the disks and directly addressing the disk heads. There’s an instruction set, I think it’s called ZBC, Zone Based Block Control, something like that. There’s an instruction set for accessing disks that we were using. The disk manufacturers gave us the draft specs of these new disks, and we were operating off the draft specs and directly controlling the disks.

[31:45] And so all that product was tied up together into a product called Discotech, which was the disk technology project. Ultimately, if you look at that pie chart, congestion collapse stopped and reliability improved. But if you looked at the pie chart of where all the money was going, it really shifted to be almost all disks.

Ryan:

[32:16] Metal, et cetera, the cascading failure you mentioned was there. That happened, and then there was a postmortem.

James:

[32:23] I don’t think we needed a postmortem. I think we knew as it was happening. When I was getting paged in the middle of the night on these things, it was pretty evident. This is, again, an argument in favor of the cloud. Imagine you’ve spent hundreds of millions of dollars on a storage system, and it’s out in production on physical hardware.

[32:47] You can’t just go and put new memory chips in every one of them. I mean, you can, but you have to pay people to come in and swap them out. That’s a tricky place. This is what I love about the industry. Some of the more challenging moments on Magic Pocket were stuff like, in one week, just a weird coincidence, two trucks crashed that were delivering servers.

[33:13] So there are two trucks showing up to deliver racks, and they both crashed. I don’t know, the drivers were okay. So we lost capacity for two weeks. We lost capacity for more than two weeks, probably six weeks. What do you do? What happens is the equivalent of your disk filling up on your laptop, except it’s a million disks, and you can’t tell the customers to go away; you can’t delete their files.

[33:43] A lot of tricky capacity work. Ultimately, what that led to was trying to build in all these protections against the unknowns, making sure we had the right amount of buffer planned out for anything bad that could happen, making sure we designed the system so there couldn’t be congestion collapse and so there wouldn’t be memory spikes. At one point, there’s a process called FMEA, which is a threat modeling process where you have a big spreadsheet and you kind of write down every bad thing that could possibly happen, and then you know how bad it would be if it happened. Existential risk does someone die? If there’s a fire in the data center, all these kinds of things get put into this spreadsheet, and you kind of do a bit of a pre-mortem to figure out all the potential failure modes and then design around them. I love that work. I really, I don’t know, I do like the firefight. I can’t say I like getting paged because I’ve spent my whole life on call, but I do like that rubber-hits-the-road stuff.

[34:21] Existential risk does someone die? If there’s a fire in the data center, all these kinds of things get put into this spreadsheet, and you kind of do a bit of a pre-mortem to figure out all the potential failure modes and then design around them. I love that work. I really do like the firefight. I can’t say I like getting paged because I’ve spent my whole life on call, but I do like that rubber-hits-the-road stuff.

[34:52] I like that. Wow. There’s congestion collapse and there’s no one that can help you. You’ve got to think through this problem.

Ryan:

[35:01] When I worked on infrastructure at Instagram, we had this concept of defcon knobs, which are basically these configs that you could flip to gracefully degrade your system while still operating it. But maybe in the case of Dropbox, you store fewer replicas, so you take on a temporary increase of risk in losing data because you need to. Did you have something like that, and did you flip it in that type of case?

James:

[35:29] Never. When it came to durability, we had absolute zero, non-negotiable standards; there was no room for negotiation on user durability. We had those knobs for background processes, for CPU and memory, for example. If there was a spike in load, you could turn off background processes and then turn off the test load on the system. Eventually, we built this system called Trampoline, and what Trampoline did was save us a ton of money.

[36:05] If we ever got too close to the threshold, we would just start writing data to Amazon Simple Storage Service because it’s right there. You can run your capacity way closer to the edge if you’re willing, under worst-case scenarios, just to dump 30 petabytes on S3 and then move it back when it’s done. Now, that didn’t happen very often. We would do it to test it. We would do that just to make sure the system worked. But yeah, being able to have an escape hatch for worst-case scenarios was really nice.

Ryan:

[36:35] I see. So S3 is kind of like elastic storage.

James:

[36:39] Exactly.

36:40 — How to do massive migrations

Ryan:

[36:40] When I looked at this project, it’s such a massive migration, and my first thought is how do you coordinate this whole project without breaking the system as it’s running? What are your thoughts on doing such a large migration without breaking things?

James:

[36:58] Yeah. Now, in terms of the engineers that built the initial version of the system, it was a handful—three, four, five, six engineers. It wasn’t a team of a thousand; it was a very small team. So how do you build such a large system with a small number of people? And then how do you do a high-risk migration? One of the things you do is keep things simple. You try very hard to build cleanly abstracted, simple systems so that their failure modes are very understandable.

[37:33] And so they’re decoupled, so they don’t have congestion, collapse, et cetera. Focusing on simplicity gets tricky, by the way, with people doing agentic development. They’re not the best at building simple systems. Simplicity is still the domain of human beings for now, but there’s a big focus on simplicity. The other was this very thick layer of validation checks during this migration.

[37:58] And in fact, when we did the migration off of Amazon Simple Storage Service, we had something called the dark launch where we would be moving data off of S3, but we’d keep it in both locations. We had to demonstrate to the Dropbox founders that we would have to keep this system running with no incidents, no downtime, and no data loss for six months before we would delete any of the data from S3.

[38:26] So we have double routed, and there’s one point in time, halfway through this process, where a bug got through to production. Nothing bad happened with the bug, but it was like bugs slipped through our multiple layers of the release process, etc. I went to the VP and I said, “Hey, a bug made it through to production, and we’re going to reset the launch clock. As a result, it’s going to launch later, and it’s going to cost us some amount of money, let’s say double-digit millions.”

[39:05] And they were like, great, thank you, that’s good, I trust you. That was the cool thing. I mean, Dropbox had a lot of incredible cultural values, but that was like, okay, cool. If you’re prioritizing user safety, that’s the right thing to do. No one was mad about that. It was almost like they were proud, you know? It was just like, yes, you’re operating in accordance with the principles of this company.

Ryan:

[39:31] Okay. So it was double writing both systems for a while and then some subset of data.

James:

[39:34] for a while and then some subset of data.

Ryan:

[39:36] Yeah, okay. And then you switched over reads once.

James:

[39:39] We were sure that the system was durable and we had all the validators running in production 24/7. We were just migrating as fast as we could. I think at some point we got to 764 gigabits per second of peering bandwidth between Amazon servers and ours. Certainly, someone on the network team over there noticed that there was that much data moving out. At one point, I got a slightly nasty email from someone saying it was super weird.

[40:08] I think the phrase “super weird” is like, it’s super weird that you’re doing so many reads and not that many writes. I didn’t respond to that email. But to be fair, Amazon was a great partner for Dropbox. So Dropbox still uses Amazon Web Services. There was no concern that they would do the wrong thing by us as a company. I mean, we only had an excellent experience with Amazon Web Services. But yeah, it was a moment for us.

[40:36] It probably strained the relationship somewhat.

Ryan:

[40:41] You mentioned simplicity and intuition; it makes sense. Do you have a concrete example, though?

James:

[40:48] Yeah, I’ve got a concrete example for you. Maybe it shows the difference between academia and industry. The storage system is a giant distributed system with files stored in various locations. You need a mapping from the file to where it lives on these disks. All we did was have a cluster of 1,000 MySQL nodes, a big giant database. It was indexed by the block ID and indicated that this block is on these disks.

[41:21] And that’s pretty simple. It’s not sophisticated. Every time we’d hire someone out of academia or maybe from other companies, they would say, “Oh, this is not very sophisticated because you could use a Patricia trie or you could use a distributed hash table, and that would map a block to a set of locations.” I think that’s optimizing for the wrong thing because the really nice thing about dumping a list of files and the locations in a giant database is that it is written in one location.

[41:57] If I want to validate what happened, if I want to check all the data is where it’s meant to be, I just walk over the table and check. We had services constantly walking over the table and checking. Whereas if it was a distributed hash table or some giant complex data structure, it’s very hard to validate. Designing for validation is very important. Designing for understanding is very important.

[42:19] It’s not about getting a system to work. It’s what do you do when it doesn’t work. Right. And so having a very simple boundary, that’s a very basic example. There are more sophisticated examples that take more time to explain. But something like that is a lot of engineers will feed, a lot of engineers will want to do interesting work, will want to advance in their career. They want to be seen as an intellectual problem solver.

[42:49] And so the tendency can be to design complex systems. My argument is always that simple systems are way harder to design than complex systems. Simplicity is so hard. And I think to the untrained eye, a simple system can seem obvious. The best compliment you could ever get about anything you design is when people say, “Oh, isn’t that the obvious way of doing it?” It’s the same as Convex; people say, “Oh, isn’t that just the obvious way of structuring?” Great, because it wasn’t obvious when we did it. No one else was doing it. Everyone thought we were idiots. If after the fact people think it’s obvious, then you really nailed it. But I think it requires an understanding that simplicity is the hardest thing in systems. And because simplicity is scalable. Yes, simplicity is scalable in terms of numbers of queries per second.

[43:20] What’s that? That’s just like the obvious way of structuring. Great. Because it wasn’t obvious when we did it. No one else was doing it. Right, right. Everyone thought we were idiots. If after the fact people think it’s obvious, then you really nailed it. But I think it requires an understanding that simplicity is the hardest thing in systems. And because simplicity is scalable. And yes, simplicity is scalable in terms of numbers of queries per second.

[43:48] But what I really mean about scalability is you can take a simple system and have it run for five years, have people work in it for five years, have all sorts of features added to it, and have requirements changed because the company realized the product didn’t work the way it wanted to work and it wants to change things. It still stands the test of time, whereas a complex, over-optimized system will not.

[44:11] I think that’s the tough thing about distributed systems design, especially LLM-augmented distributed systems design. Just because something works doesn’t mean it’s maintainable over a long period of time, doesn’t mean it’s understandable, and doesn’t mean it’s cleanly architected and abstracted. That stuff’s really very hard.

44:31 — Simplicity vs complexity in promos

Ryan:

[44:31] Absolutely. And I agree with you. I think it’s the long-term beneficial thing to do. One unusual thing, though, in the industry that I’ve seen is the incentive system for engineers. I mean, you mentioned the desire for an engineer to want to be seen as someone who can do something difficult. There’s that, but there’s also the incentive system of promotions. I’ve had many friends whose promotions were rejected because their work wasn’t complex enough.

[45:01] And so that kind of forces complexity, which is kind of unusual. I wanted to know what you thought about that.

James:

[45:08] Yeah, I mean it almost angers me. I just like it so much. Partly why I started my own company. I think the ideal for anyone is to be doing work where you’re being appreciated for solving the problem. If we get philosophical, this is what it was like going back to the farming days, right? There was no incentive to make it really complicated to milk a cow because the goal is to milk the cow, and then the reward is you got milk.

At a startup, that’s the same thing. The goal is to build the system, have it work, have the users like it, have it grow, and everyone gets rewarded and celebrated for solving the problem. It gets hard to scale that. So at large companies, you end up with so many layers of organization that people end up building alternative incentive structures.

[45:42] Right. I think it sounds so silly, but at a startup, the goal is to build the system, have it work, have the users like it, have it grow, and everyone gets rewarded and celebrated for solving the problem. It gets hard to scale that. So at large companies, you end up with so many layers of organization that people build alternative incentive structures.

[46:08] Right. It’s like I’m so far away from whatever the hell we’re trying to do over here that my goal now is to get all green check marks on my OKR plan. But who cares about your OKR plan unless it solves the problem? The thing that really drives me insane is when people try to chase artificial goals. I understand that if you’re in a company like this, you may have no choice in the matter.

[46:39] But what I want to tell people is there is a better way. That better way may not be available to you; you may not have job opportunities near where you are, for example. But if you do have the ability to work at a company where you are being appreciated for problem solving, that will make you so much better as an engineer. I see this when I interview people.

[47:07] If I do a deep dive with them, they’ll say they built a system, and I’ll ask, “Why did you build it?” and they’re like, “I don’t know, the VP told me to.” I’ll ask, “How’s the system used?” and they’re like, “I don’t really, I think ads use it.” I’m not sure. This is a caricature, but I think it’s very, very hard to do good engineering in that environment. You can do competent engineering, but the best engineering comes from a deep understanding of why. This is something we just drill into the team here at Convex; the team embodies this so strongly at Convex: everything exists for the why. Don’t build a fancy load balancer unless it’s needed.

[47:32] I’m not sure. This is a caricature, but I think it’s very hard to do good engineering in that environment. You can do competent engineering, but the best engineering comes from a deep understanding of why. This is something we just drill into the team here at Convex. The team embodies this so strongly: everything exists for the why. Don’t build a fancy load balancer unless it’s needed.

[47:57] Turns out we do need a fancy load balancer. We’re building it right now. But you should always start with, why are we doing this? What’s the point? I feel for people stuck in environments that are not like this. But you know what? Try to fight the system a little bit. I do see a lot of nihilism, a lot of defeatedness sometimes amongst junior engineers, a lot of this cynicism, like, what does it matter? Who cares? It’s just a big organization and nothing matters. But I think it does matter. If I think of the happiest times in my life, it’s been dedicating myself to a cause, trying really hard, and trying to do the right thing. I felt good when I went home, not trying to get promoted, just trying to do the right thing and then assuming I’m going to get promoted. If not, go somewhere else.

[48:26] Who cares? It’s just a big organization and nothing matters. But I think it does matter. If I think of the happiest times in my life, it’s been dedicating myself to a cause and trying really hard to do the right thing. I felt good when I went home, not trying to get promoted, just trying to do the right thing and assuming I’m going to get promoted. If not, I’ll go somewhere else.

[48:53] I know it does sound quaint when I’m saying this, but I think it’s possible to do this, and especially possible if you surround yourself with people like this. If someone is in a big company and they’re feeling frustrated by politics, look around and see if there’s a team of folks who just seem to want to do the right thing, just seem to want to do good stuff. I don’t think that’s selling out. I think that’s being true to yourself. That’s what real engineering is. Not trying to make a complicated fancy thing to get promoted. Just build the coolest thing that solves the problem.

[49:13] I think that’s being true to yourself. That’s what real engineering is. Not trying to make a complicated, fancy thing to get promoted. Just build the coolest thing that solves the problem.

49:23 — What technical teams should be focused on

Ryan:

[49:23] This really reminds me of something you had written. I thought it was really good writing. In the writing, there was this idea of system bias. You have this quote you’re writing. It says, here are some examples: the team is spending six months to improve performance by 10% when it was completely fine to begin with, or the team is trying desperately to force their tooling on clients who don’t need it.

[49:49] Or the team is riding their outdated system to the grave like the captain going down on the Titanic. I’ve definitely seen examples of all those types of things in industry. And so, yeah, I think it was in the context of your writing about what you should orient your team around. Not systems, but actually missions. And maybe that’s a way to fight system bias.

James:

[50:20] Yeah, I mean, one of my jobs at Dropbox wasn’t the most fun job, but it might have been one of the most impactful jobs. It was shutting down projects. You know, looking around and being like, huh, that thing over there that has had 60 people working on it for two years doesn’t seem to make a lot of sense to me. And then I, you know, it wasn’t a hostile thing, but I’d go and chat with a team and I’d say, hey, what are you all doing?

Do you believe in what you’re doing? Does this make sense? And the team in private would say, I don’t really know. But inertia is so strong. You know, this whole desire to not get in trouble, to just keep doing what you were previously doing is so strong, and talented people can end up doing things that don’t make a lot of sense. One of the things I said in that article is it’s kind of a cheesy story, but when we started building the storage system at Dropbox, the team was called the Magic Pocket Team because that was a silly code name for the system we built.

[50:44] Do you believe in what you’re doing? Does this make sense? The team, in private, would say, “I don’t really know.” But inertia is so strong. This whole desire to not get in trouble, to just keep doing what you were previously doing, is so strong, and talented people can end up doing things that don’t make a lot of sense. One of the things I said in that article is it’s kind of a cheesy story, but when we started building the storage system at Dropbox, the team was called the Magic Pocket Team because that was a silly code name for the system we built.

[51:17] The team was oriented around building that system, but as soon as we shipped it, I renamed the team to the Storage team. That actually took a bit of work because you had to rename all the email addresses, the channels, the repos, and the things. It seems like a waste of time. But my argument to the team was that the responsibility of the storage team is not to advocate for Magic Pocket, the storage system. It’s to solve the needs of storage for the organization. Because who else in the company knows more about storage than the storage team? If there was a point in time where S3 was a better idea, it would make sense to move back. Or maybe there was a different kind of storage system that meant to use. Right. It’s the job of the storage team to advocate for moving back. Right. And so I’ve seen this before.

[51:46] It’s to solve the needs of storage for the organization. Because who else in the company knows more about storage than the storage team? If there was a point in time where Amazon Simple Storage Service was a better idea, it would make sense to move back. Or maybe there was a different kind of storage system that meant to use. Right. It’s the job of the storage team to advocate for moving back. Right. And so I’ve seen this before.

[52:12] You have a team called the Puppet team. People don’t really use Puppet that much anymore, but for the job manager, Puppet versus Chef. They’d be kind of advocating for their team’s thing when really a team should be oriented around what problem they solve. They should not care about the system that survives. Because if you are on the Magic Pocket team and someone says we should move back to S3, that’s pretty threatening to your identity and your career.

[52:44] But if you’re on the storage team and it turns out it makes sense to move back, I don’t think that’s the case. But then that’s an exciting new product for you to own. I think it seems like such silly management philosophy, but I think it’s really, really important to orient a team and an identity around solving a problem and not owning and defending a system. You just see this in big companies. Inertia is so strong.

[53:07] Inertia is so strong.

Ryan:

[53:10] Yeah.

James:

[53:10] And you see people doing things they don’t believe in because that’s just what they do.

Ryan:

[53:14] If inertia is so strong, how did you fight it and close down all those projects?

James:

[53:20] I think I got lucky insofar as I was there pretty early on and I worked hard enough. I was putting in probably 16-hour days at the start. I’m not advocating for that, but I was dedicating my life to the company, and I think it became pretty obvious to people that I cared. This is a guy over here that really wants to do the right thing and cares about the company.

[53:42] At that point, you build up enough confidence, capital, that you feel comfortable saying things. I wasn’t afraid for my career; I was afraid of the wrong decisions getting made. So I felt psychologically comfortable making observations. Then at a certain point, there were a lot of engineers. I would mentor many of the staff plus engineers at the company.

People would sometimes get grumpy because they felt we weren’t doing the right thing or that something was inefficient. Every engineer listening to this has a story like this; they’re annoyed about some inefficiency at the company. My response was generally, do you think we should solve this problem right now? Because if we should, let me know the team to take some engineers off and the product to shut down, and I can redirect resources so we can solve this problem right now.

[54:16] And people would sometimes get grumpy because they were like, “Oh, we’re not doing the right thing over here,” or “This is inefficient.” Every engineer listening to this has a story like this. They’re annoyed about some inefficiency at the company. My response was generally, “Do you think we should solve this problem right now? Because if we should, let me know the team to take some engineers off and the product to shut down, and I can redirect resources, and we could solve this problem right now.”

And they’d be like, “Oh, well, we shouldn’t shut down any other stuff.” I’m like, “Cool, well, we just have this many engineers right now. If there’s anything lower priority, let’s stop doing the lower priority thing and do the higher priority thing.” Oftentimes the answer was, “Oh no, nothing else is lower priority.” Then the answer is we just have to accept it. Just have to accept it, right?

[54:42] And they’d be like, oh, well, we shouldn’t shut down any other stuff. I’m like, cool, well we just have this many engineers right now. If there’s anything higher or lower priority, let’s stop doing the lower priority thing and do the higher priority thing. This thing. Oftentimes the answer was, oh no, nothing else is lower priority. Then the answer is we just have to accept. Just have to accept, right?

[55:06] There’s no point in being angry or upset that we’re not doing the right thing all the time. I think there’s a dimension to “you break it, you bought it.” I don’t think, when I said part of my job was shutting products down, it was just going around causing problems. Ideally, it’s about solving problems, like, “Oh, this product is not going in the right direction, let’s redirect it and do this alternative thing.”

[55:28] And so I think the thing that helped me, I guess, was having a sense of ownership that instead of complaining, I just wanted to go fix problems. That was part of the culture. I mean, when I started at Dropbox, the infrastructure team was, I don’t know, seven, eight, nine people. We’d have someone join from Google, for example, and they’d say, “Well, someone should go build.” I can’t do anything without this logging framework. I couldn’t possibly do anything with this logging framework. I’m like, “Well, we’re going okay without it.” And then someone needs to build this thing. Everyone would be like, “Well, who is someone?” Right? Because it’s just us. It’s just us. We build it or we don’t build it. They’d pretty quickly come to understand, “Oh wait, it’s just us.”

[55:55] I can’t do anything without this logging framework. Couldn’t possibly do anything with this logging framework. I’m like, well, we’re going okay without it. And then someone needs to build this thing. And everyone will be like, well, who is someone? Right? Because it’s just us. It’s just us. We build it or we don’t build it. And they’d pretty quickly come to understand, oh wait, it’s just us.

[56:17] There’s no other idiots out there. We’re the idiots, right? So that was, I don’t know, I loved that time because it was just a time of accountability. Life gets easier and harder when you realize that everyone else is not an idiot. When you realize that everyone else is just dealing with their own stuff, right? I do not think someone will have good luck going around complaining about stuff and just saying this is a dumb idea and being negative.

I think people will have—everyone wants problems solved, though. So if you’re someone in an organization who is willing to put their head up and say, you know what, I think this thing over here is a bad idea, but here’s a different idea and I’m willing to own it and put the effort behind it, I think that’s a recipe for success.

[56:50] I think people will have—everyone wants problems solved, though. So if you’re someone in an organization who is willing to put their head up and say, “You know what, I think this thing over here is a bad idea, but here’s a different idea, and I’m willing to own it and put the effort behind it,” I think that’s a recipe for success.

Ryan:

[57:11] From that article, you had a great quote or a great question to think through this. It said you went to everyone or a bunch of people, and you would say, if we could be spending these resources working on any project at the company right now, would this still be the best use of time? I feel like it frames exactly what you just described really cleanly.

James:

[57:32] Yeah, I mean, I guess this is like maybe a trick for being a tech lead or a manager. Nothing’s a yes or no question. It’s a prioritization question. It’s not like, should we redesign the database? I don’t know, maybe, I guess. Is it the most important thing to do right now? No. Cool, let’s not do it. I think it’s much easier to have those conversations than to think about it as a yes or no.

[57:54] I often hear, “Oh, my VP won’t let me do blah.” Okay, well, it could be that your VP is uninformed, but it’s probably not. It could be your VP has a different set of priorities. Maybe their VP knows that you need to ship these features, and if you don’t, then the company is going to struggle. I don’t know. But to really frame it around prioritization, the way I think about the career ladder for engineers is that some people—maybe it’s not common—think that becoming a senior engineer means you get better at programming.

[58:27] But I don’t know, I think my programming abilities went down from level four onwards. I think once I got to level four, that was peak programmer for me. Then I probably went downhill from there, and I got wiser, whatever. But I think the real thing that happened is the scope that I cared about increased. At a certain point, you’re just thinking about what matters most at the company for the next five years.

[58:52] And I don’t think a junior engineer in their first year on the job should try to do this because you probably don’t yet have the wisdom, insight, or knowledge to make a good assessment. I think it would be a mistake to try to come up with redirecting company strategy. But as you grow, the real key part about growing is that the IC 6, 7, and 8 engineers are not necessarily the best programmers. They’re just getting better at having a broad perspective in decisions within a company.

[59:22] They’re just getting better at having a broad perspective in decisions within a company.

1:00:15 — Doing the right thing vs promo hypothetical

Ryan:

[1:00:15] You mentioned this idea of doing the right thing and then, you know, the byproduct, you also get promoted. I think that’s the dream, you know, do the right thing, get promoted.

[1:00:25] But in reality, oftentimes people would have to make the trade-off. Imagine a two-by-two matrix of doing the right thing, doing the wrong thing, getting promoted, and not getting promoted. Obviously, do the right thing, get promoted—great. Do the wrong thing, don’t get promoted—obviously bad. But I’m curious about the other two quadrants. Which one would you have picked when you were earlier in your career?

[1:00:50] Let’s say I came to you, I said, hey, you can do the wrong thing, but you’re going to get promoted, or you can do the right thing and I guarantee you’re not going to get promoted. Which one?

James:

[1:01:00] Absolutely the second one. I’m going to say a really tacky thing, right? There are a set of engineers who at a certain point just make infinity money. The amount of money they can make, you know, going to work at Anthropic is a huge amount of money. Right? And so there’s a certain point where it just doesn’t matter anymore. The money is whatever. But if you really want to maximize long-term income, I don’t think you should try to do that.

If you get to a certain level of experience, skill, and seniority, you’ve made it; that’s it, you’re done, the money’s fine. I think there’s this desire amongst junior engineers early in their career to be kind of over-optimizing for promotion and salary, etc., as opposed to investing in themselves.

[1:01:31] But if you wanted to maximize long-term income, if you get to a certain level of experience, skill, and seniority, you’ve made it. That’s it, you’re done; the money’s fine. I think there’s this desire among junior engineers early in their careers to be kind of over-optimizing for promotion, income, and salary, etc., as opposed to investing in themselves.

[1:01:59] They probably don’t want to hear me say this because it’s easier for me as an old guy to say this, right? But I think, for the longest time at Dropbox, there was a time at Dropbox where we just didn’t have our level system. I was tech leading the team and I was making the least amount of money on the team because I was at some point a technical manager. I saw everyone’s salary, so I was making the least money, but whatever, right?

[1:02:20] It all worked out in the end, right? Now that was a happy story. But I do really think I benefited so much from working with the best people. If you have two choices—making 20% more money now or working with the best people in the world—just be around the best people because that’s going to set you on the ship to success. Now, not everyone wants to do that. Not everyone wants to go on that. There’s no shame in just wanting to have a regular job and just be chilling and getting paid. Fine, there’s nothing wrong with that. But if you do want to maximize your career growth, then the way to maximize that is to maximize your skills. Hopefully, you’re not so cynical to think that there is no correlation between talent and compensation.

[1:02:49] Not everyone wants to go on that. There’s no shame in just wanting to have a regular job and just be chilling and getting paid. Fine, there’s nothing wrong with that. But if you do want to maximize your career growth, then the way to maximize that is to maximize your skills. Hopefully, you’re not so cynical to think that there is no correlation between talent and compensation. I don’t. If you think that’s the case, okay, I don’t know what to say, but there is a correlation between talent and compensation and growth. So my advice to people early in their career is to land at the best company with the best people doing the most important problems. Your life will be great because we are so lucky as engineers. Where else can you work solving problems for a job, solving puzzles for a job, and getting paid so well? Engineers get paid so well compared to most jobs.

[1:03:19] I don’t. If you think that’s the case, okay, I don’t know what to say, but there is a correlation between talent, compensation, and growth. So my advice to people early in their career is to land at the best company with the best people doing the most important problems. Your life will be great because we are so lucky as engineers. Where else can you work solving problems for a job, like solving puzzles for a job and getting paid so well? Engineers get paid so well compared to most jobs. The real privilege that we get is to work on something cool. That’s what I advocate for.

[1:03:53] The privilege, the real privilege that we get is to work on something cool. And that’s what I advocate for.

Ryan:

[1:04:02] I love the idea you mentioned earlier. That’s kind of counter to the common opinion I often hear. The common opinion I hear is that someone working at a big company is in this machine, and it’s kind of defeatist. They’re going, “I ship this thing, but I hate this” or “I don’t believe in this.” I really liked your perspective on doing the right thing and basically giving a damn that someone outside of you is doing the right thing too and expanding your sense of ownership.

[1:04:35] And I want to know what is your motivation for that? Because there are so many other people who are faced with the same inputs, and they come to a very different conclusion. So what motivates you to actually do the right thing when the machine doesn’t necessarily incentivize you to do so?

James:

[1:04:51] Yeah, well, I think the machine does incentivize you to do so, but I don’t think it’s visible immediately. I think people who do less job hopping really do grow the most. Because I would say very strongly, if you’re not in a job for three years, you’re not going to see whether your decisions were good. You can get more money as a junior engineer, but you cannot become a very talented senior engineer without being around for long enough to own the consequences of your decisions.

[1:05:23] It’s like playing a basketball game and leaving before the game’s over. You’re just not learning. I do think there’s an actual structural incentive towards staying in a job now. If you’re in a bad job, leave the bad job. Right? But there’s a structural incentive to be able to stay long enough to have an impact. But also, I don’t know, I guess it’s easy for me to say. I joined the tech industry when it wasn’t a very lucrative field.

[1:05:50] It wasn’t like it is now, but I just like it. The reason I left academia was because I wasn’t confident I was making the right decision. So what would happen, how I was in academia—I’m not saying everyone was like this, but you don’t know what to do. So you have to make up a problem to solve. You make up a problem, and then you make up a solution, hopefully a good one.

[1:06:18] And then you write a paper where you try to convince everyone that it was a really good idea. I hated it because I didn’t want to convince people. I just wanted to build it and see if it was good. I just wanted to build it and ship it and see; I didn’t want to play pretend and argue about whether it was good. That’s what makes me feel good. I don’t know. Obviously, if you’re an engineer who’s living paycheck to paycheck, you should maybe ignore what I’m saying.

[1:06:50] I don’t want to come across as unempathetic to anyone who’s really struggling financially. But if you are not struggling financially, the best thing you can do for your quality of life is to enjoy what you do every day. I don’t know, you could have a fancier car or you could enjoy what you do every day. I love cars. I’m a motorhead. But I promise that enjoying what you do every day is going to have a much bigger impact on your life.

[1:07:22] Personally, I don’t enjoy going to work and working on products that I believe in. Jamie, my co-founder, is the same way. We really get along well in this respect. We can only put up with doing things we actually care about and believe in. I think that’s the luxury—it’s more luxury than taking a first-class flight.

[1:07:49] That’s more luxury than going to a three-million-star restaurant. The luxury is you don’t get up and have to do a terrible job. You get up and go to a place where you like your coworkers, and you solve cool problems, and you go home and feel proud of yourself. If you can construct your career that way—and it’s not easy, it requires very active effort—then you’re going to have a good life.

1:08:13 — Why he dipped into management sometimes

Ryan:

[1:08:13] I saw in your career journey it said that you’re an occasional manager, and you seem like someone who really enjoys the technical aspects of things. So how did you decide to occasionally dip into management?

James:

[1:08:27] I feel like most people should not want to be managers, and I sometimes think it’s a bit of a red flag if someone wants to be a manager too much. Right. Because being a manager is a hard job. I think most people should go into management because they need to, because it’s necessary. What happened every time I went into management—I’m in a management role now as well—was because you have to.

[1:08:50] Right. But someone needed to manage the team, and so I do genuinely enjoy accountability. I like responsibility; I like having weight on my shoulders, I suppose. I went into management several times, but as soon as I had the opportunity to get out, as soon as someone else would come in and manage the team, I would bounce out of that role back into engineering. Now, going into management is tremendously educational.

[1:09:22] Being a manager really lets you see the world in a different way. You realize companies are more complicated than you thought. You realize the engineers are more complicated than you thought. You realize everyone on the team is going through something, and you realize, oh wow, now I understand why that thing happened. So being a manager is very educational. One thing I would say, I would strongly caution people against is going into management too early.

[1:09:44] In their career. I see this happen a lot with well-intentioned people who want to push others into management as a means of career advancement. I think it’s doing people a disservice. You should let folks take their time in an organization, in a career journey. I don’t think you should be going into management under most circumstances in the first three years of your career.

[1:10:08] I think you should ideally get to staff engineer before you do that. That’s not going to happen for everybody. But ideally, you take the time because if you go into management before you’re an excellent technician, it will limit your ability to influence strategy later in your career.

Ryan:

[1:10:24] How does that play out?

James:

[1:10:25] It plays out with people who are stuck or have roles as people managers where they see their job as making a team happy or maybe coordinating a team or dealing with all the day-to-day challenges of people on a team. But they’re not organizational leaders. They’re not pushing the team towards excellence. They’re not asking, “How can we reframe what this team is about? How can we help influence technical strategy?”

[1:10:59] And again, people management is a fine job. But I think the best companies are ones where all the managers are very technical, so they’re able to make sure the company’s doing well at a certain point. If you’re not a particularly technical manager, you’re not going to be able to evaluate the work of your team. You’re not going to know whether your team is even doing well. I guess maybe you might contribute to some of the stuff you were saying about cynical organizational attitudes where my manager doesn’t understand me.

[1:11:29] Maybe your manager doesn’t understand you if they haven’t spent enough time developing technical skills and struggling.

1:11:36 — Why you shouldn’t lead by example

Ryan:

[1:11:36] Yeah, there’s another piece that you wrote I thought was really good about leading by example, and you actually say it’s bad to lead by example. But there’s a quote in there that says modern tech workers can be an anti-authoritarian bunch at the best of times. Let’s say you’re a tech lead or manager. How do you strike that balance so you don’t lose credibility as a tech lead?

James:

[1:12:03] Yeah, there are command and control companies where the manager just tells people to do things, and they just do them. Those typically are not excellent companies, and not every company needs to be excellent. But if you want to have a company where your team is really innovating, where the engineers feel very personally responsible for making high-quality decisions, you have to have them believe in what you’re doing.

[1:12:30] And so, at Convex, I’m the founder and CTO. I can’t really go to someone’s desk and say, “Do this thing.” Now, they might do it just because they like me. There’s a good chance they would do it, but not because I’m the boss. They’d be like, “Well, why?” And that’s because that’s our culture. We don’t just do things because we’re told. If I want someone to do something, I’ll spend time with the team talking about why we’re doing it, where the market’s trending, where the gap in our product, what, you know.

[1:12:57] And then once we’ve really well articulated why something matters, people are just going to do it anyway. Sometimes you have to have hard conversations, but I think about it in terms of conflict in an organization. There’s this kind of hierarchy of the values you have and then why, what, and how. Engineers are very often debating the how. They’re often debating what algorithm we should use for this and whether we should use this container service or that container service. These are kind of like the implementation details. Most times when I see organizational conflict, it’s because well-intentioned people are debating as best they can about how to do something, but they don’t agree on why we’re doing it. If one team thinks the most important thing we can do right now is get more features out to expand our customer base, and the other team thinks the most important thing we can do is increase reliability because there’s a risk to the business.

[1:13:24] And should we use this container service or that container service? These are kind of like the implementation details. Most times when I see organizational conflict, it’s because well-intentioned people are debating as best they can about how to do something, but they don’t agree on why we’re doing it. If one team thinks the most important thing we can do right now is get more features out to expand our customer base, and the other team thinks the most important thing we can do is increase reliability because there’s a risk to the business, they’re both very valid perspectives. However, it’s going to lead to them doing very different things. Within an organization, I’m a strong believer that everyone needs to have 100% alignment on why. The stuff we argue about or debate or talk about ad nauseam is why. Largely, I just trust the team to do the right thing. I think that’s the case for any tech lead. If you want to have credibility on a team, if you think that you can just tell someone to do something and they’ll listen to you because you’re the senior guy, no, they won’t.

[1:13:54] They’re both very valid perspectives, but it’s going to lead to them doing very different things. Within an organization, I’m a strong believer that everyone needs to have 100% alignment on why. The stuff we argue about or debate or talk about ad nauseam is why. Then largely, I just trust the team to do the right thing. I think that’s the case for any tech lead. If you want to have credibility on a team, if you think that you can just tell someone to do something and they’ll listen to you because you’re the senior guy, no, they won’t. They won’t listen to you. If they listen to me, it’s because I’ve come in and explained it in a way that resonates with them. Again, one of my jobs at Dropbox was to resolve situations. Someone would say, “Oh, that team’s an idiot; they won’t do blah.” Then I’d go talk to that team. That team was not an idiot. We talked through it, and they would decide to do the project. It wasn’t because they were scared of me.

[1:14:30] If they listen to me, it’s because I’ve come in and explained it in a way that resonates with them. Again, one of my jobs at Dropbox was to resolve situations. Someone would say, “Oh, that team’s an idiot, they won’t do blah.” Then I’d go talk to that team. That team was not an idiot. We talked through it, and they would decide to do the project. It wasn’t because they were scared of me.

[1:14:51] I hope they weren’t. At least it was because I took the time to figure out what their motivations are. That’s something you really have to learn. If you’re a tech lead, you don’t really have that much authority over people, and you have to encourage them and get them to believe in what you’re doing. If you are leading through authority, you’re not going to have a culture where good ideas arise from within the organization.

[1:15:17] People are just going to do what they’re told.

Ryan:

[1:15:19] Influence without authority is huge. Even big companies like Meta technically don’t have titles; everyone’s just a software engineer. Is that also how Convex is run?

James:

[1:15:32] I mean, we’re a very flat organization. There are people in tech lead roles. I don’t completely buy that everyone’s a software engineer thing. It’s like, you know, Anthropic. Everyone’s a member of technical stuff because it’s kind of like a wink-wink thing. You kind of know, it’s like no one’s mentioned the title, but you kind of know if the most senior person in the company comes to your desk, you’re probably going to notice. I think there’s no point in playing pretend. People know. But I will say that you should have an organizational culture where you don’t do something just because a senior person says something. Now, I do think that reputation matters. I certainly think that if a very experienced person at a company comes and tries to explain something to you, you probably should listen to them because they probably have some wisdom.

[1:16:03] People know. But I will say that you should have an organizational culture where you don’t do something just because a senior person says something. Now, I do think that reputation matters. Like, I certainly think that if a very experienced person at a company comes and tries to explain something to you, you probably should listen to them because they probably have some wisdom. There might be something to be learned there. You should be open to it. But ultimately, even the most senior person, I don’t think should be leading through authority. They should use the benefit of their experience to be able to articulate, to win the hearts and minds. And that’s how your engineering culture is so important. And if you want a culture of ownership and innovation and drive and enthusiasm, and people trying to do the right thing, not get promoted, you have to have a culture where everyone believes in what they’re doing, and no one’s going to believe in what they’re doing.

[1:16:27] There might be something to be learned there. You should be open to it. But ultimately, even the most senior person, I don’t think should be leading through authority. They should use the benefit of their experience to be able to articulate, to win the hearts and minds. And that’s how your engineering culture is so important. If you want a culture of ownership, innovation, drive, and enthusiasm, where people are trying to do the right thing and not just get promoted, you have to have a culture where everyone believes in what they’re doing, and no one’s going to believe in what they’re doing.

[1:17:00] If the senior principal engineer comes to the desk and says, “I’m not going to tell you why, but you have to delete this database and do this other thing,” that’s not an empowering statement. What the empowering statement is, “Hey, let’s spend some time together to talk about where this product’s trending and how this is probably not going to work out and how there might be a different way we can solve this problem.”

Ryan:

[1:17:20] On the topic of tech leadership, in that article I mentioned, the title was “Don’t Lead by Example.” I think that might be confusing for people. Can you explain why you think you shouldn’t lead by example?

James:

[1:17:33] Yeah, leadership by example is a very passive thing to do. Engineers are passive people at the best of times. I think that’s stereotypically a little bit part of that personality. The very concrete example is when I first started becoming an engineering leader, I was trying to lead by example. I wanted to demonstrate the behaviors I wanted everyone else to have. Very specifically, with regards to on-call and people getting paged, I wanted people to have high ownership. I wanted people to jump on issues as soon as they happened. So I would do it. I’d be the first one to respond to a page. I would always be writing up the reports. I would always be jumping on all the bugs and stuff, really falling over myself to show how I wanted people to be. But from their perspective, all they see is that the lead is just doing all these jobs, and they don’t know. They’re like, “Oh, maybe that’s James’s job,” or “Maybe James knows how to do it, and I don’t know how to do it.”

[1:18:05] I want people to jump on issues as soon as they happen. I would do it. I’d be the first one to respond to a page. I would always be writing up the reports. I would always be jumping on all the bugs and stuff, really falling over myself to show how I want people to be. But from their perspective, all they see is that the lead is just doing all these jobs, and they don’t know. They’re like, “Oh, maybe that’s James’s job,” or “Maybe James knows how to do it, and I don’t know how to do it.”

[1:18:37] Turns out I didn’t know. I was just kind of figuring out, or maybe he likes doing those things. At a certain point, being a leader is about understanding human psychology. I don’t think you can just act a certain way in front of people and wait for them to copy you. I think you should act with integrity and values, and you should own the values of the team.

[1:19:01] But you sometimes have to explain stuff; sometimes you have to tell people very, very specifically. There’s a trajectory almost every high-achieving leader goes through. They become a tech lead and care so much that they become a micromanager. They review every line of code and are involved in every decision, and at a certain point, they become the bottleneck for the team.

[1:19:26] So this person is so overwhelmed; you might have gone through this yourself. They’re so overwhelmed, and they’re like, “Wait, my team doesn’t even seem busy right now. And I’m so busy. I’m reviewing all this code. I’m doing the strategy, what’s going on?” Then a manager will come along and say, “Hey, you’re micromanaging. You got to let your team have more ownership.” So the tech lead says, “Okay, sure, whatever.”

[1:19:49] I’ll let them own stuff. And they just take their hands off the wheel. Then the team falls apart because you can’t just stop doing the things you’re doing. You have to go and have a conversation with people. I see leadership as this kind of slider between oversight and accountability. When someone’s new to the team, when they’re very junior, they’re in a mode of oversight, like you’re checking their work. But at a certain point, you have to dial down the oversight and, very importantly, dial up the accountability. Instead of saying, I’m not going to look at what you’re doing anymore, you say, okay, cool, you’ve got this project. Let me know when it’s going to get done. Next Thursday.

[1:20:17] Right. But at a certain point, you have to dial down the oversight and, very importantly, dial up the accountability. So instead of saying, “I’m not going to look at what you’re doing anymore,” you say, “Okay, cool, you’ve got this project. Let me know when it’s going to get done. Next Thursday.”

Ryan:

[1:20:34] Cool.

James:

[1:20:35] All right. What’s the plan? This is going to happen. How are you going to know it’s correct? Great, great, great. It’s on you. I expect you to do that. Let me know if there are any issues. The ownership relationship is explicitly on them. What you want to do is basically encourage ownership within teams. You can’t go from owning something to not owning something and expect that to develop.

[1:21:00] You have to go have those conversations. You have to go and give people accountability. Now, what I have found, even though that can feel like an awkward conversation, most people genuinely like accountability. Most people like to own their work. Most people like to say, “Hey, this is on you. We’re all going down with the ship, right? I’m not going to leave you high and dry.”

[1:21:23] I’m the tech lead. I still take responsibility for this project. That’s how you can develop people within your team. A tech lead shouldn’t be about you as the boss and the team as the people who do the work. It’s about this kind of flow where you’re the more experienced person, typically maybe the more organized or more strategic person, and you’re working on developing your team members so they can take your job and then you can do something else.

Ryan:

[1:21:55] That slider you mentioned, what if you give someone accountability and they blow it? Do they go back down the slider to where you start micromanaging?

James:

[1:22:06] You have to recognize it. Right. So this is growth. I mean, this is growth. Right. It doesn’t always work. I had another article about paper cuts or something. So we’d call these paper cuts. Some decisions don’t matter that much. You get them wrong, and maybe it sets you back a week. You get them wrong, and maybe something’s a bit suboptimal. These are great candidates to give people accountability for because they do it.

[1:22:33] And if it doesn’t work, they get to experience it, and it will feel bad. I guess that’s good. It’s good to feel bad. You shouldn’t be demoralized, but it’s good to try something. It doesn’t work, and you’re like, oh, wow, that didn’t work. Then you feed that back into your little LLM in your brain, and you get better next time. Right? That’s a growth experience.

[1:22:56] I think what you don’t want to let people do is lose their arm. Paper cuts are fine, but I would not let someone, a junior person especially, design the replication system at Convex. You have to have safeguards. One of the arts as a CTO, a leader, or tech lead is figuring out the right level of altitude for how to know whether you can trust someone to take on ownership for something.

1:23:23 — How to mentor Senior Staff+ engineers

Ryan:

[1:23:23] You mentioned that, because you were the most senior engineer at Dropbox, at some point you had to mentor other very senior engineers. When I think about mentoring a junior engineer, it’s relatively straightforward patterns. But when I think about, let’s say, needing to mentor a senior staff engineer, maybe even a principal engineer, how do you mentor someone like that who’s already so polished and knows how to take ownership?

[1:23:51] Yeah. How do you mentor someone so senior?

James:

[1:23:53] Yeah. I mean, there’s in two ways. One is there is still just a whole bunch of commonality. Everyone goes through the same problems. They don’t know how to deliver harsh feedback. There is a bunch of just standard stuff people are working on. But I do think that at a certain point everyone needs to become the best version of themselves. Sounds so cheesy, right? But there is not an archetype for what. According to me, there’s not an archetype for a senior principal engineer. You’ve got to be your own brand of engineer, right? So you might be. For me, I’m like the strategic kind of collaboration, simplicity, abstraction engineer. And my coding just fell off a cliff. You know, some engineers are like the deep science fiction, you know, the super hardcore science, you know, problem-solving engineer.

[1:24:18] According to me, there’s not an archetype for a senior principal engineer. You’ve got to be your own brand of engineer, right? For me, I’m like the strategic kind of collaboration, simplicity, abstraction engineer. My coding just fell off a cliff. Some engineers are like the deep science fiction, the super hardcore science, problem-solving engineer.

[1:24:42] So everyone’s going to find their own brand. Oftentimes, what I’ll be working on is a combination of two things. One, finding their strengths and helping them be more spiky—helping them really excel in the area that makes them special. At the same time, I’m almost always working on the personal side of being an engineer, like the organizational and personal understanding, people understanding the why. I don’t know, we’re so mathy as an industry. We think that somehow, even silly things, like for example, I have to tell so many senior engineers that you can’t change someone’s mind in a meeting.

You just can’t do it. You can disagree with someone, and they’re going to be mad or whatever, right? But to change someone’s mind involves going through a complex series of neurological processes that don’t happen live in front of ten people in a meeting. If you force someone to agree with you about them being wrong, they’re just going to go along with it, and their ego is going to get bruised and whatever.

[1:25:23] You just can’t do it. You can disagree with someone, and they’re going to be mad or whatever, right? But to change someone’s mind involves going through a complex series of neurological processes that don’t happen live in front of ten people in a meeting. If you force someone to agree with you about them being wrong, they’re just going to go along with it, and their ego is going to get bruised.

[1:25:52] So, one thing, you know, firstly, meetings generally aren’t for decision making. Most of the time when you identify a disagreement, I would point out the disagreement and why I don’t agree or where the problems are, provide enough information, and then let it sit. Let them go and reflect on it and come back and have a conversation a week later after they’ve thought about the why.

[1:26:16] Right. And so this is a lot of very psychological, but it makes no sense to be like, well, they should be able to change their mind. I mean, well, they won’t, right? That team should do this. Well, they didn’t, right? You know, people should like my API? Well, they don’t, right? I think it’s like that whole, it’s almost like a capitalist attitude towards interpersonal behaviors.

[1:26:41] Right. It’s like capitalism rewards success or impact. It doesn’t matter how well-intentioned you were. If you didn’t manage to convince, you could be the smartest person in the world. But if you can’t change someone’s mind, then you are kind of useless. Right? And so I think a lot of seniors still struggle with this. It doesn’t matter how smart you are, it doesn’t matter how right you are; are you effective?

[1:27:07] And a lot of being effective at that level is about uncertainty, project management, and simplicity, but also kind of interpersonal dynamics because most hard problems happen with a team. Not always, but generally when you’re at that level, you’re going to have to have 10 or 20 people working with you to get something done. And that’s a whole different ball game.

1:27:30 — Career advice for the AI era

Ryan:

[1:27:30] On the topic of career advice, the industry’s changed a lot in the last five years because of all these agentic tools. I wanted to know if you thought there is any career advice that has majorly changed in the last five years. Is there something that you used to say five years ago that you don’t say anymore, or vice versa?

James:

[1:27:52] No, I don’t know if I’ve changed my perspective much, but I think the industry has changed this perspective dramatically. I mean, let’s just be honest about it. There is incredible demand in Silicon Valley for senior engineers, and it is getting harder for junior engineers to succeed and grow for a variety of reasons. Why is there demand for senior engineers? Well, because large language models can’t do everything.

[1:28:17] Well, the architecture and simplicity in design are still the domain of human beings, despite what you might hear on Twitter. Every company, including the labs, is desperately hiring senior engineers. But junior tasks are getting a little bit commoditized, and that worries me because I do think that learning—wisdom is kind of facts put into practice and then synthesized. People would argue that it’s easy to learn now because of ChatGPT; you can just go ask it a question about how two-phase commit works or what’s the difference between snapshot isolation and serializability, and it will give you probably a pretty good answer. But I think growth as an engineer does require wisdom, and wisdom only really happens when you synthesize it, in my opinion. I’m still very bullish on young people. We’re hiring junior engineers at Convex, and I’m very excited about it. I love working with junior engineers who are really hungry to grow.

[1:28:56] Or what’s the difference between snapshot isolation and serializability? It will give you probably a pretty good answer. But I think growth as an engineer does require wisdom. Wisdom only really happens when you synthesize it, in my opinion. I think I’m still very bullish on young people. We’re hiring junior engineers at Convex. I’m very excited about it. I love working with junior engineers who are really hungry to grow.

[1:29:28] But what I would say is train your mind. Do not listen to anyone who tells you that there is an advantage to having less knowledge. I’m not sure if you’ve seen people say these ludicrous things, like, oh, maybe in the future, not knowing engineering will be an advantage because you won’t have biases and you’ll just use Claude. I think these are ludicrous statements. Software engineering is an intellectual discipline that helps you think. The best software engineering is not about knowing syntax and it’s not about knowing an algorithm; it’s about being really good at conceptualizing problems, breaking them down into building blocks, and coming up with clean solutions. That requires experience. It’s like doing weights with your mind. Just like if you went to the gym and it never hurt.

[1:29:56] The best software engineering is not about knowing syntax, and it’s not about knowing an algorithm. It’s about being really good at conceptualizing problems, breaking them down into building blocks, and coming up with clean solutions. That requires experience. It’s like doing weights with your mind. If you went to the gym and just picked up really light weights, you’re not growing. Also, if you went to the gym, picked up a heavy weight, and let the robot pick it up for you, you’re also not really growing. You have to do the reps. It’s tough, but find a way to stress your brain every day.

[1:30:17] If you went to the gym and just picked up really light weights, you’re not growing. Also, if you went to the gym and picked up a heavy weight and thought, “Okay, cool, I think I can do it,” but let the robot pick up the weight for you, you’re also not really growing, right? You have to do the reps. It’s tough, but find a way to stress your brain every day. Find a way to.

[1:30:47] To avoid. Now, obviously, agentic coding is here, right? Obviously, that’s. I could never tell someone to never use a coding agent, because that would be silly. But I can say that it is easy to fall into a passivity trap, where you’re just being passive about your learning. I do think you need to spend some time in the intellectual wilderness of not being able to solve a problem and struggling.

[1:31:16] I would say if you’re running into a new problem, try to think of a solution yourself and then go check with a large language model. It’s going to be hard for you. It’s almost like, for example, I’m not very good at reading anymore. I got to be honest, I find it hard to sit down and read a book because my brain has been fried by the stimulation economy, right? I find that I go home and I’m tired, and I watch a YouTube video. I don’t tend to go home and read a novel. I should be better at that, but it takes discipline to do that. I would say similarly, it’s getting harder to solve a difficult problem without reaching for help. It’s getting harder and harder every day to be faced with a very difficult intellectual problem and not be like, well, I’ll just do a Google search or I’ll just ask Claude.

[1:31:45] I find it hard. I go home and I’m tired, and I watch a YouTube video. I don’t tend to go home and read a novel. I should be better at that, but it takes discipline to do that. I would say similarly, it’s getting harder to solve a difficult problem without reaching for help. It’s getting harder every day to be faced with a very difficult intellectual problem and not think, “Well, I’ll just do a Google search or I’ll just ask Claude.”

[1:32:10] You’re whatever, I’m still doing the work. I don’t know. I would really encourage people to practice using your brain every day.

Ryan:

[1:32:19] If I was just playing devil’s advocate or thinking from the junior engineer perspective, I might think, well, the proof that Claude can do this work today means that I don’t need to know it today or tomorrow or in the future. So why even build that skill in the first place? Also, these agentic tools have positive trajectories too.

James:

[1:32:43] Yes. So firstly, the agents are not particularly good at a lot of parts of engineering currently. Probably everyone should agree Claude is not good at designing distributed systems protocols right now, for example, or managing a 3 million line code base. There are parts of engineering where engineers are valuable. And like I said, you know this because the labs are all hiring engineers.

[1:33:10] No matter what they say, they’re still hiring engineers, right? Desperately hiring engineers. Really, really aggressively hiring engineers. So engineers still have value. And maybe they won’t in the future, but I doubt it. I really do think there’s a role for human ingenuity in engineering. And so here’s the trade-off I would pose to people. I mean, there’s kind of three paths. One, get out, get out of engineering, go mow lawns and do whatever if you want.

[1:33:41] That’s the most nihilistic attitude. I don’t believe in that. I really love engineering. I believe that there’s promising roles for human beings in engineering. So the second is to realize that there’s value right now for humans in engineering. And maybe one day AGI will be here. Let’s say in a year’s time AGI will be here. And there’s two people. One person just gave up on problem solving right now and they’re just feeding the machine. They’re running 17 coding agents in parallel, accepting everything Claude says, and they’ve given up.

[1:34:15] Right. And one person said, you know what, I still want to have an active role in my learning. I want to understand what it’s doing. I want to think hard about problem solving, right? Played out one year, AGI arrives. Who is going to be better placed for the future, right? The person who’s been training their mind, right? You don’t—engineering is not a means to an end. It’s a mechanism for improving your mental processes.

[1:34:41] It’s like, I still do whiteboard coding interviews, and by the way, Anthropic still does whiteboard coding interviews, just in case you were wondering. They don’t say, just use Claude. So I still do whiteboard coding interviews with candidates. Candidates are getting worse at coding. That’s absolutely true. But I don’t know any better vehicle for evaluating someone’s intellectual capacity for problem solving than seeing them solve an engineering problem.

[1:35:08] It’s a great mechanism for doing so. If you were doing a math degree, a big part of doing advanced mathematics is proving theorems. By the way, the theorems are already all proven. Part of the exams is proving a theorem that has already been proven. You might say, well, what’s the point of proving that theorem? It’s already been done. The point is that the act of proving that theorem improves your mind, and then you can go and do more innovative stuff. I would say, sure, you may not. I still think that there is a very promising role for human beings in engineering. Maybe not in coding, but coding and engineering are very different things. Even if you don’t believe me, you can either give up now, but.

[1:35:31] It’s already been done. Well, the point is that the act of proving that theorem improves your mind, right? And then you can go and do more innovative stuff. So I would say, sure, you may not. I still do think that there is a very, very promising role for human beings in engineering. Maybe not in coding, but coding and engineering are very different things, right? But even if you don’t believe me, you can either give up now, but.

[1:35:56] Or you could just keep trying to improve your brain, and you’ll be better off anyway. Imagine if you’re wrong. Imagine if you take the defeatist view. Imagine if you say, “Well, AGI is coming next week, why bother doing anything?” And imagine you’re wrong. Oh my God, you just got off the ride. You get off the ride, and there’s so much cool stuff. I mean, this is a cool time for engineering, right? This is a really cool time. There’s so much cool stuff happening. And I hate this talk about how AI means humans don’t have a role anymore. AI means no one’s going to have a job. AI means we’re not going to do anything new. What I like is, hey, look at this. All this new cool stuff we can build. Look at the ways we can make people’s lives better.

[1:36:19] This is a really cool time. There’s so much cool stuff happening. I hate this talk about how AI means humans don’t have a role anymore, that AI means no one’s going to have a job, or that AI means we’re going to do nothing else new. What I like is, hey, look at this—all this new cool stuff we can build. Look at the ways we can make people’s lives better.

[1:36:42] And to be honest, I really wish my peers and my cohort would stop it with the real doomer, human elimination kind of narrative. I think there is a little bit of a psychological anchoring. As part of Convex, we didn’t start Convex to eliminate jobs; we started Convex to make it easy for people to build cool stuff.

[1:37:10] I think the more we as an industry get behind, let’s do everything we can to make it possible for people to do more cool things. I think it’s a really exciting future we have ahead of us.

1:37:21 — Why he started his own company

Ryan:

[1:37:21] I wanted to talk about what you’re working on now at Convex and why you quit Dropbox to build Convex.

James:

[1:37:27] Dropbox is a great place. At a certain point, I was there eight years. I don’t know if I outgrew the company, but I’d been the most senior engineer for a while. At a certain point, I wanted to grow and do my own stuff, so I left the company very amicably and started Convex. Why Convex? Convex started pre-agentic era because my observation was that the real differentiator in the success of a project, especially a large project, is the quality of the abstractions, the quality of the design, the quality of the architecture. Systems that thrive over time and are extensible are systems that are architected well. In my mind, the most difficult challenge in engineering is distributed state management. How do we store state reliably and reason about it, modifying it concurrently with other users? We designed a platform for application building based on our experiences building large-scale systems.

[1:38:08] Systems that thrive over time and are extensible are systems that are architected well. In my mind, the most difficult challenge in engineering is distributed state management. How do we store state reliably and reason about it while modifying it concurrently with other users? We designed a platform for application building based on our experiences building large-scale systems.

[1:38:34] So Convex is a transactional database where the transactions are written in TypeScript; they run as stored procedures. TypeScript stored procedures are serializable. There’s automatic reactivity, so what the client sees is a consistent view of what’s on the server. I would say Convex is a very designed platform because Convex is designed to be very composable and fit together well. We designed Convex for developers to use.

[1:38:59] In particular, we wanted to make it so that application developers were able to build complex full-stack applications. That was the goal of Convex. Now all of a sudden, a coding agent development came along. That’s been really interesting for us because it turns out that what humans find hard is also what agents find hard. The coding agents are not particularly good with large code bases.

[1:39:24] They’re not particularly good at reasoning about action at a distance, race conditions across services. They’re not particularly good at simple architectures over time. And these are the things that Convex gives you as a developer. So the idea now, and almost everyone using Convex is using Convex because they have the coding agent doing their front end. But they need a backend abstraction, a higher-level abstraction than something like Amazon Web Services or something like hosted PostgreSQL, which makes their problems go away.

Ryan:

[1:39:56] So this is a layer of abstraction on top of those types of primitives that makes it easier for an application developer.

James:

[1:40:11] It ties into a lot of the stuff I said earlier about making problems go away. Frankly, I watched the interview you did with Barbara Liskov. Barbara was my advisor in grad school, and we worked a lot together on abstraction and the value in clean designs that minimize complexity. AWS is a fine tool. PostgreSQL is a fine tool, although none of the mainstream databases are that great, frankly.

[1:40:36] But they’re fine tools, but they don’t make problems go away. Right. And so the idea of Convex is a higher level set of abstractions that you can use and not reason about state management, not reason about concurrency, not reason about scheduling, not reason about transactions, not reason about polling and data sync and type safety and all those things. So Convex is a, if you think about, you know, the history of engineering over time, the abstraction floor raises.

[1:41:05] You know, when Barbara Liskov was first starting, she was using punch cards. I don’t know if she mentioned it to you, but when she started as a programmer, she never heard the word “programmer” before. That was the first time she heard the word. And then you went from punch cards to having proper operating systems, and then languages like C, and then higher-level languages, and then you had cloud computing.

[1:41:31] And over time, the abstraction floor raises, and you largely forget about what’s going on beneath the surfaces. Most people don’t think about how Amazon Simple Storage Service is implemented. I do, but that’s what I used to work on. Most people just use it, and it stores your data and gives it back. That’s great; that’s a successful abstraction. But I do strongly believe that the world is and has been overdue for a new abstraction one level up the stack.

[1:41:55] And especially now that people are doing agent development, they don’t want to own a PostgreSQL instance. They don’t want to think about Kafka versus RabbitMQ. They don’t want to think about what set of tools to use. They want it just to work so they can focus on building their application.

Ryan:

[1:42:11] When you talk about the abstraction, there’s obviously a lot of stuff going on behind the scenes in Convex and the technical side. What is it that Convex is building behind the scenes that you’re most excited about and why?

James:

[1:42:27] Basically, Convex is a new operating system in some respects. We have the primitives: queries, mutations, actions, subscriptions. What I think is cool is how we built this. We have our own distributed database that tracks read ranges and write ranges and does very efficient subscriptions over WebSockets, et cetera. So that’s the current operating system set of primitives.

[1:42:56] But Convex is getting much larger workloads now and much more interesting workloads and more high-performance workloads. So we’re in the process of developing a slightly lower-level API for doing very efficient background processes, singletons, and APIs like fork, like operating system primitives. I’m pretty excited about launching these and how much faster it’s going to make various Convex components like the workflow system.

[1:43:28] And to be honest, the thing I find exciting every day, challenging every day. I still find Convex very hard. I struggle every day. I don’t find my job easy. I feel confident at my job, but it’s not easy. Designing the new API for this is super hard. I can’t just go ask Claude; it’s not going to give a good answer, right? Because it’s innovation, it’s new ideas. I really enjoy it.

[1:43:56] I find it stressful sometimes. I find it challenging and tiring, but I also find it exciting. I would encourage engineers to try to find this kind of stuff to work on, where it’s like you’re on that edge of, “I’m really liking this, but also it’s a bit tricky.”

Ryan:

[1:44:16] You mentioned fork, and in operating systems, I’m familiar with it. You take the existing process and kind of split it. What’s the idea of fork in a distributed system?

James:

[1:44:27] So Convex almost never has scale issues with regards to live traffic. Live traffic is typically bound by user-facing interactions, people clicking on stuff, running a website, acting on a website. Every now and then, someone will come to Convex and want to kick off a million background jobs to do some background processing. It’s a big workload. You can programmatically trigger huge workloads, right?

And so one of the things we have to scale is these background workloads, and a lot of them involve things like scheduling. There are a lot of workloads in Convex that would be very efficient if you had a background singleton process to perform things like aggregates. I’ll give a very silly example, right? If you’re building an election on Convex, a voting system, and every vote is a new row in the...

[1:44:50] And so one of the things we have to scale is kind of these background workloads, and a lot of them involve things like scheduling. There are a lot of workloads in Convex that would be very efficient if you had a background singleton process to perform things like aggregates. I’ll give a very silly example. Let’s say you’re building an election on Convex, a voting system, and every vote is a new row in the table. You want to show a tally of the votes. One way of doing this is having a bunch of background processes or cron jobs adding these things up. One way is doing a table scan, which is the obvious way to use PostgreSQL, which doesn’t scale. The other is to have a background job, which, if there are new votes, adds them all up and keeps a tally. If there are no new votes, it goes to sleep and waits on a condition variable to wake up again when there is a new job to perform.

[1:45:19] In the table, you want to show a tally of the votes. One way of doing this is having a bunch of background processes or crons adding these things up. One way is doing a table scan, which is the obvious way to use PostgreSQL, which doesn’t scale. The other is to have a background job that, if there are new votes, adds them all up and keeps a tally. If there are no new votes, it goes to sleep and waits on a condition variable to wake up again when there is a new job to perform.

[1:45:45] And so these are the kind of primitives that we’re working on right now. Most people won’t even know they exist, but they allow us to build this very high-performance primitive for scheduling, aggregates, background aggregations, et cetera. I’m pretty excited about the next generation of workloads we can support.

1:46:05 — The most technically challenging work of his career

Ryan:

[1:46:05] As a result, when you reflect on your career, it sounds like you’ve done a lot of gnarly technical work across your PhD. Dropbox seemed like pretty intense systems work, and Convex is also doing a lot of cool stuff. When you look back on your career, what was the most technically stimulating work you’ve ever done? Why was it hard, and what did you learn from it?

James:

[1:46:29] There were certainly times in grad school where we were formally modeling consensus protocols and stuff. I’d be on the phone with Barbara Liskov on weekends, talking through and trying to reason about this in our heads. That was pretty intellectually stimulating and fun. But I think the stuff I found most stimulating was working on a very large storage system with a team where things were going wrong.

[1:46:53] Where the rubber hits the road, that’s where I find, and this is every day at Convex. The rubber hits the road. We have a compaction process that runs in the background, but it’s running into issues. We might have to redesign it using partitioning, etc. I feel most intellectually stimulated where there’s a really clear constraint in front of me.

[1:47:16] And that to me is engineering. If I don’t actually know what the definition of engineering is, I’m just going to make it up in my mind. Engineering is science with constraints. It’s like, how do you solve problems in the presence of resource constraints? I’m not particularly interested in constraint-free environments. That’s art. I like craft and engineering. The more visceral and difficult the constraints, the more fun that is for me.

[1:47:47] And I’ve been lucky enough to, whether it’s luck or intention, I don’t know, but I’ve always placed myself in those environments. You know, let’s go get on the hardest team and own the hardest problem and then put the effort in to survive.

1:48:10 — How he got involved in Silicon Valley

Ryan:

[1:48:10] This question might be a little bit off topic, but I know you were a consultant for the TV show Silicon Valley. I love that show, and I gotta hear, how’d you get involved with that?

James:

[1:48:21] Yeah, that was a lot of fun. A lot of folks might not know this: I had nothing to do with season one. Many TV shows don’t know whether they’re going to survive as a series. Mike Judge, who wrote Silicon Valley, is also known for Beavis and Butt-Head and Office Space. He started his career as a software engineer at, I think, Lockheed or something. So he actually was a software engineer, which a lot of people don’t realize.

[1:48:48] And so Silicon Valley was like a throwback to the kind of work he did. If anyone’s seen the movie Office Space, you would get this. That’s really a dystopian cubicle era tech industry film. They did season one of Silicon Valley, and then it was very popular, so they got picked up. They had to figure out what to do for season two, but they didn’t know what to do because they had written a storyline that gets to the point where there’s a compression algorithm, and then what happens?

[1:49:18] And so they needed to find an expert on compression. I guess ostensibly that was me. I don’t know whether I was an expert on compression; I guess I was an expert on storage at least. They came to the office, and we just chatted. It was so much fun. I was pretty heavily involved in the show. A lot of it was storyline. So first, like, yeah, sure, what would you do with the compression algorithm?

What would you design for a storage system? Coming up with story ideas that were technically accurate, you’d be surprised to know how much they care about accuracy. A lot of people I know can’t watch that show because it’s just so creepily accurate. They find it so cringy. Partly why Silicon Valley can be so cringy is because it’s real. Those stories are almost.

[1:49:47] What would you do? Could you design a storage system? Coming up with story ideas that are technically accurate, you’d be surprised to know how much they care about accuracy. A lot of people I know can’t watch that show because it’s just so creepily accurate. They find it so cringy. Partly why Silicon Valley can be so cringy is because it’s real. Those stories are almost...

[1:50:14] Almost. Maybe not everyone. So many of the stories in Silicon Valley are just real stories. They went to a bunch of companies, just farmed everyone for stories of crazy things that happened in the tech industry, and they wove them into the series. All the characters are based on real people and real archetypes. But they also cared very much about technical accuracy. So I would also do technical consulting.

[1:50:37] And then they’d say stuff like, “Oh, we’re building a data center in our house. What should the rack look like? And what should the diagram on the wall look like?” Part of me wanted to say, “Oh, well, it doesn’t really matter. No one’s going to care.” But they were like, “No, no, no, it matters.” They really cared to get it right. So, yeah, I love the show, but it can be hard to watch just because of, oh my God, how real it can feel. Yeah.

[1:51:01] How real it can feel. Yeah.

Ryan:

[1:51:05] Are there any Easter eggs where you look at that and go, that’s unusually accurate? Or, you know, that system diagram actually is very spot on.

James:

[1:51:15] I can’t. I don’t think I can even say them because there were stories of early Dropbox. There were stories of having ideas ripped off by other companies and being tricked into having meetings with folks, only to find it may be the competitor’s team there to steal the information. A lot of those stories are real. And so there are people who watch Silicon Valley and think, oh, wow, that was something I went through.

[1:51:43] And probably it was because it was about that situation.

Ryan:

[1:51:48] That’s such a cool experience. Did you get paid for that, or was it just for fun?

James:

[1:51:52] Yeah, that’s a complicated question. I got paid because I had to get paid; it was like a Hollywood union thing. I didn’t want to get paid because it made my visa more complicated. So I’ve got a green card now; I’m all good. But there was something where they had to pay me $400 anyway. I made a grand sum of $400 off that show.

1:52:16 — Career regrets

Ryan:

[1:52:16] Looking back on your career, is there any regret that comes to mind that maybe other people can learn from?

James:

[1:52:23] Yeah, I mean, I think I underinvested in my personal life, to be honest. People don’t probably say that much because I think you can be all about growth, and sure, I could have grown more. I could have dropped out of grad school, say, three years in or four years in. I probably would have learned just as much. I could have taken a job at Dropbox two or three years earlier and made a lot more money.

[1:52:48] Everyone who has been in the industry long enough has been offered the chance to co-found several billion-dollar companies. Everyone has a story about the times they could have been a billionaire several times over. I don’t really regret those. Yes, it’s been a lot of sacrifice, to be blunt. I’ve been on call my whole career. I’ve carried a laptop almost every day. There are many dinners, parties, and events I’ve had to skip, and there are people in my personal life who have suffered as a result.

I really appreciate these people; they love and care about me, and they know that I have a passion for this, so they accept me for who I am. I think this is old person talk, but everyone has to decide how much they want to really drive their career because there’s a trade-off. Absolutely. I made a tremendous amount of sacrifices in my career, and I really prioritized building as probably the number one.

[1:53:21] And I really appreciate these people. They love and care about me, and they know that I have a passion for this, so they accept me for who I am. I think this is old person talk, but yeah, I think everyone has to decide how much they want to really drive their career because there’s a trade-off. Absolutely. I made a tremendous amount of sacrifices in my career, and I really prioritized building as probably the number one.

I mean values first and then building. But if I went back in time, I would have had a good life, but I probably would have done more vacations and just had a bit more of a balanced life. I really do think. I see that with all the 996 stuff and this kind of performative photos of being in a bar with a laptop, and I’m like that’s not real.

[1:53:52] I mean values first and then building. But if I went back in time, I would have had a good life, but I probably would have done more vacations and just had a bit more of a balanced life. I really do think—I mean I see that with all the 996 stuff and this kind of performative photos of being in a bar with a laptop and stuff, and I’m like that’s not real.

[1:54:16] That’s not real. I mean, sure, I was working more than I do now back then, but I probably still work more than I did then. But I don’t do it as a checkbox; I do it because I really want to be doing stuff. I would caution people against that hustle culture. That’s not, firstly, like, you’re only young once; you should have fun. You know, I’ve got quite a few grays in here.

[1:54:46] But that’s acting. I mean, focus on solving problems, work hard, be passionate. Yeah.

Ryan:

[1:54:55] When I studied your career, there are mentions of you working 16 hours a week in various places. But you like being on call, you like fires, you like ownership; all those things are a recipe for working obscene hours.

James:

[1:55:13] Yeah. I go home and I’m tired, and I wind down by building stuff. I’m lucky enough to have a little workshop at home, so I go home and make things with my hands. You become an infra person; you become an engineer in all aspects of your life. But yeah, I would just say the cool thing is doing cool stuff that humans use.

[1:55:41] The cool thing is not working long hours, the cool thing is not showing off that you were running a coding agent all night. Who cares? The cool stuff is enjoying doing important things.

1:55:54 — Top technical book recommendation

Ryan:

[1:55:54] Do you have a best technical book recommendation for people?

James:

[1:56:00] I have to be honest, I haven’t read almost any technical book. I was in academia for a long time, so I read a lot of papers. Learning is awesome, reading is great, but balance it, right? Read something and then go put it into practice. Most of my career has been about doing. Sure, I did a PhD, so I guess that is like the academic side. But after that, most of my learning has been by doing because there’s nothing like being faced with a real problem to really develop as an engineer.

1:56:36 — Younger self & permanent underclass advice

Ryan:

[1:56:36] Yeah, I think if I answered the question, I’d probably say the same. I think learning by doing is really where it matters most. And then the last question for you is, if you could go back to the beginning of your career and give yourself some advice, what would you say?

James:

[1:56:51] I’d say, it’ll be okay. Don’t sweat the small stuff as much. It’s hard because my whole engineering brand is about caring about details, and I love design, so being obsessive is a little bit part of my DNA. But I think I would go back and say careers are long. I mean, there’s just any story anyone reads about a 22-year-old billionaire, blah, blah, blah. Just ignore that story. That’s not real. That’s not repeatable. That’s not normal. And it’s not that healthy. And it’s not that good for the people either. You probably won’t, ideally, max out your growth for 20 plus years as an engineer. I’m still learning all the time. I’ve been an engineer for several decades. So my advice would be don’t sweat it. There’s time to grow. And I do think that, again, this is a little bit of a modern phenomenon, but there is a feeling right now, oh my God, AGI has come and better max out my growth in the next three months.

[1:57:26] That’s not real. That’s not repeatable. That’s not normal. And it’s not that healthy. And it’s not that good for the people either. You probably won’t, ideally, max out your growth for 20 plus years as an engineer. I’m still learning all the time. I’ve been an engineer for several decades. So my advice would be don’t sweat it. There’s time to grow. And I do think that, again, this is a little bit of a modern phenomenon, but there is a feeling right now, oh my God, AGI has come and better max out my growth in the next three months.

Well, guess what? You ain’t going to do it. It’s not going to happen. You can’t max your growth out in the next three months. It won’t happen. You don’t have to be running 17 agents at the same time. All you gotta do is orient your career around learning every day, getting better at what you’re doing, and trying to solve things in the most simple ways.

[1:58:04] Well, guess what? You ain’t going to do it. It’s not going to happen. You can’t do it. You can’t max your growth out in the next three months. It won’t happen. You don’t have to be running 17 agents at the same time. All you gotta do is orient your career around learning every day, getting better at what you’re doing, and trying to solve things in the most simple ways.

Ryan:

[1:58:26] I mean, on Twitter, I see this take on the idea of a permanent underclass, where if you don’t make it in time for AGI, then you’re going to be part of this permanent underclass.

James:

[1:58:39] Yeah. I mean, look, it’s a bit challenging economic times for a lot of folks. I don’t want to be unsympathetic to people who are having financial difficulties. At the same time, it’s just not an instructive attitude. There’s not much you can do with that information other than feel bad about yourself, and I don’t. Someone will argue back.

[1:59:00] No, what you can do is get really good at using Claude. Well, guess what? It’s not very hard to use Claude. Sometimes people tell me, “Oh my God, I’m finding it hard to keep up with all the new models.” The new model drops, and I don’t even know what the new models are. I use them, but I forget the latest model because it doesn’t matter. Right? Like there was this thing called Ralph.

[1:59:23] Right. I guess it’s still RALPH. It’s like a loop thing. I don’t really know what RALPH is, and I haven’t heard anyone mention RALPH in the past few weeks, but it was the biggest thing on Twitter for like a month. And it just doesn’t. This is noise somehow. Sometimes I feel like it’s like tech tabloids. It’s like people think that they’re learning by somehow knowing, like listening to what Jensen said today or like, oh my God, Boris said that Claude writes itself.

[1:59:53] I don’t think people—look, that’s like—it’s just like reading about Beyoncé, but you’re a nerd, and so you’re reading about Jensen, right? But it doesn’t matter, you know? Growing—like, you don’t have to know. It’s okay. The new coding agent could come out, and you could miss it. And then next year, if it turns out it’s the big one, you’ll just use it. It’s not hard. I haven’t seen any skill so far.

I guess there’s some skill, but it’s not a hard skill. If you’re good at engineering, you can figure out how to use Claude code, right? Or open code. So just watch out for tech tabloidism. It doesn’t matter. Just be building stuff. Just do real work.

[2:00:19] I guess there’s some skill, but it’s not a hard skill. If you’re good at engineering, you can figure out how to use Claude code or open code. Just watch out for tech tabloidism. It doesn’t matter. Just be building stuff. Just do real work.

Ryan:

[2:00:37] I love that mindset. Yeah, well, thank you for your time.

James:

[2:00:42] I’m on Twitter, too. I’m part of the thing, but just ignore me.

Ryan:

[2:00:51] Oh, God. All right, well, thank you so much for your time, James. I really appreciate it. This was a lot of fun.

James:

[2:00:56] Ryan, it was great. Thank you.

In addition to language design questions, I asked him for his personal anecdotes since I felt only he could tell those stories. Below are my top three takeaways to save you time.

You can find the full conversation on YouTube, Spotify, Apple Podcasts. The transcript is on Substack if you prefer to skim.

Brought to you by:

Cursor3: a unified workspace for building software with agents. I used it to build tools for the podcast and shared the process in this episode’s ad read.

WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code

Takeaways from the conversation:

1) How Bell Labs did research - When I asked Bjarne about how project selection went, he talked about two ways of doing research.

In one way, you have a well-designed project that is carefully chosen by management. Then the project is staffed with many researchers. This was not the Bell Labs way.

The other way was to hire the best people on the planet and don’t tell them what to do. Each year, the researchers would be asked to explain what they did in 9pt font or larger on a single page. If you can’t explain what you’re doing concisely, it probably isn’t that interesting.

If the work was interesting enough, then you could continue to work on it. Even though this was unusual, the results speak for themselves as much of the technology we take for granted today was invented at Bell Labs.

2) Negative overhead abstraction - Coming into the conversation, I assumed that more abstraction meant you’d lose performance but Bjarne corrected my naive assumption.

A simple example is to look at C vs C++. Because C++ encodes more information in the language itself, the compiler has more it can use to optimize the final result. Therefore, the abstractions in C++ can be used to get better performance actually.

3) There was a garbage collection API in C++ - I had always assumed that where there was C++, there was manual memory management. I was wrong.

In 1995, Bjarne introduced a standard interface for garbage collection due to user requests. However, C++ developers tended to prefer manual resource management so the garbage collection API never got much use. Later, this garbage collection interface was removed from the standard. This is probably why you don’t hear too much about this.

By the way, thanks for the input last week on where to place ads. It looks like most people prefer the ads grouped together instead of multiple shorter breaks. I would have picked the same personally. I factored in that feedback for this episode.

Looking at other podcasts, is it seems like some creators like to lump their ads together at the beginning instead of in the middle of the episode. I can see arguments for both sides:

1. Beginning → get the interruptions out of the way so the episode can be interruption free

2. Middle → reading ads before delivering value could make people bounce

Curious your thoughts on what you’d prefer:

Thanks for reading,
Ryan Peterman

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

Timestamps

0:50 - The origin of C++

8:46 - What Bell Labs was like

17:24 - Dennis Ritchie

24:00 - When to build a programming language

31:59 - Bootstrapping a language

33:58 - C++ is not object-oriented

37:32 - Discussing type systems

46:20 - Memory safety

49:26 - Standards committee anecdotes

1:09:40 - Adding automatic garbage collection to C++

1:18:25 - Template instantiation is Turing complete

1:21:57 - Abstraction and performance

1:28:51 - AI writing code

1:35:54 - His motivation

1:39:18 - Famous quotes

1:46:48 - Reflecting on building C++

1:49:12 - Top C++ book recommendation

1:50:59 - Advice for his younger self

Transcript

0:50 — The origin of C++

Ryan:

[0:50] What is the origin story behind C++?

Bjarne:

[0:54] Well, let’s start from the real beginning. I got a job at Bell Labs, which is a really great place in New Jersey. It’s not like that anymore, but at the time it was the best applied math, applied engineering place in the world. I looked around at the great people who were there; they built Unix. They did a lot of the theory behind it, and I realized I had to do something important; otherwise, it didn’t belong.

[1:30] So I decided I was going to build a distributed Unix because it was clear that computers were getting better, networking was getting better, so we needed one of those. If I had succeeded, we would have had Unix clusters ten years earlier or something like that. But of course, I couldn’t do it. That’s not a one-person job. The first thing I realized was there wasn’t a language in the world that could do what I needed.

[2:05] It needed two things: low-level access to hardware, such as memory managers, process implementations, process schedulers, network drivers, and device drivers. Then it needed high-level features that indicate, well, there’s a module here on this computer and there’s a module there on that computer, and here’s the communication protocol they’re using, things like that. There are lots of languages that could do either, but none that could do both.

[2:43] The obvious language for the low-level stuff was C because Dennis Ritchie and Brian Kernighan were down the hall, and I said distributed Unix because I was in the home where Unix was invented and still being built. For the high-level languages, there were a fair number, but they were all too slow and they couldn’t manipulate hardware. But I learned to use Simula. I knew Kristen Nygaard and Ole-Johan Dahl, who invented object-oriented programming and Simula.

[3:22] And so I decided I had to merge these two. The way that was practical was to take the class concept from Simula and stick it into C so that it could run much faster and be used for systems programming. At the same time, I made the type system a bit more regular. User-defined types and classes were handled the same way as built-in types. That’s basically the start of what neither C nor Simula could do, which gets us to generic programming.

[4:03] Eventually, many years later, I had to add overloading. We have always had overloading. You can add two integers, you can add two floating-point numbers, you can add a floating-point number to an integer with a plus. That’s a single name, right? So I had to generalize that to be able to have a unique set of rules for both built-in and user-defined types. That’s where it came from.

Ryan:

[4:36] In one of the lectures that I saw that you gave, you talked about rewriting a simulator in BCPL. Is that the distributed Unix work?

Bjarne:

[4:46] No, that’s before that. I went to Cambridge, England, to get a PhD, and at some point, I decided I needed a simulator of software on a distributed system to do the PhD work on distributed systems. Of course, the idea of distributed Unix three or four years later came out of the same way of thinking. What I did was I wrote a really nice simulator in Simula. Simula is very good at that. It’s misnamed because it was a general-purpose programming language, and its bad name didn’t help it at all.

[5:37] But anyway, I wrote this simulator and I wrote little examples, test cases, etc. It all worked nicely. Then I tried the first real run full scale and I took the department’s mainframe and used it for a very significant time. Well, PhD students can’t do that. The chemists and the astrophysicists would never accept it. So I was kicked off the machine, and it was clear that Simula.

[6:19] I could write the program in Simula very well, but I couldn’t afford to run it. So I took the ideas and moved them to a little-used experimental computer, which was the CAP computer, which had hardware protection and capabilities and great stuff for hardware. It was somewhat unusual, so the astrophysicists couldn’t use it. They weren’t computer scientists as such, but I could. The only problem was I couldn’t run Simula there because Simula was never ported to that kind of machine; it was being used on mainframes and it was proprietary, and everything was wrong in the context of the CAP computer.

So I basically rewrote my simulator in BCPL. BCPL is a language that will make C look like a high-level language and has only one data type, the word. It was a very painful exercise, but once I’d done it, my program ran, I guesstimated about 50 times faster. I got my data and I got my PhD. So that was good. But I was convinced I would never again attempt a problem with tools that inadequate as I had tried on the mainframe in Cambridge.

[7:13] So I basically rewrote my simulator in BCPL. BCPL is a language that will make C look like a high-level language and has only one data type, the word. It was a very painful exercise, but once I’d done it, my program ran, I guesstimated about 50 times faster. I got my data and I got my PhD. So that was good. But I was convinced I would never again attempt a problem with tools that inadequate as I had tried it on the mainframe in Cambridge.

[8:07] And so I had a list of things that my ideal language should have, and, well, C didn’t have all of that, but it came closer than any other language that existed. C++ came out of there.

Ryan:

[8:25] Yeah, in that lecture you said something like that. Writing that program in BCPL was so difficult you lost half your hair debugging.

Bjarne:

[8:35] That’s almost exactly true. And I lost the other half getting C++ going over the years. But anyway, it worked.

8:46 — What Bell Labs was like

Ryan:

[8:46] You mentioned Bell Labs, and I think there’s a lot of curiosity about that topic just because it’s such a legendary place. When you graduated from your PhD and were thinking about where to work, what was Bell Labs known as at that time?

Bjarne:

[9:04] Bell Labs was the place to go if you wanted to do practical engineering at a large scale, at sort of world class. I think it was easily the best. We probably had twice as many computer scientists as MIT at the time, things like that. The Computer Science Research Center had great people, and some of them had come from Cambridge. One day, in my last year in Cambridge, one of the people from Bell Labs came along to give a talk.

[9:54] And the tradition in England and in the computer lab is, after a day’s work, you go to the pub and you chat with other people to see what has been going on. He said, “Well, when you need a job, give us a buzz.” So I did, and I flew over to New Jersey on my own tab, actually. My later boss, Sandy Fraser, a great guy working with networking, told me that I’d come at a wrong time. They didn’t have any jobs. This is not what you want to hear when you’ve just flown over the Atlantic. Anyway, the next day I gave a talk to a development group, not the research group, and then they changed their minds and took me up to the research group, and I worked there for the next couple of decades.

[10:34] This is not what you want to hear when you’ve just flown over the Atlantic. Anyway, the next day I gave a talk to a development group, not the research group, and then they changed their minds and took me up to the research group. I worked there for the next couple of decades.

Ryan:

[10:53] What was the interview process like?

Bjarne:

[10:56] You just talk to some people. I remember having a long chat with Dennis Ritchie, for instance, and I talked to people doing networking mostly. There wasn’t an interview process as such. They hadn’t actually hired anybody new for five years. So no, they just did it by the seat of the pants.

Ryan:

[11:27] So it’s kind of like the belief and credibility that other people say that you have. Like Dennis Ritchie talked to you and he knew that you knew what you were talking about?

Bjarne:

[11:38] Sandy Fraser and such. They just talk to you, see what you know and don’t know. At the end, they go to the director and say, in this case, we’ve got a good guy; can you let us have him? I, of course, didn’t know anything about that. I wasn’t there. I was out talking to somebody in California, and I get a phone call from the director saying, would you like to come and work here a week later?

Ryan:

[12:10] What gave you the conviction to fly on your own tab to go? And there wasn’t even a promise of a job yet?

Bjarne:

[12:17] No. Well, it was the best place in the world, right? Do you need any more? If it worked, it was the best. And if it didn’t work, so what? You can’t succeed at everything.

Ryan:

[12:35] Today, there are more industries that have a stronger pull than at that time. Would it have been IBM or something? That would have been the best industry.

Bjarne:

[12:43] I talked to IBM; they weren’t as good as the Bell Labs Computer Science Research Center. I was up at Yorktown Heights, and I talked to the researchers and the young researchers. I just didn’t think they were doing the right stuff and not in the right way. They were much more controlled and directed than the researchers at Bell Labs.

Ryan:

[13:12] At a place like Bell Labs, how does project selection go?

Bjarne:

[13:19] I think still there are two philosophies about how to get good research. The one is that you have a well designed project chosen carefully by management and higher management, seriously funded and maybe you do put 20 or 30 people at the problem and you solve it and you have something great. The other philosophy is you hire the best people you can find and don’t tell them what to do.

[14:01] My job was described as do something interesting in a year’s time, tell us what you did, and if we like it, we’ll extend. We will give you the same deal next year. By the way, the way you tell us is you write one sheet of paper using more than a nine-point font or more. Because if you can’t say what you did fairly briefly, you probably haven’t done something interesting enough, very unusual. So there they were actually worrying when they built Unix because it eventually involved five or seven people, and it was getting too big for that model of the world of individuals doing interesting things.

[15:03] Very different. I would say that on average, this fairly anarchic organization did better than the well-organized one. Most of the things you’ve heard of from Bell Labs came out of there. In another part of the building, they were doing hardware things. So fibers, as we use them today, came out of there. A lot of the wireless technology came out of there. The charge-coupled devices that are our cameras came out of there.

[15:43] They tried to do videophones and couldn’t get it to work because hardware hadn’t grown up to it, but they were trying to do it. The system of cells for cell phones came out of not that building, but another building. For Bell Labs, it was just a great place. The computer science people tended to talk to people doing other things. I remember when I was doing simulations, I was helping somebody build a simulator for some networking stuff.

[16:18] A lot of early C++ had to do with doing things like what happens when a network get overloaded, how do we handle the overload protocols. And in this particular case, they did a good job. And they called me back and they had a slightly bigger problem. They wanted to simulate the computer traffic of Manhattan. Even then, my answer was no, we don’t have the compute power to do that.

Ryan:

[17:02] Back then, though.

Bjarne:

[17:04] Now they probably could, but of course the computer traffic has become much more. So maybe they can’t; I don’t know. I don’t have the numbers now. Then they gave me the numbers. That was why I declined to help them because it was impossible.

17:24 — Dennis Ritchie

Ryan:

[17:24] I saw somewhere when I was doing research that you said you had gotten lunch with Dennis Ritchie once a week for like 16 years or something like that. And you know, he’s also a very legendary name. And I was curious, you know, if there’s anything that you, you learned from him or anything that impressed you about him that maybe influenced you or C++.

Bjarne:

[17:49] He was a great guy and we talked about a lot of things. He never said anything rude or negative about C++. Actually, in his Hubble paper, he points to C++ as the obvious successor to C. So all of these C versus C++ language wars are ridiculous. They should never have happened, and they certainly didn’t happen because, well, I knew Dennis. We were not fighting. I still know Brian Kernighan. I was talking to him this Friday.

[18:33] We’re good friends. And yeah, language wars are silly. Dennis helped me design Const, for instance, for C++. It used to be called Read Only and Write Only, but the C guys couldn’t handle two words and they were too long. So we got what we got. But that’s one specific thing I remember Dennis being helpful with. He was a bit worried. Worried about overloading because you had to look at the declarations of functions before you knew what the meaning of a call was.

[19:21] But that’s a very reasonable way of thinking. It just happens that it works. Anybody who writes see today are using my handiwork essentially all of the time, because the modern syntax for function definitions and function declarations and the call semantics came out of the early C++, early serial classes work of mine. So when people start ranting, they should remember that they’re actually using my handiwork every day.

Ryan:

[20:04] You had written these almost like historical accountings of the history of C++, like maybe three really long papers. I think for some conference I forgot the exact. And so in there, there was one anecdote about Dennis Ritchie. It was about this concept where he proposed to the C Standard committee this idea of a fat pointer where it also has. It stores its size as well. You mentioned the C Committee didn’t approve.

Bjarne:

[20:43] Dennis did see, but he didn’t take part in the Standards Committee. I’ve even heard people from the C Standards Committee say, no, Dennis isn’t a C expert. He’s never come to meetings. Very strange attitude. But anyway, we knew the problem about buffer overflow and range errors. The obvious solution is to use what Dennis called a fat pointer, which is a pointer with its number of elements it points to attached to it.

[21:24] But that’s two words. And that’s probably— no, that is why it wasn’t used in early C++, because then they had 48 kilobytes of memory. When I had this discussion with Dennis, I think we had a whole megabyte. When I started with C++, we had 256 kilobytes. I knew that we were going to get a megabyte. We were talking about it, and he called them fat pointers. Today in C++, they’re called span.

[22:04] And the span came out of my work with others on the C++ core guidelines. We needed something like that. We couldn’t provide the degree of control and safety that we needed. So we built span, and it came into the standard a bit later. But some of these ideas are very old.

Ryan:

[22:30] When you put together really impressive people, like the world’s greatest people, you look around and see how great the others are. Even though each individual is great, just the greatness of others can give people this feeling of imposter syndrome that’s not necessarily founded. Is that something that you ever felt or saw at Bell Labs?

Bjarne:

[22:52] Definitely, maybe I still have a bit of it, but certainly when I came to Bell Labs and saw the names on the doors and I had read the papers, they had created the fields I like to work in. Yeah, I thought I have to up my game. I have to do something bigger and better than what I had imagined. Also, you talk to them and you learn things. I learned a lot over lunch where there were a bunch of them talking about what they’re doing and why they’re doing it.

[23:30] There are some places that have that effect on people and have the density of talent. Cambridge University was one of those places. I learned a lot there. The doors were always open. It was almost a policy that we kept the doors open because of Howells.

24:00 — When to build a programming language

Ryan:

[24:00] And when we talk about a programming language and just generally about language design, if I wanted to build a programming language today, what are all the pieces that I’d need to create to make a programming language?

Bjarne:

[24:17] Well, that’s a relatively easy question to answer. Everybody asks that question, and I think it’s the wrong question. What you need is a problem that needs a solution. A lot of people just want to build a language that is better at what they are doing now and what they particularly are doing. Most of the time, that can be done reasonably well with existing languages. If you build a very specialized language, that’s fine.

But if we’re talking about more general-purpose languages, you’re then building something that, when you want to work with somebody else, it’s not ideal for them. I’m sometimes asked why C++ is so big and complicated. There are two reasons. One is history. I could not build the C++ I wanted back in the 80s for a variety of reasons—partly technology, partly computers, and partly because I didn’t know enough and I had to learn.

[24:55] But if we’re talking about more general-purpose languages, you’re then building something that, when you want to work with somebody else, it’s not ideal for them. I’m sometimes asked why C++ is so big and complicated. There are two reasons. One is history. I could not build the C++ I wanted back in the 80s for a variety of reasons—partly technology, partly computers, and partly because I didn’t know enough and I had to learn.

[25:37] So you do the standard engineering thing, you do the best you can, then you see what works and what doesn’t work and try to fix the problems. Then you repeat. That’s how C++ grew. There are some leftover things that just get in people’s way now. You have spans, you very rarely use pointers, and you should certainly not use pointers for resource handling. That was already built in with your classes in ‘79, but people didn’t get it, so there’s teaching to do.

[26:19] But anyway, once you figure out that you have a problem that requires a new language, then you start looking at what there is, and you have lots of help, lots of books about analysis and about code generation. You have frameworks like LLVM that most of the modern languages use to generate decent code. So most of the languages that compete with C++ do it by using a C infrastructure. It’s highly amusing.

[27:02] But anyway, focus on the problem and don’t think you’re the only user. If you think you’re the only user, you build a special-purpose programming language, and that’s fine. Domain-specific languages are great when you find the right solution to the right problem, but identify the problem first. In my case, the problem was I needed high- and low-level facilities in the same language. Otherwise, I had to use two languages, and I had to have them communicate properly.

[27:41] High-level languages at the time tended to use interfaces that took away performance. Quite often, they required garbage collection, which is not very good for device drivers, for instance, or for building garbage collectors. So yes, identify the problem and try to solve it.

Ryan:

[28:06] Back when you were creating C++ and you had identified the problem, you went off to build C++, and there were all these pieces, right? There’s the compiler, there’s a linker, and in the implementations of those, there’s a parser and all those things. When you were building the original thing, what was the most technically challenging part to implement?

Bjarne:

[28:33] I don’t think any part was particularly challenging. It was more those many parts, as you point out. One of the things I decided that caused trouble later was that I wasn’t going to touch the linker. It came simply because I asked around and realized people were using about 25 different linkers at Bell Labs, just in Bell Labs. If I wanted to serve my obvious initial uses, I would have to write interfaces or modifications to 25 linkers.

And nobody wants you to touch their linker because if you make a mistake, everything breaks. So I decided on a rule: don’t mess with a linker. Later, people have messed with the linkers and made them better for C++. But that was after C became a major issue. The other thing was that there were many different optimizers. Every computer from different sources had a different optimizer, and again, I couldn’t write a dozen optimizers.

[29:14] And nobody wants you to touch their linker because if you make a mistake, everything breaks. So I decided on a rule: don’t mess with a linker. Later, people have messed with the linkers and made them better for C++. But that was after C became a major issue. The other thing was that there were many different optimizers. Every computer from different sources had a different optimizer, and again, I couldn’t write a dozen optimizers.

[29:56] I mean, I’m going to write a language here, right? And I can’t write. If I wanted to be an optimizer specialist for deck computers, I could become that. I have the background, I have the training, but that wasn’t what I wanted to do. I wanted to build first a distributed system, and then when my friends and colleagues started using Simula classes, I wanted to help them. They were doing things like network simulations, hardware layout, positioning of satellites, all kinds of interesting stuff.

[30:39] So that was worth doing. I decided that actually there was a common interface to all these optimizers and code generators. It’s called C. So let’s use C as the assembler, and that worked nicely. C was very good at the low level, part of the reason I chose it. So let’s use it for the low level. I could have hidden C and recreated probably a better interface, but I decided that I’ll just use C and have C compatibility.

[31:21] At the time, what I said was that we can have Dennis Ritchie‘s mistakes, which we know, and we can have my mistakes, which we don’t know yet, so we’ll take Dennis’s. That’s much more manageable and understandable, and I don’t have to teach people how to write a for loop and things like that. So that’s how C compatibility came in, partly as an implementation technique and partly to get into the culture and tool support and such.

31:59 — Bootstrapping a language

Ryan:

[31:59] I saw somewhere in my research that C++ was used to write some part of the language toolchain, and immediately I had this thought of a chicken and egg problem. How do you use this language to build something that it is using itself? How does that work?

Bjarne:

[32:23] This is bootstrapping, and it was not an unusual thing. So I started with C++. I wrote a preprocessor that did some of the fundamental things in what became C++ classes, including fairly simple inheritance and overloading. Then, in that, I wrote a simple compiler for a subset of C++. Now I can use operator overloading and overloading in general classes, so I can build a scope class that handles lookup and naming and things like that.

[33:22] And then you work from there, just writing the next version in the previous version. You keep going, and after a couple of years, you have something that became known to the world as C++. I wrote a book about it, and a compiler came out in the world. But I didn’t invent this technique. This was known as bootstrapping. I think I was taught it as an undergrad that you could do things like that.

33:58 — C++ is not object-oriented

Ryan:

[33:58] Most people look at C++ and think that’s an object-oriented language. I’ve heard you say multiple times that that’s not the case or that’s not your immediate thought. Why is that?

Bjarne:

[34:10] Yeah, I never called it an object-oriented programming language. If you look at the C++ programming language, the first edition, the closest I come is to say some people call these techniques object-based. Actually, it’s more focused on classes; it’s type-oriented, class-oriented. It actually supports the techniques of object orientation very well. In particular, it follows Simula‘s model of defining types, defining classes, and defining class hierarchies to handle groups of related classes.

[35:00] But that was never all it was. For instance, I do not want object-oriented complex numbers. I don’t want to say 2 dot something to get to some parts of numbers. I really want to say two plus Z, and I want that to end up being roughly the same as Z plus 2—no dots, no arrows. Math has developed a notation over the last 300 years or so. Descartes was, I think, the first one to use this notation, and it is very good.

[35:54] I didn’t want everything to be object-oriented. Furthermore, I wanted things that did not require inheritance, that did not require runtime resolution, not to use it. So for arithmetic and for complex numbers and such, I wanted Fortran compatibility. I was rather keen on what’s called reuse in those days. But I saw it slightly different from a lot of researchers. A lot of researchers wanted to build a language, a system that allowed reuse.

[36:38] I wanted to reuse things that existed. Fortran was there with some great software, C was there with some great system software, and actually helped with compilers and such. There was a Simula that was used a fair bit too. So I wanted to reuse that, and I wanted to make sure that worked. And that meant I couldn’t go too far away from the hardware. I couldn’t build all of the things that were considered ideal, or even the things I would consider ideal.

[37:19] This is the real world; this is the real set of problems you are attacking. You have to respect the constraints that come with that view of what you’re doing.

37:32 — Discussing type systems

Ryan:

[37:32] At the time that you wrote C++, C was already there and it had a weaker type system than what C++ eventually had. Just give your thoughts on the trade-offs behind that. Why did you choose to make the typing system stronger in C++?

Bjarne:

[37:47] Because we needed it. The weakness in the type system is one of the most obvious sources of errors, and it’s certainly one of the sources of endless testing and debugging. I hate debugging. I would much rather do design. You can’t really have either design or debugging. Some people claim they can, but they can’t. So I want to move the arrow towards more design that helps the debugging and makes fewer mistakes at runtime.

[38:33] And the type system is one of them. And actually what you get and see today to a large extent is much stronger. Well, no, it is a much stronger type than it was in those days, and partly because of C++. Also, there are things you can’t express unless you have a strong type system. I mentioned overloading before. Overloading is essential for generic programming. And if you want to write, say, a vector of T where T is a parameter type, you have to have overloading because you can only operate on T’s, providing all the T’s have the same interface for what you need.

[39:17] So you need the type system to resolve those things, and that can be resolved at compile time. The compiler gets a bit more complicated, probably a bit slower, but you don’t need to do so much debugging. There was a large-scale experiment done at Bell Labs in Chicago where they had some groups using C switching to C++, and they wanted to know whether they were more or less productive. Some people claimed that the slower compilation slowed them down.

[40:04] Somebody simply measured how much compile time was used before and after switching to C++, and they found that the amount of compilation time on compute power was roughly identical. That is, C++ was slower by about a factor of two at that time. But the C++ people compiled twice as often. This is just one experiment. The factor of two is just one experiment, but I wanted to move towards using more compile time resolution.

[40:51] Still doing that.

Ryan:

[40:53] I mean, for every language there’s this dichotomy of having it being statically typed versus dynamically typed. And C++ is one of the most famous statically typed languages. Why did you choose a statically typed language?

Bjarne:

[41:09] Because of the problems I wanted to attack. What do you do when you get a runtime error in something like Smalltalk? You go into the debugger, and that makes a lot of sense. If there’s a programmer sitting at a screen getting the error, it doesn’t make any sense. If a telephone switch finds a runtime error, then you have to resolve it. Furthermore, you want performance, and you want small programs to fit into memories.

[41:48] This is true even today because I think 99% of all computers are embedded systems, and they tend to be memory constrained. Again, if you do runtime resolution, you need to have enough information, enough data to do the runtime resolution. I wanted to fit into small memories—small meaning 120k, 250k, 1 megabyte, things like that. I think it’s still relevant for many systems.

[42:32] You can build a camera like that; it can still have several megabytes of memory. But if you put in a lot of memory, it gets bigger, costs more, and the battery runs out quicker. So we don’t do that. Phones, cameras, and things like that are still memory constrained. Statically typed languages, languages optimized for memory consumption, are just better at that. That’s why we use it; we’re using it right now.

[43:10] I suspect that the microphones have chips in them too. There’s a lot of C++ in that world. The composition there is C and assembler.

Ryan:

[43:24] And you mentioned the research that was done on the compile time on

Bjarne:

[43:32] If you catch things earlier, you compile less often, but maybe it takes longer in this case. I could see a similar analogy where you catch errors way earlier if you have a statically typed language because the compiler is yelling at you before you put together that final thing. Whereas in a dynamically typed language, the errors may come later.

Ryan:

[43:32] You catch things earlier, you compile less often, but maybe it takes longer in this case. I could see a similar analogy where you catch errors way earlier if you have a statically typed language because the compiler is yelling at you before you put together that final thing. Whereas in a dynamically typed language, the errors may come later.

Bjarne:

[44:00] I don’t know any solid research on that, but you can look at it. JavaScript and Python are very popular, and they are runtime checked and they run much slower. I mean, raw Python runs something like 70 times slower than raw C++. The reason it’s viable is that a lot of key Python libraries are written in C or C++ to get the performance. So you get the performance by actually getting to the point that I was starting out with.

[44:43] You need high-level stuff, and you need the thing that can manipulate hardware. Here they are using two languages, but still the same fundamental needs. It’s easier to try out things in a dynamically typed language because you don’t have to know enough about the language; you don’t have to know about type systems. Your average web developer or astrophysicist is not a computer scientist and doesn’t want to become one.

[45:20] So there are advantages there. But the problem is that errors found by the type system in a statically typed language are discovered at runtime later. As systems grow, performance problems start. Furthermore, it becomes harder to write reliable software. You need much more unit testing, for instance, in a dynamic language because the compiler doesn’t do it for you. If you want things to guarantee to work—like the telephone switch mustn’t crash, your car mustn’t crash, your plane mustn’t crash—you want guarantees, and they’re harder to provide in a very flexible dynamic type system.

46:20 — Memory safety

Ryan:

[46:20] One thing that I think C++ is infamous for is memory safety issues or foot guns that exist there.

Bjarne:

[46:31] I’m so tired of that. I haven’t had those problems for years. Somebody did a study of the obvious problems with buffer overflows and people hacking in using that kind of stuff. Almost all of these cases involve people writing C-style code or in C. Herb Sutter has a talk with actual numbers, and they are quite significant. It’s sort of that kind of problem. More than 90% are from people who don’t write modern C++.

They use raw pointers to pass things around without the number of elements. No fat pointers, no spans. You have them in C++; you can use them, you can use vectors. We have hardened libraries; everybody has hardened libraries that do the runtime checking. Apple has it, Google has it, Microsoft has it. It’s just not standard until now. C26 has a hardened option that is standard. The work I’m doing on profiles will give you a way of guaranteeing that you don’t do the stupid things.

[47:24] They use raw pointers to pass things around without the number of elements. No fat pointers, no spans. You have them in C++; you can use them, you can use vectors. We have hardened libraries; everybody has hardened libraries that do the runtime checking. Apple has it, Google has it, Microsoft has it. It’s just not standard until now. C26 has a hardened option that is standard. The work I’m doing on profiles will give you a way of guaranteeing that you don’t do the stupid things.

[48:12] So anyway, fundamentally, theoretically, the problem was solved many years ago, and people just do what they’ve always done and get the problems they’ve always had. That makes me sad. It’s one of the things that makes me work on coding guidelines, enforced profiles, and education.

Ryan:

[48:40] I mean, education is one way to solve the problem. Is there a way to get the compiler to just prevent people from doing all those risky things? And is that enabled by default in modern C++ today?

Bjarne:

[48:53] No, but it should be. I’m proposing that for C++29, the simpler versions of that should have been in C++26. But there are still a lot of people, even in the C++ Standards Committee, that are very devoted to their old code and their old ways of doing things. There are people who say you should only standardize what is common in industry, but when the bugs are common in industry, you should do something else.

49:26 — Standards committee anecdotes

Ryan:

[49:26] The Standards Committee is a topic I want to talk about. It’s interesting. I mean, the language is now run by a democracy. One question I wanted to ask you is if it was a dictatorship, and you had full say over what language features would be included, would that make it harder to get by?

Bjarne:

[49:48] First of all, it never was a dictatorship. I never had full control. Once you have some users, in my opinion, you gain some responsibility for making sure that they’re helped and their stuff works. You can’t keep breaking the language. That’s what academic language development does. They break to improve all the time, and then they can’t maintain a user population. I didn’t actually choose to have a standards committee.

[50:23] I chose responsibility to the community. But one day, two guys came in representing IBM and HP, and I can’t remember if it was Sun or DEC that was the third thing they represented. But anyway, the biggest computer and software suppliers in the world at the time came into my office in SH9 and said, “Well, Bjarne, do you want to help us standardize C++ under ISO rules?” I said, “No, I can’t do that.”

[51:10] I’m still doing experiments. It’s still not complete. So they said, “No, Bjarne, you don’t get it. Our organizations cannot use a language that’s not standardized. They cannot use a language that’s owned by a corporation that we might compete with. And we do sometimes, okay, we trust you, of course, but not your employer. We compete with them sometimes. And you can get run over by a boss. No, no, no.”

[51:49] We need a standard, and we need a standards committee. So this goes on for about an hour. They twist my arm. Ow, ow, ow. In the end, they said, okay, I will standardize C++ under ANSI rules just like you suggest. The computer community needs that. By the way, what’s the ANSI rule for standardization? They told me, and we started a year later. But this was the way it came about.

[52:25] Some very important organizations wanted that standardization. C++ was on track to get standardized, and AT&T, being primarily a user of software, was also in favor of standardization. I found out, and so they supported it. The documentation I had written was based on it. Actually, I rewrote the documentation that became the ARM, the Annotated C++ Standards Manual, which provided the definition, the manual of the language, and for every feature, some rationale and some way it could be implemented or was implemented.

[53:16] And that became the foundation document for the standardization.

Ryan:

[53:21] When they were strong-arming you, what if you had just said no? What would have happened?

Bjarne:

[53:26] Well, I think C++ would have faded into becoming an academic cube language that was loved by some small community, and it would have disappeared out of the mainstream of computing. There are people who say this stronger than I do. They say that C is spread and its usage is that it has a standard; it’s not owned by a corporation. It is one of the things that sometimes blocks the wannabe C++ killers.

[54:17] I remember the ads for Java and people standing up saying, “We’ll kill, absolutely kill C++ in two years.” I thought that was rude. Anyway, we have 10, 12 times more C++ developers today than we had when they said it, so it didn’t work.

Ryan:

[54:43] How is it that C++—not exactly that it’s a war—but just if we looked at adoption, clearly C++ gained a lot more adoption than Java. Yet I know Java had the backing of a big company that was putting a lot of marketing dollars in, and C was kind of, I think you’ve said that it had almost zero, next to zero marketing done for it.

Bjarne:

[55:13] Next to zero was $5,000 to be used over three years. Sun used much more money on advertising and marketing Java than was ever used in C++ development. To this day, the standards committee has a problem. It has no funding, and that means it’s hard to do extra experiments; it’s hard to deploy things. Other language communities keep sort of stealing C++ compiler and tool developers because they’re good.

[55:59] But it makes it hard to predict how fast we can implement things today. Last I checked, the C++ standards committee had 527 members. We work on consensus because if you don’t have consensus, then you get dialects. We don’t want to have a feature that’s voted in say 60 to 40 or even worse, 52 to 48. No percent. We don’t do that. And that’s painful and tedious and good.

Ryan:

[56:45] When you say consensus, that 100% need to approve is not necessary. We don’t need unanimity. We need a massive majority. And basically, I would like to see 90%, and we often do 80%. I start to worry.

Bjarne:

[56:47] To approve 100% is not necessary. We don’t need unanimity. We need a massive majority. And basically, I would like to see 90%, and we often do 80%. I start to worry.

Ryan:

[57:08] What’s the lower bound that’s coded into the rules?

Bjarne:

[57:10] There’s no lower bound coded into the rules. The rule says that the convener of the ISO committee determines what is consensus. Pure numbers don’t say it. Could you imagine you had a vote, 95% versus 5%? But the implementers of C++ compilers and standard libraries from Google, Apple, Microsoft, and others were all in the 5%. Is that consensus? I can reassure you that no convener would call that consensus.

Ryan:

[58:02] And that makes sense intuitively. I kind of wonder, with democratic decisions, there need to be objective rules. So what if the convener made the wrong decision?

Bjarne:

[58:13] It happens. But you can’t just have numeric rules. Not everybody cares for the whole language. Not everybody understands what’s going on. You can vote at your third meeting. So you might have somebody with a vote that has eight months of experience with the standardization and doesn’t understand standardization and knows only what they know from their development organization that they have been part of, which might be a small one.

[58:55] You need some judgment, and you hope that the convener has that judgment. The convener always asks the national representatives. I mean, the other way of getting a consensus is that you have a massive consensus, but you have ten countries where the representatives didn’t agree. That’s not consensus. And even when there looks, if there is a look, if everybody is for it, if it’s massive and all of that, there’s not a problem.

[59:35] But if there’s a problem, the convener asks the national body heads, he asks the implementers, sort of key people that are necessary for getting the voted change into real use. Sometimes educators also before they make that decision. Not everybody weighs equally once there’s a disagreement.

Ryan:

[1:01:45] I saw in some of your writing you said one of the most negatively received ideas you’d ever presented was Auto. I know Auto eventually made its way in there, but what’s the story behind why it was so negatively received?

Bjarne:

[1:02:02] At that time, it was just unusual. People thought it was weakening the type system. It also opened the door to fairly general generic programming that is not heavily syntax-based. Auto is the beginning of concepts, which is the ability to put constraints on generic code. Auto is just the simplest constraint; it must be a type as opposed to seven. Maybe I didn’t explain this well enough, and there’s a variety of backgrounds in the committee. Maybe they didn’t know languages of the generic types, such as ML and Haskell.

[1:03:04] So it was a horrible ache. Anyway, we still got it because we needed something like that, but it wasn’t enough. I have looked at industrial software and problems with the overuse of Auto. You should only use Auto when you have an idea about what is needed there. It’s good in generic code where you go and eventually check that the type is correct, that Auto has resolved to something that supports the operations that you’re going to do on it.

[1:03:50] And that’s what concepts formalize. But it was always checked at the end, and I noticed a group of people that was overusing auto, actually in a framework for networking. They were saying that they were being slowed down, not so much with bugs, but they had to look up the functions being called to see what that auto could possibly bind to. And then they had to put in comments that said what the auto was meant.

[1:04:31] So you have auto, and the comment says must be an input channel. Now you simply define input channel, and then instead of saying auto, you say input channel auto. Fine. That’s what the system is. My design of that simply said that auto is the simplest concept, and you should simply only set input channel C++ equals blah blah blah. But anyway, the committee wanted an indicator that this was going on.

Ryan:

[1:05:10] Oh well, I saw another anecdote about the standards committee being heated at times. You mentioned there’s this thing about shuttle diplomacy between two corners of the room. I think it was IBM and Intel. They both needed different support. What’s the story behind that?

Bjarne:

[1:05:30] I was actually talking to Brian McKnight, who was the IBM representative at the time. We were discussing some of the things that were happening then, and it’s still remembered. So basically, IBM was doing the... What’s that architecture called?

Ryan:

[1:05:54] PowerPC. And Intel was doing well. They had different models of the underlying hardware, especially coordination with the caches and things like that. The guy representing Intel wasn’t actually an Intel guy. Anyway, also a good guy. I used some of his slides in my presentations. I knew these guys, but they were totally deadlocked.

Bjarne:

[1:05:55] PowerPC and the x86. The Intel was doing well. They have different models of the underlying hardware, especially coordination with the caches and things like that. The guy representing Intel wasn’t actually an Intel guy. Anyway, also a good guy. I used some of his slides in my presentations. I knew these guys, but they were totally deadlocked.

[1:06:36] I mean, these are massive organizations with massive amounts of code out there. Basically, some things could be done. But the IBM guy, Brian, said that they had a lot of software, mostly in the lowest level, even down in the microcode, that was relying on the way they had done it. The people who had done it had left the company a long time ago, and they just couldn’t rewrite all of that code and get it right, even if the Intel guys were right.

[1:07:38] Okay. And the Intel guys had similar arguments and similar points. This is better. We are using it. I was shuffling; they were in different corners of a large room. So I go up to the Intel guy, the guy representing Intel here, and what’s the problem? Tell me about it. Explain it. I go down, explain. He’s saying this. They say, well, there’s this, this, this. I go back again and I spent a couple of hours literally doing shuttle diplomacy, walking from one corner of the room to the other.

[1:08:18] And we reached an agreement. That’s in C++. A couple of years later, they both agreed that they were now using a combination of what they had before and what the other guys brought in. So actually, the result was improvement, cross-pollination.

Ryan:

[1:08:45] That’s funny. Why did you have to do shuttle diplomacy? Why not just a group conversation?

Bjarne:

[1:08:50] Because they’ve been trying that for days and probably for meetings before that, and it didn’t work. So I guess I was just translating and asking questions. I mean, those were experts. I don’t consider myself an expert at that level. I’ve done hardware, I’ve done microcode, so I’m not an amateur, but these guys are really good. So the IBM guy is now the guy doing most of the synchronization on the Linux.

[1:09:30] We’re still using his stuff today. He has a C++ version of it, so he can get it into the bottom of the Linux kernel.

1:09:40 — Adding automatic garbage collection to C++

Ryan:

[1:09:40] When I was reading your writing in these papers, there’s this part where it seems like in 1995 you had this idea to introduce some form of automatic garbage collection into C++. That kind of surprised me because when I think about C++, one of my immediate thoughts is, no garbage collector. We’re going to manage the memory ourselves. How would that even work?

Bjarne:

[1:10:10] There’s two things there. One, I wanted to automate resource management in general, not just garbage, not just memory. For that, you have constructors, destructors, and the techniques later known as RAII—Resource Acquisition Is Initialization—which is probably my worst naming ever. But I was busy at the time. So in the standards committee, those people insisted that we needed to be able to do garbage collection.

[1:10:50] And there were garbage collectors out there. Oh, there was Hans Boehm here. He was the one representing the Intel model of stuff. He has a conservative garbage collector still used today. We thought we needed an interface so that it could be standardized how you used such a garbage collector. Basically, I was listening to the users, expert users, and they thought it was necessary. I thought that support for memory management and resource management was important.

[1:11:32] I’ve thought that from the beginning. I didn’t think garbage collection was appropriate for a lot of what I was doing. But certainly, automating the management was ideal. After a long set of discussions, we found an interface that people agreed on, and we put it into C++. What we found was that over the next 10 years, the amount of usage of garbage collection decreased as RAII, the resource management that had been there all the time, got more and better understood and was used more.

[1:12:24] Furthermore, the people who still used garbage collectors didn’t use the standard interface because they had figured out ways of doing it better. Today, there are still a few people doing garbage collection, but it’s not part of the standard.

Ryan:

[1:12:43] How does that work? Is it kind of like a wrapper around the memory allocation methods?

Bjarne:

[1:12:48] Yeah, okay. You have a different implementation of new or malloc or operate a new or whatever it is you’re using at your lowest level, and then delete becomes something slightly different too.

Ryan:

[1:13:11] There’s this cautionary tale in the C++ community about this ship, Vasa, and I was kind of curious why that’s popular.

Bjarne:

[1:13:21] Oh, we had a meeting in Stockholm at some point, and they have a wonderful ship that, if you ever get to Stockholm, you should see: the Vasa. It’s a battleship from the 1600s. There’s a story to that, and that’s the one I tell people. The King was ordering a battleship that should be the best and most beautiful battleship around. It was going to be a good fighting battleship and used for diplomatic visits. So it should be beautiful. They laid down the keel and started building it. Then they heard that a likely opponent was building battleships with two gun decks. This was an old-fashioned battleship with only one gun deck. If you put a one gun deck battleship next to a two gun deck battleship, the highly predictable result is a lot of holes in the one gun deck battleship, and it’s gone.

[1:14:05] So it should be beautiful. And they laid down the keel and they started building it. Then they heard that a likely opponent was building battleships with two gun decks. This was an old-fashioned battleship with only one gun deck. If you put a one gun deck battleship next to a two gun deck battleship, the highly predictable result is a lot of holes in the one gun deck battleship, and it’s gone.

[1:14:42] So the King orders that this ship should now have two gun decks. And they’ve already started building it. So they add another gun deck; they add cannons up there. And the King also watched. Now the ship is bigger, they want more statues and beautiful things. So it becomes a bit top-heavy. And rumor has it—I’ve never checked this rumor, so it might be wrong—that the ship designer committed suicide out of horror.

[1:15:23] Also, a thing that I don’t believe is just a rumor was when it was built, they tested it for stability. The way you test a ship like that for stability is you take the whole crew and you run them from one side to the other back and forth, creating harmonic sway. If you can do that 14 times, then it will stand up to the Baltic and the North Sea. Rumor has it—actually, as I said, I think it’s a fact—that they did it seven times and then they stopped because it looked dangerous.

[1:16:08] So this was 1624, I think the ship gets finished. It’s sailing out, the most wonderful ship you’ve ever seen. It’s sailing out in Stockholm harbor, trumpets blaring, flags flying, families of crew on board, the whole thing. It gets halfway across the harbor, a gust of wind comes, it kills a roar, and it’s gone. And it ends down in some place where there’s not much oxygen. So it was well preserved, and they fished it up again, and you can see it.

[1:16:56] And so I tell this story to the standards committee and I point out there’s something they did wrong. They built more features on top without improving the foundation. Always improve the foundation to make sure that it’s not just a random set of features that you have added, because that’s complexity. Furthermore, do not compromise your testing. That’s really dangerous. And furthermore, you’ve all noticed when your high bosses say something should be done, and the high bosses don’t always know what’s right. Sometimes the professional thing is to say, no, we are not doing this.

[1:17:43] We have to take it easy. If they had said, okay, we’ll build a one-gun deck battleship, we’ll just not call it the Vasa, call it something neutral. Then next year, you can have a battleship that’s been designed from the bottom up to be a two-gun battleship. You wouldn’t have any problems with that. But the high management, meaning the king who was in Poland at the time, so he couldn’t even see it, says, nope, must be delivered on time.

[1:18:17] And so they delivered something on time that just couldn’t do the job. But go see the ship. It’s great.

1:18:25 — Template instantiation is Turing complete

Ryan:

[1:18:25] At some point, someone demonstrated that the C++ template instantiation mechanism was Turing complete. So what the compiler is going to do to kind of preprocess that C++ program can actually be used for computation. I was just trying to understand how that is possible. It was mentioned something about calculating prime numbers at compile time. How does that work?

Bjarne:

[1:18:57] Well, the prime number thing was just a curiosity. It used the error messages to report the result. But when you build something, you can get Turing completeness. You need some form of iteration or recursion, and you need a comparison. That’s about it. Then you can achieve Turing completeness. At least some of the theoreticians say, “Hey, we can’t do that. It’ll run forever.” The guy who came up with the first example of this, Erwin Unruh, actually thought I should prohibit it somehow.

[1:19:50] I should ban it. My reaction was, “This looks useful. Great.” I think I was right. Furthermore, nothing runs forever. If you have a Turing machine, you have the tape, and the tape has to be infinite. So if you imagine building a real Turing machine the way Turing designed it, you have to have a bunch of navigators building track all the time when it gets out there. Of course, we don’t do that. The point is that the compiler will run out of resources long before we get into real problems.

[1:20:30] Machines are finite, so the problem doesn’t become real unless there are bugs and the bugs get caught. Guaranteed. So, it’s not a problem. What happened, though, was that people were misusing templates to do simple calculations like prime numbers or trustworthiness. Sieve or calculating factorials and such. It’s so awful, and it’s so expensive, and it uses up so much memory that it becomes a problem. So that was why I and Gabbitas Reyes built constexpr, which basically says you can calculate perfectly ordinary code at compile time. It is much simpler, much more what we’re used to, and much faster to compile, usually resulting in much faster code.

[1:21:37] And you have that today, and you have Constexpr if you want to guarantee that this is done. That takes care of the obvious misuse of the idea of templates being true and complete. It turns them into ordinary functions.

1:21:57 — Abstraction and performance

Ryan:

[1:21:57] Generally with programming languages there’s this high level intuition that the closer to the machine you are, the higher the performance is. And I tend to see C as closer to the machine than C++, for instance.

Bjarne:

[1:22:18] No, it’s not the case, it’s not the case. It’s not as good as compile time calculation that C++ is. And anyway, we have exactly the same machine model because C borrowed the C11 machine model. So if you write the same code in both languages, you get the same result. Except the C++ compilers can do more at compile time and so C++ runs as faster, faster than C. In most cases there’s more information. If you give Optimizer more information, it can do a better job.

Ryan:

[1:23:00] Okay. Yeah, because that was what I was going to ask you. You had said somewhere that C++ can be more performant than C, but I tend to think that more abstraction costs you something.

Bjarne:

[1:23:12] It’s compiled away. This is why I talk about zero overhead abstraction, and people are beginning to take me to task for that because that’s understating the ability of the C++ compiler. We can do negative overhead abstraction.

Ryan:

[1:23:34] What if I was really good at writing assembly and I had all the time in the world to write it? How does that compare?

Bjarne:

[1:23:42] If you are very smart and you have infinite time, you can do better. By and large, we are not as smart as the optimizers anymore, and we don’t have infinite time. So if we are smart enough, we can only do a small piece of code. And now the question is, did we get enough time to use our smarts? This is even starting to affect clever code. I gave a talk to Slack last year, which is a group of very performance-oriented people from the finance industry.

[1:24:33] My title was “Don’t Be Clever.” Actually, the written title was “Don’t Be (Too) Clever,” but I can’t pronounce parentheses. I got out alive. My main point was that C++ is good enough for more than 98% of your code. So if you want time to be clever, you use these techniques, and I showed modern C++. That way, you get time so you can do all the clever optimizations. The problem is, clever optimizations these days tend to be machine dependent.

[1:25:15] That is, if you get a new computer or if you get a new version of the compiler, you might actually have pessimized your code. I’ve seen this repeatedly ever since the 80s. There are people who do nothing but use different optimizations on the next generation hardware. My standard techniques for improving things actually are to first throw away the clever stuff and then see if you run faster or slower.

[1:25:58] Usually, you run faster because clever stuff, at least 1990s store style clever stuff, which there’s a lot of it still today, because the techniques carry on in people’s heads and some of the code remains, tends to use a rats nest of pointers, and that gives the compilers and optimizers problems. They also sometimes use more allocations, which is not good. You want to minimize memory access, you want to maximize your cache performance and things like that.

[1:26:41] And compilers are getting very good at that. I have seen this kind of thinking. I wrote a paper about it together with a friend of mine in Spain doing fluid dynamics, and we threw away the clever stuff—actually a performance test suite example. So it was not a toy, and we got only a 20% improvement by reducing the code to about 80% of what it was before. Some people didn’t think that was significant.

[1:27:26] I thought it was a significant proof that the technique was appropriate. You apply optimizations only when you need them. Knuth says don’t do premature optimization, but he also pointed out that 2 to 3% is where you should optimize, which is exactly the number I’m using. First, build the stuff using high-level facilities, see if it’s good enough, and if it isn’t, and you have to time it, you don’t guess your time. Then you figure out where the time is spent and then you optimize that.

[1:28:10] But a lot of the time, you don’t need to go to that stage; it’s fast enough.

Ryan:

[1:28:15] I see. So when you say cleverness here, it’s like human-level manual management to eke out performance.

Bjarne:

[1:28:23] Yes.

Ryan:

[1:28:24] And you’re saying that actually if you don’t do that, you’re giving the compiler more to optimize, and it can do a good job. It’s much, much better than it used to be. Code that was cleverly and correctly optimized in the 1990s is often pessimized today because machine architectures have changed and the compilers have improved.

Bjarne:

[1:28:31] A good job, and it’s much, much better than it used to be. Code that was cleverly and correctly optimized in the 1990s is often pessimized today because machine architectures have changed and the compilers have improved.

1:28:51 — AI writing code

Ryan:

[1:28:51] When I look at the industry today, more and more code is being written by machines than by humans. I feel like a lot of programming language design is thinking about how to make it amenable to humans solving problems and writing the code. I’m curious if you have any thoughts on whether you think programming language design will change if more and more of the code is written by models and machines.

Bjarne:

[1:29:23] I think that in the field I’m mostly interested in, code will still be written by humans, and they will use abstraction. The examples I’ve seen of attempts for AI to generate code in this domain have not been successful. They generate more bugs, more security holes. They have bloated code, which pessimize again because you use more memory, and it’s hard to validate. The senior developers that would be needed to validate it have started to retire because they don’t want to deal with the validation of something that changes every time you make a change in your code or your prompts. Furthermore, a lot of the things I think about involve regulatory bodies for this validation. You have to be able to validate what you changed. When you make a change and the AIs, the tools change, even if you make a slight difference in the prompt, a lot of the code will change, and you have to check it again.

[1:30:08] I’ve seen some of them starting to retire because they don’t want to deal with the validation of something that changes every time you make a change in your code, in your prompts. Furthermore, a lot of the things I think about involve regulatory bodies for this validation. You have to be able to validate what you changed. When you make a change and the AIs, the tools change, even if you make a slight difference in the prompt, a lot of the code will change, and you have to check it again.

[1:30:47] All of the code that was generated knows more code generated than if it was written by humans. When a human makes a change, it will make a change that’s localized. You can look for the effects of that localized change. If an AI writes it, you don’t actually know where it’s changed. You have to try and figure that out. So if you’re doing something that has been done many times before, like writing a standard web app, what you say is correct.

[1:31:22] Also, AI is not useless. That’s not what I’m saying. It can be used to write documentation. Again, it has to be humanly validated, but it helps write things. It’s good at text. It’s not, at least now, good at safety-critical, performance-critical code. Now, let’s say that 70 or 80% of the world’s code doesn’t fit that pattern. But it’s that 10 or 20% of the code that I’m interested in. And there, it’s not there.

[1:32:09] And I don’t see it coming with the LLM model. Furthermore, when fed with training data, it has to be trained with old code. My job, as I see it, is to make sure people write new things and use new techniques that are improvements over the old code. I find that LLM-based code is imitating old code and getting old performance and old bugs again. Maybe you can improve that. I hear rumors of Bjarne apps being written that fit my writings, but even that is problematic because I’m not saying exactly the same as I did 20 years ago.

[1:33:06] But anyway, we’ll see. Also, even Dijkstra was looking into the possibility, and he claimed that the idea of having natural languages as the programming language was idiotic. He’s less polite than I am. I think that a language like English is very flexible, and what we say is often very ambiguous. We need a programming language that’s precise, that’s engineering, that’s math; it’s not English.

Ryan:

[1:33:48] And for that code that is performance or safety critical, I imagine there will be some group of people using LLMs for that. Based on what you’re saying, the intuition is that you would foresee more breakages and bugs because it’s not valid.

Bjarne:

[1:34:10] People that are really good at that kind of stuff tend to not want to spend all their time validating. Another problem is that they want to eliminate junior programmers because there are lots of them. But if you do that, where do you get the senior programmers from? We’ll see. I mean, you can ask me the same question again in ten years, and there will be more knowledge. Undoubtedly, some of what I said will not be correct. And my guess is some of what I say will be correct in ten years. I’m always told by AI proponents that either the problem has already been solved or it’ll be solved in the next release. But I hear Anthropic 4.7 is having more problems than 4.6 for reasons I don’t understand. The idea that the next version will solve the problem is always a dangerous assumption. Furthermore, it’s getting more and more expensive.

[1:34:42] And my guess is some of what I say will be correct in 10 years. I’m always told by AI proponents that either the problem has already been solved or it’ll be solved in the next release. But I hear Anthropic 4.7 is having more problems than 4.6 for reasons I don’t understand. The idea that the next version will solve the problem is always a dangerous assumption. Furthermore, it’s getting more and more expensive.

[1:35:23] If you have to build a $100 million center and use and run the electricity for it, how many junior developers does it take to be cheaper? They’re starting to need money. It’s not unproblematic. And I’m in a subfield where it is probably more problematic than most.

1:35:54 — His motivation

Ryan:

[1:35:54] One thing I saw in a profile that you did is they asked you what keeps you going on C++ or what motivates you, and you said one is the fun of kind of building the future. The second thing was the obligation to make sure C++ moves forward. When you started C++, I can’t imagine you knew that you were embarking on a journey for decades.

Bjarne:

[1:36:21] And so not decades, but I knew it was a longer journey because I knew I couldn’t build the language I wanted. I could build a subset of it. There were two reasons for that. One was, well, I was the team that did it. Secondly, there was a lack of resources and a lack of time. I didn’t have the input needed to make sure that what I designed was right. So we have the engineering issue: build what you can, see what works, improve it.

[1:36:59] And so I knew I was getting into something like that. I knew I was building a language meant to evolve. And meant to evolve means that you make certain decisions in knowing that that is different. For instance, that’s one reason C++ wasn’t just an object-oriented programming language. Because I could see in the world that there were things that didn’t seem to fit that paradigm. And so I knew we would evolve.

[1:37:35] The other half of that answer to that question, what keeps me going is applications. It’s really nice to see interesting uses and such. I was at JPL and I talked to the people who are doing the Mars rovers. That’s cool stuff. I’ve been to CERN. I’m going to CERN this summer to see how you do high-energy physics. I don’t know anything about high-energy physics. Well, probably more than the average, but nowhere near being a physicist.

[1:38:10] And so you can go there and see they do interesting things, and there are things that surprise you. I was talking to a guy at CERN some years ago, and his job was to open and close doors. These doors weigh a couple of tons and are made of lead; they move across to close off an area to protect against radiation or something like that. I don’t know the details, but the point is he has to start up this door, which is not too hard. You have engines. But then you have to make sure you stop it. Because when you have a couple of tons this wide going into a wall, it will not stop. Normally, you have to write. And the code for that was interesting. I learned something. I still travel around and talk to people and see what C++ is being used for, what it can be used for, and what it can’t be used for. Just learning and learning is fun.

[1:38:45] You have engines, but then you have to make sure you stop it. Because when you have a couple of tons this wide going into a wall, it will not stop. Normally, you have to write. The code for that was interesting. I learned something. I still travel around and talk to people and see what C++ is being used for, what it can be used for, and what it can’t be used for. Just learning is fun.

1:39:18 — Famous quotes

Ryan:

[1:39:18] There’s a few quotes that you have which I thought would be interesting. If you could just give some context behind them. One of the quotes is, “C++ makes it easy to shoot yourself in the foot. C makes it harder, but when you do, it blows your whole leg off.”

Bjarne:

[1:39:38] Somebody asked a question at a talk I was given in Boston back in the 80s, and I shot that one back not thinking, but it’s a good quote and it’s correct. Arno Penzias got a Nobel Prize in Physics, so he’s not a nobody. I was trying to explain to a large group of Bell Labs managers about C++, and he said, “You can’t have a power tool without knowing how to use it.” So if you have a saw, you saw like this.

[1:40:22] If you have a power saw and you try to do that, it’ll bounce, and you will have to be very lucky not to get hurt. Notice it’s roughly the same story. What is behind that is if you get a power tool and you misuse it, you will encounter more problems. Get a car that accelerates faster, and it can wrap you around a tree in a way an old-fashioned, slow-accelerating car can’t. It’s fundamental to having power tools.

Ryan:

[1:41:03] You also have this other great quote: nobody should call themselves a professional if they only know one language. Obviously, you’d recommend people learn C++, but if they had to know a second or a third language for the sake of being a better engineer or programmer, what would you recommend?

Bjarne:

[1:41:22] Yeah, and if you’ve heard, if you’ve seen that interview, you’ll know I waffle on that deliberately. It is not so much which other languages you know, but that you get a set of ideas that are embedded in those languages. So what you should do is learn languages that are different from yours. I’m not too fuzzy about which languages they are. I think I said learn a scripting language today that would be Python or JavaScript.

[1:42:07] Then I guess it was Unix shell or something like that. Have a look at a functional language. ML or Haskell would be obvious solutions. Or just pick something different. The point is that you mustn’t get stuck with just what’s in your language. It’s not good for you to be monoglot. I mean, you know what you call somebody who knows three languages? Trilingual. Who knows two languages? Bilingual. One language? American is a very popular joke, at least outside America. And it’s the same idea with programming languages. But it’s more important with programming languages, I think, because you’re building things, and you should broaden your mind with ideas and techniques.

[1:42:43] American is a very popular joke, at least outside America. It’s the same idea with programming languages. But it’s more important with programming languages, I think, because you’re building things, and you shouldn’t. You should broaden your mind with ideas and techniques.

Ryan:

[1:43:08] Another quote is, “People who think they know everything really annoy those of us who know we don’t.” I was curious about the context behind that or your thoughts on it.

Bjarne:

[1:43:19] Well, that’s. I mean, that’s very simple. There’s so many people who think they’re simple solutions to just about everything in the world. In this context, they’ll come and tell me how much simpler C++ could be. And this is true. If you only want to do one thing, usually the one they have in mind, you can make a much simpler language. But this is like if we threw away this part of C++, it will be much simpler and nicer.

[1:43:57] Usually, they want to throw away things like C++, but then you annoy a few million people, and you don’t actually succeed because they’ll stick to the old stuff. So it’s a way of expressing my frustration with people who oversimplify. People think they can program without learning to program. They think they can be engineers without learning engineering. They think they can be politicians without knowing how to run a company or a country.

[1:44:36] Oversimplification annoys me, and I probably shouldn’t express annoyance. I very rarely do, but in this particular case, my frustration showed.

Ryan:

[1:44:50] Yeah, I saw somewhere in response to C++ being difficult for some people, that programming should be approachable and anyone can learn programming. I think you expressed the opinion that C++ is not necessarily for everyone; it’s for serious programmers.

Bjarne:

[1:45:11] Yeah, I mean, the first line of the C programming language, version one, first edition, was, “C is designed to make life more pleasant for the serious programmer.” I took away the first version, which was professional, because I saw amateurs, and it was really, really good. A serious programmer is probably programming for somebody else. If you program for yourself, it doesn’t matter; it’s you, and that’s your problem.

[1:45:56] If you do it for your friends, you can lose friends. If you build something for a million people, you can do harm in the world. And so that’s what it’s for. I mean, Guido van Rossum built Python with the explicit aim of allowing many people, or even everybody, to program. And he succeeded. I designed C++ to be a really good tool for serious programmers, engineers, mathematicians, and such. And I succeeded too.

[1:46:38] It’s just not the same problem. Remember where we started? I said the problem, look at the problem, and then learn from what worked and what doesn’t.

1:46:48 — Reflecting on building C++

Ryan:

[1:46:48] Looking back on C++ and the whole journey, is there any part where you think, “Oh, that was a mistake,” or something that you learned from in the design?

Bjarne:

[1:47:00] Many, many times I learned something. I think most of the things never made it into C++. That is, this is what you have experiments for, and that’s what you have initial uses for. I think I got the major part of the language right, and I think I could improve every single detail. But stability and compatibility are essential. If you make an insignificant change, it will annoy a few people, and it wouldn’t matter. If you make a significant change, you will annoy a lot of people, and it will not work because, say, a million people will stick to the old way. So I try to grow the language without breaking it. I have this thing that happens again and again. I explain it. People come up and say to me, “C++ is too complicated. You must simplify it.” And I need these two features. I need them yesterday. You must, when you’re doing this, give me these two features.

[1:47:48] If you make a significant change, you will annoy a lot of people, and it will not work because, say, a million people will stick to the old way. So I try to grow the language without breaking it. I have this thing that happens again and again. I explain it. People come up and say to me, C++ is too complicated. Yeah, you must simplify it. And I need these two features. I need them yesterday. You must, when you’re doing this, give me these two features.

[1:48:34] Yes. And whatever you do, don’t break my code. I have a million lines of it that doesn’t work. That’s impossible. And so that is why I’m working on coding guidelines and on profiles, which are enforced guidelines. That way, you can design a profile that ensures you can use the libraries that you need and ensures that you don’t misuse the features that are unnecessary and dangerous in your field.

1:49:12 — Top C++ book recommendation

Ryan:

[1:49:12] For anyone who wants to learn C++, what is the top technical book recommendation you have?

Bjarne:

[1:49:22] There’s a book I wrote when I was teaching undergrads. This is accidental; I didn’t mean it to be there. Anyway, this is the second edition of Programming Principles and Practice Using C++. This is a big fat book written for undergrads. The third edition is not as thick because the language has improved, and I can actually get the ideas across better with less text.

[1:49:59] But use the latest C++. Learn the modern way first. Don’t start learning all the bad ways of writing C as the starter. A lot of courses still say you learn C first, so you learn to misuse malloc and pointers. Then later, you can learn how to use a vector and a string and not have the problems. But yeah, profiles are there to enable compiler and static analyzer support for that kind of thinking.

[1:50:40] And educators are asking for something like that too. A lot of people think profiles are simply to deal with memory safety and performance. No, it has to give people a better tool both for learning and for doing specific kinds of work.

1:50:59 — Advice for his younger self

Ryan:

[1:50:59] And then the last question for you is, if you could go back to the beginning of your career and give yourself some advice, what would you say?

Bjarne:

[1:51:06] Oh dear. Yeah, that’s the time machine question. I sometimes set that for my students. You have a time machine. Go back and give Dennis some advice. And once you’ve done that, step 10 years forward and give me some advice. It’s a good exercise. I usually get some really good stories out of it. Some suggestions. I think a lot of—I tried to avoid the two-way conversions of the building types in C++. I should have fought harder for that.

[1:51:58] I tried but was stopped by the people in Bell Labs, and these were more experienced people than me. I should have gone further there. Furthermore, I should have delayed the release of C++ until I could have something template-like so I could do a better standard library. It wouldn’t have been good enough, but it would have gotten people into the habit of using a standard. Everybody was building standard libraries, and we got saved by Alex Stepanov with the STL.

[1:52:41] But that was real luck because I made a mistake in not delaying until I could have built a good vector and class hierarchy. And then finally, if I’d known what I know now about standards committees and bloated bureaucracies—and we have more subgroups now than we had members to start out with—I would have tried very hard to set up some kind of steering group so that people could make suggestions.

[1:53:27] But we wouldn’t have a vote with, say, 500 people. We would have suggestions from a community of 500 people, and we would have maybe a group of five or six people with vast experience who cared for the whole language and made the decisions based on what was proposed. Something like that. But I did not have the experience or the knowledge to make such a suggestion. Notice that I did not mention tools.

[1:54:03] C++ has a weakness in tools, and that was because it grew up early in a time with limited tools, limited compute power, and limited memory. One constraint on the exercise I give to the students for time machines is to try and make sure that it would be possible to follow your advice. If I just said I want this, then a lot of the things couldn’t be done until 20 years later and therefore would never have happened.

[1:54:49] There’s a lot of languages designed to be perfect for the future computers and the future programmers. Most of them die because by the time ten years later they get the language, the world has changed.

Ryan:

[1:55:07] On that first one, I imagine that would have been really tough to do because the Bell Labs people were so senior.

Bjarne:

[1:55:15] I failed. I tried, but it’s obvious that you don’t want narrowing conversions. I even wrote a paper about how to get rid of them last year in a library. But it is a fundamental flaw in the type system of C++. It came because they needed, being people like Dennis Ritchie and the Unix team, to handle both integers and floating point. They didn’t think of explicit type conversion and thought explicit type conversion was too clunky.

[1:55:59] They didn’t actually get casts until about five years after they got floating point integers. And of course, you have to be able to turn a floating point into an integer, right? So that you get implicit conversions whenever you can. Also, things like integers into characters are problematic. But since you are writing fundamental software, you didn’t want to write something complicated, and you didn’t want to have runtime checking.

[1:56:33] You couldn’t afford that. It was established long before I came, and my attempts to deal with that failed.

Ryan:

[1:56:47] It sounds like it wasn’t for no reason. It saves resources, maybe, or is very limited.

Bjarne:

[1:56:53] They didn’t have the resources to deal with it. They built lint, the static checker, to deal with some of it and small machines. Another thing was that that group of programmers was significantly smarter and significantly more experienced than the average developer. Today we have the law of large numbers. I think the latest estimate I’ve seen on the number of software developers in the world is 47 million.

[1:57:28] And at that time with Unix, the number of programmers was probably a few dozen. The ones that didn’t have a PhD from a good university were geniuses. It’s easier to get a PhD than to be a genius. They offered a different set of problems with a different set of machines and a different set of people. Boy, it was a pain and still is.

Ryan:

[1:58:02] Awesome. Well, thank you so much for your time, Bjarne Stroustrup. I really appreciate it.

Bjarne:

[1:58:05] Okay, thank you.

Also, since he’s on the ground floor of CS education I wanted to know how AI was impacting students outside of the rumors I see on social media.

Below are my top three takeaways to save you time.

You can find the full conversation on YouTube, Spotify, or Apple Podcasts. The transcript is on Substack if you prefer to skim.

Brought to you by:

Cursor3: a unified workspace for building software with agents. I used it to build tools for the podcast and shared the process in this episode’s ad read.

WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code

Takeaways from the conversation:

1) How he lectures well - I was most curious about this since most professors don’t teach in a way that gets students excited like David does. He attributes his success to two main factors.

First, he makes sure to design a “memorable moment” in each lecture. This is usually some fun, visual exercise that gives students a unique moment to anchor their memory to. His classic example is ripping a phone book in half to demonstrate binary search. People often say to him years later that they still remember those moments and the concept he was teaching.

Second, he brings as much energy as possible often motivated by insecurity. He said that one of his worst fears is being in front of a bored audience. He also feels he owes it to the students to represent the subject in a way that makes them want to learn.

2) AI’s downstream impact on enrollments and cheating - Less students are enrolling in computer science. Part of it is fear, but a stronger motive is that companies just don’t come to hire from Harvard like they used to. David said they just don’t seem to be hiring as many junior engineers as before.

The more interesting part to me though was how AI is impacting cheating. He said although cheating has stayed consistent at 5-10% of the student body each semester, what has changed is how hard it is to prosecute cheaters. When people cheat now using AI, they get answers that are difficult to attribute to a source. That makes it harder to hand a smoking gun to the adminstrative board.

3) Why learn C in 2026 and the most challenging concept to learn - C is such an old language at this point so some people critique why you’d need to learn that today. His argument was that C is low-level so you can learn how the computer works without being too low-level like assembly code.

Also, since it is such a small language it forces students to reimplement basic data structures which is a great learning exercise.

He taught so many years of the same introductory courses so I asked him what concept gave people the most trouble. He answered immediately that it was pointers. If you understand pointers well you should feel proud!

We talked about a bunch of other topics too but these are the three I figured would be most interesting.

As I experiment with ad reads, two things I’m sure of are:

1. Only place an ad after value is delivered, say ~30 minutes of content before an ad is shown

2. Keep ads brief, ideally <1min

One thing I’m not sure of though is if people prefer ads to be placed all clumped together or spaced out. People who listen to podcasts, please vote below so I can get a sense of what you prefer:

As always, thanks for reading!
Ryan Peterman

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

Timestamps

1:09 - Getting into computer science

3:27 - Becoming the professor of CS50

11:19 - How to lecture well

14:25 - Depth vs engagement in education

18:11 - Why don’t we consolidate educational resources

23:20 - Why start with C

31:51 - The ideal use of AI in education

34:54 - Cheating and AI

38:21 - Should we really learn CS still?

45:24 - College vs online education

47:06 - The most difficult concept to learn

51:00 - Growth vs fixed mindset

52:35 - The future of CS50

55:56 - Biggest career regret

1:00:29 - Top book recommendations

1:02:36 - Advice for his younger self

Transcript

1:09 — Getting into computer science

David:

[1:09] Yeah, it’s a really good question. So I was that problem set. My first hello World program was in September of 1996 when I first stepped foot in a class called CS50. I was a sophomore at the time and hadn’t honestly gotten up the nerve until sophomore year to even consider taking the class. Like when I came into college first year. And this is a story I tell at the very start of CS50. Most years I really gravitated toward fields that were more familiar, more comfortable for me and I share with students that I really liked Constitutional law, like that was my favorite class in high school.

[1:41] And I figured that meant when you get to college I should probably major or concentrate as we say at Harvard, in government. And so for the first year, year and a half, I was heads down focused on studying government. But when I finally got up the nerve to follow some friends, I think into the CS50 classroom that day when this very well reputed computer scientist Brian Kernahan was at the helm for just that one year, I was totally hooked.

[2:05] And it was the first time in like 19 years that homework was fun. So much so that when the week’s problem sets or assignments would come out, I would look forward to going back to my dorm on Friday evenings to work through the night on my CS50 problem sets. So I felt like that was a sign that I’m supposed to study computer science.

Ryan:

[2:22] And I, I saw on that assignment it says minus two and this little there’s a little note there that I actually couldn’t quite quite make out. Looking back now as the teacher, why did you get a minus two there?

David:

[2:35] It was something stupid and very easily redressible. But I did not start off computer science or CS50 on the best foot. I got -2 out of probably 2 points on hello World.

Ryan:

[2:46] I transcribed it and I tried to compile your program and it didn’t compile interest.

David:

[2:52] Okay, so thanks, 30 years later I learn it should’ve been minus 3.

Ryan:

[2:55] Actually I was able to compile. It’s kind of interesting, but you have to kind of force the compiler to do your bidding. It’s like void main and you’re supposed to be like int main typically.

David:

[3:09] Typically. Now it has since been standardized in C99, which was in my defense a version of C that did not exist in 1996. And nowadays we use C11 or newer in CS50, so you probably had default compiler settings on that did not like that old fashioned main signature. In my defense, that part was correct.

3:27 — Becoming the professor of CS50

Ryan:

[3:27] In 1996, what was the the story behind you going from a student to the teacher?

David:

[3:34] Eventually I had an opportunity my senior year of college to teach an introductory course in computer science at Harvard’s Extension School, which is the continuing ed program largely for adults. The course was literally called Introduction to Computers and the Internet, because in 1999 we were still in the habit of introducing people to computers and the Internet as opposed to taking it for granted more so nowadays.

[3:54] And it was me. In a room full of hundred or so adults, I was easily the youngest person in the room at like 21 years old. The story I usually share is that that was the first and last time I wore suspenders because I was so determined to project being older even though I was still just a senior. But that really whet my appetite in turn not only for more computer science, even though that was very introductory and more technology focused for teaching.

[4:19] And over time I real over the next few years I realized that doors would be closed to me if I wanted to teach at a place like Harvard College. And I eventually returned to Harvard to do my PhD for five years in computer science. And then in 2007 when I was finishing up, the former professor, my own advisor, was moving on to be dean of the school. And so there was this vacancy at the helm of CS50 and I somehow talked my way into the job.

[4:43] They were interested in having a senior faculty member take over the course. I guess they weren’t able to find someone that first year, so I was meant to fill in for just one year until they found someone else.

Ryan:

[4:57] when you took over CS50. It feels like the course completely changed when you got into it. Was your first thought, I want to take this online and kind of make all these major changes, or was that a process over time?

David:

[5:14] Very much a process. And so what people see now is really a evolution of the class, as opposed to some overnight revolution, so to speak. The online aspect really started with Harvard Extension School, since I was fortunate right place, right time to be teaching that extension school course my senior year, when distance education, so to speak, was becoming a thing. And my mentor and boss, Henry Leitner at Harvard, offered me the opportunity not only to teach this class, but also to put it online, I think in the year 2000, give or take.

[5:43] The very first year I taught it, spring of 1999, we were still filming the class, but on VHS. And fun fact, at the time, it was the course’s teaching fellows who were, in fact, my friends, who were also undergraduates at the time, who, who were doing the filming and operating a tripod with a camera. And I swear to God, we still have footage, probably on some VHS tape of one of the cameras going when one of my dear friends and teaching fellows fell asleep during the middle of class.

[6:08] So we’ve aspired to higher production value since, but it was really, it happened very organically. So once we started participating in the extension school’s online education program for several years, Apple released the iPod around 2003 or 4, give or take. And so at the time, we were distributing the course’s video via real video and or real audio, which are older technologies now, but were state of the art for streaming at the time.

[6:35] We figured out a way how to sort of download all of those bits for redistribution as MP3s initially and put them on itunes, which back in the day you could upload, and maybe still today, your own RSS file, which is a flavor of xml, which is kind of similar to HTML, but more custom, that just describes what and where your audio files are. And we made this available primarily for our own Harvard Extension School students, because at the time, even though it was very progressive to have streaming, it was a little annoying that you needed a constant Internet connection.

[7:03] Buffering hadn’t really been invented yet. Certainly downloading those videos was, by design not possible. But with podcasting, of course, you could download the assets in advance. And for our own students, the vision was that they could listen to the class only on audio at the gym or during their commute and just generally make the educational Content a little more accessible. A year or two later, Apple released the video ipod.

[7:24] And so we very much steered into that and downloaded those same assets, but in video form, to make them available on the video ipod and people’s Macs and later PCs. And we were fortunate around that time, early 2000s, where Wired magazine took notice and noted for us that we were among the most popular podcasts in some category. And it was kind of news to us that people cared. We did know that we were starting to see bandwidth problems at the very early days.

[7:50] In the very early days, we were using Dreamhost to host the MP3 files. And Dreamhost had, I think, free accounts, but only up to some number of megabytes per month. And we kept hitting the threshold. And so what we would do is sign up for another DreamHost account, another DreamHost account, another Dreamhost account. And we would use, like, DNS trickery to just reroute the URLs in the RSS file to the new web host to keep up.

[8:14] And so that’s when all of our attention sort of was drawn to the possibilities and that we can make available this content not just for our own students, but for anyone else who either geographically, socioeconomically, couldn’t access that same kind of class.

Ryan:

[8:29] I see. So the idea was it was a supplementary material for people who had paid for the Harvard Extension School and then. But other people just open on the Internet could listen if they wanted.

David:

[8:41] Yeah. And that alone was a touchy subject on campus at first, because here we were giving away the very thing that other people were paying for. But at the end of the day, what people are paying for is the additional support structure you get in a more traditional environment, the more traditional credentialing, the transcript and the credit and so forth. But the knowledge itself, it does society no good to withhold that.

Ryan:

[9:01] I think so. I think this is a brutal reality of making content on the Internet. There’s so much competition for attention that all the content has to kind of hook people. Let’s say you’re scrolling on. On Instagram. That first second’s really got to capture someone, otherwise you’re going to go to the next one. And I’m curious, because you are making content for the Internet with these lectures that you post online.

[9:27] Do you think about, how can I, you know, hook the audience? Does that ever factor into your. Your lecture design lectures?

David:

[9:35] No. Some of our social content, yes. Insofar as we are producing, in addition to the courses traditional in classroom content, things that are designed clearly for social media, whether it’s interviews, for instance, whether it is excerpts from CS50‘s Fair, this exhibition of final projects, whether it’s steering in the directions of some popular meme just to sort of catch the attention of our own students or new students.

[9:58] But we have been very deliberate over the years from the beginning and especially since the age of the MOOC in 2012 when Coursera and EDX and other platforms were coming around to not steer into this bite sized 3 minutes, 5 minute chunks that I know there is data to confirm that it drives engagement but not necessarily educational outcomes. We have fairly unusually in recent years stuck to the more traditional model of like CS50.

[10:27] Lectures are like three hours long. And there are downsides to that. Absolutely. But ironically, online you avoid some of the in person downsides because you can pause and rewind and fast forward, you can search for something, open another tab, go down this intellectual rabbit hole or rewind to figure out what it some detail you missed. I mean I, I can’t even count how many times in college, high school, more generally that I’m sure I zoned out.

[10:51] And it’s too often the case that if you miss some detail you’re now you might as well leave the class at that point. And like online solves that for you. And I haven’t seen a need pedagogically for us to break up the content into such small pieces and to sort of take that ownership away from the students. I think we’d prefer that they meet us halfway. And if you need to take more than three hours to watch the lecture, that’s totally fine.

[11:15] But it’s not designed for scrolling type consumption I would say.

11:19 — How to lecture well

Ryan:

[11:19] Right. What about in the, in the idea of like a long video, there’s still this concept that you kind of want to keep people engaged. And so how do you keep people engaged for a three hour lecture?

David:

[11:30] Yes. So that we are very conscious of and the way we’ve generally described that is trying to create memorable moments. And this is not for social media. This is as much for the in person audience as it is for the online audience. And by memorable moments I mean in like CS50‘s first lecture we do this bit where I’ll tear a phone book in half to demonstrate the performance of something called binary search and algorithm for finding information more quickly than linearly searching the phone book one page at a time.

[11:55] And that’s really just to be dramatic. It has less and less impact these days because most students of school age are no longer familiar with the Technology known as a phone book. But it’s literally analogous to the digital form in iOS or in Android, of course. And so it doesn’t take a huge leap for someone to realize, okay, this is the physical incarnation of that, and it’s just kind of fun, even though it’s getting harder and harder to find the actual phone books.

[12:19] When we get to searching algorithms and sorting algorithms, we very often have a student come up on stage, for instance, and for sorting or for searching, we have a whole bunch of like gym lockers, small versions thereof, that we put numbers in, either on printed paper or little plastic numbers. And the goal is to have a student like, find the number 50 or some other number that we’ve hidden behind the doors.

[12:38] And it’s an opportunity just to talk about either searching the doors linearly, left to right, right to left, maybe randomly, maybe more methodically as via binary search. If the numbers are sorted, that then leads us to opportunities to talk about bubble sort and selection, sort and insertion sorts. Algorithms that you probably wouldn’t bother implementing or using in the wild because there’s more performant ones certainly.

[12:59] But we use them as these pedagogical tools to explore the. The problem to be solved, which is, all right, I can only use binary search if the data is sorted, so how do I sort it? And how expensive is that going to be worthwhile, the whole process in the get go? And so we’ll have eight students come up on stage and sort themselves physically and really perform in certain ways. And there’s so many examples of that through CS50, we try to do at least one such thing every class.

[13:25] I mean, not unlike the way John Oliver, for instance, ends last week. Tonight we’re trying to do some big song and dance, which ironically is always at the end as the hook. We do try to put it maybe toward the beginning of lecture or in the middle, but that’s not just for engagement and not to make, to keep folks attention, but really to latch onto their memories so that even if you’re in the weeds of this introductory computer science course, there’s so much new information, it’s the proverbial fire hose hitting you in the face you can cling to.

[13:52] Okay, all right. I remember like my. My roommate was literally the one on stage acting out bubble sort. And you can kind of picture in your mind’s eye what was happening. Or that phone book example is a perfect one that years after leaving Harvard, we have alumni coming up to us and saying, oh, I still REM the phone book demo. And those memorable Moments, ideally theatrical in nature, I think are what brings material, whether it’s CS or something else, to life.

[14:16] But that is very much to engage any learner, present or remote, as opposed to being optimized for some technology.

14:25 — Depth vs engagement in education

Ryan:

[14:25] One thing that I, I wonder because computer science is such a dense topic where I guess there could be a trade off with, imagine another style of lecture is, you know, there’s a chalkboard and you’re up there kind of blandly writing out all of the information. I, I could imagine you could go through much more depth in that case. Do you feel like there’s any trade off there?

David:

[14:52] Absolutely. I mean, this is a criticism we get from some students, particularly those with prior background or among those more comfortable where do we really need 10 minutes on linear search or you know, another 15 minutes on binary search? And the answer is quite clearly no for those students. And even for most students, I would say we do spend a disproportionate amount of time on certain cherry picked topics that we do think lend themselves to this theatricality for really getting students interested in fundamentally and excited by the material to help motivate them the rest of the week when they’re going to be spending 5, 10, 15, 20 plus hours on some weeks assignment and to help them see sort of the forest for the trees, like what is actually important and meaningful and fun about this.

[15:34] Because it’s probably not the keystrokes and the debugging and the lower level implementation details. So we talk about this actually in a paper, in a talk we gave at a CS education conference a few years back, trying to find that balance between the theatricality and the density of material. But to your question about dryness, I mean, I would like to think that dryness really has no place in most forms of education because then it could have been a book or it could have been an email if it’s just someone reciting words, worse, writing things down in ways that aren’t at all interactive, like do we really need to be all in this room together?

Ryan:

[16:13] design to me in my research. And looking at the reception of CS50 and people’s perspective on how you are as an educator, they absolutely love your energy and like your delivery. Do you rehearse that or is that something that you always had as an educator?

David:

[16:31] Yeah, I think it’s just sort of the expression you got to bring your A game when you get up onto stage. And I think a lot of it honestly comes from a place of insecurity. Like I really don’t want to be the one on stage in front of a bored audience, like no one wants to be in that situation. And so I think a lot of the energy that I try to bring to bear and the excitement I show is really meant to one, make sure people want to be and stay there for the duration of the class, whether it’s short or long.

[16:56] And also help them see the excitement in and the possibilities of, and the applicability of a field that I myself have fell in love with so many years ago. Because then they can decide for themselves if they feel that same emotion, if they too look forward to going home to their dorm or their home on Friday nights and working on programming assignments, of all things. But I feel like we certainly owe them, and I think teachers owe students more generally educationally, the opportunity to make that decision for themselves and to put forward our best foot, or to present the field in the most exciting, inspiring way that we can, if indeed we think it’s important that other people after us study and research and apply these fields.

Ryan:

[17:40] I noticed this dichotomy in education when I was going to ucla, which was there were roughly two types of professors that I had. There was one type of professor that was beloved by the students and really passionate at educating and kind of involved. And then there’s this other type of professor which was really they might have been really incredible and impressive as researchers, but their classes were really poorly rated by all the students.

18:11 — Why don’t we consolidate educational resources

[18:11] And with the online education that we can do today, I mean, like CS50, all the resources are available. I could imagine that objectively we could take the people who are most passionate about teaching and give it to everyone, rather than having some teachers that are not excited kind of consolidate. Imagine taking the world’s best instructor and giving that to everyone. Why doesn’t consolidation happen if we have all the technology for spreading literally the world’s best resources to every situation?

David:

[18:41] Yeah, that’s a good question, since I think our own goal is certainly not to put out of business other educators, other classes. However, as a computer scientist, I would be among the first to notice that there’s a huge inefficiency in the way education broadly works, not only in this country, but presumably internationally as well, whereby you have hundreds, thousands of teachers essentially all doing the same thing in parallel, and not necessarily the meaningful part of interacting with and uplifting and mentoring students, but like preparing their presentations or their lecture notes, or writing the assignments, or grading that work.

[19:17] There’s so much meta work involved in education that probably doesn’t need to be borne by so many people that the computer scientist in me invariably wants to factor that out somehow. And so I absolutely think that we, educationally, as universities, as schools, should be leaning on each other much more. I’d like to think that’s a lot of what drives us in terms of CS50‘s own mission and the work that we do.

[19:39] But we too have encountered frictions along the way. It was very unusual, for instance, for 10 years that we were collaborating with our friends down the road in New Haven at Yale University where we were offering CS50 on both campuses in parallel. And more recently we’ve been doing this with some of our friends at Oxford and lifelong learning group there. This is very much still the exception to the rule.

[19:59] Unfortunately, even after 10 plus years of MOOCs massive open online courses, I dare say a lot of institutions, a lot of faculty are very set in their ways. In fact, one of my regrets of the COVID era was that we had this unprecedented opportunity now and almost mandate to move everything online. And we therefore had this opportunity to say, hey to Harvard students, why don’t you take this Stanford course or this UCLA course or this Yale course, or this MIT course that you couldn’t necessarily take in person for lack of transport or for lack of safety at the time.

[20:32] And I could get no one on campus to, to get on board with this idea of maybe offering one computer science course on this campus and let the other students take it. Then you offer, as we did at Yale, like a digital humanities class on some other campus and let the Harvard students take it. And there’s just not much of an appetite, I dare say, in higher education, if not education writ large for that resource sharing.

[20:54] And I think there should be, I don’t think there should be one computer science course, introductory course. I think some healthy competition is a good thing. I don’t think there need to be thousands, probably not hundreds, maybe dozens, from some of the best teachers. The best schools would probably benefit us all if those same teachers then were not put out of work, but then could lean on each other, use some of the materials we’ve created, adopt or as we say, adapt some of our own resources and treat education as a buffet of educational materials that you can then make your own without having to do so much of the same legwork and reinventing wheels across school and state lines.

Ryan:

[21:32] The mindset that you said, the computer scientist mindset of getting rid of the redundancies and kind of consolidating resources, I mean, it’s immediately logically obvious to me. But what would like, let’s say there’s three top courses in America. There’s like MIT‘s, there’s Stanfords and there’s Harvards and they want to give that to other institutions, like, I don’t know, other colleges. What would stop those colleges from taking an objectively better set of resources and giving that to their students?