Guido van Rossum: Python and the Future of Programming | Lex Fridman Podcast #341

1. 0:00 – 0:48

   Introduction

   1. LFLex Fridman0:00

      Can you imagine possible features that Python 4.0 might have that would necessitate the creation of the new 4.0, given the amount of pain and joy, suffering and triumph-

   2. GRGuido van Rossum0:19

      Mm-hmm.

   3. LFLex Fridman0:19

      ... that was involved in the move between version two and version three? The following is a conversation with Guido van Rossum, his second time on this podcast. He is the creator of the Python programming language and is Python's emeritus BDFL, benevolent dictator for life. This is the Lex Fridman podcast. To support it, please check out our sponsors in the description and now, dear friends, here's Guido van Rossum.

2. 0:48 – 6:01

   CPython

   1. LFLex Fridman0:48

      Python 3.11 is coming out very soon, in it, CPython claimed to be 10 to 60% faster. How'd you pull that off? And what's CPython?

   2. GRGuido van Rossum1:00

      CPython is the last Python implementation standing, also the first one that was ever created. The original Python implementation that I started over 30 years ago.

   3. LFLex Fridman1:10

      So what does it mean that Python, the programming language, is implemented in another programming language called C?

   4. GRGuido van Rossum1:17

      What kind of audience do you have in mind here?

   5. LFLex Fridman1:19

      Uh...

   6. GRGuido van Rossum1:19

      People who know programming or-

   7. LFLex Fridman1:21

      No. There's somebody on a boat that's into fishing and they've never heard about programming but also some world-class programmers. You're gonna have to speak to both. Imagine a boat with two people, one of them has not heard about programming and is really into fishing and the other one is like a- an incredible Silicon Valley programmer that's programmed in everything, C, C++, Python, Rust, Java, and knows the entire history of programming languages so you're gonna have to speak to both.

   8. GRGuido van Rossum1:49

      I imagine that boat in the middle of the ocean-

   9. LFLex Fridman1:51

      Yes.

   10. GRGuido van Rossum1:51

       ... I'm- I'm gonna please the guy who knows how to fish first (laughs) .

   11. LFLex Fridman1:55

       Yes, please (laughs) . He seems like the most useful in the middle of the ocean, you got- (laughs) you gotta make him happy.

   12. GRGuido van Rossum2:01

       I'm sure he has a cellphone so, uh-

   13. LFLex Fridman2:04

       (laughs)

   14. GRGuido van Rossum2:04

       ... he's probably very suspicious about what goes on in that cellphone but he must have heard that inside a cellphone is a tiny computer. And a programming language is computer code that tells the computer what to do.

   15. LFLex Fridman2:17

       It's a very low level language, it's zeros and ones and then there's assembly and then-

   16. GRGuido van Rossum2:24

       Oh, yeah. But we- we don't talk about these really low levels because those just confuse people. I mean, when we're talking about human language, we're not usually talking about vocal tracts and how you position your tongue. I was talking yesterday about how when you have a Chinese person and they speak English, uh, there's- there's a bit of a stereotype, they often don't know... Or they- they can't- can't seem to make the difference well between an L and an R.

   17. LFLex Fridman2:53

       Mm-hmm.

   18. GRGuido van Rossum2:54

       And I have a theory about that and I've never checked this with linguists, uh, that it probably has to do with the fact that in Chinese there is not really a difference and it could be that there are regional variations in how Chi- native Chinese speakers pronounce that one sound that sounds to L to some... Like L to some of them, like R to others.

   19. LFLex Fridman3:19

       So it's both the sounds you produce with your mouth throughout the history of your life and what you're used to listening to. I mean, every language has that. Russian has-

   20. GRGuido van Rossum3:29

       Exactly.

   21. LFLex Fridman3:29

       ... the Slavic languages have sounds like J, the letter J, like, uh, Americans or English speakers don't seem to know the sound J. J, they seem uncomfortable with that sound (laughs) .

   22. GRGuido van Rossum3:43

       Yeah. So I'm-

   23. LFLex Fridman3:45

       Oh yes, okay, so we're not- we're not going to the shapes of tongues and the sounds that the mouth can make, fine. Words-

   24. GRGuido van Rossum3:51

       And similarly we're not going into the ones and zeros or machine language. I would say a programming language is a list of instructions like a cookbook recipe that sort of tells you how to do a certain thing, like make a sandwich, well, acquire a loaf of bread, cut it in slices, uh, take two slices, uh, put mustard on one, put, uh, jelly on the other or something, then add the meat, then add the cheese.

   25. LFLex Fridman4:22

       Mm-hmm.

   26. GRGuido van Rossum4:23

       Uh, I've heard that science teachers can actually, uh, do great stuff with recipes like that and trying to interpret their students' instructions incorrectly until the students are completely unambiguous about it.

   27. LFLex Fridman4:37

       With language, see that's the difference between natural languages and programming languages, I think ambiguity is a feature, not a bug in human spoken languages. Like, uh, that's the dance of communication between humans.

   28. GRGuido van Rossum4:54

       Well, for lawyers, ambiguity certainly is a- a feature. Uh, for plenty of other cases, uh, the ambiguity is- is not much of a feature but we work around it, of course.

   29. LFLex Fridman5:08

       Well, hold on-

   30. GRGuido van Rossum5:08

       What's more important is context.
