Guido van Rossum is the creator of Python programming language. Please support this podcast by checking out our sponsors:
- GiveDirectly: https://givedirectly.org/lex to get gift matched up to $1000
- Eight Sleep: https://www.eightsleep.com/lex to get special savings
- Fundrise: https://fundrise.com/lex
- InsideTracker: https://insidetracker.com/lex to get 20% off
- Athletic Greens: https://athleticgreens.com/lex to get 1 month of fish oil

EPISODE LINKS:
Guido's Twitter: https://twitter.com/gvanrossum 
Guido's Website: https://gvanrossum.github.io/
Python's Website: https://python.org

PODCAST INFO:
Podcast website: https://lexfridman.com/podcast
Apple Podcasts: https://apple.co/2lwqZIr
Spotify: https://spoti.fi/2nEwCF8
RSS: https://lexfridman.com/feed/podcast/
Full episodes playlist: https://www.youtube.com/playlist?list=PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4
Clips playlist: https://www.youtube.com/playlist?list=PLrAXtmErZgOeciFP3CBCIEElOJeitOr41

OUTLINE:
0:00 - Introduction
0:48 - CPython
6:01 - Code readability
10:22 - Indentation
26:58 - Bugs
38:26 - Programming fads
53:37 - Speed of Python 3.11
1:18:31 - Type hinting
1:23:49 - mypy
1:29:05 - TypeScript vs JavaScript
1:45:05 - Best IDE for Python
1:55:05 - Parallelism
2:12:58 - Global Interpreter Lock (GIL)
2:22:36 - Python 4.0
2:34:53 - Machine learning
2:44:35 - Benevolent Dictator for Life (BDFL)
2:56:11 - Advice for beginners
3:02:43 - GitHub Copilot
3:06:10 - Future of Python

SOCIAL:
- Twitter: https://twitter.com/lexfridman
- LinkedIn: https://www.linkedin.com/in/lexfridman
- Facebook: https://www.facebook.com/lexfridman
- Instagram: https://www.instagram.com/lexfridman
- Medium: https://medium.com/@lexfridman
- Reddit: https://reddit.com/r/lexfridman
- Support on Patreon: https://www.patreon.com/lexfridman

Can you imagine possible features that Python 4.0 might have that would

Given the amount of pain and joy, suffering and triumph that was involved in the move between version 2 and version 3.

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.

To support it, please check out our sponsors in the description.

And now, Dear friends, here's Guido van Rossum.

In it, CPython claimed to be 10 to 60% faster.

CPython is the last Python implementation standing, also the first 1 that was ever created.

The original Python implementation that I started over 30 years ago.

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

What kind of audience do you have in mind here?

No, there's somebody on a boat that's into fishing and they've never heard about programming, but also some world-class programmers.

1 of them has not heard about programming, is really into fishing, and the other 1 is like an incredible Silicon Valley programmer that's programmed in everything.

C, C++, Python, Rust, Java, He knows the entire history of programming languages, so you're gonna have to speak to both.

I imagine that boat in the middle of the ocean, I'm gonna please the guy who knows how to fish first.

He seems like the most useful in the middle of the ocean.

So he's probably very suspicious about what goes on in that cell phone.

But he must have heard that inside his cell phone is a tiny computer and a programming language is computer code that tells the computer what to do.

It's zeros and ones and then there's assembly and then.

Oh, yeah, 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, there's a bit of a stereotype they often don't know.

Or they can't seem to make the difference.

And I've never checked his with linguists.

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 native Chinese speakers pronounce that 1 sound that sounds like L to some of them, like R to others.

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.

Russian has, the Slavic languages have sounds like zh, the letter zh, like Americans or English speakers don't seem to know the sound Z.

They seem to be uncomparable with that sound.

So we're not going to the shapes of tongues and the sounds that the mouth can make.

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.

Well, acquire a loaf of bread, cut it in slices, take 2 slices, put mustard on 1, put the jelly on the other or something, then add the meat, then add the cheese.

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

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, that's the dance of communication between humans.

Well, for lawyers, ambiguity certainly is a feature.

For plenty of other cases, the ambiguity is not much of a feature, but we work around it of course.

So with context, the precision of the statement becomes more and more concrete, right?

But when you say I love you to a person that matters a lot to you, the person doesn't try to compile that statement and return an error saying, please define love, right?

No, but I imagine that my wife and my son interpreted very differently.

Nevertheless, the context is already different in that case.

So that's the programming language, is ability to unambiguously state a recipe.

You go through in PEP8, 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 code readability counts.

That's a thing between programmers because on the 1 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 fact, they have lots of context, but 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.

A software is developed by teams of people.

Even the mad scientist sitting alone in his lab can 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.

