YouSaid · the spoken record

Guido van Rossum

lines on the record
185
first
2022-11-26
most recent
2022-11-26
sittings or episodes
1
sources
podcast

Every line below is reproduced as it was said and linked to the record it came from. Nothing here is summarised or generated. Directory · Search · Corrections

  1. “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.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  2. “Well, we. The key thing is that we already had 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 use that existing dummy syntax for. But there was no syntax for defining generics directly syntactically in the language. MyPy literally meant my version of Python, where it refers to Yuka. He had a parser that translated MyPy into Python by doing the type checks and then removing the annotations and all the angular brackets from the positions where he was using them. A pre-processor model doesn't work very well with the typical workflow of Python development projects.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  3. “I guess people have nothing better to do in those long cold winters. I don't know. I think Yucca lived in England when he invented that stuff, actually. But MyPy is the original static type checker for Python. And the type annotations that were introduced with PEP484 were sort of developed together with the static type checker. And in fact, Yuka had first invented a different syntax that wasn't quite compatible with Python. And Yuka and I sort of met at the Python conference in, I think, in 2013. And 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.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  4. “And in most cases, doing it. Statically before you ship your code to production. More efficient than doing it at runtime piecemeal.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

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

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  6. “They're mostly associated with the function object, not with each individual variable, but you can sort of map from the arguments to the variables.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  7. “Seems like a tricky thing. But 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, They mean Python is very introspectible language. You can look at a variable and ask yourself, what is the type of this variable? And if 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.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  8. “Provide hints because we can still say, well, the source code leads us to believe that these x and y are both integers. And so we can generate an add integer instruction. But we can still have a fallback that says, oh, if somehow the 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.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  9. “It's like a linter That's definitely a development tool, but the type annotations currently are not used for speeding up the interpreter. And there are a number of reasons many people don't use them, even when they do use them. they sometimes contain lies where the static type checker says everything's fine 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. And some Python programs wouldn't even be possible because they're too dynamic. And so we made a choice of not using the annotations. There is a possible future where eventually... Three, four, five releases in the future. We could start using those annotations to sort of”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  10. “But exactly. 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”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  11. “It is more than documentation. I mean, so it. It is a sub language of Python 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.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  12. “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.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  13. “Make the interpretation more efficient without losing the super dynamic nature of the language. That's always the challenge.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  14. “This is a trick that is especially important for interpreted languages with dynamic typing because if The compiler could read in the source. These X and Y that we're adding are integers, the compiler can just insert the single add machine code that Hardware, machine instruction that exists on every CPU and ditto for floats. But because in Python you don't generally declare the types of your variables. You don't even declare the existence of your variables. They just spring into existence when you first assign them, which is really cool and sort of helps those beginners because there is less bookkeeping they have to learn how to do before they can start playing around with code. But it makes the interpretation of the code less efficient. And so we're sort of. Trying to”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  15. “Python is not the first language to do with a thing like this. This is a fairly well known trick, especially from. Other interpreted languages that had reason to be sped up. We occasionally look at papers about HHVM, which is for Facebook's. Efficient compiler for PHP. There are tricks known from the JVM and sometimes it just comes from academia.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  16. “Hoping that most of the time we guess right because if it turns out that we guessed wrong too often or we didn't have a good guess at all, things might actually end up running a little slower. So someone armed with this knowledge and a copy of the implementation, someone could easily construct a counter example where they say, oh, I have a program and now it runs five times as slow in Python 3.11 than it did in Python 3.10. That's a very unrealistic program. That's just an extreme fluke.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  17. “And so what we actually have to do is when we have the add integer operation, We still have to check are the two arguments in fact integers. We applied some tricks to make those checks efficient. And we know statistically that the outcome is almost always, yes, they are both integers. And so we quickly make that check, and then we proceed with the sort of add integer operation. And then there is a fallback mechanism where we say, oops, one of them wasn't an integer. Now we're going to pretend that there was just the fully generic add operation. We wasted a few cycles believing it was going to be two integers and then we had to back up. But we didn't waste that much time and statistically most of the time. Basically, we're sort of”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  18. “We say, oh, so this ad operation, even though it's the generic ad operation, it might as well be the add integer operation. And the add integer operation is much more efficient because it just says assume that A and B are integers, do the addition operation, do it right there in line. Produce the result And the big lie here is that in Python, even if you have great evidence that in the past it was always two integers that you were adding, at some point in the future, that same line of code could still be hit with two floating points or two strings or maybe a string and an integer”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  19. “And so what we do is instead of having this single bytecode that says, here's an add operation and the implementation of add is fully generic. It looks at the object from the object. It looks at the type. Then it takes the type and it looks up the function pointer. Then it calls the function. Now the function has to be has to look at the other argument and has to double check that the other argument has the right type. And then there's a bunch of error checking before it can actually just go ahead and add the two bit patterns in the right way. What we do is Every time we execute an add instruction like that, we keep a little note of In the end, after we hit the code that did the addition for a particular type, what type was it? And then after a few times through that code, if it's the same type all the time.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  20. “Optimization is the observation that In a particular line of code. So now you write your little Python program and you write a function and that function sort of takes a bunch of inputs and at some point it adds two of the inputs together. Now, I bet you, even if you call your function a thousand times, that all those calls are likely all going to be about integers, because maybe your program is all about integers, or maybe your On that particular line of code where there's that plus operator, Every time the program hits that line, the variables A and B that are being added together happen to be strings.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  21. “Function interprets the same bit pattern as a floating point number. And then there is the string data type, which again interprets the bit pattern as the address of a sequence of characters. There are lots of lies in that story, but that's sort of a basic idea.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  22. “The operator is more like It's an index in a list of functions that the integer type defines. And so the integer type Is really a collection of functions, and there is an add function, and there's a multiply function, and there are like 30 other functions for other operations. There's a power function, for example. And you can imagine that in memory there is a distinct slot for the ad operations. Let's say the ad operation is the first operation of a type and the multiply is the second operation of a type. So now we take the integer type and we take the floating point type. In both cases, the ad operation is the first slot and multiply is the second slot. Each slot contains a function and the functions are different because the add to integers function interprets the bit patterns as integers, the add to float.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  23. “Is the type of that object, and does that object type define an add operation? And so you can imagine that there is a sort of a type integer that knows how to add itself to another integer. And there is a type floating point number that knows how to add itself to another floating point number. integers and floating point numbers are sort of important. I think mostly historically because in the first computers Use the sort of the same bit pattern when interpreted as a floating point number had a very different value than when interpreted as an integer.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  24. “A certain category of functions can be written using a single symbol, the plus sign. And sort of a bunch of other functions can be written using another single symbol, the multiply sign. So, if we take addition, the way traditionally in Python, the add bytecode was executed is Pointers, pointers, and more pointers. So first we have two objects. An object is basically a pointer to a bunch of memory that contains more pointers. Well, not quite, but there are a lot of them. Simplify a bit, we look up in one of the objects.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  25. “Well, let me first talk about the specializing part because the adaptive part is the sort of. The second order effect, but they're both important. So bytecode is a bunch of machine instructions, but it's an imaginary machine. But the machine can do things like call a function, add two numbers, print a value. Those are sort of typical instructions in Python. And if we take the example of adding two numbers, actually in Python the language, there's no such thing as adding two numbers. There's just the compiler doesn't know that you're adding two numbers. You might as well be adding two strings or two lists. Or two instances of some user defined class that happened to implement this operator called add. That's a very interesting and fairly powerful mathematical concept. It's mostly a user interface trick because it means that”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  26. “We changed some parts of the bytecode, but not very much. And so we only had to change the parts of the compiler where we decided that the breakdown of a Python program in bytecode instructions had to be slightly different. Death didn't gain us the performance improvements. The performance improvements were like making the interpreter faster in part by sort of. Removing the fat from some internal data structures used by the interpreter. The key idea is an adaptive specializing interpreter.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  27. “That is a thing from the Java world, although it's now applied to almost all programming languages, especially interpreted ones.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  28. “It is the code that is digested by the interpreter. That's the compiler. We tweaked very minor bits of the compiler. Almost all the work was done in the interpreter. When you have a program, you compile it once and then you run the code a whole bunch of times. Or maybe there's one function in the code that gets run many times. Now, I know that sort of people who know this field are expecting me to at some point say, we built a just-in-time compiler, actually we didn't. We just made the interpreter a little more efficient”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  29. “Yeah. Stupid. Python is actually, even though it's always called an interpreted language, there's also a compiler in there. It just doesn't compile to machine code. It compiles to bytecode, which is sort of code for an imaginary computer that is called the Python interpreter.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  30. “We focused A few areas where we still felt there was low hanging fruit. The biggest one is actually the interpreter itself. And this has to do with details of how Python is defined. So I don't know if the fisherman is going to follow this story here.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  31. “Interpreter basically, it's sort of a recipe for understanding recipes. So instead of a recipe that says bake me a cake, we have a recipe for. Well, given the text of a program, How do we run that program? And that is sort of the recipe for building a computer.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  32. “In many cases, the simplest way I could solve a particular sub problem because when you're designing and implementing a language, you have to have many hundreds of little problems to solve. And you have to have solutions for every one of them before you can sort of say, I've invented a programming language.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  33. “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, even if it's not the best solution, not the fastest or the most memory efficient or whatever. A simple solution and simple is fairly subjective, but mathematicians have also thought about sort of what is a good definition for simple in the case of algorithms. But 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 started with Python, I was a good programmer in general. I knew sort of basic data structures and knew the C language pretty well. But there were many areas where I Only somewhat familiar with the state of the art. And so I picked”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  34. “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 3 5 7 11 and so now you sort of reduced your search pace by 50% again 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, 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 square root? And before you get to a better algorithm than that, You have to have several PhDs in discrete math. So that's as much as I know.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  35. “So, if you know basically nothing about prime numbers except the definition, maybe you go for x from 2 through n minus 1 is n divisible by x. And then at the end, if you got all nos 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. And the second is you can also stop iterating when you have reached The square root of n because you know that if it has a divisor larger than the square root, it must also have a divisor smaller than the square root. 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.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  36. “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 2, so there we stop, but say 11. It's divisible by 10. The answer is no, 10 times in a row. So now we know 11 is a prime number. 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 4 or is it divisible by 5? All you have to check in the case of 11 is is it divisible by 2, is it divisible by 3? Take It's divisible by four, well, 12 divided by 4 is 3, so you should have come across the question, is it divisible by 3 first?”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  37. “That can be simple looking code. It's easy to understand. It's easy to reason about that you can tell quickly that it's correct, at least in the sort of mathematical sense of correct. Because it's implemented in C, maybe it performs relatively well. But over time, as sort of 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 classic example is computing prime numbers. Is 10 a prime number?”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  38. “Has to do with simplicity of software versus performance. 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, When I originally started Python or C Python, I didn't expect there would be Great success and fame in my future. So I I try to get something working and useful. In about three months And so I sort of cut corners. I borrowed ideas left and right when it comes to language design as well as implementation. I also wrote much of the code as simple as it could be. 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. And every time you get presented with new input, you do the whole computation from the top.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  39. “Everything is very subjective, and yes, you most certainly can have a gut feeling, and your gut can also be wrong. That's why there are billions of people, because they're not all right. I mean, clearly there are more people living in the Bay Area who have plans to sort of create a Google-sized company, then there's room in the world for Google-sized companies. And they're going to have to duke it out in the market space.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  40. “But can you create that spreadsheet? Because that's sort of you're mentioning a whole bunch of inputs that go into that spreadsheet where you have to estimate things that are very hard to measure and even harder. I mean, they're hard to measure retroactively and they're even harder to predict. Like what is the better community? Well, better is one of those incredibly difficult words. What's better for you is not better for someone else.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  41. “Where you're trying to estimate, well, if I learn this language, I expect to make X million dollars in a lifetime. And if I learn that language, I expect to make Y million dollars in a lifetime, which is higher and which has more risk and where is the chance that it's like picking a stock.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  42. “And there's not a single answer, right? Because depending on how much time you have to learn new stuff, where you are in your life, what you're currently working on, who you want to work with, what communities you like. There's not one right choice. Maybe if you sort of You can look back 20 years, you can say, well, that whole detour through action script was a waste of time. Nobody could know that. So you can't beat yourself up over that. You just need to accept that not every choice you make is going to be perfect. Maybe sort of keep plan B in the back of your mind. But don't overthink it. Don't try to, don't. Don't create a spreadsheet with like.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  43. “It's also still evolving quite a bit. I mean, That is not a sort of fossilizing community. They are doing great innovative work, actually. But their innovations are hard to follow if you're not already a hardcore C user.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  44. “I mean, if at age sixteen 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 in sort of your observation 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 technology is now so ubiquitous, of course, that it's even if it's bound to die, it's going to take a very long time.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

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

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  46. “That's why we start when we're young, right? But that seems very true to me that when you're young, you have your whole life ahead of you and you're allowed to make mistakes. In fact, you should feel encouraged to do a bit of stupid stuff. Try not to get yourself killed or seriously maimed, but try stuff that deviates from what everybody else is doing. And like nine out of ten times, you'll just learn why everybody else is not doing that or why everybody else is doing it some other way One out of ten times you sort of You discover something that's better or that somehow works. I mean, there are all sorts of crazy things that were invented. By accident, by people trying stuff together.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  47. “What you learned, the skill you picked up Learning ActionScript. Was sort of perhaps a super valuable skill at the time you picked it up. If you learned ActionScript early enough. That's kill is no longer in demand”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  48. “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 sort of get started. There wouldn't be jet planes without propeller planes, I bet you.”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  49. “Well, you know, in most cases like that, the particular technology eventually gets replaced 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 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 Was a somewhat better way to do animations, but those animations are still there. Not all of them, but sort of...”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source

  50. “What do you do if you're ever not with your own keyboard and you have to use someone else's PC keyboard that has a standard layout?”

    2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source