3. 6:01 – 10:22

   Code readability

   1. LFLex Fridman6:01

      You go through in PEP 8, the style guide for Python code, some ideas of what this language should look like.... feel like, read like. And the big idea there is that, uh, code readability counts. What does that mean to you and how do we achieve it? So this recipe should be readable.

   2. GRGuido van Rossum6:19

      Oh, that's, that's a thing between programmers because, uh, on the one hand we always explain the concept of programming language as computers need instructions and computers are very dumb and they need very precise instructions because they don't have much context. In, in, in fact, they have lots of context but they're, their context is very different. But what we've seen emerge during the development of software starting in the, probably in the late '40s is that software is a very social activity. A software developer is not a mad scientist who sits alone in his lab writing brilliant code. Uh, a so- software is developed by teams of people. Uh, even the mad scientist sitting alone in his lab can't type fast enough to produce enough code so that by the time he's done with his coding he still remembers what the first few lines he wrote mean.

   3. LFLex Fridman7:21

      Mm-hmm.

   4. GRGuido van Rossum7:22

      So even the mad scientist coding alone in his lab would, would be sort of wise to adopt conventions on how to format the instructions that he gives to the computer so that... The thing is, there is a difference between a cookbook recipe and a computer program. The cookbook recipe, the, the author of the cookbook writes it once and then it's printed in 100,000 copies and then lots of people in their kitchens try to recreate that recipe, that, that, that particular pie or dish from the recipe. And so there, the, the goal of the cookbook author is to make it clear to the human reader of the recipe, the human amateur chef in most cases. When you're writing a computer program, you have two audiences at once. It needs to tell the computer what to do, but it also is useful if that program is readable by other programmers because computer software, unlike the typical recipe for a cherry pie, is so complex that you don't get all of it right at once. You end up with the activity of debugging and you end up with the activity of... So debugging is trying to figure out why your code doesn't run the way you thought it should run.

   5. LFLex Fridman9:06

      That means broadly. It could be stupid little errors or it could be big logical errors.

   6. GRGuido van Rossum9:11

      It could be anything from-

   7. LFLex Fridman9:13

      Spiritual.

   8. GRGuido van Rossum9:14

      Yeah, fra- it could be anything from a typo to, uh, a wrong choice of algorithm to building something that does what you tell it to do but that's not useful.

   9. LFLex Fridman9:26

      Yeah. It seems to work really well 99% of the time but does weird things 1% of the time on some edge cases.

   10. GRGuido van Rossum9:35

       That's pretty much all software nowadays.

   11. LFLex Fridman9:37

       All good software, right?

   12. GRGuido van Rossum9:39

       Well, yeah, for, for bad software then... (laughs)

   13. LFLex Fridman9:42

       (laughs) That 99 goes down a lot. So but, it's not just about the complexity of the program. It's, like you said, it, it is a social endeavor in that you're constantly improving that recipe for the cherry pie.

   14. GRGuido van Rossum9:55

       But you're sort of, you're in a group of people improving that recipe. Or the mad scientist is improving the recipe that he created a year ago and making it better. Or adding, adding something. He decides that he wants a, I don't know, he wants some decoration on his pie or icing or...

   15. LFLex Fridman10:18

       So there's broad philosophical things and there's specific advice on style.

4. 10:22 – 26:58

   Indentation

   1. LFLex Fridman10:22

      So first of all the thing that people first experience when they look up Python, there is a, it is very readable but there's also a, like a spatial structure to it. Can you explain the indentation style of Python and what is the magic to it?

   2. GRGuido van Rossum10:39

      Spaces are important for readability of any kind of text. If you take a cookbook recipe and you remove all the sort of, all the bullets and other markup and you just crunch all the text together, maybe you leave the spaces between the words but that's all you leave, when you're in a kitchen trying to figure out, oh, what are the ingredients and what are the steps and where does this step end and the next step begin, you're gonna have a hard time if it's, if it's just one solid block of text.

   3. LFLex Fridman11:16

      Mm-hmm.

   4. GRGuido van Rossum11:17

      On the other hand, what, what a typical cookbook does if the paper is not too expensive, each recipe starts on its own page. Maybe there's a picture next to it. The list of ingredients comes first. Uh, there's a standard notation. Uh, there's, there's shortcuts so that you don't have to sort of write two sentences on how you have to cut the onion because there are only three ways that people ever cut onions in a kitchen, small, medium and in slices or something like that. (laughs)

   5. LFLex Fridman11:51

      Right.

   6. GRGuido van Rossum11:52

      None of my examples make any sense to real cooks, of course, but...

   7. LFLex Fridman11:55

      Yeah. (laughs) We're talking to programmers with the metaphor of cooking. I love it. Um, but there is a strictness to the spacing that Python defines, so there's some looser things, some stricter things, but the four spaces for the-... a, for the indentation is really interesting. It, it really, um, it really defines what the language looks and feels like.

   8. GRGuido van Rossum12:19

      Because indentation sort of taking a block of text and then having inside that block of text a smaller block of text that is indented further as sort of a, a group. It's, it's, it's like you have an- a bulleted list in a complex business document and inside some of the bullets are other bulleted lists. You will indent those too.

   9. LFLex Fridman12:45

      Mm-hmm.

   10. GRGuido van Rossum12:46

       If each bulleted list is indented several inches, then at two levels deep there's no s- no space left on the page to put any of the words of the text.

   11. LFLex Fridman12:56

       Sure.

   12. GRGuido van Rossum12:56

       So you can't indent too far. On the other hand, if you don't indent at all, uh, you can't tell whether something is a top level bullet or a second level bullet or a third level bullet. So you have to have some compromise. And, uh, based on ancient conventions and the sort of the typical width of a computer screen in the '80s, uh, and all sorts of things, sort of... We, we came up with sort of four spaces as a compromise. I mean, there, there are groups, there are lar- large groups of people who code with, uh, two spaces per indent level. Uh, for example, the Google style guide, uh, all the Google Python code, and I think also all the Google C++ code is indented with only two spaces per block. If you're not used to that, it's harder to, at a glance, understand the code because the, the sort of the, the high level structure is determined by the indentation. On the other hand, there, there are other programming languages where the indentation is, uh, eight spaces or a whole tab stop, in, in sort of classic Unix. And to me that looks weird because you, you sort of after three indent levels, you've, you've got no room left.

   13. LFLex Fridman14:18

       Well, there's some languages where the indentation is a recommendation. It's, it's a stylistic one. The code compiles even without any indentation. And then Python really, indentation is a fundamental part of the language, right?

   14. GRGuido van Rossum14:33

       It doesn't have to be four spaces. So you, you can code Python with two spaces per block or, or six spaces or 12 if you really want to go wild. But sort of everything that belongs to the same block needs to be indented the same way. In practice, in most other languages, people recommend doing that anyway. If you look at C or Rust or C++, all those languages, Java, don't have a requirement of indentation. But except in extreme cases, they're just as anal about having their code properly indented.

   15. LFLex Fridman15:17

       So any IDE that does syntax highlighting that works with Java or C++, they will yell at you aggressively if you don't do proper indentation?

   16. GRGuido van Rossum15:28

       They suggest the proper indentation for you. Like, uh, in C, you type a few words and then you type a curly brace, which there is their notion of sort of begin an, an indented block.

   17. LFLex Fridman15:43

       Yeah.

   18. GRGuido van Rossum15:44

       Uh, then you hit return and then it automatically indents four or eight spaces depending on, uh, your s- your style preferences or how your editor is configured.

   19. LFLex Fridman15:53

       Was there a possible universe in which you considered having braces in Python?

   20. GRGuido van Rossum15:59

       Absolutely. Yeah.

   21. LFLex Fridman16:00

       What was it, 60/40? 70/30? In your head, uh-

   22. GRGuido van Rossum16:05

       Uh-

   23. LFLex Fridman16:06

       ... what was, what was the trade-off?

   24. GRGuido van Rossum16:07

       For a long time, I was actually convinced that the indentation was just better. Uh, without context, I would still claim that indentation is better. Uh, it reduces clutter. However, as I started to say earlier, context is almost everything. And in the context of coding, most programmers are familiar with multiple languages even if they're only good at one or two.

   25. LFLex Fridman16:41

       Mm-hmm.

   26. GRGuido van Rossum16:42

       And apart from Python and maybe Fortran, I don't know how that's written these days anymore. But all the other languages, Java, Rust, C/C++, JavaScript, Typescript, Perl, are all using curly braces, uh, to sort of indicate blocks. And so Python is the odd one out.

   27. LFLex Fridman17:04

       So it's a radical idea. Do you still, a- as a radical renegade revolutionary, do you still stand behind this idea of space, of, uh, indentation versus braces? Like what, what... Can you dig into it a little bit more why you still stand behind indentation?

   28. GRGuido van Rossum17:22

       Because context is not the whole story. History i- in, in a sense provides more context. So for Python, there's no chance that we can switch. Python is using curly braces for something else, dictionaries mostly.

   29. LFLex Fridman17:41

       Mm-hmm.

   30. GRGuido van Rossum17:42

       We would get in trouble if we wanted to switch. Just like you couldn't redefine C to use indentitation even if you agree that it, that indentation sort of in a greenfield environment would be better. You can't change that kind of thing in a language.