So even the mad scientist coding alone in his lab 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 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 particular pie or dish from the recipe.

And so there 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 2 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.

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

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

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

That's pretty much all software nowadays.

So, but it's not just about the complexity of the program.

It's like you said, it is a social endeavor in that you're constantly improving that recipe for the cherry pie.

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

He decides that he wants, I don't know, he wants some decoration on his pie or icing or.

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

So first of all, the thing that people first experience when they look at Python, there is a, it is very readable, but there's also like a spatial structure to it.

Can you explain the indentation style of Python and what is the magic to it?

Spaces are important for readability of any kind of text.

If you take a cookbook recipe and you remove 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 the 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 just 1 solid block of text.

On the other hand, what a typical cookbook does if the paper is not too expensive, each recipe starts on its own page.

There's shortcuts so that you don't have to sort of write 2 sentences on how you have to cut the onion because there are only 3 ways that people ever cut onions in a kitchen, small, medium, and in slices, or something like that.

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

We're talking to programmers with a metaphor of cooking.

But there is a strictness to the spacing that Python defines.

So there's some looser things, some stricter things, but the 4 spaces for the indentation is really interesting.

It really defines what the language looks and feels like.

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 group, It's like you have a bulleted list.

In a complex business document and inside some of the bullets are other bulleted lists, you will indent those 2.

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

On the other hand, if you don't indent at all, 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 based on ancient conventions and the sort of the typical width of a computer screen in the 80s and all sorts of things sort of, we came up with sort of 4 spaces as a compromise.

I mean, there are groups, there are large groups of people who code with 2 spaces per indent level.

For example, the Google style guide, all the Google Python code, and I think also all the Google C++ code is indented with only 2 spaces per block.

If you're not used to that, it's harder to at a glance understand the code because the sort of the high level structure is determined by the indentation.

On the other hand, there are other programming languages where the indentation is 8 spaces or a whole tab stop in sort of classic Unix.

And to me, that looks weird because you sort of, after 3 indent levels, you've got no room left.

Well, there's some languages where the indentation is a recommendation, it's a stylistic 1, the code compiles even without any indentation.

And then Python really, indentation is a fundamental part of the language, right?

So you can code Python with 2 spaces per block or 6 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.

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.

They'd suggest the proper indentation for you.

Like in C you type a few words and then you type a curly brace which is their notion of sort of begin an indented block.

Then you hit return and then it automatically indents 4 or 8 spaces depending on your style preferences or how your editor is configured.

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

For a long time I was actually convinced that the indentation was just better.

Without context I would still claim that indentation is better.

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 1 or 2.

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 to sort of indicate blocks.

Do you still, as a radical renegade revolutionary, do you still stand behind this idea of space, of indentation versus braces?

Like what, can you dig into it a little bit more?

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

We would get in trouble if we wanted to switch.

Just like you couldn't redefine C to use indentation, even if you agree that indentation sort of in a greenfield environment would be better.

You can't change that kind of thing in a language.

It's hard enough to reach agreement over much more minor details.

Maybe, I mean, in the past in Python, we did have a big debate about tabs versus spaces and 4 spaces versus fewer or more.

And we sort of came up with a recommended standard and sort of options for people who want to be different.

But yes, I guess the thought experiment I'd like you to consider is if you could travel back through time when the compatibility is not an issue, and you started Python all over again, can you make the case for indentation still?

Well, it frees up a pair of matched brackets of which there are never enough in the world for other purposes.

Sort of easier to grasp for people who don't already know another programming language.

Because the sort of 1 of the things and I mostly got this from my mentors who taught me programming language design in the earlier 80s.

When you're teaching programming, for the total newbie who has not coded before, not in any other language, A whole bunch of concepts in programming are very alien or sort of new and maybe very interesting but also distracting and confusing and there are many different things you have to learn.

You have to sort of in a typical 13 week programming course, you have to, if it's like really learning to program from scratch, You have to cover algorithms, you have to cover data structures, you have to cover syntax, you have to cover variables, loops, functions, recursion, classes, expressions, operators.

If you can spend a little less time having to worry about the syntax.

The classic example was often oh the compiler complains every time I put a semicolon in the wrong place or I forget to put a semicolon.

Python doesn't have semicolons in that sense.

And you are also not sort of misled into putting them where they don't belong because you don't learn about them in the first place.

The flip side of that is forcing the strictness onto the beginning programmer to teach them that programming values attention to details.

You don't get to just write the way you write in English paper.

other details that they have to pay attention to.

So I think they'll still get the message about paying attention to details.

The interesting design choice, I still program quite a bit in PHP, and I'm sure there's other languages like this, but the dollar sign before a variable, that was always an annoying thing for me.

