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

“Yeah, there are a couple of possible futures there. The most likely future is that we'll get multiple subinterpreters, which each run a completely independent Python program.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And that's sort of the moment that the gill became infamous. Because the guild was the solution we used to sort of This single interpreter and share it between all the different operating system threads that you could create. And so as long as the hardware physically only had one CPU, that was all fine. And then as hardware vendors were suddenly telling us all, oh, you got to paralyze. Everything's got to be paralyzed. People started saying, oh, but we can use multiple threads in Python and then they discovered, oh, but actually all threads run on a single core.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“The whole idea of multiple threads in the OS was that even if your computer only had one CPU, you could still fire up at many threads as you wanted, well, within Reason, maybe 10 or 12, not 5,000. And so we thought we had conquered the The abstraction of threads pretty well because multi-core CPUs were not in most Python programmers' hands anyway. And then, of course, a couple of more iterations of Moore's law and computers getting faster. And at some point, the chip designers decided that they couldn't make the CPUs faster, but they could still make them smaller. And so they could put multiple CPUs on one chip. And suddenly there was all this pressure about do things in parallel. And that's where the solution we had in Python didn't work.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“But the nice thing was, if you were using sockets from Python, then all the things you can do wrong with sockets in C would automatically give you a clear error message instead of just ending up with a malfunctioning hanging program. And so we thought, well, we'll do the same thing with threading. But we didn't really want to rewrite the interpreter to be thread safe because that was Would be Because all the objects were written with the assumption that there's only one thread. And so we said, okay, well, we'll take our losses, we'll provide something that looks like threads. And as long as you only have a single CPU on your computer, which most computers at the time did, it feels just like threads because”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“We thought, and maybe we were wrong, but at the time we thought, well, we quickly want to be able to support these multiple threads because they seemed at the time in the early 90s when they were new, at least to me. They seemed a cool, interesting programming paradigm. And one of the things that Python at least at the time felt was nice about the language was that we could give a safe version of all kinds of cool new operating system toys to the Python programmer. Like I remember One or two years before threading, I had spent some time adding networking sockets. To Python, and they were very literal translation of the networking sockets that were in the BSD operating system, so Unix BSD.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And if you don't have enough CPUs, the operating system sort of simulates those extra CPUs. On the other hand, if you have enough CPUs, you can get a lot of work done by deploying those multiple CPUs. But Python wasn't written to do that. And so As libraries for multi threading were added to C, but every operating system then there was adding their own version of that.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Global interpreter Solves the problem that Python originally was not written with either asynchronous or parallelism in mind at all. There was no concurrency in the language. There was no parallelism. There were no threads. Only a small number of years into Python's initial development, all the new cool operating systems like SonOS and Silicon Graphics, IRIX, and then eventually POSIX and Windows all came with threading libraries that let you do multiple things in parallel. And there is a certain sort of principle, which is the operating system handles the threads for you. And the program can pretend that there are as many CPUs as there are threads in the program. And those CPUs were completely independently.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And that leads to a certain style of spaghetti code that I find sort of aesthetically. Not pleasing, and I was sort of never very successful, and I had heard many stories about people who were also. Sort of complaining about that style of coding. It was very prevalent in JavaScript at the time at least because it was like how the JavaScript event loop. Basically, it works. And so I thought, well, the task based model where each task has a bunch of logic, we had mechanisms in the Python language that we could easily reuse for that. And I thought, I want to build a whole library for asynchronous networking IO. And all the other things that may need to be done asynchronously. Based on that paradigm. And so I just chose a paradigm and tried to see how far I could get with that. And it turns out that it's a good paradigm.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“A packet comes in, I sort of look at the number of the pack, there's some number on the packet and I say, oh, that packet goes on this pile and then I can do a little bit. And then sort of that pile provides my context. And as soon as I'm done with the processing, I sort of can forget everything about what's going on because the next packet will come in from some random other client and it's that pile or it's this pile. And every time a pile is maybe empty or full or whatever the criteria is, I can toss it away or use it for a new space. Several traditional third party libraries for asynchronous I.O. processing in Python chose the model of a callback. And that's the idea where you have a bunch of different stacks of paper in front of you. And every time someone gives you a piece gives you new sheet, you decide which stack it belongs to.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“But a tasking async or a thread in other contexts is devoted to one thing, and it has logic for all the stages, like when it's a web request, like first, wait for the first line of the web request, parse it because then you know if it's a get or a post or a put or whatever or an error. Then wait until you have a bunch of lines until there's a blank line, then parse that as headers, and then interpret that and then wait for the rest of the data to come in if there is any more that you expect, that sort of standard web stuff. And the other thing is, and there's always endless debate about which approach is more efficient and which approach is more error prone, where I just have a whole bunch of stacks in front of me and Whenever”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Looking at this web connection, and I'm just blocked until something comes in and then I'm already waiting for it. I get the data, I process the data, and then I go back to the top and say, no, sort of, I'm waiting for the next packet. Those are about the two paradigms. One is a paradigm where there is sort of notionally a threat of control, whether it's an actual operating system thread or more an abstraction in async.io, we call them tasks.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“There are a couple of different ways you can handle parallel I.O. And this happens sort of at an architectural level in operating systems as well. Like Windows prefers to do it one way and Unix prefers to do it the other way. You sort of Have an object that represents a network endpoint, say a connection with a web browser that your client. And say you're waiting for an incoming request. Two fundamental approaches are Okay, I'm waiting for an incoming request. I'm doing something else. Come wake me up or sort of come tell me when something interesting happened. Like a packet came in on that network connection. And the other paradigm is. We're on a team of a whole bunch of people with maybe a little mind and we can only manage one web connection at a time. Just sitting”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“The time I was very much involved with that, I was like the lead architect I ended up talking to people who had already developed serious third-party libraries that did similar things and sort of taking ideas from them Getting their feedback on my design and eventually we put it in the standard library and after a few years I got distracted. I think the thing, the big thing that distracted me was actually type annotations But other people kept it alive and kicking, and it's been quite successful actually in the world of Python web clients.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“When someone for the umpteenth time actually said these async chat and async core modules that you have in the standard library are not quite enough to solve my particular problem, can we add one tiny little feature? And everybody said, no, that stuff is not to, but you're not supposed to use that stuff. Write your own using third-party library and then everybody started a debate about what the right third-party library was. And somehow I felt that there was actually a queue for, well, maybe we need better state of the art. Module in the standard library for multiplexing input output from different sources. You could say that it spiraled out of control a little bit. It was at the time it was the largest Python enhancement proposal that was ever proposed.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, like when you're writing a web server, when a request comes in, a user sort of needs to see a particular web page. You have to find that page maybe in the database and format it properly and send it back to the client. There's a lot of waiting, waiting for the database, waiting for the network, and so you can handle hundreds or thousands or millions of requests. Concurrently on one machine anyway, ways of doing that in Python were kind of stagnated. Forget there might have been around 12, 2014.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, yeah, so we had this really old library for doing things Concurrently, especially things that had to do with I.O. and networking I.O. was especially sort of a popular topic. In the Python standard library, we had a brief period where there was lots of development. And I think it was late 90s, maybe early 2000s. Little modules were added that were the state of the art of doing asynchronous IO or sort of non blocking IO, which means that you can keep multiple network connections open and sort of service them all in parallel, like a typical web server does.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“If you see an oven that's not in use, it's already reserved for someone else who got in line first. And that's sort of what the restaurant metaphor was trying to explain”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“That's not a bad idea because if you're preparing, if you're baking cakes and you have multiple people all baking cakes, but there's only one oven. Then maybe you can tell that the oven is in use, but maybe it's preheating. And so you make a sign that says oven in use. And you flip the sign over and it says often is free when you're done baking your cake. And that's a lock. That's sort of, and what do you do when you have two ovens or maybe you have 10 ovens? You can put a separate sign on each oven, or maybe you can sort of someone who comes in wants to see at a glance, and maybe there's an electronic sign that says there are still five ovens available. Or maybe they're already three people waiting for an oven, so you can't.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And you think you're smart and you'll put a lock around it. And in practice, in terms of bugs per lineup per 1,000 lines of code This is an area where everything is worse.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“You have to keep in your head what is in A, what is in B, what is in C. Hopefully you have better names. And that is challenging enough. If you have two different pieces of code that are sort of being executed Simultaneously, whether it's using the parallel or the concurrent approach, if like Is the number of fishermen and B is the number of programmers, but in another part of the code, A is the number of mermaids and B is the number of mermen. And somehow that's the same variable. If you do it sequentially, if first you do your mermaid computation and then you do your people in the boat computation, it doesn't matter that the variables are called A and B, and that is literally the same variable because you're done with one use of that variable. But when you mix them together, suddenly...”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“The programmer is, at least with the current state of the art, is responsible for writing the code correctly. And it's hard enough to keep track of a recipe that you just Execute one step at a time. Chop the carrots, then peel the potatoes, mix the icing. You need your whole brain when you're reading a piece of code what is going on. Okay, we're loading the number of mermaids in variable A and the number of men in variable B and now we take the average or whatever. I like how we're just”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Because at the conscious level, our brains are not trained to sort of keep track of multiple things at the same time. Like, obviously, you can walk and chew gum at the same time because they're both activities that require only a little bit of your conscious activity. But try balancing your checkbook and watching a murder mystery on TV. You'll mix up the digits or you'll miss an essential clue in the TV show.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“In the computer world, there is a big difference when people are talking about parallelism, like a parallel computer. That's usually really several complete CPUs that are sort of tied together and share something like memory or an IO bus. Concurrency can be a much more abstract concept where You have the illusion that things happen. Simultaneously, but what the computer actually does is it spends a little time running some this program for a while and then it spends some time running that program for a while and then spending some time for the third program for a while.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, the idea is if the fisherman has two fishing rods, Since fishing is mostly a matter of waiting for a fish to nibble, well, it depends on how you do it actually. But if you're doing the style of fishing where you sort of throw it out and then you let it sit for a while until maybe you see a nibble, one fisherman can easily run two or three or four fishing rods. And so as long as you can afford the equipment, you can catch four times as many fish by small investment in four fishing rods. And so since your time... Sort of say you have all Saturday to go fishing. If you can catch four times as much fish, you have a much higher productivity.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Was one of my rare Sort of more literary or poetic moments where I thought I'll just open with a crazy example. Catch your attention and the rest is very dry stuff about locks and semaphores and how semaphore is a generalization of a lock.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It sounds like you'd find places like that in Tokyo. It sounds like a very Japanese thing or in the Bay Area there are pop-up places that probably more or less work like that. I've never eaten at such a place.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And it's not part of Yeah, I remember that it might have been five years ago or so we were trying to get some better MyPy integration into PyCharm because MyPy is sort of Python tooling and PyCharm. Had its own. Checking heuristic thing that we wanted to replace with something based on MyPy, because that was what we were using in the company. And for the guy who was writing that PyCharm extension, it was really a struggle to sort of find documentation and get the development workflow going and debug his code and all that. So that was not a pleasant experience.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“They're usually actually just specializations of intelligent because underneath it's all the same editing engine with different. Veneer on top Where in VS Code, Many things you do. Require loading third party extensions in PyCharm, it is possible to have third-party extensions, but it is a struggle to create one.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Base engine that you have no control over. I mean, it's open source, but nobody except the people who work on that part. Changes it much and it has sort of a package manager and a whole series of interfaces for packages and an additional series of conventions for how packages should interact with the lower layers and with each other. And powerful primitive operations that let you. Move the cursor around or select pieces of text or delete pieces of text or interact with the keyboard and the mouse and whatever peripherals you have. And so the sort of extreme extensibility and the package ecosystem that you see in VS Code is a mirror of very similar architectural features in Emacs.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And that sort of new features of Emacs usually update all the list packages and add new list packages. And oh yeah, there's also some very obscure thing improved in the part that's not in Lisp, but that's usually not why you would upgrade to a new version of Emacs. There's a core implementation that sort of can read a file and it can put bits on the screen and it can sort of manage memory and buffers. And then what makes it an editor full of features is all the list packages. And of course, the design of how the list packages interact with each other and with that sort of that base layer of the core immutable engine. But almost everything in that core engine. An Emacs case can still be overridden or replaced. And so VS Code has a similar architecture where there is like”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I'm not going to stop you Think that sort of everybody has to decide for themselves which one they want to invest more time in. I actually Ended up giving VS code a very tentative try when I started out at Microsoft and really liking it And it sort of took me a while before I realized why that was. And I think that actually the founders of VS Code may not necessarily agree with me on this. But to me, VS code is in a sense the spiritual successor of Emacs. Because as you probably know as an old Emacs The key part of Emacs is that it's mostly written in Lisp.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Turns out that if you grab all 5 million lines of code, there are many classes with the same name. And so PyCharm sort of once you fired it up and once it's indexed your repository was very helpful. But the soon as I had to edit code, I would jump back to Emacs and do all my editing there because I could type much faster and switch between files when I knew which file I wanted much quicker. And I never really got used to the whole PyCharm user interface.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Historically, I actually started out with using Vim, but when it was still called VI. For a very long time, I think from the early 80s to Say two years ago Was Emacs user? Between, I'd say, 2013 and 2018. I dabbled with PyCharm, mostly because it had a couple of features. I mean, Is like deriving an 18 wheeler truck, whereas Emacs is more Like driving your comfortable Toyota car. That you've had for $100,000 and you know what every little rattle of the car means. I was very comfortable in Emacs, but there were certain things it couldn't do. It wasn't very good at sort of at least the way I had configured it. Didn't have very good tooling in Emacs for finding the definition of a function. When I was at Dropbox exploring a five million line Python code base, Just grapping all that code for where is there a class foobar?”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“I can't put a number on it, but from the number of packages that do interesting things with it at runtime and the fact that there are like now three or four very mature type checkers. That each have their segment of the market. And then there is PyCharm, which has a sort of more heuristic-based type checker that also supports the same syntax. My assumption is that Many, many people developing Python software professionally for some kind of production situation are using a static type checker, especially anybody who has a continuous integration cycle probably has a One of the steps in their testing routine that happens for basically every commit is run a static type checker. And in most cases, that will be myPy. So, I think it's a pretty popular topic.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And you see that everywhere, right? Because there's not one single JavaScript engine either. There is one in Chrome. There is one in Safari. There is one in Firefox.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Every month, every two months, certainly many times a year, some type checkers also include a bunch of experimental ideas that aren't official standard Python syntax yet. The static type checkers also just get better at discovering things that sort of are unspecified by the language, but that sort of could make sense. And so each static type checker actually has its sort of strong and weak points.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And worse, once we've all agreed that we are going to put some new syntax in, we can never take it back. At least sort of deprecating an existing feature takes many releases because you have to assume that people started using it as soon as we announced it. And then you can't take it away from them right away. You have to start telling them, well, this will go away, but we're not going to tell you that it's an error yet. And then later it's going to be a warning. And then eventually three releases in the future. Maybe we remove it. On the other hand, the typical static type checker. Still has a release like.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Nobody is currently excited about doing any work towards that. That doesn't mean that five or ten years from now the situation isn't different. At the moment, Aesthetic type checkers Still evolve at a much higher speed than Python and its annotation syntax evolve. You get a new release of Python once a year. Those are the only times that you can introduce new annotation syntax. And there are always people who invent new annotation syntax that they're trying to push.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Correct. Yeah, all my word processors tend to typo correct that as pyrite, the name of the, I don't know what it is. Some kind of semi precious metal”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, there is definitely that. But the best Not so much to sort of enforce team uniformity, but to actually help developers. Catch bugs that the compilers for whatever reason don't catch. And there is lots of that in Python. But a static type checker focuses on a particular aspect of the linting, which, I mean, MyPy doesn't care how you name your classes and variables, but it is meticulous about when you say that there was an integer here and you're passing a string there, it will tell you, hey, that string is not an integer. So something's wrong either. Either you were incorrect when you said it was an integer or you're incorrect when you're passing it to string.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Things like definition of names, use of names, it'll tell you likely things that are wrong. And in some cases, linters are really style checkers. For Python, there are a number of linters that check things like, do you use the PEP8 recommended naming scheme for your functions and classes and variables? Because classes start with an uppercase and the rest starts with a lowercase. Like differences there. And so the linter can tell you, hey, you have a class that whose first letter is not an uppercase letter. And that's just, I just find it annoying if I wanted that to be an uppercase letter. I would have typed an uppercase letter, but other people find it very comforting that if the linter is no longer complaining about their code that they have followed all the style rules.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Linters often do static analysis where they try to point out things that are likely mistakes but not Incorrect according to the language specification. Like maybe you have a variable that you never use. For the compiler that is valid, you might be planning to use it in a future version of the code and the compiler might just optimize it out. But the compiler is not going to tell you, hey, you're never using this variable. A linter will tell you that variable is not used. Maybe there's a typo somewhere else where you meant to use it, but you accidentally use something else or there are a number of sort of common scenarios. And a linter is often A big collection of little heuristics. By looking at the combination of how your code is laid out, maybe how it's indented, maybe the comment structure, but also just”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Facebook wrote their version and they worked on it in secret for about a year and then they came clean and went open source. Google in the meantime was developing something called PyType, which was mostly Interesting because as you may have heard, they have one gigantic monorepo. All the code is checked into a single repository. Facebook has a different approach. So Facebook developed Pyre. Which was written in OCamel, which worked well with Facebook's development workflow Google developed something they called PyType, which was actually itself written in Python. And it was meant to sort of fit well. Dare static type checking needs in Google's gigantic monorepo.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Making myPy faster, say, or adding new features to MyPy, but both Google and Facebook and later Microsoft develop their own static type checker. I think Facebook was one of the first they decided that they wanted to use the same technology that they had successfully used for HHVM. Because they sort of, they had a bunch of compiler writers and sort of static type checking experts who had written the HHVM compiler and it was big success within the company. And they had done it in a certain way, sort of. Wrote a big, highly parallel application in an obscure language named OCamel, which is apparently mostly very good for writing static type checkers.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“MyPy was the original static type checker. So MyPy quickly evolved from Yuka's own variant of Python to a static type checker for Python and sort of PEP484, that was it like. Very productive year where many hundreds of messages were exchanged debating the merits of every aspect of that PEP. And so MyPy is a static type checker for Python. It is itself written in Python. Most additional static typing features that we introduced in the time since 3.6. We're also prototyped through MyPy. Mipi being an open source project with a very small number of maintainers. Was successful enough that people said this static type checking stuff for Python is actually worth an investment for our company. But somehow they chose not to support”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It's very different culture and to some extent differences in culture are random, but to some extent the differences have to do with the environment. And the fact that JavaScript is primarily The language for developing web applications, especially the client side, and the fact that it's basically the only language for developing web applications makes that community sort of just have a different nature than the community of other languages”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“It's an enormously helpful extra tool that helps you sort of. Keep your head straight about what your code is actually doing I mean, it helps with editing your code. It helps with ensuring that your code Is not too incorrect. And it's actually. Quite compatible with JavaScript, never mind this syntactic sort of hack that is still years in the future. But any library that is written in pure JavaScript can still be used from TypeScript programs. And also the other way around, you can write a library in TypeScript and then export it in a form that is totally consumable by JavaScript. That's sort of compatibility is sort of the key to the success of TypeScript.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“And you could shove it directly into JavaScript interpreter without transpilation. The interesting thing in the JavaScript world, at least the web browser world, the web browsers have changed how they deploy and they sort of update their JavaScript engines much more quickly than they used to in the early days. And so there's much less of a need for translation in JavaScript itself because most browsers just support the most recent version of ECMA script.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“That's right. At the same time, an interesting development in the JavaScript slash TypeScript world at the moment is that there is a proposal under consideration. It's only a stage one proposal that proposes to add a feature to JavaScript where just like Python, it will ignore certain syntax. When running the JavaScript code and what it ignores is more or less a superset of the TypeScript annotation syntax. So that would mean that eventually if you wanted to, you could take TypeScript.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, in the JavaScript world, transpilers are sort of the standard way of working anyway, which is why TypeScript being a transpiler itself is not a big deal.”
2022-11-26 · Lex Fridman Podcast · #341 – Guido van Rossum: Python and the Future of Programming · IDENTIFIED FROM THE TRANSCRIPT · source