5. 26:58 – 38:26

   Bugs

   1. GRGuido van Rossum26:58

      I mean, if you- if you look at the number of bugs per line of code, even in- in very well-tested code that in practice works just fine-

   2. LFLex Fridman27:10

      Mm-hmm.

   3. GRGuido van Rossum27:11

      ... there are actually lots of things that don't work fine, and there are error-correcting or self-correcting mechanisms at many levels.

   4. LFLex Fridman27:22

      Including probably the user of the code? (laughs)

   5. GRGuido van Rossum27:25

      Well, in the end, the user who sort of is told, "Well, you gotta reboot your, your PC-"

   6. LFLex Fridman27:31

      Yeah.

   7. GRGuido van Rossum27:31

      ... is part of that system.

   8. LFLex Fridman27:33

      Yeah.

   9. GRGuido van Rossum27:33

      And a slightly, uh, less drastic thing is reload the page, which we all know how to do-

   10. LFLex Fridman27:41

       Yeah.

   11. GRGuido van Rossum27:42

       ... without thinking about it when something weird happens. You- you try to reload a few times before you say, "Oh, there's something really weird."

   12. LFLex Fridman27:50

       Okay. Or try to click the button again if the first time didn't work. (laughs)

   13. GRGuido van Rossum27:53

       (laughs) Well, yeah, that- that we should all have learned not to do that because that's probably just gonna turn the light back off.

   14. LFLex Fridman28:01

       Yeah, true. So do it three times, that's the-

   15. GRGuido van Rossum28:03

       Yeah.

   16. LFLex Fridman28:03

       ... that's the right lesson. So, uh... and I wonder how many people actually like the dollar sign. Like you said, it is documentation. So to me it's whatever the opposite of syntactic sugar is. Syntactic poison? (laughs) To me, it is such a pain in the ass that I have to type in a dollar sign. Also super error prone, so it's not self-documenting, it's- it's like a bug-generating thing. It is a kind of documentation, that's the pro, and the con is it's a source of a lot of bugs. But actually I have to ask you, um... this is a really interesting idea of bugs per line of code. If you look at all the computer systems out there, from the code that runs nuclear weapons to the code that runs all the amazing companies that you've been involved with and not, the code that runs Twitter and Facebook and Dropbox and Google and Microsoft Windows and so on, and we, like, laid out... wouldn't that be a cool, like, table, bugs per line of code? And what would the... let's- let's put, like, actual companies aside. Do you think we'd be surprised by the number we see there for all these companies?

   17. GRGuido van Rossum29:18

       That depends on whether you've ever read about research that's been done in this area before. And I didn't know. The- the- the last time I- I saw some research like that, it was probably in the '90s, and the research might have been done in the '80s. But the- the conclusion was, across a wide range of different software, different languages, different companies, different development styles, the number of bugs is always... I think it's in the order of about one bug per 1,000 lines in sort of mature software that- that is considered-

   18. LFLex Fridman30:06

       Interesting.

   19. GRGuido van Rossum30:07

       ... as good as it gets.

   20. LFLex Fridman30:08

       Can I give you some facts here? There's a lot of-

   21. GRGuido van Rossum30:10

       Oh, yeah.

   22. LFLex Fridman30:10

       ... really good papers. So you said mature software, right? So here's, um, a report from a- a programming analytics company. Now, this is from the developer perspective.... well, let me just say what it says because this is very weird and surprising. On average, a developer creates 70 bugs per 1,000 lines of code. 15 bugs per 1,000 lines of code find their way to the customers. This is in software they've analyzed.

   23. GRGuido van Rossum30:41

       Oh, I was, I was wrong by an order of magnitude there.

   24. LFLex Fridman30:44

       Or ...or, um... Fixing a bug takes 30 times longer than writing a line of code. That I can believe.

   25. GRGuido van Rossum30:50

       Yeah, totally.

   26. LFLex Fridman30:51

       75% of a developer's time is spent on debugging. Um, that's for an average developer. They, they analyze this 15-

   27. GRGuido van Rossum30:58

       Ar- argue. One... (laughs)

   28. LFLex Fridman31:00

       (laughs) 1,500 hours a year. In US alone, $113 billion are spent annually on identifying and fixing bugs.

   29. GRGuido van Rossum31:10

       And I imagine this is marketing literature for someone who claims to have a golden bullet or, or a silver bullet that makes all that investment in fixing bugs go away but that, that is usually, uh, not going to-

   30. LFLex Fridman31:25

       Yeah.