It didn't quite fit into my understanding of why this is good for a programming language.

I'm not sure if you ever thought about that 1.

There is a whole lineage of programming languages.

PHP is 1, Perl was 1, the Unix shell is 1 of the oldest, or all the different shells.

The Dollar was invented for that purpose because the very earliest shells had a notion of scripting but they did not have a notion of parameterizing the scripting.

And so a script is just a few lines of text where each line of text is a command that is read by a very primitive command processor that then sort of takes the first word on the line as the name of a program and passes all the rest of the line as text into the program for the program to figure out what to do with as arguments.

And so by the time scripting was slightly more mature than the very first script, there was a convention that just like the first word of line is the name of the program, the following words could be names of files.

Input.txt, output.html, things like that.

The next thing that happens is, oh, it would actually be really nice if we could have variables and especially parameters for scripts.

Parameters are usually what starts this process.

But now you have a problem because you can't just say the parameters are X Y and Z and so now we call say Let's say X is the input file and Y is the output file.

I have my program and I write program X, Y.

Well, that already has a meaning because that presumably means X itself is the file.

It's a file name, it's not a variable name.

And so the inventors of things like the Unix shell and I'm sure job command language at IBM before that had to use something that made it clear to the script processor.

Here is an X that is not actually the name of a file which you just pass through to the program you're running, here is an X that is the name of a variable.

And when you're writing a script processor, you try to keep it as simple as possible.

Because certainly in the 50s and 60s, the thing that interprets the script was itself a very, had to be a very small program because it had to fit in a very small part of memory.

And so saying, oh, just look at each character.

And if you see a dollar sign, you jump to another section of the code and then you gobble up characters or say until the next space or something.

And so it was sort of invented as a clever way to make parsing of things that contain both variable and fixed parts very easy in a very simple script processor.

It also helps, even then, it also helps the human author and the human reader of the script to quickly see, oh, 20 lines down in the script, I see a reference to XYZ.

So now we know that XYZ must be 1 of the parameters of the script.

Several things to say, which is the leftovers from the simple script processor languages are now in code bases, like behind Facebook, or behind most of the backend.

I think PHP probably still runs most of the backend of the internet.

Oh yeah, yeah, I think there's a lot of it in Wikipedia too, for example.

It's funny that those decisions, or not funny, it's fascinating that those decisions permeate through time.

I mean, the sort of, the inner workings of DNA have been stable for, well, I don't know how long it was, like 300 million years, half a billion years.

And there are all sorts of weird quirks there that don't make a lot of sense if you were to design a system like self-replicating molecules from scratch.

Well, that system has a lot of interesting resilience.

It has redundancy that results, like it messes up in interesting ways that still is resilient when you look at the system level of the organism.

Code doesn't necessarily have that, a computer programming code.

You'd be surprised how much resilience modern code has.

I mean, if you look at the number of bugs per line of code, even in very well tested code that in practice works just fine, there are actually lots of things that don't work fine.

And there are error correcting or self-correcting mechanisms at many levels.

Well, in the end, the user who sort of is told, well, you got to reboot your PC, is part of that system.

And a slightly less drastic thing is reload the page, which we all know how to do without thinking about it when something weird happens.

You try to reload a few times before you say, oh, there's something really weird or try to click the button again if the first time didn't work.

Well, yeah, that we should all have learned not to do that because that's probably just going to turn the light back off.

So do it 3 times, that's the right lesson.

And I wonder how many people actually like the dollar sign.

So To me, it's whatever the opposite of syntactic sugar is, syntactic poison.

To me, it is such a pain in the ass that I have to type in a dollar sign.

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, 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 that, let's put like actual companies aside.

Do you think we'd be surprised by the number we see there for all these companies?

That depends on whether you've ever read about research that's been done in this area before.

And I don't know, the last time I saw some research like that, there was probably in the nineties and the research might've been done in the eighties, but 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 1 bug per thousand lines in sort of mature software that is considered as good as it gets.

So here's a report from a programming analytics company.

Now this is from a developer perspective.

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 1000 lines of code find their way to the customers.

I was wrong by an order of magnitude there.

Fixing a bug takes 30 times longer than writing a line of code.

75% of a developer's time is spent on debugging.

In US alone, $113 billion is spent annually on identifying and fixing bugs.

And I imagine this is marketing literature for someone who claims to have a golden bullet or silver bullet that makes all that investment in fixing bugs go away.

Well, there are, I mean, they're referencing a lot of stuff, of course, but it is a page that is, you know, there's a contact us button at the bottom.

Presumably if you just spend a little bit less than $100 billion, we're willing to solve the problem for you.

See all Lex Fridman transcripts on Youtube

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