2 hours 42 minutes 40 seconds
🇬🇧 English
Speaker 1
00:00
The following is a conversation with Chris Lattner, his second time on the podcast. He's 1 of
Speaker 2
00:05
the most brilliant engineers in modern computing, having created LLVM compiler infrastructure project, the Clang compiler, the Swift programming language, a lot of key contributions to TensorFlow and TPUs as part of Google. He served as Vice President of Autopilot Software at Tesla, was a software innovator and leader at Apple, and now is at Sci-5 as Senior Vice President of Platform Engineering, looking to revolutionize chip design to make it faster, better, and cheaper. Quick mention of each sponsor, followed by some thoughts related to the episode.
Speaker 2
00:40
First sponsor is Blinkist, an app that summarizes key ideas from thousands of books. I use it almost every day to learn new things or to pick which books I want to read or listen to next. Second is Neuro, the maker of functional sugar-free gum and mints that I use to supercharge my mind with caffeine, L-theanine, and B vitamins. Third is Masterclass, online courses from the best people in the world on each of the topics covered from rockets, to game design, to poker, to writing, and to guitar.
Speaker 2
01:13
And finally, Cash app, the app I use to send money to friends for food, drinks, and unfortunately lost bets. Please check out the sponsors in the description to get a discount and to support this podcast. As a side note, let me say that Chris has been an inspiration to me on a human level because he is so damn good as an engineer and leader of engineers and yet he's able to stay humble, especially humble enough to hear the voices of disagreement and to learn from them. He was supportive of me and this podcast from the early days, and for that, I'm forever grateful.
Speaker 2
01:49
To be honest, most of my life, no 1 really believed that I would amount to much. So when another human being looks at me, it makes me feel like I might be someone special. It can be truly inspiring. That's a lesson for educators.
Speaker 2
02:02
The weird kid in the corner with a dream is someone who might need your love and support in order for that dream to flourish. If you enjoy this thing, subscribe on YouTube, review it with 5 Stars on Apple Podcasts, follow on Spotify, support on Patreon, or connect with me on Twitter at Lex Friedman. And now, here's my conversation with Chris Latner.
Speaker 3
02:25
What are the strongest qualities of Steve Jobs, Elon Musk, and the great and powerful Jeff Dean since you've gotten a chance to work with each?
Speaker 4
02:35
You're starting with an easy question there. These are 3 very different people. I guess you could do maybe a pairwise comparison between them instead of a group comparison.
Speaker 4
02:45
So if you look at Steve Jobs and Elon, I worked a lot more with Elon than I did with Steve. They have a lot of commonality. They're both visionary in their own way. They're both very demanding in their own way.
Speaker 4
02:58
My sense is Steve is much more human factor focused, where Elon is more technology focused.
Speaker 3
03:04
What does human factor mean?
Speaker 4
03:05
Steve's trying to build things that feel good, that people love, that affect people's lives, how they live. He's looking into the future a little bit in terms of what people want, where I think that Elon focuses more on learning how exponentials work and predicting the development of those.
Speaker 3
03:24
Steve worked with a lot of engineers. That was 1 of the things that reading the biography and how can a designer essentially talk to engineers and get their respect?
Speaker 4
03:35
I think so. I did not work very closely with Steve. I'm not an expert at all.
Speaker 4
03:38
My sense is that he pushed people really hard. But then when he got an explanation that made sense to him, then he would let go. And he did actually have a lot of respect for engineering. But he also knew when to push.
Speaker 4
03:52
And when you can read people well, you can know when they're holding back and when you can get a little bit more out of them. And I think he was very good at that. I mean, if you compare the other folks, so Jeff Dean, right? Jeff Dean's an amazing guy.
Speaker 4
04:06
He's super smart, as are the other guys. Jeff is a really, really, really nice guy, well-meaning. He's a classic Googler. He wants people to be happy.
Speaker 4
04:17
He combines it with brilliance, so he can pull people together in a really great way. He's definitely not a CEO type. I don't think you'd even want to be that. Do you
Speaker 3
04:28
know if he still programs?
Speaker 4
04:29
Oh, yeah. He definitely programs. Jeff is an amazing engineer today, right?
Speaker 4
04:32
And that has never changed. So it's really hard to compare Jeff to either of those 2. I think that Jeff leads through technology and building it himself and then pulling people in and inspiring them. And so I think that that's 1 of the amazing things about Jeff, but each of these people, with their pros and cons, all are really inspirational and have achieved amazing things.
Speaker 4
04:57
So it's been, I've been very fortunate to get to work with these guys.
Speaker 3
05:00
For yourself, you've led large teams, you've done some of the incredible difficult technical challenges. Is there something you've picked up from them about how to lead?
Speaker 4
05:12
Yeah, well, so I mean, I think leadership is really hard. It really depends on what you're looking for there. I think you really need to know what you're talking about.
Speaker 4
05:20
So being grounded on the product, on the technology, on the business, on the mission is really important. Being, understanding what people are looking for, why they're there. 1 of the most amazing things about Tesla is the unifying vision, right? People are there because they believe in clean energy and electrification, all these kinds of things.
Speaker 4
05:41
The other is to understand what really motivates people, how to get the best people, how to build a plan that actually can be executed, right? There's so many different aspects of leadership and it really depends on the time, the place, the problems. You know, there's a lot of issues that don't need to be solved. And so if you focus on the right things and prioritize well, that can really help move things.
Speaker 3
06:01
2 interesting things you mentioned. 1 is you really have to know what you're talking about. How you've worked on a lot of very challenging technical things.
Speaker 3
06:12
Sure. So I kind of assume you were born technically savvy, but assuming that's not the case, how did you develop technical expertise? Like even at Google, you worked on I don't know how many projects, but really challenging, very varied.
Speaker 4
06:32
Compilers, TPUs, hardware, cloud stuff, bunch of different things. The thing that I've become comfortable with as I've gained experience is being okay with not knowing. And so a major part of leadership is actually, it's not about having the right answer, it's about getting the right answer.
Speaker 4
06:52
And so if you're working in a team of amazing people, right, and many of these places, many of these companies all have amazing people. It's the question of how do you get people together? How do you build trust? How do you get people to open up?
Speaker 4
07:05
How do you get people to be vulnerable sometimes with an idea that maybe isn't good enough, but it's the start of something beautiful? How do you provide an environment where you're not just like top-down, that shall do the thing that I tell you to do, but you're encouraging people to be part of the solution, and providing a safe space where if you're not doing the right thing, they're willing to tell you about it.
Speaker 3
07:29
You're asking dumb questions.
Speaker 4
07:31
Yeah, dumb questions are my specialty. Yeah. Well, I've been in the hardware realm recently, and I don't know much at all about how chips are designed.
Speaker 4
07:38
I know a lot about using them. I know some of the principles and the ars technical level of this. But It turns out that if you ask a lot of dumb questions, you get smarter really quick. And when you're surrounded by people that want to teach and learn themselves, it can be a beautiful thing.
Speaker 3
07:55
So let's talk about programming languages, if it's okay.
Speaker 4
07:58
Sure, sure.
Speaker 3
07:59
At the highest absurd philosophical level, because I-
Speaker 4
08:01
Don't get romantic on me, Lex.
Speaker 3
08:04
I will forever get romantic and torture you, I apologize. Why do programming languages even matter?
Speaker 4
08:14
Okay, well, Thank you very much. So you're saying why should you care about any 1 programming language or why do we care about programming computers?
Speaker 3
08:20
No, why do we care about programming language design, creating effective programming languages, choosing 1 programming language versus another programming language? Why we keep struggling and improving through the evolution of these programming languages.
Speaker 4
08:39
Sure, sure, sure. Okay. So, I mean, I think you have to come back to what are we trying to do here, right?
Speaker 4
08:43
So we have these, these beasts called computers that are very good at specific kinds of things, and we think it's useful to have them do it for us, right? Now, you have this question of how best to express that, because you have a human brain still that has an idea in its head, and you wanna achieve something, right? So, well, there's lots of ways of doing this you can go directly to the machine and speak assembly language and then you can express directly what the computer understands that's fine you can then have higher and higher and higher levels of abstraction up until machine learning and you're designing a neural net to do the work for you. The question is where along this way do you want to stop and what benefits do you get out of doing so?
Speaker 4
09:23
And so programming languages in general, you have C, you have Fortran, Java, and Ada, Pascal, Swift, you have lots of different things. They'll have different trade-offs, and they're tackling different parts of the problems. Now, 1 of the things that most programming languages do is they're trying to make it so that you have pretty basic things like portability across different hardware. So you've got, I'm gonna run on an Intel PC, I'm going to run on a RISC-V PC, I'm going to run on ARM phone or something like that, fine.
Speaker 4
09:53
I want to write 1 program and have it portable, and this is something that assembly doesn't do. Now, when you start looking at the space of programming languages, This is where I think it's fun because programming languages all have trade-offs and most people will walk up to them and they look at the surface level of syntax and say, oh I like curly braces or I like tabs or I like you know semicolons or not or whatever right. Subjective, fairly subjective, very shallow things. But programming languages, when done right, can actually be very powerful.
Speaker 4
10:24
And the benefit they bring is expression. Okay, and If you look at programming languages, there's really 2 different levels to them. 1 is the down in the dirt, nuts and bolts of how do you get the computer to be efficient, stuff like that, how they work, type systems, compiler stuff, things like that. The other is the UI.
Speaker 4
10:45
The UI for programming language is really a design problem, and a lot of people don't think about it that way.
Speaker 3
10:50
The UI, you mean all that stuff with the braces and-
Speaker 4
10:53
Yeah, all that stuff is the UI, and what it is, and UI means user interface. What's really going on is it's the interface between the guts and the human. And humans are hard, right?
Speaker 4
11:05
Humans have feelings, they have things they like, they have things they don't like, and a lot of people treat programming languages as though humans are just kind of abstract creatures that cannot be predicted. But it turns out that actually there is better and worse. People can tell when a program language is good or when it was an accident. 1 of the things with Swift in particular is that a tremendous amount of time by tremendous number of people have been put into really polishing and making it feel good.
Speaker 4
11:36
But it also has really good nuts and bolts underneath it.
Speaker 3
11:39
You said that SWIFT makes a lot of people feel good. How do you get to that point? So how do you predict that tens of thousands, hundreds of thousands of people are going to enjoy using this, the user experience of this programming language?
Speaker 4
11:57
Well, you can look at it in terms of better and worse, right? So if you have to write lots of boilerplate or something like that, you will feel unproductive. And so that's a bad thing.
Speaker 4
12:04
You can look at it in terms of safety. If like C, for example, is what's called a memory unsafe language. And so you get dangling pointers and you get all these kind of bugs that then you have spent tons of time debugging and it's a real pain in the butt, and you feel unproductive. And so by subtracting these things from the experience, you get happier people.
Speaker 3
12:23
But again, keep interrupting. I'm sorry. But- It's so hard to deal with.
Speaker 3
12:29
If you look at the people, people that are most productive on Stack Overflow, they have a set of priorities that may not always correlate perfectly with the experience of the majority of users. You know, if you look at the most upvoted, quote unquote, correct answer on Stack Overflow, is usually really sort of prioritizes like safe code, proper code, stable code, you know, that kind of stuff. As opposed to like if I want to use go-to statements in my basic, right? I want to use go-to state, like, what if 99% of people want to use go-to statements?
Speaker 3
13:12
So you use completely improper, you know, unsafe syntax.
Speaker 4
13:16
I don't think that people actually, like if you boil it down and you get below the surface level, people don't actually care about go-tos or if statements or things like this. They care about achieving a goal. So the real question is, I want to set up a web server and I want to do a thing, whatever.
Speaker 4
13:32
Like how quickly can I achieve that? From a programming language perspective, there's really 2 things that matter there. 1 is, what libraries exist? Then how quickly can you put it together?
Speaker 4
13:44
What are the tools around that look like? When you want to build a library that's missing, what do you do? Now, this is where you see huge divergence in the force between worlds. And so you look at Python, for example.
Speaker 4
13:57
Python is really good at assembling things, but it's not so great at building all the libraries. So what you get, because of performance reasons, other things like this, is you get Python layered on top of C, for example, and that means that doing certain kinds of things, it doesn't really make sense to do in Python. Instead, you do it in C, and then you wrap it, and then you're living in 2 worlds, and 2 worlds never is really great because tooling and the debugger doesn't work right, and all these kinds of things.
Speaker 3
14:23
Can you clarify a little bit what you mean by Python is not good at building libraries, meaning it doesn't make it conducive?
Speaker 4
14:30
Certain kinds of libraries. No, but just
Speaker 3
14:32
the actual meaning of the sentence. Yeah. Meaning like it's not conducive to developers to come in and add libraries, or is it the duality of the, it's a dance between Python and C and-
Speaker 4
14:48
Well, so Python's amazing. Python's a great language. I did not mean to say that Python is bad for libraries.
Speaker 4
14:53
What I meant to say is there are libraries that Python's really good at that you can write in Python. But there are other things, like if you want to build a machine learning framework, you're not going to build a machine learning framework in Python because of performance, for example. Or you want GPU acceleration or things like this. Instead, what you do is you write a bunch of C or C++ code or something like that, and then you talk to it from Python.
Speaker 4
15:18
This is because of decisions that were made in the Python design, and those decisions have other counterbalancing forces. But the trick when you start looking at this from a programming language perspective is you start to say, okay, cool. How do I build this catalog of libraries that are really powerful? And how do I make it so that then they can be assembled into ways that feel good and they generally work the first time?
Speaker 4
15:44
Because when you're talking about building a thing, you have to include the debugging, the fixing, the turnaround cycle, the development cycle, all that kind of stuff into the process of building the thing. It's not just about pounding out the code. And so this is where things like, you know, Catching bugs at compile time is valuable, for example. But if you dive into the details in this, Swift, for example, has certain things like value semantics, which is this fancy way of saying that when you treat a variable like a value, it acts like a mathematical object would.
Speaker 4
16:21
Okay, so you have used PyTorch a little bit. In PyTorch, you have tensors. Tensors are n-dimensional grid of numbers. Very simple, You can do plus and other operators on them.
Speaker 4
16:34
It's all totally fine. But why do you need to clone a tensor sometimes? Have you ever run into that? Yeah.
Speaker 4
16:41
OK. And so why is that? Why do you need to clone a tensor?
Speaker 3
16:43
It's the usual object thing that's in Python.
Speaker 4
16:46
So in Python, and just like with Java and many other languages, this isn't unique to Python. In Python, it has a thing called reference semantics, which is the nerdy way of explaining this. And what that means is you actually have a pointer do a thing instead of the thing.
Speaker 4
17:01
Now, this is due to a bunch of implementation details that you don't want to go into. But in Swift, you have this thing called value semantics. And so when you have a tensor in Swift, it is a value. If you copy it, it looks like you have a unique copy.
Speaker 4
17:15
And if you go change 1 of those copies, then it doesn't update the other 1 because you just made a copy of this thing.
Speaker 3
17:21
So that's like highly error prone in at least computer science, math-centric disciplines about Python. That the thing you would expect to behave. Like math.
Speaker 3
17:35
Like math. It doesn't behave like math and in fact, quietly doesn't behave like math and then can ruin the entirety of your math.
Speaker 4
17:43
Exactly. Well, and then it puts you in debugging land again. Yeah. Right now, you just want to get something done and you're like, wait a second, where do I need to put clone and what level of the stack, which is very complicated, which I thought I was reusing somebody's library and now I need to understand it to know where to clone a thing.
Speaker 3
17:59
Hard to debug, by the way.
Speaker 4
18:01
Exactly. And so this is where programming languages really matter. So in Swift, having value semantics so that both you get the benefit of math working like math, but also the efficiency that comes with certain advantages there, certain implementation details there, really benefit you as a programmer.
Speaker 3
18:18
Can you clarify the value semantics? Like, how do you know that a thing should be treated like a value?
Speaker 4
18:23
Yeah, so Swift has a pretty strong culture and good language support for defining values. And so if you have an array, so tensors are 1 example that the machine learning folks are very used to. Just think about arrays, same thing, where you have an array, you put, you create an array, you put 2 or 3 or 4 things into it, and then you pass it off to another function.
Speaker 4
18:46
What happens if that function adds some more things to it? Well, you'll see it on the side that you pass it in. This is called reference semantics. Now, what if you pass an array off to a function?
Speaker 4
19:01
It scrolls it away in some dictionary or some other data structure somewhere. Well, it thought that you just handed it that array, then you return back and that reference to that array still exists in the caller and they go and put more stuff in it. The person you handed it off to may have thought they had the only reference that and so they didn't know that this was going to change underneath the covers. This is where you end up having to do clone.
Speaker 4
19:26
I was past a thing, I'm not sure if I have the only version of it, so now I have to clone it. What value semantics does is it allows you to say, hey, I have a SunSwift, it defaults to value semantics.
Speaker 3
19:38
So defaults to value semantics and then because most things should be treated like values, then it makes sense for that to be
Speaker 4
19:45
the default. And 1 of the important things about that is that arrays and dictionaries and all these other collections that are aggregations of other things also have value semantics. And so when you pass this around to different parts of your program, you don't have to do these defensive copies.
Speaker 4
19:59
And so this is great for 2 sides, right? It's great because you define away the bug, which is a big deal for productivity, the number 1 thing most people care about. But it's also good for performance because when you're doing a clone, so you pass the array down to the thing, it was like, I don't know if anybody else has it, I have to clone it. Well, you just did a copy of a bunch of data, it could be big.
Speaker 4
20:20
Then it could be that the thing that called you is not keeping track of the old thing. So you just made a copy of it and you may not have had to. So the way the value semantics work in Swift is it uses this thing called copy on write, which means that you get the benefit of safety and performance. It has another special trick because if you think, certain languages like Java, for example, they have immutable strings.
Speaker 4
20:44
What they're trying to do is they provide value semantics by having pure immutability. Functional languages have pure immutability in lots of different places, and this provides a much safer model and it provides value semantics. The problem with this is if you have immutability, everything is expensive. Everything requires a copy.
Speaker 4
21:02
For example, in Java, if you have a string X and a string Y, you append them together, we have to allocate a new string to hold X, Y. If they're immutable. Well, and strings in Java are immutable, and if there's optimizations for short runs, and it's complicated, but generally think about them as a separate allocation and so when you append them together you have to go allocate a third thing because somebody might have a pointer to either of the other ones right and you can't go change them So you have to go allocate a third thing. Because of the beauty of how the Swift Values Max system works out, if you have a string on Swift, you say, hey, put in x, right?
Speaker 4
21:40
And they say, append on YZW, it knows that there's only 1 reference to that. And so it can do an in-place update. And so you're not allocating tons of stuff on the side. You're not, you don't have all those problems.
Speaker 4
21:54
When you pass it off, you can know you have the only reference. If you pass it off to multiple different people, but nobody changes it, they can all share the same thing.
Speaker 3
22:02
So you get a lot
Speaker 4
22:03
of the benefit of purely mutable design. And so you get a really nice sweet spot that I haven't seen in other languages.
Speaker 3
22:09
Yeah, that's interesting. Like I thought there was going to be a philosophical like narrative here that you're gonna have to pay a cost for it. It sounds like, I think value semantics is beneficial for easing of debugging or minimizing the risk of errors, like bringing the errors closer to the source, bringing the symptom of the error closer to the source of the error, however you say that.
Speaker 3
22:40
But you're saying there's not a performance cost either if you implement
Speaker 4
22:45
it correctly. Yeah, Well, so there's trade-offs with everything. And so if you are doing very low-level stuff, then sometimes you can notice the cost.
Speaker 4
22:53
But then what you're doing is you're saying, what is the right default? So coming back to user interface, when you talk about programming languages, 1 of the major things that Swift does that makes people love it, that is not obvious when it comes to designing a language, is this UI principle of progressive disclosure of complexity. So Swift, like many languages, is very powerful. The question is, when do you have to learn the power as a user?
Speaker 4
23:20
Swift, like Python, allows you to start with print, hello world. Certain other languages start with public static void main class, this is like all the ceremony. You go to teach a new person, hey, welcome to this new thing. Let's talk about public, access control classes, wait, what's that?
Speaker 4
23:41
String system.out.println, packages. And so instead if you take this and you say, hey, we need packages, modules, we need powerful things like classes, we need data structures, we need all these things. The question is, how do you factor the complexity? How do you make it so that the normal case scenario is you're dealing with things that work the right way and the right way, give you good performance by default.
Speaker 4
24:09
But then as a Power User, if you want to dive down to it, you have full C performance, full control over low-level pointers. You can call malloc if you want to call malloc. This is not recommended on the first page of every tutorial, but it's actually really important when you want to get work done. And so being able to have that is really the design in programming language design.
Speaker 4
24:29
And design is really, really hard. It's something that I think a lot of people kind of, outside of UI, again, a lot of people just think is subjective, like there's nothing, you know, it's just like curly braces or whatever. It's just like somebody's preference, but actually good design is something that you can feel.
Speaker 3
24:48
And how many people are involved with good design? So if we looked at Swift, but look at historically, I mean, this might touch like, it's almost like a Steve Jobs question too, like how much dictatorial decision-making is required versus collaborative, and we'll talk about how all that can go wrong or right.
Speaker 4
25:11
But. Yeah, well, Swift, so I can't speak to in general, all design everywhere. So the way it works with Swift is that there's a core team. And so core team is 6 or 7 people-ish, something like that, that is people that have been working with Swift since very early days.
Speaker 4
25:26
And so I-
Speaker 3
25:27
And by early days is not that long ago.
Speaker 4
25:30
Okay, yeah. So it became public in 2014. So it's been 6 years public now, but, but so that's enough time that there's a story arc there.
Speaker 4
25:39
Okay. And there's mistakes have been made that then get fixed and you learn something and then you, you know, and So what the core team does is it provides continuity. And so you want to have a, OK, well, there's a big hole that we want to fill. We know we want to fill it.
Speaker 4
25:55
So don't do other things that invade that space until we fill the hole. There's a boulder that's missing here. We want to do, we will do that boulder, even though it's not today. Keep out of that space.
Speaker 3
26:06
And the whole team remembers of the, remembers the myth of the boulder that's there.
Speaker 4
26:11
Yeah, yeah. There's a general sense of what the future looks like in broad strokes and a shared understanding of that combined with a shared understanding of what has happened in the past that worked out well and didn't work out well. The next level out is you have the, what's called the Swift Evolution Community, and you've got in that case hundreds of people that really care passionately about the way Swift evolves.
Speaker 4
26:30
And that's like an amazing thing to, again, the core team doesn't necessarily need to come up with all the good ideas. You got hundreds of people out there that care about something and they come up with really good ideas too. And that provides this like tumbling, rock tumbler for ideas. And so the evolution process is, you know, a lot of people in a discourse forum, they're like hashing it out and trying to like talk about, okay, well, should we go left or right?
Speaker 4
26:53
Or if we did this, what would be good? And, you know, here you're talking about hundreds of people, so you're not going to get consensus necessarily. You're not obvious consensus. And so there's a proposal process that then allows the core team and the community to work this out.
Speaker 4
27:08
And what the core team does is it aims to get consensus out of the community and provide guardrails, but also provide long-term, make sure we're going the right direction kind of things.
Speaker 3
27:20
So does that group represent like the, how much people will love the user interface? Like, do you think they're able to capture that? Well, I mean,
Speaker 4
27:29
it's something we talk about a lot. It's something we care about. How well we do that's up for debate, but I think that we've done pretty well
Speaker 3
27:36
so far. Is the beginner in mind? Yeah.
Speaker 3
27:38
Like, because you said the progressive disclosure.
Speaker 4
27:40
Yeah, so we care a lot about that, a lot about power, a lot about efficiency, a lot about there are many factors to good design, and you have to figure out a way to work your way through that.
Speaker 3
27:53
So if you think about, like a language I love is Lisp, probably still because I use Emacs, but I haven't done anything, any serious working list, but it has a ridiculous amount of parentheses. I've also, you know, with Java and C++, the braces, you know, I like, I enjoyed the comfort of being between braces. You know?
Speaker 3
28:20
And then Python is, sorry to interrupt, just like, and last thing to me, as a designer, if I was a language designer, God forbid, is I would be very surprised that Python with no braces would nevertheless somehow be comforting also. So like, I could see arguments for all of these.
Speaker 4
28:40
So look at this, this is evidence that it's not about braces versus tabs.
Speaker 3
28:44
Right, Exactly, you're good, it's a good point.
Speaker 4
28:46
Right, so like, you know, there's evidence that shows this. But see, like, it's 1
Speaker 3
28:50
of the most argued about things.
Speaker 4
28:52
Oh yeah, of course, just like tabs and spaces, which it doesn't, I mean, there's 1 obvious right answer, but it doesn't actually matter.
Speaker 3
28:59
What's that?
Speaker 4
29:00
Come on, we're friends. Like, come on, what are you trying to do to me here?
Speaker 3
29:03
People are gonna, yeah, half the people
Speaker 4
29:04
are gonna tune out, yeah. So, but then-
Speaker 3
29:07
So, you're able to identify things that don't really matter for the experience.
Speaker 4
29:12
Well, no, no, no, it's always a really hard, so the easy decisions are easy, right? I mean, you can find those are not the interesting ones. The hard ones are the ones that are most interesting, right?
Speaker 4
29:21
The hard ones are the places where, hey, we want to do a thing. Everybody agrees we should do it. There's 1 proposal on the table, but it has all these bad things associated with it. Well, okay, what are we gonna do about that?
Speaker 4
29:33
Do we just take it? Do we delay it? Do we say, hey, well, maybe there's this other feature that if we do that first, this will work out better. How does this, if we do this, are we paying ourselves a new corner, right?
Speaker 4
29:46
And so this is where, again, you're having that core team of people that has some continuity and has perspective, has some of the historical understanding, is really valuable. Because it's not just like 1 brain. You get the power of multiple people coming together to make good decisions. And then you get the best out of all these people, and you also can harness the community around it.
Speaker 3
30:06
What about the decision of whether in Python having 1 type, or having strict typing?
Speaker 4
30:14
Yeah, let's talk about this. I like how you put that by the way. Many people would say that Python doesn't have types.
Speaker 3
30:21
Doesn't have types, yeah.
Speaker 4
30:22
But you're right.
Speaker 3
30:23
Well, I've listened to you enough to where... Yeah. I'm a fan of yours and I've listened to way too many podcasts and videos of you talking about this.
Speaker 4
30:32
Oh yeah, so I would argue that Python has 1 type. And so like when you import Python and Swift, which by the way works really well, you have everything comes in as a Python object. Now, here there are trade-offs because, you know, it depends on what you're optimizing for.
Speaker 4
30:47
And Python is a super successful language for a really good reason, because it has 1 type, you get duck typing for free and things like this. But also you're pushing, you're making it very easy to pound out code on the 1 hand, But you're also making it very easy to introduce complicated bugs that you have to debug. And you pass a string into something that expects an integer, and it doesn't immediately die. It goes all the way down the stack trace, and you find yourself in the middle of some code that you really didn't want to know anything about, and it blows up, and you're just saying, well, what did I do wrong?
Speaker 4
31:18
And so types are good and bad, and they have trade-offs. They're good for performance and certain other things, depending on where you're coming from. But it's all about trade-offs. And so this is what design is.
Speaker 4
31:28
Design is about weighing trade-offs and trying to understand the ramifications of the things that you're weighing, like types or not, or 1 type or many types. But also within many types, how powerful do you make that type system is another very complicated question with lots of trade-offs. It's very interesting, by the way. But that's like 1 dimension.
Speaker 4
31:51
And there's a bunch of other dimensions. JIT compiled versus static compiled. Garbage collected versus reference counted. Versus manual memory management versus, you know, like in like all these different trade-offs and how you balance them are what make a program language good.
Speaker 4
32:05
Concurrency.
Speaker 3
32:06
Yeah. So in all those things, I guess, when you're designing the language, you also have to think of how that's going to get all compiled down to.
Speaker 4
32:15
If you care about performance, yeah. Well, and go back to Lisp. Lisp, also I would say JavaScript is another example of a very simple language.
Speaker 4
32:25
I also love Lisp. I don't use it as much as maybe you do or you did.
Speaker 3
32:29
No, I think everyone who loves Lisp, It's like, I don't know, I love Frank Sinatra, but how often do I seriously listen to Frank Sinatra?
Speaker 4
32:40
Sure. But you look at that or you look at JavaScript, which is another very different but relatively simple language. There's certain things that don't exist in the language. But there is inherent complexity to the problems that we're trying to model.
Speaker 4
32:53
And so what happens to the complexity? In the case of both of them, for example, you say, well, what about large-scale software development? Well, you need something like packages. Neither language has a language affordance for packages, and so what you get is patterns.
Speaker 4
33:07
You get things like NPN, you get things like these ecosystems that get built around. I'm a believer that if you don't model at least the most important inherent complexity in the language, then what ends up happening is that complexity gets pushed elsewhere. And when it gets pushed elsewhere, sometimes that's great because often building things as libraries is very flexible and very powerful and allows you to evolve and things like that. But often it leads to a lot of unnecessary divergence in the force and fragmentation.
Speaker 4
33:36
And when that happens, you just get kind of a mess. And so the question is, how do you balance that? Don't put too much stuff in the language, because that's really expensive and makes things complicated. But how do you model enough of the inherent complexity of the problem that you provide the framework and the structure for people to think about?
Speaker 4
33:54
Also, so the key thing to think about with programming languages, and you think about what a programming language is there for is it's about making a human more productive, right? And so like there's an old, I think it's a Steve Jobs quote about, it's a bicycle for the mind, right? You can definitely walk, but you'll get there a lot faster if you can bicycle on your way.
Speaker 3
34:17
A programming language is a bicycle for the mind? Yeah. It's basically, wow, that's a really interesting way to think about
Speaker 4
34:23
it. By raising the level of abstraction, now you can fit more things in your head. By being able to just directly leverage somebody's library, you can now get something done quickly. In the case of Swift, SwiftUI is this new framework that Apple has released recently for doing UI programming.
Speaker 4
34:39
And it has this declarative programming model, which defines away entire classes of bugs. It builds on value semantics and many other nice Swift things. What this does is it allows you to just get way more done with way less code, and now your productivity as a developer is much higher. That's really what programming languages should be about, is it's not about tabs versus spaces or curly braces or whatever.
Speaker 4
35:03
It's about how productive do you make the person? And you can only see that when you have libraries that were built with the right intention that the language was designed for. And with Swift, I think we're still a little bit early, but SwiftUI and many other things that are coming out now are really showing that. And I think that they're opening people's eyes.
Speaker 3
35:22
It's kind of interesting to think about like how that, you know, the knowledge of something of how good the bicycle is, how people learn about that. You know, So I've used C++. Now this is not going to be a trash talking session about C++, but I used C++ for a really long time.
Speaker 3
35:41
I can go
Speaker 4
35:41
there if you want. I have the scars.
Speaker 3
35:45
I feel like I spent many years without realizing like there's languages that could for my particular lifestyle, brain style, thinking style, there's languages that could make me a lot more productive in the debugging stage, in the development stage, and thinking like the bicycle for the mind, that I can fit more stuff into my...
Speaker 4
36:07
Python's a great example of
Speaker 3
36:08
that, right?
Speaker 4
36:09
I mean, a machine learning framework in Python is a great example of that. It's just very high abstraction level, and so you can be thinking about things on a very high level algorithmic level, instead of thinking about, okay, well, am I copying this tensor to a GPU or not? Right?
Speaker 4
36:23
It's not what you want to be thinking about.
Speaker 3
36:25
As I was telling you, I guess the question I had is, how does a person like me or in general people discover more productive languages. Like how, as I've been telling you offline, I've been looking for a project to work on in Swift so I can really try it out. I mean, my intuition was doing a hello world is not going to get me there.
Speaker 3
36:51
To get me to experience the power of the language.
Speaker 4
36:53
You need a few weeks to change your metabolism.
Speaker 3
36:56
Exactly, beautifully put. That's 1 of the problems with people with diets. Like I'm actually currently, to go in parallel, but in a small tangent is, I've been recently eating only meat.
Speaker 3
37:09
Okay? And, okay. So most people are like, the thing that's horribly unhealthy or whatever, you have like a million, it, whatever the science is, it just doesn't sound right.
Speaker 4
37:22
Well, so back when I was in college, we did the Atkins diet. That was a thing.
Speaker 3
37:26
Similar, but you have to always give these things a chance. I mean, with dieting, always not dieting, but just the things that you like. If I eat, personally, if I eat meat, just everything, I can be super focused, or more focused than usual.
Speaker 3
37:42
I just feel great. I've been running a lot, doing pushups and pulls and so on. I mean, Python is similar in that sense for me.
Speaker 4
37:50
Where are you going with this?
Speaker 3
37:53
I mean, literally, I just felt I had a stupid smile on my face when I first started using Python. I could code up really quick things. Like I would see the world.
Speaker 3
38:05
I'll be empowered to write a script to do some basic data processing, to rename files on
Speaker 4
38:12
my computer.
Speaker 3
38:14
And like Perl didn't do that for me. I mean, a little bit.
Speaker 4
38:19
Well, and again, none of these are about which is best or something like that, but there's definitely better and worse here.
Speaker 3
38:25
But it clicks. Well, yeah.
Speaker 4
38:27
If you look at Perl, for example, you get bogged down in scalars versus arrays, versus hashes, versus type globs, and all that stuff. Python's like, yeah, let's not do this.
Speaker 3
38:38
And some of it is debugging. Like everyone has different priorities. But for me, it's, can I create systems for myself that empower me to debug quickly?
Speaker 3
38:47
Like I've always been a big fan, even just crude like asserts, like always stating things that should be true, which in Python I found myself doing more because of type, all these kinds of stuff.
Speaker 4
39:02
Well, you could think of types in a programming language as being kind of assert.
Speaker 3
39:05
Yeah.
Speaker 4
39:06
They could check the compile time, right? So how do you learn a new thing? Well, so this is how do people learn new things, right?
Speaker 4
39:13
This is hard. People don't like to change. People generally don't like change around them either. We're all very slow to adapt and change, and usually there's a catalyst that's required to force yourself over this.
Speaker 4
39:28
For learning a programming language, it really comes down to finding an excuse, like build a thing that the language is actually good for, that the ecosystem is ready for. If you were to write an iOS app, for example, that'd be the easy case. Obviously, you would use Swift for that. There are other- Android.
Speaker 4
39:48
So Swift runs on Android.
Speaker 3
39:50
Oh, does it?
Speaker 4
39:50
Oh, yeah. Yeah, Swift runs in lots of places.
Speaker 3
39:52
How does that work?
Speaker 4
39:55
OK, so Swift is built on top of LLVM. LLVM runs everywhere. LLVM, for example, builds the Android kernel.
Speaker 4
40:03
Oh, okay. I
Speaker 3
40:05
didn't realize this.
Speaker 4
40:06
Yeah. Swift is very portable, runs on Windows, it runs on lots of different things.
Speaker 3
40:13
I'm sorry to interrupt. SwiftUI, And then there's a thing called UIKit. So can I build an app with Swift?
Speaker 4
40:20
Well, so that's the thing, is the ecosystem is what matters there. So SwiftUI and UIKit are Apple technologies.
Speaker 3
40:27
Okay, got it.
Speaker 4
40:27
And so they happen to, like SwiftUI happens to be written in Swift, but it's an Apple proprietary framework that Apple loves and wants to keep on its platform, which makes total sense. You go to Android and you don't have that library. So Android has a different ecosystem of things that hasn't been built out and doesn't work as well with Swift.
Speaker 4
40:45
So you can totally use Swift to do arithmetic and things like this, but building a UI with Swift on Android is not a great experience right now.
Speaker 3
40:54
If I wanted to learn Swift, 1 practical different version of that is Swift for TensorFlow, for example. And 1 of the inspiring things for me with both TensorFlow and PyTorch is how quickly the community can switch from different libraries. You can see some of the community switching to PyTorch now, but it's very easy to see, and then TensorFlow is really stepping up its game.
Speaker 3
41:24
And then there's no reason why. I think the way it works is basically it has to be 1 GitHub repo, like 1 paper steps up.
Speaker 4
41:31
It gets people excited.
Speaker 3
41:32
It gets people excited and they're like, I have to learn this at Swift for what? What's Swift again? And then they learn and they fall in love with it.
Speaker 3
41:41
I mean, that's what happened. PyTorch is a-
Speaker 4
41:42
There has to be a reason, a catalyst. And so, and there, I mean, people don't like change, but it turns out that once you've worked with 1 or 2 programming languages, the basics are pretty similar. 1 of the fun things about learning programming languages, even maybe Lisp, I don't know if you agree with this, is that when you start doing that, you start learning new things.
Speaker 4
42:03
Because you have a new way to do things and you're forced to do them and that forces you to explore and it puts you in learning mode and when you get in learning mode, your mind kind of opens a little bit and you can see things in a new way, even when you go back to the old place.
Speaker 3
42:17
Right. So with Lisp, it's functional. Yeah. But I wish there's a window.
Speaker 3
42:23
Maybe you can tell me if there is. There you go. This is a question to ask what is the most beautiful feature in a programming language. Before I ask it, let me say like with Python, I remember I saw list comprehensions.
Speaker 3
42:37
It was like when I really took it in. I don't know, I just loved it. It was like fun to do. It was fun to do that kind of, it was something about it, to be able to filter through a list and to create a new list on a single line was elegant.
Speaker 3
42:56
I could all get into my head and it just made me Fall in love with the language. So is there, let me ask you a question. Is there, what do you use the most beautiful feature in a programming languages that you've ever encountered in Swift maybe and then outside of Swift?
Speaker 4
43:15
I think the thing that I like the most from a programming language. So I think the thing you have to think about with a programming language, again, what is the goal? You're trying to get people to get things done quickly.
Speaker 4
43:27
So you need libraries, you need high-quality libraries, and then you need a user base around them that can assemble them and do cool things with them. And so to me, the question is, what enables high quality libraries? Okay. And there's a huge divide in the world between libraries who enable high quality libraries versus the ones that put special stuff in the language.
Speaker 3
43:52
So programming languages that enable high-quality libraries. Got it.
Speaker 4
43:58
What I mean by that is expressive libraries that then feel like a natural integrated part of the language itself. So an example of this in Swift is that int and float and also array and string, things like this, these are all part of the library. Like int is not hard-coded into Swift.
Speaker 4
44:17
And so what that means is that because int is just a library thing defined in the standard library, along with strings and arrays and all the other things that come with the standard library, well, hopefully you do like int. But Anything that any language features that you needed to define int, you can also use in your own types. So if you wanted to find a quaternion or something like this, right? Well, it doesn't come in the standard library.
Speaker 4
44:43
There's a very special set of people that care a lot about this. But those people are also important. It's not about classism, right? It's not about the people who care about ints and floats are more important than the people who care about quaternions.
Speaker 4
44:55
And so to me, the beautiful things about programming languages is when you allow those communities to build high quality libraries that feel native, that feel like they're built into the compiler without having to be.
Speaker 3
45:07
What does it mean for the int to be part of not hard-coded in? Yeah. So what is an int?
Speaker 3
45:18
Okay.
Speaker 4
45:19
Int is just an integer. In this case, it's like a 64-bit integer or something like this.
Speaker 3
45:24
But so the 64-bit is hard-coded or no?
Speaker 4
45:28
No, none of that's hard-coded. So int, if you go look at how it's implemented, it's just a struct in Swift. So it's a struct and then how do you add 2 structs?
Speaker 4
45:37
Well, you define plus. So you can define plus on Int. Well, you can define plus on your thing too. You can define Int has like an isOdd method or something like that on it.
Speaker 4
45:47
Yeah, you can add methods on the things. Yeah.
Speaker 3
45:51
So you can define operators like how it behaves. That's used beautiful when there's something about the language which enables others to create libraries which are not hacky.
Speaker 4
46:05
Yeah, they feel native. And so 1 of the best examples of this is Lisp, right? Because in Lisp, all the libraries are basically part of the language, right?
Speaker 4
46:15
You write term rewrite systems and things like this. And so
Speaker 3
46:18
can you, as a counter example, provide what makes it difficult to write a library that's native? Is it the Python C?
Speaker 4
46:25
Well, so 1 example, I'll give you 2 examples. Java and C++, or Java and C, They both allow you to define your own types. But int is hard code in the language.
Speaker 4
46:38
OK, well, why? Well, in Java, for example, coming back to this whole reference semantic value semantic thing, Int gets passed around by value. Yeah. But if you make a pair or something like that, a complex number, it's a class in Java, and now it gets passed around by reference, by pointer.
Speaker 4
47:00
Now you lose value semantics. You lost math. Well, that's not great. If you can do something with int, why can't I do with my type?
Speaker 4
47:10
That's the negative side of the thing I find beautiful, is when you can solve that, when you can have full expressivity, where you as a user of the language have as much or almost as much power as the people who implemented all the standard built-in stuff. Because what that enables is that enables truly beautiful libraries.
Speaker 3
47:31
It's weird because I've gotten used to that. That's 1, I guess, other aspect of program language design. You have to think, you know, the old first principles thinking, like, why are we doing it this way?
Speaker 3
47:45
By the way, I mean, I remember because I was thinking about the Walrus operator and I'll ask you about it later, but it hit me that the equal sign for assignment. Yeah. Like why are we using the equal sign for assignment?
Speaker 4
48:01
Yeah. That's not the only solution. If you look at Pascal, they use colon equals for assignment and equals for equality. And they use like less than, greater than instead of the not equal thing.
Speaker 4
48:15
Like there are other answers here.
Speaker 3
48:16
So, but like, and yeah, like ask you all, but how do you then decide to break convention to say, you know what, everybody's doing it wrong. We're gonna do it right.
Speaker 4
48:30
Yeah. So, so it's like an ROI, like return on investment tradeoff. Right. So if you do something weird, let's just say like not like colon equal instead of equal for assignment, that would be weird with today's aesthetic.
Speaker 4
48:44
Right. And So you'd say, cool, this is theoretically better, but is it better in which ways? What do I get out of that? Do I define away class of bugs?
Speaker 4
48:52
Well, 1 of the class of bugs that C has is that you can use like if X equals
Speaker 3
48:59
Y. Yeah. Right.
Speaker 4
49:01
Well, turns out you can solve that problem in lots of ways. Clang, for example, GCC, all these compilers will detect that as a likely bug, produce a warning.
Speaker 3
49:10
Do they? Yeah. I feel like they didn't.
Speaker 3
49:12
Or Clang does. GCC didn't. It's like 1 of the important things about programming language design is like you're literally creating suffering in the world. Okay, like I feel like, I mean, 1 way to see it is the bicycle for the mind, but the other way is to like minimizing suffering.
Speaker 4
49:31
Well, you have to decide if it's worth it, right? And so let's come back to that. But if you look at this, and again, this is where there's a lot of detail that goes into each of these things.
Speaker 4
49:42
Equal in C returns a value. Yep. That's messed up. That allows you say X equals Y equals Z like that works and see.
Speaker 4
49:52
Yeah, is it messed up? You know, well, so that
Speaker 3
49:55
most people think it's messed up. I think
Speaker 4
49:57
it is very by messed up. What I mean is it is very rarely used for good, and it's often used for bugs. Yeah.
Speaker 4
50:06
Right. That's
Speaker 3
50:07
a good definition.
Speaker 4
50:09
You could use, in hindsight, this was not such a great idea. Right now, 1 of the things with Swift that is really powerful, and 1 of the reasons it's actually good versus it being full of good ideas is that when we launched Swift 1, we announced that it was public, people could use it, people could build apps, but it was gonna change and break. When Swift 2 came out, we said, hey, it's open source and there's this open process which people can help evolve and direct the language.
Speaker 4
50:37
The community at large, like Swift users can now help shape the language as it is. What happened is that as part of that process is, a lot of really bad mistakes got taken out. So for example, Swift used to have the C style plus plus and minus minus operators. Like what does it mean when you put it before versus after?
Speaker 4
50:58
Right? Well, that got cargo-culted from C into Swift early on. What's cargo-culted? Cargo-culted means brought forward without really considering it.
Speaker 3
51:07
Okay.
Speaker 4
51:08
This is maybe not the most PC term. But- I have to look it
Speaker 3
51:12
up in Urban Dictionary.
Speaker 4
51:13
Yeah. Yeah. So it got pulled into C without or it got pulled into Swift without very good consideration. And we went through this process and 1 of the first things got ripped out was plus plus and minus minus because they lead to confusion.
Speaker 4
51:27
They have very little value over saying, you know, X plus equals 1 and X plus equals 1 is way more clear. And so when you're optimizing for teachability and clarity and bugs and this multidimensional space that you're looking at, things like that really matter. And so being first principles on where you're coming from and what you're trying to achieve and being anchored on the objective is really important.
Speaker 3
51:49
Well, let me ask you about the most, sort of this podcast isn't about information, it's about drama.
Speaker 4
51:59
Okay.
Speaker 3
51:59
Let me talk to you about some drama. So you mentioned Pascal and colon equals. There's something that's called the Walrus operator.
Speaker 4
52:08
Yeah.
Speaker 3
52:10
And Python
Speaker 1
52:12
3.8
Speaker 3
52:13
added the Walrus operator. And the reason I think it's interesting, it's not just because of the feature, it has the same kind of expression feature you can imagine to see that it returns the value of the assignment. And then you can comment on that in general, but on the other side of it, it's also the thing that toppled the dictator.
Speaker 3
52:37
It finally drove Guido to step down from BDFL, the toxicity of the community. So maybe, what do you think about the walrus operator in Python? Is there an equivalent thing in Swift that really stress tested the community? And then on the flip side, what do you think about Guido stepping down over it?
Speaker 4
52:58
Yeah, well, if I look past the details of the Walrus operator, 1 of the things that makes it most polarizing is that it's syntactic sugar. Okay.
Speaker 3
53:06
What do you mean by syntactic sugar?
Speaker 4
53:08
It means you can take something that already exists in language and you can express it in a more concise way.
Speaker 3
53:14
So, okay, I'm gonna play devil's advocate. So, this is great. Is that a objective or subjective statement?
Speaker 3
53:21
Like, Can you argue that basically anything is syntactic sugar or not?
Speaker 4
53:27
No. Not everything is syntactic sugar. So for example, the type system. Like, can you have classes versus, like, do you have types or not?
Speaker 4
53:40
So 1 type versus many types is not something that affects syntactic sugar. And So if you say I want to have the ability to define types, I have to have all this language mechanics to define classes. And oh, now I have to have inheritance. And I have all this stuff.
Speaker 4
53:54
That's just making language more complicated. That's not about sugaring it. Swift has sugar. So Swift has this thing called iflet.
Speaker 4
54:04
And it has various operators that are used to concisify specific use cases. So the problem with syntactic sugar, when you're talking about, hey, I have a thing that takes a lot to write and I have a new way to write it. You have this horrible trade-off which becomes almost completely subjective, which is how often does this happen and does it matter? And 1 of the things that is true about human psychology, particularly when you're talking about introducing a new thing, is that people overestimate the burden of learning something.
Speaker 4
54:35
And so it looks foreign when you haven't gotten used to it. But if it was there from the beginning, of course it's just part of Python. Like unquestionably, like this is just the thing I know. And it's not a new thing that you're worried about learning.
Speaker 4
54:47
It's just part of the deal. Now with Guido, I don't know Guido well.
Speaker 3
54:55
Yeah, have you passed cross much?
Speaker 4
54:56
Yeah, I've met him a couple of times, but I don't know Guido well. But the sense that I got out of that whole dynamic was that he had put not just the decision maker weight on his shoulders, but it was so tied to his personal identity that he took it personally and he felt the need and he kind of put himself in the situation of being the person instead of building a base of support around him. I mean, this is probably not quite literally true, but by-
Speaker 3
55:24
Too much, so there's too much-
Speaker 4
55:26
Too much concentrated on him, right? And so-
Speaker 3
55:29
And that can wear you down.
Speaker 4
55:31
Well, yeah, particularly because people then say, Guido, you're a horrible person. I hate this thing, blah, blah, blah, blah, blah, blah, blah. And sure, it's like maybe 1% of the community that's doing that.
Speaker 4
55:41
But Python's got a big community, and 1% of millions of people is a lot of hate mail and that just from human factor will just wear on you.
Speaker 3
55:49
What to clarify, it looked from just what I saw in the messaging for the, let's not look at the million Python users, but at the Python core developers. It feels like the majority, the big majority on a vote were opposed to it.
Speaker 4
56:03
Okay, I'm not that close to it, so I don't know
Speaker 3
56:05
what happened. So, okay, so the situation is like literally, yeah, I mean, the majority, the core developers, they're against it.
Speaker 4
56:13
Were opposed to it.
Speaker 3
56:14
So, And they weren't even like against it. It was, there was a few, well, they were against it, but the against it wasn't like, this is a bad idea. They were more like, we don't see why this is a good idea.
Speaker 3
56:31
And what that results in is there's a stalling feeling. Like you just slow things down. Now from my perspective, you could argue this and I think it's very interesting if we look at politics today and the way Congress works, it's slowed down everything.
Speaker 4
56:49
It's a dampener.
Speaker 3
56:50
Yeah, it's a dampener, but that's a dangerous thing too because if it dampens things, if the dampening results in-
Speaker 4
56:58
What are you talking about? It's a low-pass filter, but if you need billions of dollars injected into the economy, or trillions of dollars, then suddenly stuff happens, right? And so.
Speaker 4
57:07
For sure.
Speaker 3
57:09
So you're talking about.
Speaker 4
57:10
I'm not defending our political situation, just to be clear.
Speaker 3
57:13
But you're talking about like a global pandemic. I was hoping we could fix the healthcare system and the education system.
Speaker 4
57:23
I'm not a politics person, I don't know. When it comes to languages, the community's kind of right in terms of it's a very high burden to add something to a language. So as soon as you add something, you have a community of people building on it and you can't remove it, okay?
Speaker 4
57:37
And if there's a community of people that feel really uncomfortable with it, then taking it slow, I think, is an important thing to do and there's no rush, particularly if it was something that's 25 years old and is very established and it's not coming into its own.
Speaker 3
57:54
What about features?
Speaker 4
57:56
So I think that the issue with Guido is that maybe this is a case where he realized it had outgrown him. It went from being the language. Python, I mean, Guido's amazing, but Python isn't about Guido anymore.
Speaker 4
58:12
It's about the users, and to a certain extent, the users own it. Guido spent years of his life, a significant fraction of his career on Python. And from his perspective, I imagine he's like, well, this is my thing. I should be able to do the thing I think is right.
Speaker 4
58:28
But you can also understand the users where they feel like, this is my thing. I use this like, and I don't know, it's a hard thing.
Speaker 3
58:38
But what, if we could talk about leadership in this, because it's so interesting to me, I'm gonna make, I'm gonna wear it, hopefully somebody makes it. If not, I'll make it a water stopper, you're sure. Because I think it represents to me, maybe it's my Russian roots or something, you know, it's the burden of leadership.
Speaker 4
58:56
Like
Speaker 3
58:56
I feel like to push back, I feel like progress can only, like most difficult decisions, just like you said, there'll be a lot of divisiveness over, especially in a passionate community. It just feels like leaders need to take those risky decisions that if you like listen, that with some non-zero probability, maybe even a high probability, would be the wrong decision. But they have to use their gut and make that decision.
Speaker 4
59:29
Well, this is 1 of the things where you see amazing founders. The founders understand exactly what's happened and how the company got there and are willing to say, we have been doing thing X the last 20 years, but today we're gonna do thing Y.
Speaker 3
59:45
And they
Speaker 4
59:45
make a major pivot for the whole company. The company lines up behind them, they move and it's the right thing. But then when the founder dies, the successor doesn't always feel that agency to be able to make those kinds of decisions.
Speaker 4
59:58
Even though the CEO is the 1 that's gonna make it.
Omnivision Solutions Ltd