6. 38:26 – 53:37

   Programming fads

   1. LFLex Fridman38:26

      that, that's one of, some of the debates I have with myself about everything, uh, from a technology perspective, is how much to hold onto the tools you're comfortable with versus how much to invest in using modern tools. And the signal that the communities provide you with is the noisy one because a lot of people year to year get excited about new tools, and you have to make a prediction. Are these tools defining a new generation of something that will transform programming, or is this just a fad that will pass? Certainly with JavaScript frameworks and, uh, front end and back end of the web, there's a lot of different styles that came and went. (laughs) I remember learning, um, what was it called? ActionScript? I remember for Flash, um, you know, learning how to program in Flash.

   2. GRGuido van Rossum39:16

      Oh.

   3. LFLex Fridman39:16

      Uh, learning how to design, doing graphic animation, all that kind of stuff with Flash. Same with Java applets. I remember creating quite a lot of Java applets, thinking that this potentially defines the future of the web, and it did not.

   4. GRGuido van Rossum39:29

      Well, you know, in most cases like that, the particular technology eventually gets replaced. But many of the concepts that the technology introduced or made accessible first are preserved, of course, because yeah, we're not using Java applets anymore, but the notion of reactive web pages that sort of contain little bits of code that respond directly to something you do like pressing a button or a link or hovering even-

   5. LFLex Fridman40:08

      Mm-hmm.

   6. GRGuido van Rossum40:09

      ... uh, is, has certainly not gone away. And that those animations that were made painfully complicated with Flash, I mean, Flash was an innovation when it first came up and when it was replaced by JavaScript equivalents stuff, it was a somewhat better way to do animations but those animations are still there. Not all of them, but, but sort of, again, there is an evolution and often, so often with technology that the sort of the technology that was eventually thrown away or replaced was still essential to, to sort of get started. There wouldn't be jet planes without propeller planes.

   7. LFLex Fridman41:01

      I betcha. But from a user perspective, yes. From the feature set, yes. But I, from a programmer perspective, it feels like all the time I've spent with ActionScript, all the time I spent with Java on the applet side for the GUI development, I, well, no, Java I have to push back. That, that was useful. That, because it transfers, but the Flash doesn't transfer. So some things you learn and invest time in.

   8. GRGuido van Rossum41:30

      What... Yeah, what, what you learned, the ski- the skill you picked up learning ActionScript-

   9. LFLex Fridman41:37

      Yeah.

   10. GRGuido van Rossum41:38

       ... was sort of, it w- it was perhaps a super valuable skill at the time you picked it up. If, if you, if you learned ActionScript early enough, but that skill is no longer in demand.

   11. LFLex Fridman41:57

       Well, that's the calculation you have to make when you're learning new things. Like today, people start learning programming. Today, I'm trying to, to see what are the new languages to try, what are the new, uh, systems to try that... What are the new IDEs to try to, to keep, keep improving? Keep-

   12. GRGuido van Rossum42:13

       Oh that's, that's why we start when we're young, right?

   13. LFLex Fridman42:16

       (laughs)

   14. GRGuido van Rossum42:17

       When, when we're... But, but that seems very true to me that, that when you're young you have your whole life ahead of you and you're...... you're allowed to make mistakes. In fact, you should, you should feel encouraged to do a bit of stupid stuff.

   15. LFLex Fridman42:33

       Yeah.

   16. GRGuido van Rossum42:33

       Try not to get yourself killed or seriously maimed, but try stuff that deviates from, from what everybody else is doing and, like, nine out of 10 times, you'll just learn why everybody else is not doing that (laughs) -

   17. LFLex Fridman42:50

       Yeah.

   18. GRGuido van Rossum42:50

       ... or why everybody else is doing it some other way. And one out- out of 10 times, you sort of, you discover something that's better or that, that somehow works. I mean, there are all sorts of crazy things that were invented, uh, by accident, by people trying, trying stuff together.

   19. LFLex Fridman43:11

       That's great advice, to try random stuff, make a lot of mistakes.

   20. GRGuido van Rossum43:14

       Once you're married with kids, you're probably going to, uh, be a little more risk-averse because now there's more at stake and you've already hopefully had some time where you, where you were experimenting with crazy shit.

   21. LFLex Fridman43:27

       (laughs) I like how marriage and kids solidifies your choice of programming language. How does that, uh, the Robert Frost poem with the, The Road Less Taken, which I think is misinterpreted by most people, but, uh, a- anyway, I, I, I feel like the choices you make early on, especially if you go all in, they're gonna define the rest of your life's trajectory in a way that, like, you basically are picking a camp. So, um, you know, there's, if you invest a lot in PHP, if you invest a lot in .NET, if you invest a lot in JavaScript, you're going to stick their... You're, that's, that's your life journey. It's very hard to jump-

   22. GRGuido van Rossum44:07

       Well, only as far as that technology remains relevant.

   23. LFLex Fridman44:14

       Yes, yes.

   24. GRGuido van Rossum44:14

       I mean, if, if at age 16 you learn coding in C and by the time you're 26, C is, like, a dead language, then there's still time to switch. There's probably some kind of survivor bias or whatever it's called-

   25. LFLex Fridman44:35

       (laughs) Yes.

   26. GRGuido van Rossum44:36

       ... in, in sort of your observation that, that you pick a camp because there are many different camps to pick and if you pick .NET, then, then you can coast for the rest of your life because that's, uh, technology is now so ubiquitous, of course, that it's... Even if it's, if it's bound to die, it's gonna take a very long time.

   27. LFLex Fridman44:59

       Well, for me personally, I had a very difficult, and in my own head, brave leap that I had to take, relevant to our discussion, which is most of my life I programmed in C and C++. And so, uh, having that hammer, everything looked like a nail, so I would literally even do scripting in C++.

   28. GRGuido van Rossum45:21

       (laughs) .

   29. LFLex Fridman45:21

       Like, I would create programs that do script-like things and, uh, when I first came to Google and, and before then, it became already, before TensorFlow, before all of that, there was a growing realization that C++ is not the right tool for machine learning. We could, we could talk about why that is. It's unclear why that is. A lot of things has to do with community and culture and how to merge this and stuff like that. But for me, to decide to take the leap to Python, like, all out, basically switch completely from C++, except for, uh, highly performant robotics applications, there were still, um, there was still a culture of C++ in, in the space of robotics.

   30. GRGuido van Rossum46:03

       Mm-hmm.
7. 53:37 – 1:18:31

   Speed of Python 3.11

   1. LFLex Fridman53:37

      Speaking of which, let's go back to the boat with the, with the fisherman who's tuned out long ago. (laughs)

   2. GRGuido van Rossum53:43

      (laughs)

   3. LFLex Fridman53:43

      Let's talk to the programmer. Let's jump around and go back to CPython that we tried to define as the reference implementation and one of the big things that's coming out in 3.11. What's the right way to pronounce that?

   4. GRGuido van Rossum53:54

      We tend to say 3.11 because it really was like, we went 3.8, 3.9, 3.10, 3.11 and we're planning to go up to 3.99.

   5. LFLex Fridman54:05

      99? What happens after 99?

   6. GRGuido van Rossum54:07

      Probably just 3.100.

   7. LFLex Fridman54:09

      100?

   8. GRGuido van Rossum54:09

      If we make it there.

   9. LFLex Fridman54:10

      Okay. And go all the way to 420. I got it. Forever Python V3. We'll talk about four, but more for fun. (sighs) So 3.11 is coming out. One of the big sexy things in it is it'll be much faster. So how did you, beyond hiring a great team or working with a great team, make it faster? What are some ideas?... uh, that may- makes it faster. It has to do with simplicity of software versus performance. Mm-hmm.

   10. GRGuido van Rossum54:43

       And so even though C is known to be a low-level language, which is great for writing sort of a high-performance language interpreter-

   11. LFLex Fridman54:53

       Mm-hmm.

   12. GRGuido van Rossum54:54

       ... when I originally started Python or CPython, I didn't expect there would be great success and fame in my future. Uh, so I- I tried to get something working and useful, uh, in about three months.

   13. LFLex Fridman55:20

       Mm-hmm.

   14. GRGuido van Rossum55:21

       And so I- I sort of, I cut corners, I borrowed ideas left and right when it comes to language design as well as implementation. Uh, I also wrote much of the code as simple as it could be. And there- there are like- there are many things that you can code more efficiently by adding more code. It's a bit of a- sort of a time-space trade-off, where you can compute a certain thing from a small number of inputs, uh, and every time you get presented with new input, uh, you do the whole computation from the top.

   15. LFLex Fridman56:09

       Mm-hmm.

   16. GRGuido van Rossum56:10

       That can be simple-looking code, it's easy to understand, it's easy to reason about that you can- you can tell quickly that it's correct, uh, in- at least in the- the sort of mathematical sense of correct. Uh, because it's implemented in C, maybe it performs relatively well. But over time, as sort of as the requirements for that code and the need for performance go up, you might be able to rewrite that same algorithm using more memory, maybe remember previous results so you don't have to recompute everything from scratch. Like the- the classic example is computing prime numbers. Like, is 10 a prime number? Well, you sort of, is it divisible by two? Is it divisible by three? Is it divisible by four? And we go all the way to, is it divisible by nine? And it is not- well, actually, 10 is divisible by two, so there we stop. But say 11, is it divisible by 10? The answer is ni- is no ten times in a row, so now we know 11 is a prime number. On the other hand, if we already know that two, three, five, and seven are prime numbers, and you know a little bit about the mathematics of how prime numbers work, you know that if you have a rough estimate for the square root of 11, you don't actually have to check, is it divisible by four or is it divisible by five? You- all you have to check in the case of 11 is, is it divisible by two, is it divisible by three? Because take 12, if it's divisible by four, well, 12 divided by four is three, so you- you should have come across the question, is it divisible by three first.

   17. LFLex Fridman58:04

       Mm-hmm.

   18. GRGuido van Rossum58:05

       So if you know basically nothing about prime numbers b- except the definition, maybe you go for X from two through N minus one, is N divisible by X? And then at the end, if you got, uh, all nos, uh, for every single one of those questions, you know, oh, it must be a prime number. Well, the first thing is you can stop iterating when you find a yes answer.

   19. LFLex Fridman58:34

       Mm-hmm.

   20. GRGuido van Rossum58:35

       And the second is you can also stop iterating when you had- have reached the square root of N because you know that if it has a divisor larger than- than the square root, it must (laughs) also have a divisor smaller than the square root.

   21. LFLex Fridman58:50

       Mm-hmm.

   22. GRGuido van Rossum58:51

       Then you say, oh, except for two, we don't need to bother with checking for even numbers because all even numbers are divisible by two. So if it's divisible by four, we would already have come across the question, is it divisible by two? And so now you go special case check, is it divisible by two? And then you just check three, five, seven, 11. Uh, and so now you- you sort of reduced your search base by 50% again by- by skipping all the even numbers except for two. If you think a bit more about it or you just read in your book about the history of math-

   23. LFLex Fridman59:29

       (laughs)

   24. GRGuido van Rossum59:29

       ... one of the first algorithms ever written down, all you have to do is check, is it divisible by any of the previous prime numbers that are smaller than the- the square root? And before you get to a better algorithm than that, you have to have several PhDs in- in discrete math. So that's as much as I know. (laughs)

   25. LFLex Fridman59:54

       So th- of course, that same story applies to a lot o- other algorithms. String matching is a good example of, uh, h- how to come up with an efficient algorithm. And sometimes-

   26. GRGuido van Rossum1:00:03

       Yep.

   27. LFLex Fridman1:00:04

       ... the more efficient algorithm is not so much more complex than the inefficient one. But that's an art, and it's not always the case. In the general cases, the more performant the algorithm, the more complex it's gonna be. There's a- there's a kind of trade-off.

   28. GRGuido van Rossum1:00:20

       The simpler algorithms are also the ones that people invent first because when you're looking for a solution, you look at the simplest way to get there first. And so if there is a simple solution, uh-

   29. ... even if it's not the best solution, not the fastest or the memory, most memory-efficient or whatever. Uh, a simple solution, and simple is, is fairly subjective but mathematicians have also, uh, thought about sort of what is a good definition for simple in the case of algorithms. Uh, but the simpler, the simpler solutions tend to be easier to follow for other programmers who haven't made a study of a particular field. And when I, when I started with Python, I, I was a good programmer in general. I knew sort of basic data structures, I knew the C language pretty well, but there were many areas where I was only somewhat familiar with the state-of-the-art.

   30. LFLex Fridman1:01:28

       Mm-hmm.
8. 1:18:31 – 1:23:49

   Type hinting

   1. GRGuido van Rossum1:18:31

      the challenge.

   2. LFLex Fridman1:18:32

      3.5 got the PEP 484 type hints. What is type hinting and is it used by the interpreter, the hints? Or is it just syntactic sugar?

   3. GRGuido van Rossum1:18:44

      So the type hints is an optional mechanism that people can use and it's especially popular with sort of larger companies that have very large code bases written in Python.

   4. LFLex Fridman1:18:58

      Do you think of it as almost like documentation saying these two variables are this type?

   5. GRGuido van Rossum1:19:02

      It is more than documentation. I mean, so it, it...... it is a sub-language of Python where, where you can express the types of variables. So here is a variable, and it's an integer, and here's an argument to this function, and it's a string, and here is a function that returns a list of strings.

   6. LFLex Fridman1:19:22

      But that's not checked when you run the code.

   7. GRGuido van Rossum1:19:24

      But... Exactly. There, there is a separate piece of software called a static type checker that reads all your source code without executing it and thinks long and hard about what it looks from just reading the code that code might be doing and double-checks if that makes sense if you take the types as annotated into account.

   8. LFLex Fridman1:19:51

      So this is something that's supposed to run as you develop.

   9. GRGuido van Rossum1:19:54

      It's like a linter, yeah.

   10. LFLex Fridman1:19:55

       A linter.

   11. GRGuido van Rossum1:19:56

       It... That's definitely a development tool, but the type annotations currently are not used for, uh, speeding up the interpreter, and there are a number of reasons, uh, many people don't use them. Even when they do use them, uh, they sometimes contain lies, where the static type checker says everything's fine, but I cannot prove that this integer is ever not an integer. But at runtime, somehow someone manages to violate that assumption, and the interpreter ends up doing just fine. If we started enforcing type annotations in Python, many Python programs would no longer work.

   12. LFLex Fridman1:20:44

       Mm-hmm.

   13. GRGuido van Rossum1:20:45

       And some Python programs wouldn't even be possible because they're too dynamic. And so we ma- we made the choice of not using the annotations. There, there is a possible future where eventually, three, four, five releases in the future, we could start using those annotations to sort of provide hints because we can, we can sti- s- still say, "Well, the source code leads us to believe that these X and Y are both integers," and so we can generate and add o- and add integer instruction.

   14. LFLex Fridman1:21:22

       Mm-hmm.

   15. GRGuido van Rossum1:21:23

       But we can still have a fallback that says, oh, if the, if somehow the code, code at runtime provided something else, maybe it provided two decimal numbers, we can still use that generic add operation as a fallback. But we're not there.

   16. LFLex Fridman1:21:41

       Is there currently a mechanism or do you see something like that where you can almost add like an assert inside a function that says, "Please check that my type hints are actually mapping to reality." Sort of like insert manual-

   17. GRGuido van Rossum1:21:59

       Yeah.

   18. LFLex Fridman1:21:59

       ... static typing.

   19. GRGuido van Rossum1:22:00

       There are third-party libraries that, uh, are in that business.

   20. LFLex Fridman1:22:05

       So it's possible to do that kind of thing? It's possible to, for a third-party library to take a hint and enforce it?

   21. GRGuido van Rossum1:22:12

       Well, yes.

   22. LFLex Fridman1:22:12

       It seems like a tricky thing.

   23. GRGuido van Rossum1:22:13

       But what, well, what we actually do is... And this, I think this is a fairly unique feature in Python. The type hints can be introspected at runtime. So while the program is running... I mean, Python is a very introspectable language. You can look at the variable and ask yourself, "What are the..." "What is the type of this, this variable?" And if that, maybe that variable happens to refer to a function, you can ask, "What are the arguments to the function?" And nowadays, you can also ask, "What are the type annotations for the function?"

   24. LFLex Fridman1:22:50

       So the type annotations are there inside the variable as it's at runtime.

   25. GRGuido van Rossum1:22:55

       They're mostly associated with the function object, not with each individual variable, but, uh-

   26. LFLex Fridman1:23:01

       Right.

   27. GRGuido van Rossum1:23:02

       ... you can sort of map from, from the arguments to the variables.

   28. LFLex Fridman1:23:06

       And that's what a third-party library can help with.

   29. GRGuido van Rossum1:23:07

       And... Exactly. And the problem with that is that all that extra runtime type checking, uh, is going to slow your code down instead of speed it up.

   30. LFLex Fridman1:23:17

       I think, uh, to reference this, uh, sales pitchy blog post that says, "75% of developer time is spent on debugging," I would say that in some cases that might be okay. It might be okay to pay the cost of performance for the catching of the types, the type errors.
9. 1:23:49 – 1:29:05

   mypy

   1. GRGuido van Rossum1:23:49

   2. LFLex Fridman1:23:49

      Yeah. Can you tell me about M-Y-P-Y, MyPy project?

   3. GRGuido van Rossum1:23:55

      Mm-hmm.

   4. LFLex Fridman1:23:56

      What is it? What's the mission? And, in general, what is the future of, uh, static typing in Python?

   5. GRGuido van Rossum1:24:04

      Well, so MyPy, uh, was started by a Finnish, uh, developer, Jukka Lehtosalo.

   6. LFLex Fridman1:24:11

      So many cool things out of Finland, I gotta say. Just that part of the world.

   7. GRGuido van Rossum1:24:15

      I guess people have nothing better to do-

   8. LFLex Fridman1:24:17

      (laughs)

   9. GRGuido van Rossum1:24:18

      ... in those long cold winters. (laughs)

   10. LFLex Fridman1:24:20

       Yeah, could be.

   11. GRGuido van Rossum1:24:20

       I don't know, I think Jukka lived in England when he invented the, that stuff actually. But-

   12. LFLex Fridman1:24:26

       Mm-hmm.

   13. GRGuido van Rossum1:24:26

       ... MyPy is the original static type checker for Python. And the, the type annotations that were introduced with PEP 484 were sort of developed together with the, the static type checker. And in fact, Jukka had first invented a different syntax that wasn't quite compatible with Python, and, uh, Jukka and I sort of met at a Python conference in, I think, in 2013, and we, we sort of came up with a compromise syntax that would not require any changes to Python.... and that would let Mypy sort of be an add-on static type checker for Python.

   14. LFLex Fridman1:25:16

       Just out of curiosity, was it like double colon or something? What- what was he proposing that would break Python?

   15. GRGuido van Rossum1:25:21

       I think he was using angular brackets for, uh, types like in C++ or, uh, Java generics.

   16. LFLex Fridman1:25:29

       Yeah, you can't use angular brackets in Python? It'll be too tricky for 10% of stuff.

   17. GRGuido van Rossum1:25:34

       Well, we- the- the key thing is that we already had a no- a syntax for annotations, we just didn't know what to use them for yet. So type annotations were just the sort of most logical thing to- to use that existing dummy syntax for.

   18. LFLex Fridman1:25:54

       So you-

   19. GRGuido van Rossum1:25:54

       But there was no, there was no syntax for, uh, defining generics directly, syntactically in the language. Mypy literally meant my version of Python, where "my" refers to Jukka.

   20. LFLex Fridman1:26:11

       (laughs)

   21. GRGuido van Rossum1:26:11

       He had a parser that translated Mypy into Python-

   22. LFLex Fridman1:26:16

       Mm-hmm.

   23. GRGuido van Rossum1:26:16

       ... by, like, doing the type checks and then removing the annotations and all the angular brackets, uh, from the positions where- where he was using them.

   24. LFLex Fridman1:26:30

       Boy.

   25. GRGuido van Rossum1:26:30

       But a pre-processor model doesn't work very well with the typical workflow of, uh, Python development projects.

   26. LFLex Fridman1:26:38

       That's funny. I mean, that could have been another major split if it became successful. Like, uh, if you watch TypeScript versus JavaScript, there's a- like a split in the community over types, right? That seems to be stabilizing now.

   27. GRGuido van Rossum1:26:53

       It's not necessarily a split. There are certainly plenty of people who don't use TypeScript but just use the original JavaScript notation, just like there are many people in the Python world who don't use type annotations and don't use static type checkers.

   28. LFLex Fridman1:27:11

       No, I know. But there is a bit of a split between TypeScript and Java- old school JavaScript, ES whatever, 5, 4.

   29. GRGuido van Rossum1:27:17

       Well, in the JavaScript world, transpilers are sort of the standard way of working anyway.

   30. LFLex Fridman1:27:23

       Yeah.
10. 1:29:05 – 1:45:05

    TypeScript vs JavaScript

    1. GRGuido van Rossum1:29:05

    2. LFLex Fridman1:29:05

       Just on a tangent of a tangent, d- do you see... If you were to recommend somebody use a thing, would you recommend TypeScript or JavaScript?

    3. GRGuido van Rossum1:29:14

       I would recommend, uh, TypeScript.

    4. LFLex Fridman1:29:17

       Just because of the strictness of the typing?

    5. GRGuido van Rossum1:29:19

       It's an enormously helpful extra tool that helps you sort of keep your head straight about what your code is actually doing. I mean, it's- it's- it- it helps with editing your code, it helps with ensuring that your code is not too incorrect, and it's actually quite compatible with JavaScript. Never mind this syntactic sort of hack that is still years in the future, but any library that is written in pure JavaScript can still be used from TypeScript programs, and also the other way around. You can write a library in TypeScript and then export it in a form that is totally consumable by JavaScript. That sort of compatibility is, uh, is sort of the key to this- to the success of TypeScript.

    6. LFLex Fridman1:30:17

       Yeah. Just to look at it as almost like a biological system that's evolving, it's fascinating to see JavaScript evolve the way it does.

    7. GRGuido van Rossum1:30:24

       Well, maybe we should consider that biological systems are just, uh, engineering systems too, right?

    8. LFLex Fridman1:30:30

       Yes. But-

    9. GRGuido van Rossum1:30:31

       Just very advanced. (laughs)

    10. LFLex Fridman1:30:32

        (laughs)

    11. GRGuido van Rossum1:30:33

        With- with more history.

    12. LFLex Fridman1:30:35

        But it's almost like the most visceral in the JavaScript world because there's just so much code written in JavaScript that for its history was messy. If you talk about bugs per line of code, I just feel like JavaScript eats the cake or whatever the terminology is. It- it beats Python by a lot in terms of number of bugs, meaning like way more bugs in JavaScript.

    13. GRGuido van Rossum1:31:00

        Mm-hmm.

    14. LFLex Fridman1:31:01

        And then- and then the- obviously the browsers are devel-... I mean, it's just there's so much active development. It feels a lot more like evolution where a bunch of stuff is born and dies and there's experimentation and debates versus Python is more...... um, all that stuff is happening. But there's just a longer history of stable working giant software systems written in Python, versus JavaScript is just a giant, beautiful, I would say, mess of code.

    15. GRGuido van Rossum1:31:31

        It's a very different culture and, to some extent, differences in culture are random, but to some extent they- the differences have to do with the environment.

    16. LFLex Fridman1:31:42

        Yeah.

    17. GRGuido van Rossum1:31:42

        Uh, and the fact that JavaScript is primarily the language for, uh, developing web applications, especially the client side. And the fact that it's basically the only language for developing web applications makes that community sort of just have a different nature than the community of other languages.

    18. LFLex Fridman1:32:08

        (sighs) Plus the graphical component, um, and the fact that they're deploying it on all kinds of, uh, shapes of screens and devices and all that kind of stuff. It just creates a beautiful chaos. Anyway, back to MyPy. So what... Okay, you- you met, you talked about a syntax that could work. Where does it currently stand? What's the future of static typing in Python?

    19. GRGuido van Rossum1:32:35

        It is still controversial, but it is much more accepted than when MyPy and PEP 484 were- were young.

    20. LFLex Fridman1:32:43

        What's the connection between, uh, PEP 484 type hints and MyPy?

    21. GRGuido van Rossum1:32:48

        MyPy was the original static type checker. So it- e- MyPy quickly evolved from UKAS-owned variant of Python to a static type checker for Python. And, uh, sort of PEP 484 that- that was at, like, a very productive year where, like, many hundreds of messages were exchanged debating the merits of every aspect of- of that PEP. And so MyPy is a static type checker for Python. It is itself written in Python. Most additional static typing features that we introduced in the time since 3.6, uh, were also prototyped through MyPy. MyPy being an open source project with a very small number of maintainers, it was successful enough that people said, "This static type checking stuff for Python is actually worth an investment for our company."

    22. LFLex Fridman1:33:57

        Nice.

    23. GRGuido van Rossum1:33:57

        But somehow they chose not to support making MyPy faster, say, or adding new features to MyPy. But, uh, both Google and Facebook, and later Microsoft, developed their own static type checker. I think Facebook was one of the first. They decided that they wanted to use the same technology that they had successfully used for, uh, HHVM, because they- they sort of- they had a bunch of compiler writers and- and sort of static type checking experts who had written the HHVM compiler, and it was a big success within the company. And they had done it in a certain way, sort of. They wrote a big highly parallel application in an obscure language named OCaml, which is apparently mostly very good for, uh, writing static type checkers.

    24. LFLex Fridman1:35:01

        Interesting.

    25. GRGuido van Rossum1:35:02

        Yeah.

    26. LFLex Fridman1:35:02

        Uh, I- I have a lot of questions about how to write a static type checker then. That's very confusing.

    27. GRGuido van Rossum1:35:08

        Facebook wrote their version and they worked on it in secret for about a year, and then they came clean and went open source. Uh, Google, in the meantime, was developing something called PyType, which was mostly interesting because it... As you may have heard, they have one gigantic mono repo. So all the code is checked into a single repository. Facebook has a different approach. So Facebook developed Pyre, which-

    28. LFLex Fridman1:35:40

        Yeah.

    29. GRGuido van Rossum1:35:40

        ... which was written in OCaml, which worked well with Facebook's development workflow. Uh, Google developed something they called PyType, which was actually itself written in Python. Uh, and it was meant to sort of fit well in their static type checking needs in Google's gigantic mono repo.

    30. LFLex Fridman1:36:05

        So Google has (laughs) the one giant... Got it. So the... J- just to clarify this, static type checker philosophically is a thing that's supposed to exist outside of the language itself, and it's just a workflow, like a debugger for the program.

Episode duration: 3:15:50