├── README.md ├── VTT-creator-notes.txt ├── language-creators chopped copy.txt ├── language-creators.txt ├── language-creators.vtt ├── otter └── language-creators.txt ├── redpencil ├── language-creators.docx └── language-creators.txt └── trint ├── language-creators.csv ├── language-creators.docx ├── language-creators.srt ├── language-creators.txt └── language-creators.vtt /README.md: -------------------------------------------------------------------------------- 1 | # A Language Creators' Conversation 2 | 3 | Transcripts for "A Language Creators' Conversation: Guido van Rossum, James Gosling, Larry Wall & Anders Hejlsberg" 4 | 5 | * original video: https://www.youtube.com/watch?v=csL8DLXGNlU&t=48m29s 6 | * edited to skip 48'29" of opening remarks: https://www.youtube.com/watch?v=sBVYn0cIlWM 7 | 8 | Transcripts in the `redpencil/`, `otter/` and `trint/` folders are unedited. 9 | The files are exactly as received or exported from the applications. 10 | 11 | 12 | ## Professional transcription 13 | 14 | Tanscript produced by Ellie Leonard of 15 | [Red Pencil Transcripts LLC](http://www.redpenciltranscripts.com/), 16 | hired by Luciano Ramalho. 17 | 18 | Timestamps for these transcripts follow the [original video](https://www.youtube.com/watch?v=csL8DLXGNlU&t=48m29s), starting at 48'29". 19 | 20 | * revised transcript (work in progress): [`language-creators.txt`](https://github.com/standupdev/language-creators/blob/master/language-creators.txt) 21 | 22 | Received transcript: 23 | 24 | * Word document: [`redpencil/language-creators.docx`](https://github.com/standupdev/language-creators/blob/master/redpencil/language-creators.docx) 25 | * plain text (from `.docx`): [`redpencil/language-creators.txt`](https://github.com/standupdev/language-creators/blob/master/redpencil/language-creators.txt) 26 | 27 | 28 | ## Automatic transcriptions 29 | 30 | Timestamps for these transcripts follow the [edited video](https://www.youtube.com/watch?v=sBVYn0cIlWM). 31 | 32 | ### By [Otter.ai](https://otter.ai/) 33 | 34 | * plain text: [`otter/language-creators.txt`](https://github.com/standupdev/language-creators/blob/master/otter/language-creators.txt) 35 | 36 | ### By [Trint](https://trint.com/) 37 | 38 | * Word document: [`trint/language-creators.docx`](https://github.com/standupdev/language-creators/blob/master/trint/language-creators.docx) 39 | * plain text (from `.docx`): [`trint/language-creators.txt`](https://github.com/standupdev/language-creators/blob/master/trint/language-creators.txt) 40 | * full transcript: [`trint/language-creators.csv`](https://github.com/standupdev/language-creators/blob/master/trint/language-creators.csv) 41 | * SubRip universal subtitles: [`trint/language-creators.srt`](https://github.com/standupdev/language-creators/blob/master/trint/language-creators.srt) 42 | * Subtitles for HTML players: [`trint/language-creators.vtt`](https://github.com/standupdev/language-creators/blob/master/trint/language-creators.vtt) 43 | 44 | 45 | ## Reference 46 | 47 | _New York Times_ story where I learned about Ellie Leonard, Otter.ai, and Trint.com: 48 | 49 | > [**In the Battle Against the Machines, She’s Holding Her Ground**](https://www.nytimes.com/2020/04/08/technology/ai-transcription-human-services.html): Ellie Leonard’s transcription business has thrived, despite the arrival of automated services and advancing A.I. technology. 50 | -------------------------------------------------------------------------------- /VTT-creator-notes.txt: -------------------------------------------------------------------------------- 1 | Notes for filling in the language-creators VTT file 2 | 3 | MDN spec for VTT files is here: https://developer.mozilla.org/en-US/docs/Web/API/WebVTT_API 4 | 5 | The file we're filling in is based on trint/language-creators.vtt for the edited 6 | version of the video, which has none of the opening remarks material. That file is 7 | already properly formatted VTT, we mostly need to proofread and fill in some gaps. 8 | When this is complete, the complete video's VTT file can have the same process and 9 | a simple script can be run to ensure the proper numbering of the segments. 10 | 11 | The transcribed file has the entirety of the audio, therefore you will need 12 | to cross reference the start of your block of time. 13 | The first section the VTT's 00:00:00 is at 48:29 of the transcription 14 | BEGIN PART 2 in the VTT is at 51:55 which corresponds to 2:00:55 in the transcription. 15 | I have tried to leave useful markers in the file, using NOTE (see below). 16 | 17 | Key points: 18 | Always identify the speaker. There are six participants with crosstalk 19 | plus audience questions 20 | 21 | NOTE (all caps) can be used inline (as this line is) 22 | or it can be used for a block 23 | NOTE 24 | this is the first line of a block of notes 25 | this is the second line in a block of notes 26 | avoid special characters in notes 27 | see the MDN link above for specifics 28 | 29 | 30 | Proofreading notes: 31 | Each segment must be numbered and must use the fewest digits (e.g. 1 not 001) 32 | 33 | It is OK to remove segments from the VTT so long as the segment numbers remain in 34 | order, see example below. 35 | 36 | For consistency times must be in HH:MM:SS.TTT format as this file entends past an hour 37 | timestamps must be written completely as HH:MM:SS.TTT --> HH:MM:SS.TTT 38 | 39 | Times do not have to be contiguous 40 | 00:00:00.000 --> 00:00:03.00 41 | 00:00:09.050 --> 00:00:11.250 42 | skipping six seconds is fine 43 | 44 | However, leaving captions/subtitles on screen during silences allows the reader 45 | an opportunity to thoroughly read the text 46 | 47 | Two lines of text that use the center 50% of the screen is usually as much as a reader 48 | can handle in a few seconds. On the other hand short captions that flash in an 49 | instant can be disorienting and difficult to keep up with. 50 | 51 | For example: 52 | 53 | 1672 54 | 01:00:41.190 --> 01:00:42.190 55 | CAROL Yeah. 56 | 57 | 1673 58 | 01:00:42.380 --> 01:00:43.879 59 | [Participant 2] Great. There's been a lot of talk tonight 60 | 61 | 1674 62 | 01:00:43.880 --> 01:00:45.559 63 | [Participant 2] about the evolvability of 64 | 65 | 1675 66 | 01:00:45.560 --> 01:00:46.999 67 | [Participant 2] languages and 68 | 69 | Is probably more comfortable as: 70 | 71 | 1672 72 | 01:00:41.190 --> 01:00:43.879 73 | CAROL Yeah. 74 | 75 | [Participant 2] Great. There's been a lot of talk tonight 76 | 77 | 1674 78 | 01:00:43.880 --> 01:00:46.999 79 | [Participant 2] about the evolvability of 80 | languages and 81 | 82 | YouTube keyboard commands 83 | SPACE un/pauses 84 | ARROW LEFT/RIGHT back and forward 5 seconds 85 | COMMA (,) back 1/30th second* 86 | PERION (.) forward 1/30th second* 87 | 88 | * these two are useful when you're within the five seconds you're trying to 89 | confirm. Holding them will let you pan through the video in very slow motion 90 | -------------------------------------------------------------------------------- /redpencil/language-creators.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/fluentpython/language-creators/c1cad634eeb5e74bfd1fd34685fb80d84e799b0f/redpencil/language-creators.docx -------------------------------------------------------------------------------- /redpencil/language-creators.txt: -------------------------------------------------------------------------------- 1 | LUCIANO RAMALHO 2 | LANGUAGE-CREATORS.MP4 3 | 4 | 5 | START (LANGUAGE-CREATORS.MP4) 6 | 7 | [BEGIN PART I] 8 | 9 | [0:48:29] 10 | 11 | MC: Okay, are you guys ready for some language creators? 12 | 13 | [APPLAUSE/CHEERING] 14 | 15 | MC: Okay. Without further ado I will introduce Carol Willing. She is a Python steering council and Project Jupyter steering council member. She blends the strengths of Python and Jupyter Notebooks to improve access to learning and education. Due to the worldwide foundation of the Python language, the hard work of the Jupyter team, and users worldwide, Carol was awarded the 2017 ACM Software System Award, recognizing the lasting influence... 16 | 17 | [0:49:00] 18 | 19 | MC: ...of Jupyter (at broad) collaboration to develop open-source tools for interactive computing with a language agnostic design. Thank you. 20 | 21 | [APPLAUSE] 22 | 23 | CAROL: Okay. First, welcome everybody for being here. It is my absolute pleasure to share this evening with you and some of the people that actually influenced my career in software development. So let's get through this. And for those of you that are watching us on the livestream, hello and welcome, and we hope you have a wonderful evening with us. We have a really distinguished panel of language creators, and I'd like to invite them to the stage as they read their bios. I'm going to keep the bios really short because I think most of them need no introduction whatsoever. And that'll save us some time for more juicy language design stuff. 24 | 25 | [0:50:00] 26 | 27 | CAROL: Okay. So first we have Guido Van Rossum, who developed the Python language that touches pretty much every corner of society today in some way. And [CROSSTALK]... 28 | 29 | [APPLAUSE/CHEERS] 30 | 31 | CAROL: James Gosling, who's the creator of Java, which is used across a wide variety of devices and deployments at scale. Welcome and please join us. 32 | 33 | [APPLAUSE] 34 | 35 | CAROL: Anders Hejlsberg, who has architected a number of languages over the past several decades, including Turbo Pascal, Delphi, C#, and some of you might know this little language, TypeScript. 36 | 37 | [APPLAUSE/CHEERS] 38 | 39 | CAROL: And last but certainly not least, Larry Wall, who combined his unique... 40 | 41 | [0:51:00] 42 | 43 | CAROL: ...perspective on text and computing with his strong background in linguistics to create Perl and its sister-sibling, Perl 6. Welcome. 44 | 45 | [APPLAUSE/CHEERS] 46 | 47 | CAROL: Okay. So just a couple housekeeping things about this evening's format, you're in for an engaging and hopefully very lively discussion, more lively than we were at dinner. I think that's possible, right? Okay. "The format... 48 | 49 | JAMES: I would need more beer. 50 | 51 | [LAUGHTER] 52 | 53 | CAROL: More beer? Okay, we can do that. Keep it coming. Okay, so the format will be two sessions with a 15-minute intermission. What I'll do is I will start by asking one of the panelists a question, and hopefully the response will be, like, one to two minutes. And then we'll kind of throw it open for other panelists to respond... 54 | 55 | [0:52:00] 56 | 57 | CAROL: ...and hopefully get a really good discussion going. And the more discuss the less I have to ask questions, and the more in-depth we can go on the really cool stuff. After the 15-minute intermission we're going to take questions from the audience over a... 58 | 59 | WOMAN: Twitter. 60 | 61 | CAROL: Twitter, okay. So tweet out your questions. Hashtag is #puppyBDFL. And if you can get those in by 8:00 we'll kind of collate them and have some really great audience questions about language creation and language design. So I am going to invite you to sit back, enjoy a cup of strong Java, C# responses and insights, learn Perls of wisdom, and embrace the Python programming (zen). 62 | 63 | [APPLAUSE/CHEERS] 64 | 65 | CAROL: So enough of my bad puns. 66 | 67 | [0:53:00] 68 | 69 | CAROL: Let's get this thing started, and we'll start the celebration with a question for Guido about the principles of language design. Guido, you've mentioned before--perhaps somewhat jokingly--the Harry Potter theory of language design. What is this theory, and what do you see as the key principles of language design? 70 | 71 | [BACKGROUND CONVERSATION] 72 | 73 | GUIDO: Am I good? Okay. The Harry Potter theory of language design was a blog post I once wrote where I didn't know what - I cannot believe that every little detail that J.K. Rowling put in the first Harry Potter book was intended as some important plot point in part six or seven or (eight) maybe. And even... 74 | 75 | [0:54:00] 76 | 77 | GUIDO: ...if J.K. Rowling was such a genius that she had it actually all planned out who the pet rat was, who I think we found in book three was actually a wizard in disguise. But in book one it was just, like, a temporary diversion during the train ride, and otherwise you didn't hear much about the rat with the finger missing. In language design often that's exactly how things go. You choose some detail because you have to commit. You sort of - you have to pick key words, you have to choose a style of coding. Like, maybe you choose indentation instead of curly (inaudible)... 78 | 79 | LARRY: Or maybe you don't. 80 | 81 | [LAUGHTER] 82 | 83 | GUIDO: You're a special case. 84 | 85 | [LAUGHTER] 86 | 87 | GUIDO: But whatever you do, in some way you're stuck... 88 | 89 | [0:55:00] 90 | 91 | GUIDO: ...with that. And you find new uses of that detail that you picked before you knew how important it would be. And sort of the craft of designing a language is on the one hand pick your initial set of choices so that there are a lot of possible continuations of the story. The other half of the art of language design is going back to your story and inventing creative ways of continuing it in a way that you had not anticipated. 92 | 93 | CAROL: So I think each of you have languages that have spanned multiple decades. So what were some of the principles that maybe you (dealt with)? 94 | 95 | JAMES: You know, so Java was sort of odd in that it didn't come out of... 96 | 97 | [0:56:00] 98 | 99 | JAMES: ...like, a personal passion project or something. It was from trying to build a prototype. You know, I mean, we were trying to understand a particular (domain), (inaudible) (embedded systems). And spent a lot of time talking to people who build software for embedded systems and trying - you know, spent a lot of time trying to understand (inaudible) and, you know, what was it in the whole process for them, what was it in how things evolved (inaudible), how did their systems fit into the universe? Because it wasn't - you know, because I was trying to worry - we were worried about things outside of datacenters. And this was a project that had about a dozen people on it. And my little... 100 | 101 | CAROL: (It started)? 102 | 103 | JAMES: Yeah. But it was - my little... 104 | 105 | [0:57:00] 106 | 107 | JAMES: ...piece was sort of, like - you know, we sort of figured out that part of the problem was that C has issues. 108 | 109 | [LAUGHTER] 110 | 111 | JAMES: And so I started out - so out of this, like, large pie of a project my slice was to make things a little easier from a programming language point of view and fix the (pain) points that came from the programming language part. And it started out as kind of do a better C; and it got out of control. The rest of the project really ended up just providing context. You know, the only thing out of that project that survived was Java. 112 | 113 | [0:58:00] 114 | 115 | JAMES: But the fact that it was sort of directed at a set of (pain) points that happened to be, you know, about people who were living outside of datacenters, and people who were sort of getting shredded by problems with networking, and security, and reliability, and, you know, they had to build things that ran in hostile environments like in homes, which any home with a child in it is a hostile environment. 116 | 117 | [LAUGHTER] 118 | 119 | CAROL: Speaking of hostile environments, Perl [CROSSTALK/LAUGHTER]... What were some of the guiding principles for designing Perl? 120 | 121 | LARRY: (Inaudible) 122 | 123 | CAROL: I love you, Larry. 124 | 125 | LARRY: Yeah. [LAUGHTER] 126 | 127 | [0:59:00] 128 | 129 | LARRY: That helps. Originally Perl was designed more coming at it as a linguist than a computer scientist. So I sort of almost actively ignored some of the computer science literature at the time and said, well, what can we just throw together in one pot that will work more like a natural language, instead of a, you know, instead of putting in a campus - university campus and deciding where all the walkways were going. We were just going to see where people want to walk and then put shortcuts in all those places, and build it more as a network, not as a, you know, terribly orthogonal, or computer-(science-y), or mathematical thing. And that turned out to be in the right place at the right time for bootstrapping a lot of the web. And... 130 | 131 | [1:00:00] 132 | 133 | LARRY: ...it also got used a lot for system administration. And so various principles that relate to trying to provide APIs to everything, and trying to be both a good text processing language linguistically, but also a good (glue) language is why it was kind of very useful when the HTML is text and, you know, database (inaudible). That needs (glue). And someone was in the right place at the right time. We were very fortunate to have that timing because in the '90s it became very stable, a lot of widespread use. A lot of people were - you know, the language itself was stabilizing in the form that it was. But there were a lot of issues, and still are. And so in the year 2000 we took a step back and... 134 | 135 | [1:01:00] 136 | 137 | LARRY: ...basically said, "We're going to break everything that needs breaking." So we kind of did the same thing, you know, as the Python (2), the three step, except instead of breaking a few things, we decided to break everything that needed breaking. So we came up with a whole (inaudible) of design principles in the 15 years since then. By the way, Perl 6 did come out two years ago; it's getting faster. 138 | 139 | [CHEERS/APPLAUSE] 140 | 141 | LARRY: And, you know, at the beginning we said we were going to do something impossible and fail at it, but be a very interesting failure. And so far it is proving to be that. But in the course of [CROSSTALK] - yeah. In the course of that we came up with (some) really interesting list of about sixty different design principles. 142 | 143 | CAROL: Which he's going to read all of them right now. 144 | 145 | [CROSSTALK/LAUGHTER] 146 | 147 | LARRY: I'm not going to read - you know all of them - many of them already. You know, kill two birds with one stone, pick the right defaults, you know... There's lots like that. 148 | 149 | [1:02:00] 150 | 151 | LARRY: But we came up with some cute ones like, "You think that's cute today..." 152 | 153 | [LAUGHTER] 154 | 155 | CAROL: What about tomorrow? 156 | 157 | LARRY: Yeah. You know, "Conserve your brackets because ASCII - even Unicode does not have enough brackets." 158 | 159 | [LAUGHTER] 160 | 161 | LARRY: "And don't reinvent object orientation poorly, which (inaudible) did." No. "(If something's) too strong for (inaudible), late binding sometimes cause your programs to be late." 162 | 163 | [LAUGHTER] 164 | 165 | LARRY: Some of the major ones are - you know, like, a lot of the stuff is Perl(fied) to screw over time. And, you know, there were a lot of weird magical variables. I blame (Chico). And so a great deal of the redesign was just saying, "Okay, what is the right peg..." 166 | 167 | [1:03:00] 168 | 169 | LARRY: "...to hang everything on? Is it object-oriented? Is it something in the (lexical) scope, or in the larger scope, or...?" You know, "What is the right peg to hang each piece of information on? And if we don't have that peg how do we create it? 170 | 171 | CAROL: That's a great question. And since it's such a great question I'm going to put Anders on the spot. And Terence Parr had a quote about, "While programmers value simplicity, they more often value powerful functionality and amazing one-liners, incurring the cost of complexity. So... 172 | 173 | LARRY: Works for us. 174 | 175 | CAROL: (Inaudible) So what are your thoughts about simplicity versus complexity, and some of the principles that might guide you as you develop your languages? 176 | 177 | ANDERS: I suppose I was always, like, in doing the language... 178 | 179 | [1:04:00] 180 | 181 | ANDERS: ...design that I've done, always, like, tried to make it so that there was only one way to do a particular thing. You know, some - a lot of languages have four different ways of doing something, and you pick the wrong one and then only weeks later do you realize you went down the wrong branch, and now you've got to back up. And so - but it's not always easy, right? And I think there is, like, often we're guilty of creating what I call - this thing I call "simplexity," which is, like, you take something complex and then you wrap a simple wrapper on top of it that's (hoping to make) the complexity go away, but what you're really creating is (simplexity). You know, it's just, like, a bad abstraction on top of another bad abstraction that is (inaudible). So - I don't know. I mean, it's... 182 | 183 | LARRY: We think of that as picking the right default over the complex thing. 184 | 185 | ANDERS: Yeah, but, I mean... 186 | 187 | [1:05:00] 188 | 189 | ANDERS: ...the thing about that - about language design is, like, any decision you make you have to live with forever. I mean, and in languages you can always add but you can never take away. And so you've got to actually as a language designer be very judicious about reasoning over not so much what to put in, but what not to put in, you know what I mean? Because people come to you all the time, "Oh, wouldn't it be great if you could do this, if - that, or you could...?" Well, yeah, but you can't fundamentally change the nature of the beast. If you created an empirical - an imperative programming language you can't turn it into a functional programming language. I mean, you can borrow from functional programming, but it is what it is and you've got to stay true to the nature of the beast or you've got to create a new beast, so to speak. 190 | 191 | CAROL: Right. Great. Any other thoughts about...? 192 | 193 | GUIDO: Can we interrupt yet? 194 | 195 | CAROL: Excuse me? 196 | 197 | [1:06:00] 198 | 199 | GUIDO: Can we interrupt yet, or do you have more questions? 200 | 201 | CAROL: You can totally interrupt anytime. 202 | 203 | [LAUGHTER] 204 | 205 | GUIDO: So Anders' sort of point about what do you leave out - and what I remember in the early days of Python's design, there were so many people who thought they have a good idea. And I wasn't always sufficiently critical to say no. And so there are a few things that didn't work out, but at the time I hadn't learned to say no. Like, I quickly enough did learn to say no, and I sort of developed, like, several lines of the fence. Like, the first line of the fence is, Hey, you think you need a new language feature, but actually you can already write that from Python. 206 | 207 | [1:07:00] 208 | 209 | GUIDO: If you need it a lot, write a function or a module. Well, if they say, "Yeah, but everybody needs that..." Well, nowadays we say, "Put it on the package repository." In those days I said, "Well, maybe you can propose a new standard (inaudible) module." That's a lot cheaper for the language design than a new language feature. And another line of the fence was, "Well, you can actually write extensions in C or in Fortran if you really care to," and you can help yourself (that). You can modify the behavior of the language in ways that aren't accessible when you just write the pure language, but you can still sort of - you can extend it in a way that doesn't fundamentally alter the core language. And if you've tried all those things and you've failed, then maybe... 210 | 211 | [1:08:00] 212 | 213 | GUIDO: ...you could argue for, "Well, we have to change something in the core language." 214 | 215 | ANDERS: Yeah, I'll interrupt, too. I find that whenever I get feedback on whatever it is programming language I've been working on, it's - people come to you with a particular instance of a problem. And it's your job as a language designer to tease out the class of problem they're talking about, and then try to understand whether there's a feature there underneath that you could put in place that is broadly applicable, not just to that one problem, but, "Oh look, this could solve this, and this, and this problem as well." And so you're putting in place a class, not an instance, so to speak. That's, like - and if all you're talking about is an instance then you're probably better off leaving it out (inaudible). But it's a subjective thing, but... 216 | 217 | LARRY: One of our principles is, "Save your money for college (inaudible)." 218 | 219 | [1:09:00] 220 | 221 | [LAUGHTER] 222 | 223 | LARRY: We actually found this in the early design of Perl 6. We asked for RFCs--I expected about 20 suggestions; we got 361. 224 | 225 | CAROL: Whoa. 226 | 227 | LARRY: So we had this in spades. We - and, you know, it's completely overwhelming, until I hit upon this principle, you know, which Anders alluded to, which is basically ignore the proposed solution. 228 | 229 | ANDERS: Yeah. 230 | 231 | LARRY: But there is a (pain) point underneath. And if you look at more - enough of these RFCs and they have the same (pain) point, there is something you should (address). There's some fundamental unification issue underneath, or something that just is funky that could be fixed. And especially if you're doing a complete redesign, then you can think about that sort of thing. 232 | 233 | JAMES: Yeah, and working with (inaudible). It's really hard. (Inaudible)... 234 | 235 | [1:10:00] 236 | 237 | JAMES: ...before Java, which (inaudible). You know, there were a whole lot of problems where - you know, it's clear that there was a problem there. There were, like, twenty or thirty worldwide academics who were absolutely at the top of their league for understanding the issues. Every one of them had two entirely different suggestions. They couldn't agree with themselves. You get, like, 40 different people in a room. The model (inaudible) and they've all got radically different ideas. And, you know, (inaudible), you know, it was their (inaudible) for (inaudible). And for some reason, you know, they - it's actually important to do the science project, you know? So, like, with generics... 238 | 239 | [1:11:00] 240 | 241 | JAMES: ...in Java, before Java was first released, it was really clear that this was, like, a big issue. The - and, you know, Bill Joy and I came about as close to spilling blood on this topic as I've gotten at (work). And, you know, I would much rather do something - or much rather leave something out than do something stupid. 242 | 243 | LARRY: Yeah. One of our principles: "Plan to be smarter later." 244 | 245 | JAMES: Yeah. Well, but that means - that means - the opening answer is no, right? And one of the things that happened with, like, a whole bunch of different topics in the evolution of Java was that they kind of turned into competitions. And generics and (closures) were both probably the most hard-fought... 246 | 247 | [1:12:00] 248 | 249 | JAMES: ...competitions with people writing PhD theses on the topic. And I was, like, trying them all out. And, I mean, some had no shortage of smart people at the time. But it's really hard to be, you know, a planet full of grad students... 250 | 251 | CAROL: So speaking of grad students, at some point I think most of you were grad students, correct? No? 252 | 253 | LARRY: In linguistics. 254 | 255 | CAROL: In linguistics? Okay. Well, okay. But at some point you all, probably 20, 30 years ago, decided, "Okay, I'm going to write my own language." And things were very different back then. Internet was sort of starting, maybe not even there, single... I think we had computers. We had phones, right? Cell phones... 256 | 257 | LARRY: Nobody cared [CROSSTALK] - nobody cared what you did with the eighth bit. 258 | 259 | [CROSSTALK/LAUGHTER] 260 | 261 | [1:13:00] 262 | 263 | ANDERS: Oh, I think you're that (inaudible). 264 | 265 | CAROL: But these are languages that persisted through many changes and, you know, on different hardware. When you started designing your language what was the key goal that you were trying to meet, versus using some other existing language? 266 | 267 | JAMES: Well, I mean, for me it's never been a key goal. I mean, one of the secrets of success is try to solve as many problems at once as you can. And, you know, if there's just one problem there's probably an easier way than a new fucking programming language, right? [LAUGHTER] Right? 268 | 269 | GUIDO: If you think that way you'll never have a new programming language. There's always a better solution. 270 | 271 | JAMES: [CROSSTALK] Well, it depends on how much you hate... 272 | 273 | [1:14:00] 274 | 275 | JAMES: ...chasing down memory corruption bugs. 276 | 277 | [LAUGHTER] 278 | 279 | LARRY: The three virtues of a program are laziness, impatience, and hubris. 280 | 281 | [CHEERS/LAUGHTER] 282 | 283 | LARRY: It takes hubris to... 284 | 285 | ANDERS: Yeah, the world needs another programming language [CROSSTALK] hole in its head. 286 | 287 | LARRY: Don't look at (inaudible) code. 288 | 289 | ANDERS: But the thing about programming languages that I think a lot of people don't realize is that every programming language is about 90% the same and maybe 10% new, if you're lucky. And a lot of people get very focused on the 10% new and forget about the 90% the same that makes it a great language, right? I mean, there's a lot of hard, boring work in creating programming language, lot of semantics that you've just got to worry about. And, like, everyone loves to talk about syntax. And syntax is the easy part; semantics is the hard part. 290 | 291 | [1:15:00] 292 | 293 | ANDERS: You know, like, how the types work, and what are all the supported promotions, and what are the different kinds of type constructors that the language has, etc., etc. These are the hard things to design, but not the things that people... People love to (inaudible) on the syntax. You know, "Should it be a colon or a comma?" you know? And it's, like, oh my God, let's have a long thread about that. [LAUGHTER] 294 | 295 | CAROL: So talking about people having opinions, and syntax, and typing, these languages don't all take the same approach to typing. Maybe we'll start with Guido and talk about typing in Python, and then kind of work our way around. 296 | 297 | GUIDO: Typing in Python evolved at various points during the language design. 298 | 299 | [1:16:00] 300 | 301 | GUIDO: I mean, I just remembered that when Python first happened INT was not a class; INT was a little conversion function. There was an internal object (type) which was really just kind of a (V-table) that represented integer objects. And there was a built in function if you needed to convert a (string) to an integer, and that was... We had a bunch of those functions, and we realized that we had made a mistake--we had given users classes that were different from the built-in object types. And for a long time it was, like, oh well, like, the real stuff is implemented in C. And the user writes a little bit of glue on top... 302 | 303 | [1:17:00] 304 | 305 | GUIDO: ...of that. And when I found out that we had 80 different competing web frameworks it was sort of time to realize that people were writing much larger programs, and that a different approach to types was needed. And that's where we sort of re-invented the whole approach to types in Python. And there was a bunch of cleanup that didn't happen until Python 3 actually. But one of the things we introduced, and we were lucky that there weren't--actually despite those 80 web frameworks--there weren't enough users that we were completely stymied by backwards compatibility yet, like we are now. So we just - one day we changed the function INT into a designator for the class INT. 306 | 307 | [1:18:00] 308 | 309 | GUIDO: And sort of it followed that calling the class would mean constructing an instance of the class, so that if you had simple code that wrote INT (inaudible) some expression (inaudible), it would work exactly the same way. It would have the same effect. But the workings inside were completely different. There was one particular file that sort of implemented the sort of basic functionality of types in the language. And in Python 1 it was, like, 50 lines of code. And at some point I rewrote it and it was 5000 lines of code. 310 | 311 | CAROL: Wow. That's some (inaudible). What about types in Java? 312 | 313 | JAMES: So I've got this long history of caring about... 314 | 315 | [1:19:00] 316 | 317 | JAMES: ...things like performance and building robust software, and often that comes out about... You know, I'm much more worried about what it takes to build production-quality software than about what it takes to just, like, do, like, a quick thing. And Java's not a great language for quick things, but it's... You know, for me one of the things that I love to do, and maybe I'm weird, but being able to do automatic theorem-proving on (hunks) of code. And a type system is a really great (part) to be one of the foundations of theorem-proving. And theorem-proving for hunks of code turns out to be really... 318 | 319 | [1:20:00] 320 | 321 | JAMES: ...useful for things like building off of (inaudible) compilers, and doing ahead of time correctness-jumping, trying to be able to theorem-prove away as many things as possible. You know, so, like, you know, one of the not-well-known things about Java is that, you know, in the Java spec, you know, it's array subscript checking is always on. But, you know, it's only conceptually always on, right? The truth is that there are - there's more than (enough hooks) for the compiler to theorem-prove away almost all index checks. And same thing with, like, NULL pointer checks and all kinds of things that look like they're heavyweight, but they're really... 322 | 323 | [1:21:00] 324 | 325 | JAMES: ...(cheap). You know, so one of the things that I really cared about at the time was that A+B should almost always be, you know, at most one instruction. Bonus points for zero instructions. 326 | 327 | [LAUGHTER] 328 | 329 | CAROL: [CROSSTALK] Makes it a lot faster. 330 | 331 | JAMES: Well, the thing about zero instructions is often you can, like, fold them into some weird addressing (mode), right? 332 | 333 | CAROL: Yeah. 334 | 335 | JAMES: And so in kind of the universe I tend to live, being able to look at A+B and realize it's that instruction, that all feeds off of the type system. And sometimes you can do this with sort of optimistic (inaudible) (compilation), and depending on how far you want to push that. So, like, the... 336 | 337 | [1:22:00] 338 | 339 | JAMES: ...JavaScript engine in Chrome is absolutely astonishing for the kind of gore that they go through to optimistically compile JavaScript code. But it's also very hard to do those kinds of tricks if you're trying to get into small footprint devices, you know? So, you know, there are Java compilers that work for machines that only have, like, 50K. 340 | 341 | CAROL: Right. 342 | 343 | JAMES: And, you know, to do that kind of compaction and distillation you need every kind of (hook) that gives you every little - every last drop of information. And the earlier you know it the better a job you can do. 344 | 345 | CAROL: Right. So Anders, speaking of lots of information that one gets, TypeScript gives you a lot of flexibility and power. 346 | 347 | [1:23:00] 348 | 349 | CAROL: What's your general view about typing? 350 | 351 | ANDERS: Well, let me actually... It's funny that you mention (CPU) cycles and counting how many of whatever... I remember when I wrote Turbo Pascal, which was all written in Z80 assembly code - and back in those days you could literally look up the intel manual, or the Zilog, or whatever, you know, and see how many clock cycles every instruction took. And actually it would work out just like that. 352 | 353 | CAROL: I remember that. 354 | 355 | ANDERS: And now everything takes zero clock cycles except when it takes a thousand clock cycles. [LAUGHTER] When you hit the memory wall... And it is absolutely impossible to reason about how CPUs execute (your) code today. That's just one... 356 | 357 | JAMES: Well, it's not impossible. It's just... 358 | 359 | ANDERS: [CROSSATLK] No, it's not. But it's much harder. 360 | 361 | JAMES: Oh yeah. But it is a complete pain in the ass. 362 | 363 | ANDERS: Yes, it is. 364 | 365 | JAMES: And they don't give you manuals that are good enough, right? 366 | 367 | ANDERS: No - no - no. 368 | 369 | JAMES: If you want to actually understand it you need to get the chip diagrams. 370 | 371 | ANDERS: But with respect... 372 | 373 | [1:24:00] 374 | 375 | ANDERS: ...to types, I've always worked on programming languages that have type systems. But it's interesting how it's gone from being type systems for the code generator's sake, or type systems for, you know, generating errors, to now I almost view type systems as a tooling feature. And that's really sort of the thing that has been interesting (inaudible) bit for TypeScript, it is, you know... First of all, starting with a dynamically-typed programming language like JavaScript, and then trying to add a type system on top of it that faithfully reflects the semantics of the programming language... And the reason we're doing it is actually not because we think type systems are interesting, but because if you think about what it is that powers programmer productivity today... Like everyone loves their IDE, like, whatever IDE you're using. I hope it's Visual Studio Code. 376 | 377 | [1:25:00] 378 | 379 | ANDERS: But if it's not, you know, I'm sure you're all, like, accustomed to things like statement completion, and refactoring, and code navigation, and go to definition, and so forth. And if you think about it, the things that - the thing that powers that is semantic knowledge of your code. And the thing that provides the semantic knowledge of your code is a compiler with a type system. And once you add types you can actually dramatically increase productivity, which in some ways seems counterintuitive, right? I thought, like, dynamic languages were easier to approach because you got rid of the types, which was, like, a bother all the time. Well, it turns out that you can actually be more productive by adding types if you do it in a non-intrusive manner, and if you work hard on doing good type inference and so forth, you know? 380 | 381 | JAMES: [CROSSTALK] So I wanted to jump in here. 382 | 383 | CAROL: Let's let Larry jump in and then (inaudible). 384 | 385 | [1:26:00] 386 | 387 | LARRY: I'll probably take over the whole [CROSSTALK]... 388 | 389 | JAMES: So I really, really, really believe in that point, in the power tools for power geeks thing. And one of the things that drives me nuts is the "real men use VI" movement. And, you know, it's really - I just want to punch people who are, like, "Well, I'm a real..." 390 | 391 | CAROL: There is no violence on stage. 392 | 393 | JAMES: ..."I'm a real developer because I use VI." And it's, like, you know... 394 | 395 | ANDERS: "...because I do it the hard way." 396 | 397 | JAMES: I think IDEs make language developers lazy. 398 | 399 | [AUDIENCE RESPONSE] 400 | 401 | CAROL: Wow. You should expand on that, Larry. 402 | 403 | JAMES: IDEs let me get a lot more done a lot faster. I mean, I'm not - I'm really not into proving my manhood. 404 | 405 | [1:27:00] 406 | 407 | JAMES: [CROSSTALK] I'm into getting things done. 408 | 409 | CAROL: Case and point. But I'm going to take the devil's advocate here for a second. 410 | 411 | GUIDO: Emax. 412 | 413 | CAROL: Something like - Emax, okay, yeah. The Jupyter Notebooks--a lot of science people - data scientists get a lot done in actually a pretty simplistic IDE with a dynamic language most of the time. So... 414 | 415 | JAMES: They could get a lot more done. 416 | 417 | [LAUGHTER] 418 | 419 | CAROL: I don't know - I don't know. 420 | 421 | ANDERS: No, but I think typeset - I mean, it's not just - a type system can help you. First of all, if you're uninitiated and you want to know, "Here's my (fu)," and now I say "(fu dot)," and that - the IDE can show you, "What can I type next?" right, as opposed to, "I've got to go read manuals and figure it out or know it all," right? I mean, the original developer of whatever piece of code might know it all. But then... 422 | 423 | [1:28:00] 424 | 425 | ANDERS: ...people move on, new people come, you know, there's - here's this project, there was no documentation written about it. And if you think about it, types are documentation, too, right? I mean, and there are just - there are so many things about, like - like, adding them that down the line give you increased productivity [CROSSTALK]. 426 | 427 | CAROL: Okay. So there's productivity and then there is... 428 | 429 | ANDERS: But that's... 430 | 431 | CAROL: ...maintainability. 432 | 433 | ANDERS: Oh, well, both. 434 | 435 | CAROL: And maybe any different thoughts about maintaining some...? 436 | 437 | LARRY: I didn't get to talk about types yet. 438 | 439 | CAROL: Oh, well, talk about types. You don't want to leave Perl types out. 440 | 441 | LARRY: Well, the story is very different for Perl 5 and Perl 6, is the thing. As you know, Perl 5 just sort of grew over time. And the whole idea - it was sort of a ticklish idea. Everything - you can pretend everything is a string, even if it's a number or a (floating point) internally; it's just all, you know, interchangeable. 442 | 443 | [1:29:00] 444 | 445 | LARRY: And that works out for bootstrapping people to a language quite nicely. And it's a feature that we wanted to keep in Perl 6, but what we discovered in Perl 5 as part of the redesign was it's fine if the new user is confused about the interchangeability of (inaudible), to use a technical term, of your (inaudible) types. But it's not so good if the computer is confused about things. [LAUGHTER] You know, the Perl 1 engine was written way back in the dark ages when you had (inaudible) a bunch of stuff in, and it cheated a lot. So part of the redesign when we did the whole Perl 6 thing, we wanted to do object-oriented programming better than these languages, and we wanted it to be functional programming, better than most functional programming languages. To do that you have to have a fundamental, very sound type system... 446 | 447 | [1:30:00] 448 | 449 | LARRY: ...a sound (inaudible) object model underneath. And you really have to take seriously these slogans like, "Everything is an object. Everything is a closure. Everything..." You know, in Perl 6 even (inaudible) our closures. And you've got to optimize hard to get them away from there. But I - and I also agree with this idea that the types also are a cultural - I talked about pegs - hanging things on pegs. They're one of the pegs we didn't have something to hang on in Perl 5, and now we can, you know, hang all the - all the meta-information. And they could just run the little program. They don't even have to have an idea; they can say, "Oh, this object (inaudible)," you know, they could do their own introspection of the whole thing. And people just do that all the time. By the way, we do also have an IDE [LAUGHTER]. 450 | 451 | CAROL: Good points all around. So... 452 | 453 | [1:31:00] 454 | 455 | CAROL: ...most of the time programmers actually spend maintaining code versus writing new code out in the wild. And what things or elements of a programming language make it easier to maintain code? And maybe we'll start with Guido. 456 | 457 | GUIDO: Well, I've found that - [BREAK/BLACKOUT] - TypeScript is actually incredibly useful, and so we're adding a very similar idea to Python. We're adding it in a slightly different way because we have a different (inaudible)... [MIC FREQUENCY] I'm sorry, I turned my chair because my neck was, like, turned (inaudible). Sorry. 458 | 459 | CAROL: All right, it's the ghost. 460 | 461 | [1:32:00] 462 | 463 | GUIDO: Anyway, [CROSSTALK] I sort of learned a painful lesson that for small programs dynamic typing is great. For large programs you have to have a more disciplined approach. And it helps if the language actually gives you that discipline rather than telling you, "Well, you can do whatever you want." 464 | 465 | LARRY: Yeah, that was part of our scale-up idea for Perl 6, that the types would help with programming in the large. Because we did notice both limitations of, you know, (loose) typing. 466 | 467 | JAMES: Yeah, about 20 years ago I started working really heavily on refactoring engines, and, you know, being able to do, like, largescale refactoring on, like, millions of lines of code... 468 | 469 | [1:33:00] 470 | 471 | JAMES: ...at once. And that really changes the way you think about maintaining code. You know, because there's - you know, the world is filled with libraries that have things like stupid variable names, stupid method names. Because, you know, when you started out it meant one thing. But now you realize that you really didn't really understand what you were doing in the beginning, and so this - this method name really should be different. But nobody ever renames methods, because it's really hard to go over a piece of code and rename exactly the right variable. But if you've got a good refactoring engine you just type, you know, meta-control R, type in the new name. You know, hundreds and hundreds of files later--which takes about, you know, maybe 30 seconds if it's a lot of files--you're done. 472 | 473 | [1:34:00] 474 | 475 | GUIDO: And so you basically rewrite volume one of a seven-volume series. 476 | 477 | [LAUGHTER] 478 | 479 | ANDERS: No, but this is actually, like, (inaudible) you're describing... And (inaudible) was the genesis of the TypeScript project, which was these enormous JavaScript code pieces that we were seeing customers, right, and then in-house projects. And they were getting bigger and bigger because JavaScript engines were getting good enough for you to write really big programs. But maintaining them was impossible, because it turned into write-only code. You know, you dared not touch it once you had written it because it worked. And then - but, you know, there's this property called "text." And I really want to change it to be, I don't know, like, some other name. Except there is, like, a million other properties called "text." And if I just, like, do a global search and replace for "text," then, oh my God, it's, like, it all... So I can't change anything. But if you have semantic... 480 | 481 | [1:35:00] 482 | 483 | ANDERS: ...understanding of, like, "this property called 'text' is different from that other property over here called 'text,'" and if you want to rename this one that doesn’t mean you want to rename that one. But that takes for something like a type system to be in place. And, you know, once you start adding that you add documentation to the code and you add these capabilities where we're now seeing people, like, with regularity refactor hundreds of thousands of lines of JavaScript code, you know, like, in minutes. And it just works afterwards. And people are, like, amazed that it's possible. But it's true that it takes a bit more work to begin with. And it's maybe not right if you're writing five lines of code. Okay, that may be more bother than you really care to. But, you know, it starts to pay off pretty quickly. 484 | 485 | LARRY: (Inaudible) (in addition) to types, really good lexical scoping helps with refactoring. It fits back into this... 486 | 487 | [1:36:00] 488 | 489 | LARRY: ..."what's the right peg to hang this on?" And often it's lexically-scoped or dynamically-scoped somehow. And they're doing those right and not interfering with threading and all sorts of interesting questions (inaudible). 490 | 491 | CAROL: So I'm going to throw one more question out before the break in three minutes. And we made sort of a reference to Donald Knuth, one of the Turing winners, in this last section of conversation. And he wrote, "Premature optimization is the root of all evil." So what's your approach to optimizing code and gaining efficiency, say, in Python? 492 | 493 | GUIDO: Well, I'm terrible at that so I leave it to others. 494 | 495 | [LAUGHTER] 496 | 497 | CAROL: That is spoken like a very wise language-creator. 498 | 499 | GUIDO: And they've (lift) up to the task. I mean, Python's hash table implementation has been rewritten so many times... 500 | 501 | [1:37:00] 502 | 503 | GUIDO: ...I don't understand any part of it. [LAUGHTER] But it is so much better than the thing I actually copied out of Knuth 30 years ago. 504 | 505 | CAROL: You copied it out of (Clue)? 506 | 507 | LARRY: "Knuth." 508 | 509 | CAROL: Oh, Knuth, oh okay. 510 | 511 | JAMES: Yeah, so I kind of 50% believe that, because there are - you know, the premature optimization in terms of algorithms and code, that part of it I believe. But, you know, people often don't really think about the role of data structures in optimization. And if a data structure is exposed you have to - you know, and you decide that you, you know, this algorithm is a problem, but, you know, the reason that it's a problem is because, you know, this data structure was just slapped together... 512 | 513 | [1:38:00] 514 | 515 | JAMES: ...and they thought, oh, there'd only ever be, like, ten items in the list, or ten items in the set. And then you start, you know, having, you know, million-item sets all the time. And all of a sudden, you know, your little linked list is not going to hack it, right? 516 | 517 | LARRY: Or (inaudible). 518 | 519 | JAMES: Or - yeah. And so if you can - you know, it's, like, you know, hide early; hide often, right? Never tell the truth about what your data structures are. 520 | 521 | [LAUGHTER] 522 | 523 | CAROL: and on that note we're going to take... You want a quick (point)? 524 | 525 | ANDERS: I just wanted to say that I think, like with anything, the important thing is to make sure that you actually have the right data before you start optimizing, right? But too often you have a hunch that, oh, I think if I... 526 | 527 | [1:39:00] 528 | 529 | ANDERS: ...need - I need to do this, you know? I need to change this data structure from being a linked list to being [CROSSTALK] or whatever. And - but if you imagine, then you discover it doesn't matter. And - but really there's this other thing that you haven't even thought about that matters enormously, and maybe you should go look over there. So get proof, get - use a profiler, figure out where is the time actually spent? I am continually surprised and I write compilers for a living, and I'm always surprised about where time is spent. 530 | 531 | CAROL: All right. And that - with that we're out of time for this section. We're going to take a quick 15-minute break, and when we come back the really hard questions are going to come out, because the audience questions that have been submitted are going to be the ones that we move into. So thank you. 532 | 533 | [CHEERING/APPLAUSE] 534 | 535 | CAROL: [CROSSTALK] You guys have been wonderful. 536 | 537 | [1:40:00] 538 | 539 | [BEGIN PART 2] 540 | 541 | [2:00:55] 542 | 543 | M: ...each and every one of you has a community that is formed around the languages that you've created. I'm curious if you would talk to ways in which you've seen the design choices you've made for your language shape the communities that formed around those languages. 544 | 545 | [CROSSTALK] 546 | 547 | LARRY: It really helps if you're trying to make everybody - you know, what's your slogan here, "Everybody...?" 548 | 549 | CAROL: "Everybody comfortable?" 550 | 551 | LARRY: No. 552 | 553 | CAROL: [LAUGHTER] "...feel valued and supported..." 554 | 555 | LARRY: Make, you know, all Americans I heard, you know, feel, like, comfortable programming. 556 | 557 | CAROL: Oh, CS for All, yes, to make... 558 | 559 | LARRY: Yeah, that was it. 560 | 561 | CAROL: Yes. 562 | 563 | LARRY: I'm getting senile. But... 564 | 565 | CAROL: The sign was a clue. 566 | 567 | LARRY: ...it's not CS for All if it's just Americans. 568 | 569 | CAROL: No. 570 | 571 | LARRY: And there are many underserved... 572 | 573 | [2:02:00] 574 | 575 | LARRY: ...populations in the world. And what we've really discovered, that it really helps build international camaraderie and community to have world-class, literally, support for Unicode. 576 | 577 | CAROL: Yes. 578 | 579 | LARRY: So I would encourage any language designers out there, don't do this halfway stuff with, you know, code points. Go (inaudible). 580 | 581 | CAROL: I completely agree. Guido, you had something you were going to say? 582 | 583 | GUIDO: I was going to try and say that I (don't know) how my language design choices necessarily affected the community, but my choices about how to interact with communities certainly have affected the language design (inaudible) deeply. I was somehow imbued with the importance of user-centered language design... 584 | 585 | [2:03:00] 586 | 587 | GUIDO: ...because Python borrows a little bit from (inaudible) (ABC) (inaudible). Its authors had a bunch of things right, and one of those was listen to the users; ask the users what they think. And then (inaudible) suggested solutions and you first figure out for the program (list) (inaudible) you do give the users a voice. And I've sort of taken that out and let the users help me design the language. And now they're ready to take over. 588 | 589 | ANDERS: I was going to say, I always felt like it's important as a language designer that you don't create unnecessary work for your community. Because it's very easy to, in the name of purity or whatever, go change something or strive for the perfect language. And I've always said, like, I mean... 590 | 591 | [2:04:00] 592 | 593 | ANDERS: ...show me the perfect language and I'll show you a language with no users, you know? Every language has imperfections in it, and it has them because it has evolved. And the hard part of language design is actually not version 1-0 - it's, like, all the versions that come after, where you're trying to sneak new things in without actually causing extra burdens on people who don't necessarily care about the things that you're trying to sneak in, right? And so that's the hard part of language design I think is the evolution of the language and keeping your community with you as you evolve. 594 | 595 | JAMES: Yeah, and so we Java we, like, always followed that. We've maybe been a little bit excessive about it. I mean, I've got binaries that I compiled, like, twenty years ago... 596 | 597 | [2:05:00] 598 | 599 | JAMES: ...that still run. And it's, you know, on machines that were never invented when the code was compiled. And you only get there with crazy discipline and a tolerance for living with your mistakes. But it makes the - you know, it also ends up selecting who your users are, because in the Java universe pretty much everybody is really disciplined. Beca- you know, it's kind of like mountain climbing. You know, you don't get - dare get sloppy with your gear when you're mountain climbing, because it has a clear price. And, you know, when - you said something about - Larry, you said something about Unicode. Java's had Unicode since '92. 600 | 601 | [2:06:00] 602 | 603 | JAMES: So, you know, it's - you know, trying to be inclusive... [CROSSTALK] Yeah. And that really made a difference. I mean, lots of folks thought it was, like, the lamest thing ever. But that was during my, you know, Lord of Java phase, which... 604 | 605 | LARRY: That was (a great decision). 606 | 607 | JAMES: Yeah, but that phase of my life ended in about '95. 608 | 609 | LARRY: I'd like to say something about the stability thing and as it relates to community. And that is we did this perfect - tried to do perfect backward compatibility thing all the way up through Perl 5 and did a really good job of it. It's one of the most stable things... There's still Perl 1 owners that (inaudible). That eventually runs into the problem that, you know, you can't (inaudible). You can't fix your mistakes. So one of the mistakes that we made was kind of a meta mistake... 610 | 611 | [2:07:00] 612 | 613 | LARRY: ...and that was assuming that you had to always have that kind of stability and not change anything. How would it be to design a language where the language itself could be evolved from within by the community and be the language we want 25 or 50 years from now? This ties into what Paul Graham was talking about, a hundred-year language. And we kind of took that seriously--what is it that prevents languages from evolving, not having things (inaudible) right? But fundamentally the Perl 6 compiler is written in Perl 6. Most of the runtime system is written in Perl 6. The users can extend it. Perl 6 itself does not care whether things are built in or not; it all works the same. So most of the built-ins are written as if they were user code. So users, even if... 614 | 615 | [2:08:00] 616 | 617 | LARRY: ...we say, "No, we don't want that in the language right now, but put it in a module," you can turn classes into monitors with about that much code. You can implement an actor model in classes with about that much code. You can mutate - adding operators is just trivial. When it does, it does everything perfectly one pass. It drops into the sub-compiler. And with the end it comes back out. So there's never any ambiguity as to what language you are in. And so because the scoping of the exact language here, and it lexically-scoped, any lexical scope can say, "Use whatever language I want." A future version of Perl 6, you could say, "Use COBOL, use Python." If someone - well, actually people have written Python parsers in Perl 6. I don't think anybody's written a COBOL parser yet. 618 | 619 | [2:09:00] 620 | 621 | [LAUGHTER] 622 | 623 | LARRY: But we'd like to think that, you know, all languages are sub-languages of Perl 6 now. So I think that [LAUGHTER] - I think that they're... (Inaudible) semantics, which are hard. I agree semantics are hard. But I think there is a way forward. [CROSSTALK] I think there is a way forward to get the stability and the evolution, and I think we're trying for that. 624 | 625 | CAROL: Awesome. Do we want to take another audience question? All right. Thanks. 626 | 627 | M: Hi. 628 | 629 | CAROL: Can you talk into the mic like you're eating the mic? 630 | 631 | M: Hello? Hi. Yeah, can you hear me? 632 | 633 | CAROL: Yeah. 634 | 635 | M: Great. There's been a lot of talk tonight about the evolvability of languages and the trouble with implementing things that might not be backwards-compatible. What's something that you wish you could have implemented with our language, but for that... 636 | 637 | [2:10:00] 638 | 639 | M: ...or maybe another reason it wasn't possible? 640 | 641 | GUIDO: Well, I have a (inaudible) I am sort of jealous of because it's appearing in more and more other languages. It's (inaudible)-matching. And I cannot come up with the right keyword because all the interesting keywords are already very popular method names for other forms of (inaudible)-matching. 642 | 643 | CAROL: Naming's hard. 644 | 645 | ANDERS: Yeah. Well, I'll go. My favorite is always, like, the $2 billion mistake of - or the billion-dollar mistake of having NULL in the language. And since JavaScript has both NULL and undefined it's the $2 billion mistake. But, I mean, if - and, I mean, what's done is done, right? And now... 646 | 647 | [2:11:00] 648 | 649 | ANDERS: ...you know, I spend a significant portion of my time actually working on ways to make code NULL-safe, to... And who in here has ever had a NULL pointer exception, right? I mean, there you go. It is by far the most problematic part of language design. And it's a single value that [LAUGHTER] if only that wasn't there, imagine all the problems we wouldn't have, right, if type systems (were) designed that way. And some type systems are, and some type systems are getting there. But, boy, trying to retrofit that on top of a type system that has NULL in the first place is quite an undertaking. 650 | 651 | LARRY: The features I wanted to add were negative features. I think all of us as language designers have borrowed things... You know, we all steal from each other's languages all the time. And... 652 | 653 | [2:12:00] 654 | 655 | LARRY: ...often we steal good things. But for some reason we also steal bad things. You know... 656 | 657 | CAROL: Like what? 658 | 659 | LARRY: Like regular-expression syntax. 660 | 661 | CAROL: Oh, yeah. [LAUGHTER] I'll give you that one. 662 | 663 | LARRY: Like the C-precedence table. 664 | 665 | CAROL: Ah, okay, another. 666 | 667 | LARRY: Okay. These are things that I could not fix in Perl 5, and we did fix in Perl 6. Because... 668 | 669 | CAROL: Oh yay, awesome. All right, we do seem to be doing pretty well with the audience. So how about another audience question? 670 | 671 | M: Hi, hello there. So, well, what I wanted to ask is you can serve notice these sort of (inaudible) effect in regards to tech and programming throughout time to (inaudible) different paradigms. There's a certain time where people were, like, "Are we going to do things (imperatively)? Are we going to go..." 672 | 673 | [2:13:00] 674 | 675 | M: "...object-oriented or functional?" And for example, right now there's a whole bunch of languages that are sort of, like, very aggressively taking that standpoint of being very pro-being friendly with concurrency or being very over-jealous about (inaudible) with memory. And I think that that kind of pendulum effect happens because technology has actually been evolving throughout time. Our machines are, like, beefier and we have more memory now. So the ways that we designed programming languages now are probably a lot different than they were 20 or 30 years ago. So considering that, where do you think, or how do you think the programming languages ten years into the future are going to look like? Or in your opinion where is language design headed to, like, in the future? 676 | 677 | JAMES: So my favorite candidate for that... 678 | 679 | [2:14:00] 680 | 681 | JAMES: ...is that, you know, these, you know, major breaks and things like that always happen because, you know, something major happens in the underlying technology. And, you know, one of the areas of underlying technology that is kind of like a computer that I think is really underserved is writing code for GPUs, right? I mean, right now there are no languages worth a crap--and that's a technical (term), trademark [LAUGHTER]--that work well on GPUs. And, you know, maybe because there's, like, a limited number of algorithms that people are willing to - are really interested in, but they're really important ones. Or maybe it's because they're inherently all mathematical and the number of people who care about writing numerical code... 682 | 683 | [2:15:00] 684 | 685 | JAMES: ...is small. I'm one of those though, and - you know? And so every now and then I spend time thinking about, you know, what would you do to make GPU programming really easy? 686 | 687 | LARRY: We need a champion in Perl 6 to hook up our (vector) (inaudible) to the GPUs. 688 | 689 | JAMES: Yeah, but it's more than just vector operators. I mean, that's kind of my problem with the whole thing is that most of these things are just libraries of hand-coded assembly that do vector operators. And surely there's something more clever than that. 690 | 691 | ANDERS: Maybe I'll just add with language design, you know, one of the things that's interesting, you look at, like, all of us old geezers sitting up here, and we're proof-positive that languages move slowly. And, I mean, it's not, you know, like - a lot of people make the mistake of thinking that languages move... 692 | 693 | [2:16:00] 694 | 695 | ANDERS: ...at the same speed as, like, hardware or, like, all of the other technologies that we live with. But languages are much more like math, and much more like the human brain, and, you know, and it all evolves slowly. And we're still programming in languages that were invented 50 years ago. Like functional - all of the principles of functional programming were thought of more than 50 years ago. I do think one of the things that is luckily happening is that, like as Larry said, everyone's borrowing from everyone. And languages are becoming more multi-paradigmed. Yeah, I think it's wrong to talk about, "Oh, I only like object-oriented programming languages," or "I only like imperative-programming," or "functional-programming." I mean, it's important to look at where is the research, or where are the new - where's the new thinking and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already. 696 | 697 | [2:17:00] 698 | 699 | ANDERS: And I think we're all learning a lot from functional-programming languages these days; I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect, and no one writes pure functional programs. I mean, because they don't exist. So it's all about, like, how can you tastefully sneak in mutation in ways that you can better reason about, as opposed to mutation and free-threading for everyone, you know? And that's, like, just a recipe for disaster, right? So... 700 | 701 | M: (Inaudible) on the functional (inaudible)? 702 | 703 | [LAUGHTER] 704 | 705 | ANDERS: All languages are imperfect, let's just settle it right there, you know? [LAUGHTER] 706 | 707 | M: (Inaudible) all languages, I think in the late '70s I heard a saying that said, "We don't know what the language of the future will look like, but we know what it will be called, and it'll be called 'Fortran.'" 708 | 709 | [LAUGHTER] 710 | 711 | [2:18:00] 712 | 713 | M: I started (wanting to take that) as a (humbling) lesson. 714 | 715 | LARRY: Yes. We've been thinking a lot about the parallels and concurrency issue. This is one of those issues where we were waiting to be smarter. We did borrow, I mean, steal, a bunch of ideas from Pascal in terms of lazy lists and things like that. But in terms of how you actually are going to deal with the end of Moore's Law--or if not the end of Moore's Law, at least, you know, multi CPUs, many - you know, many (cores)--when you've got a thousand (cores) what are you going to do with them? And so a lot of our early design on Perl 6 was - we didn't understand how we wanted to do it yet, but we knew very - we knew very deeply that we didn't want... 716 | 717 | [2:19:00] 718 | 719 | LARRY: ...to do anything that would prevent it. So a lot of the early design decisions were, you know, just saying, "Well, we have to keep this open." Then when the right smart people came along they said, "Look, what you really have to look at is things that are composable." Threads are not composable--you can't take two threads and turn it into a third thread. What you want is things like we stole from Go--we stole promises and channels. From C# we stole functional-reactional programming. And with these sort of primitives, which end up being duals of your regular list-processing kind of primitives--they just happen to be working on events--and you can have loops - event loops that work just like regular loops, except they're running on... And you - same control flow, so that is easy to learn. There are ways of sneaking these things into a language, at least in the ways that we understand right now, that... 720 | 721 | [2:20:00] 722 | 723 | LARRY: ...I heard, was it - who was it talking about adding fibers to their runtime? I think it was a Java news item. But lightweight threads that can - you - as Erlang has done - has shown, you know, you can run 100,000 threads in your process and... 724 | 725 | CAROL: That's another language that's been around for a long time. 726 | 727 | LARRY: Oh yeah, and we stole from them, too. We like their pattern-matching. But... 728 | 729 | JAMES: Well, one of the meta-theorems is that all good language design is theft. 730 | 731 | LARRY: Of course. So, yeah, I mean, we're thinking about it. We don't know - have all the answers yet. But I think all these languages, you know, long-term tend to converge on similar solutions. 732 | 733 | CAROL: So very sadly we are at the last question. I know, it went so quickly, and unfortunately all good things must end, except for maybe good languages. 734 | 735 | [2:21:00] 736 | 737 | CAROL: So I'm going to start and maybe quickly wrap up. As you look back over the long lives of the languages that you've written, what have you found most rewarding? 738 | 739 | LARRY: The people. 740 | 741 | CAROL: The people? 742 | 743 | LARRY: By far. 744 | 745 | [APPLAUSE] 746 | 747 | ANDERS: Yeah, absolutely. Oh, I - yeah. Yeah, I mean, that's what keeps me coming back to work every day is, like, the incredible excitement that the community shows you. And I am so grateful for all the people who have used the... I mean, there's nothing more rewarding than have people just, like, on Twitter or wherever it is go, "Oh my God, this is so great." And it's, like, yeah - that makes you want to just keep doing more of it. I mean, it's... 748 | 749 | JAMES: Oh yeah, every - you know, when somebody comes up to me, you know, in the street somewhere and says, you know, "Thanks for giving me a career. Can I have a selfie?" [LAUGHTER]... 750 | 751 | [2:22:00] 752 | 753 | JAMES: ...you know, that's, like - that's the kind of, like, you know, light-and-dark thing. But... 754 | 755 | LARRY: Being famous is not all... 756 | 757 | JAMES: ...it's really wonderful. 758 | 759 | LARRY: ...being famous is not all great. I mean, I've ha- it's happened to me in Silicon Valley at a movie theater or the tire shop--"You're Larry Wall." 760 | 761 | JAMES: Yeah, well, what's really weird is when your kids are with you when that happens. [LAUGHTER] 762 | 763 | LARRY: But yes, it's when the - when people said, "You gave me a career. You gave me a livelihood. You fed my family." That's the best. 764 | 765 | [CROSSTALK] 766 | 767 | LARRY: And not just - we're not talking about a star-relationship here, of each of us to those individuals; we're talking about the second-order community 2.0 kind of effects. It's one thing to see them, you know, getting help from you; it's another thing to see them helping each other. 768 | 769 | [2:23:00] 770 | 771 | LARRY: That's a whole level above even the individual relationships I feel, to see a community that is learning how to love, you know, kind of building the little bit of heaven on earth. There's just nothing like it. 772 | 773 | [APPLAUSE] 774 | 775 | CAROL: Completely agree. Guido, you get the last word. 776 | 777 | GUIDO: I love learning from (inaudible). 778 | 779 | CAROL: And we love learning from you as well. And with that I want to say we've all learned so much from all of our wonderful panelists tonight. I want to thank you for allowing me to share and celebrate this moment with you. The little fifth-grade kid in me that was plinking away on BASIC at Bell Labs, who later watched the PC cell phone, internet, web and Cloud computing change our world, never dreamed that I would be chatting with four individuals who profoundly impacted our world by doing what they... 780 | 781 | [2:24:00] 782 | 783 | CAROL: ...love, creating and building languages. Please join me in a huge round of applause to thank Anders, James, Larry, and Guido for inspiring this evening. 784 | 785 | [CHEERS/APPLAUSE] 786 | 787 | ANDERS: And thank you, Carol. 788 | 789 | [2:24:22] 790 | 791 | END (LANGUAGE-CREATORS.MP4) 792 | 793 | 794 | 795 | 796 | 797 | 798 | 799 | 800 | 801 | 802 | 803 | 2 804 | [LUCIANO RAMALHO] Red Pencil Transcripts LLC 805 | [LANGUAGE-CREATORS.MP4] Lolo, MT 59847 806 | (406) 240-2448 807 | 808 | -------------------------------------------------------------------------------- /trint/language-creators.csv: -------------------------------------------------------------------------------- 1 | In,Out,Duration,Text,Speaker,Status 2 | 00:00:00,00:00:38,00:00:37,"You guys ready some language creator. I have further to introduce Carol Willey. She is a python during counseling Project Jupiter Steering Council member. She blends the strings of pythonic. Jupiter notebook's to improve access to learning and education due to the worldwide foundation of the Pyfrom language. The hard work of the Jupiter team users worldwide. Carroll was awarded the Twenty Seventeen ACM Software System Award, recognizing the lasting influence of Jupiter, a broad collaboration to develop its open source tools for interactive computing with a language agnostic design.",,not-edited 3 | 00:00:38,00:00:39,00:00:00,Thank you.,,not-edited 4 | 00:00:47,00:00:59,00:00:11,"Welcome, everybody, for being here. It is my absolute pleasure to share this evening. You and some of the people that actually influenced my career in software development.",,not-edited 5 | 00:01:01,00:01:45,00:00:44,So let's get through this. And for those of you that are watching us on the lifespan. Hello and welcome and hope you have a wonderful evening with us. We haven't really distinguished panel of language creators. And I'd like to invite them to the stage as we read their bios. I'm going to keep the bios really short because I think most of them need no introduction whatsoever. And that'll save us some time more. Do you see language design stuff? OK. So first we have been Rassam to develop the Python language that touches pretty much every corner of society today in some way. And it's.,,not-edited 6 | 00:01:51,00:02:00,00:00:08,"He's the creator of Java, which is UK-EU, used across a broad variety of devices and deployments at scale. Well done.",,not-edited 7 | 00:02:00,00:02:01,00:00:01,And please get a.,,not-edited 8 | 00:02:07,00:02:19,00:00:11,"Childcare has architected a number of languages over the past several decades, including Turbo Pascal, Delphi, C-sharp, and so you might know this little language typescript.",,not-edited 9 | 00:02:26,00:02:27,00:00:00,Definitely not these.,,not-edited 10 | 00:02:27,00:02:40,00:00:12,Larry Wall to combined his unique perspective on text and computing with his strong background in linguistics to Craig Pearl and its sister sibling Pearl 6. Welcome.,,not-edited 11 | 00:02:51,00:03:04,00:00:13,"So just a couple of housekeeping things about this evening's format. You're in for an engaging and hopefully very lively discussion. More likely than we were at dinner. I think that's possible, right?",,not-edited 12 | 00:03:04,00:03:12,00:00:07,OK. The format. More beer. OK. We can do that. Keep it coming.,,not-edited 13 | 00:03:13,00:03:34,00:00:20,"OK. So the format will be two sessions with a fifteen minute intermission. What I'll do is I will start by asking one of the panelists a question, and hopefully a response will be like one to two minutes and then kind of throw it open for other panelists to respond and hopefully get a really good discussion going.",,not-edited 14 | 00:03:34,00:03:54,00:00:20,"And the more you discuss, the less I have to ask questions and the more in-depth we can go on the really cool stuff after the 15 minute intermission. We're going to take questions from the audience over a winner Twitter.",,not-edited 15 | 00:03:54,00:04:25,00:00:31,"OK. So tweet out your questions. Hashtag is happy bbf out. And if you can get those in by 8:00, we'll kind of collect them and have some really great audience questions about language creation and language design. So I'm going to invite you to sit back, enjoy a cup of strong Java Sea, start offering responses and insights, learned pearls of wisdom and embrace. The Python program makes it.",,not-edited 16 | 00:04:33,00:04:59,00:00:26,"We'll start the celebration with a question for Kito about principles of language design. You mentioned before, perhaps somewhat jokingly, the Harry Potter theory of language design. What is this theory and what do you see as the key principles of language design? I think you're good to me. Am I good? OK.",,not-edited 17 | 00:05:01,00:05:18,00:00:16,The Harry Potter theory of language design was close to. I do know that I cannot believe that every detail that J.K. Rowling puts on the first Harry Potter book was intended as.,,not-edited 18 | 00:05:20,00:05:40,00:00:20,"Some important Wolf point game part 6 or 7. And even if J.K. Rowling was such a genius that he hadn't actually owned land, that and that was who I think we found out the FUTHI was.",,not-edited 19 | 00:05:44,00:05:55,00:00:10,"But who won? It was just like a temporary diversion during the train ride. And otherwise, you didn't hear much about the rap with fingerprints in languages.",,not-edited 20 | 00:05:55,00:07:12,00:01:17,"I often. That's exactly how things go. You you choose some detail because you have to commit. You sort of you have to pick keywords. You have to choose a style of coding like you maybe you choose indentation instead of curly braces or maybe you don't. You're a special case, but whatever you do in some way, you're stuck with them and you find new uses of that. That detail that you picked before you knew how important that would be and the sort of the craft of designing the language is on one hand pick your initial set of choices so that there are a lot of possible continuations of the story. The other half of the of the art of language design is going back to your story and inventing creative ways of continuing it in a way that you had not.",,not-edited 21 | 00:07:15,00:07:19,00:00:04,So I think each of you have languages that span multiple decades.,,not-edited 22 | 00:07:19,00:07:52,00:00:33,"So what are some of the principles that made, you know, so so Javal would sort of on in the. It didn't come out of like a personal passion project or something. It was. From trying to build a prototype, you know, I mean, we were trying to understand it because the. A lot of time talking to people who build software or embedded systems.",,not-edited 23 | 00:07:59,00:08:19,00:00:19,"And you know, what was it in the whole process? How did their systems fit into the universe? It wasn't because I was trying to worry when we were worrying about things outside of data centers.",,not-edited 24 | 00:08:22,00:08:33,00:00:10,"This was a project that had about a dozen people on it and my little. Yeah, but it was my my little piece was what it was was sort of like.",,not-edited 25 | 00:08:36,00:08:59,00:00:22,"You know, we we we we sort of figured out that part of the problem was that. See has issues. And and so I started out so. So out of this like large pie of a project, my slice was.",,not-edited 26 | 00:09:01,00:09:09,00:00:08,To make things a little easier from a programing language point of view and fix the pain points that came from the programing language part.,,not-edited 27 | 00:09:10,00:09:29,00:00:19,"And it started out as kind of do a better see. And then it and it got out of control. The rest of the project really ended up just providing context. You know, the only thing out of that project that survived was was Java.",,not-edited 28 | 00:09:31,00:09:54,00:00:23,"But but but the fact that it was sort of directed at a set of pain points. But it happened to be it, you know, about people who were living outside of data centers and people who were. Getting shredded by problems with networking and security and reliability.",,not-edited 29 | 00:09:56,00:10:28,00:00:31,"They had to build things that ran in hostile environments like in the homes, which in any home with a child in it is a it is a hostile environment. Speaking of hostile environments, feral. What are some of the guiding principles for designing for a business? I love you, Larry.",,not-edited 30 | 00:10:40,00:11:19,00:00:38,"More and more coming out of this. A computer scientist. So I sort of actively ignored some of the computer science literature of the time and said, well, what can we just talk together? One part of the brain will work more like a natural language instead of. But instead of putting on a campus university campus and deciding world, the walkways would go, we're just going to see where people want to walk. And they put shortcuts in all those places and know that more as a network, not as a terribly orthogonal or computer science or mathematical thing.",,not-edited 31 | 00:11:20,00:11:30,00:00:10,And then that turned out to be in the right place at the right time for bootstrapping a lot of the web and.,,not-edited 32 | 00:11:31,00:12:33,00:01:01,"It also got used a lot for system administration and so various principles that relate to trying to provide API eyes to everything. I'm trying to be both a good text processing language linguistically, but also a quick Google language. Here's why it was. Kind of very useful, was hasty and there was text and, you know, database seconds that's that needs. And so it was in the right place at the right time. We were very fortunate to have that time because in the 90s it became very stable, a lot of a lot of widespread use. Lot of people were you know, the language itself was stabilizing in the form that it was. But there were a lot of issues and salat. And so in the year 2000, we we took a step back and and and basically said, we're gonna break everything he's breaking.",,not-edited 33 | 00:12:33,00:13:15,00:00:41,"So we kind of did the same thing. You know, it's done the pipeline to the step, except instead of breaking a few things, we decided to break everything here. So we came up with a whole raft of design principles and 50 years since then. By the way, forensics did come up two years ago. It's getting faster. And it's suddenly at the beginning we said we were going to do something impossible and and fail at it could be a very big failure. And so far, this proved me to be that. But in the course of the fail. Yeah. In the course of that, we came up some really interesting list of about 60 different design principles.",,not-edited 34 | 00:13:19,00:13:27,00:00:08,"When read, even though I think many of them have already, you know, you know, kill two birds with one stone, pick the right people, you know.",,not-edited 35 | 00:13:29,00:13:34,00:00:04,"It's possible like that. But we came up with some cute ones, like, you think that's cute today?",,not-edited 36 | 00:13:38,00:13:41,00:00:02,"Oh, oh, know.",,not-edited 37 | 00:13:43,00:14:47,00:01:04,"Conserve your brackets because SFE, even Unicode does not have enough brackets that don't reinvent object orientation queerly, which arguably provided no substitute strong features for weak buttons, late binding sometimes oposite programs be. But some of the major ones are, you know, a lot of the stuff is just perfect to screw over time. And, you know, there were a lot of weird magical variables I'm going to. And so. A great deal of the redesign was to say, OK, what is the right peg to hang everything on? Is it off to Korea? Is it something in the works for school or in a larger school? Or what is the right to have each piece of information on? And if we don't have that thing, how do we create it? Great question.",,not-edited 38 | 00:14:48,00:15:02,00:00:14,"And since it's such a great question, Anderson, the spot and Terrence Parr had a quiz about while programmers value simplicity, they more often value powerful functionality.",,not-edited 39 | 00:15:02,00:15:18,00:00:16,"An amazing one liners incurring the cost of complexity. So for express. Yes. So what are your thoughts about simplicity versus complexity and some of the principles that might guide you, as you know? Really?",,not-edited 40 | 00:15:22,00:15:35,00:00:12,"Suppose I. I was always late in doing the language, saying that I've done. Always tried to make it so that there was only one way.",,not-edited 41 | 00:15:37,00:15:49,00:00:12,So a lot of languages have four different ways of doing something and you pick the wrong one. And then only later you realize you went down the wrong branch and now you've got it back up.,,not-edited 42 | 00:15:49,00:16:37,00:00:48,"And so. So it's not it's not always easy. And I think there's like often we're guilty of creating what I call this thing I call simplex. Take something from blacks, you grab a single wrapper on top of it. That's make the complexity go away, but you're really creating is simplicity. You know, it's just like a bad abstraction on top of another bad abstraction that is simpler. So I don't know. I mean, it's it's we think that as picking up correct default overly complex thing. Yeah. But but I mean, the thing about that, about language design is like like any any decision you have to live with forever.",,not-edited 43 | 00:16:38,00:17:25,00:00:46,"I mean that and in languages you you can always add, but you can never take away. And so you've got to actually, as a language sign up to be very judicious. About reasoning over not so much what to put in, but what not to put it, an army because people come to you all the time. Wouldn't it be great if you could do this with that? Are you going to? Well, yeah, but you can't fundamentally change the nature of the beast. If you created an empirical and an imperative programing language, you can't turn it into a functional program. Show me you can you can borrow from functional programing. But it is what it is. And you gotta stay true to the nature of the beast, or you gotta create a new beast so-to-speak. Right.",,not-edited 44 | 00:17:27,00:17:36,00:00:09,Any other thoughts? Excuse me? Can we interrupt you or you may have to interrupt any time. So.,,not-edited 45 | 00:17:38,00:18:02,00:00:24,"This is sort of the point about what what do you leave out? And the what I remember in the early days of Python's design, there were so many people who thought they had a good idea. Is sufficiently critical to say no.",,not-edited 46 | 00:18:03,00:19:37,00:01:33,"And so there are a few things that didn't work out at the time, I I haven't learned to say no. And I quickly enough did learn to say no. And I sort of felt like several lines of defense. Like the first line of defense is, hey, you think you need a new language feature, but actually you can already write that typo if you needed the locked right to function or a module. Well, if they say, yeah, but everybody needs that. Well nowadays we say put it on the package repository in those days. I said well maybe you can propose a new standard library module. That's a lot cheaper for the language design than the new language feature. And another line of defense was, well, you can actually write extensions in C or Fortran if you really care to. And you can help yourself that you can modify the behavior of the language in ways that aren't accessible when you just write the pure language. But you can still sort of you can extend it in a way that doesn't fundamentally alter the core language. And if you've tried all those things and and you failed, then maybe you could argue for, well, you have to change something in the core language. Hi, I'm interrupting.",,not-edited 47 | 00:19:39,00:20:29,00:00:50,"I find that whenever I get feedback on whatever whatever it is, program makers, I've been working on it. It's people come to you with a with a particular instance of a problem. And it's your job as a language assignment to tease out the class problem they're talking about and then try to understand whether there is a feature there underneath that you could put in place that is broadly applicable, not just to that one crawl. You're putting in place a class, not an instance suit. So that damn slide. And if all you're talking about is an instance, then you're probably better off. Save your money for power.",,not-edited 48 | 00:20:32,00:21:00,00:00:27,"Actually found this. In the early design of the Perl 6, we asked our CS I expected. Since we got 361, so we have this in spades lately. And, you know, it's completely overwhelming. Until I hit upon this principle, which Anderson alluded to, which is basically a lot of the proposed solution. Yeah, but there is a pain point underneath.",,not-edited 49 | 00:21:01,00:22:06,00:01:05,"And if you look at more enough of these RFD and they haven't seen pain point, there is something you should address. There's some fundamental unification you should do underneath or something that is is clunky that could be fixed. And especially if you're doing a complete redesign that you can think about the sort of. To fix it. How do you know? There were a lot of problems where. Difference that just won a victory with themselves. You get like 40 different.",,not-edited 50 | 00:22:35,00:23:13,00:00:38,"Released. It was really clear in the way that this was like a big issue and you feel dry and I came about as close to spilling blood on this topic as I've got. And, you know, I would much rather. Do something much, rather leave something out there, do something stupid. One of our principals planned to visit Margaret later. Yeah. Well, well, what that means is that that means the opening answer is no. No. Right.",,not-edited 51 | 00:23:14,00:23:59,00:00:45,"And one of the things that happened with like a whole bunch of different outfits and their job was that they kind of turned into competitions and generics and closer to work both. Probably the most hard fought competition. People were writing pretty steep pieces on the topic. And I was like trying them all out. I mean, some had no shortage of smart people at the time, but it's really hard to be a planet full of grad students, even grad students. At some point, I think most kids who were in grad school. That's correct. And in linguistics and linguistics. But it's.",,not-edited 52 | 00:24:00,00:24:20,00:00:20,"Oh, probably 20, 30 years ago to say I'm going to write my own language. And people are very different. Back then, the Internet was sort of starting. Maybe not that they're single. I think we have computers. We have cell phones.",,not-edited 53 | 00:24:20,00:24:23,00:00:03,"Nobody cared, but nobody cared. What's all that about?",,not-edited 54 | 00:24:24,00:24:27,00:00:02,Nobody cared what you did with the eighth that.,,not-edited 55 | 00:24:31,00:24:44,00:00:12,Decades. But these are languages that persisted. Many changes and they're on different hardware.,,not-edited 56 | 00:24:45,00:25:13,00:00:28,"When you started designing your language, what was the key goal that you were trying to meet versus using some other extinguishment? Well, I mean, for me, it's never been people. And one of the secrets of success is try to solve as many problems at once as you can. And, you know, if there's just one problem, there's probably an easier way.",,not-edited 57 | 00:25:17,00:25:23,00:00:06,Right. Right. You think that way you'll never have a new program.,,not-edited 58 | 00:25:25,00:25:33,00:00:08,"Well, there's always a better solution in the 300. Well, it depends on how much you pay. Chasing down memory, corruption.",,not-edited 59 | 00:25:34,00:25:43,00:00:09,But the three virtues of the program are. Blasi This impatience and cupids takes Kupers.,,not-edited 60 | 00:25:46,00:26:05,00:00:18,The world needs another program like. Is that a code? But the thing about programing language is that I think a lot of people don't realize that every programing language is about 90 percent the same and maybe 10 percent if you're lucky.,,not-edited 61 | 00:26:06,00:26:14,00:00:07,And a lot of people get very focused on the 10 percent new and forget about the 90 percent of the same. That makes it at great length. Right.,,not-edited 62 | 00:26:14,00:26:21,00:00:06,"I mean, there's a lot of hard or you work in creating programing language, loss, semantics that it's got to worry about.",,not-edited 63 | 00:26:21,00:26:29,00:00:08,And like everyone and loves to talk about syntax and syntax is the easy part. Semantics is the hard part.,,not-edited 64 | 00:26:30,00:26:52,00:00:21,"You know, like how do the types of work and one of one only dogbone supported promotions and one of the different kinds of type constructors that the language, as etc. said are these are the hard things to do to design. But, but but not the things that people people love to bike shed on the syntax, you know, shouldn't be a colon or or comma.",,not-edited 65 | 00:26:52,00:27:05,00:00:13,"You know, it's like, oh my God, it's have a long thread about that. So talking about people having opinions and syntax and typing.",,not-edited 66 | 00:27:08,00:27:22,00:00:13,These languages don't all take the same approach to typing. Maybe we'll start with veto and talk about typing in Python and then kind of work our way around.,,not-edited 67 | 00:27:30,00:28:10,00:00:40,"I mean, I just remember that when Pyfrom first happened, it was not a class. It was a little conversion function. There was an internal object type, which was really just kind of a Zite table that represented integer objects. And there was a built in function if you needed to convert the string to an integer and that was we had a bunch of those functions and we realized that we we had made a mistake.",,not-edited 68 | 00:28:11,00:30:13,00:02:02,"We had given users classes that were different from the built in object types. And for a long time, it was like, oh, well, like the real stuff is implemented in C and the user writes a little bit of blue top of that. And when when I found out that we had 80 different competing web frameworks, it was sort of time to to realize that people were writing much larger programs. And that's a different approach. Two types was needed. And that's where we sort of reinvented the whole approach to types in Python. And there was a bunch of cleanup that didn't happen until 5 3, actually. But one of the things we introduced and we were lucky that there weren't actually despite those 80 web frameworks, there weren't enough users that we were completely stymied by backwards compatibility. Yet like we are now. So we just one day we changed the function into a designated for the class. And sort of followed that calling, the class would be constructing an instance of the class so that if you had simple code that wrote in left brand some expression right. And would work exactly the same way that we have the same effect. But the workings inside were completely different. There was one particular file that's sort of implemented the that's sort of the basic functionality of types in the language and it in for one to it was like 50 lines of code. And at some point I rewrote it and it was five thousand by.",,not-edited 69 | 00:30:16,00:30:59,00:00:42,"That's great. What about Titus in Dublin? I got this this this one history of caring about things like. Building robot software often that that that comes out about, you know, I'm much more worried about what it takes to build production quality software than about what it takes, just like you like a quick thing and chuckles not a great language for.",,not-edited 70 | 00:30:59,00:32:37,00:01:37,"Things, but it's it's OK, it's not for me. One of the one of the things that I love to do and maybe I'm weird, but being able to do automatic or improving on hunks of cup and and. Type system is a really great place to be, one of the foundations there begin they're improving it for. Four months of code turns out to be really useful for things like building optimized. And doing it ahead of time. To be able to hear improvable way as many things as possible, so satellite like like, you know, one of the not well-known things about about Java is that, you know, in the jobless pack, you know, it says Ouray, subscript checking is always on. But, you know, it's only conceptually all of his all right. But the truth is that there are there's more than on my books or the compiler to improve away almost all index checks. And same thing with like null pointer checks and all kinds of things that look like they're heavy weight, but they're really cheap, you know, so it's a one of the things that I like. I really cared about it.",,not-edited 71 | 00:32:37,00:32:58,00:00:20,"The time was that A plus B should almost always be at most one instruction bonus points for zero instructions. What about after? Well, the thing about zero instructions is often you can like fold them into some weird addressing mode. Right.",,not-edited 72 | 00:32:59,00:34:20,00:01:20,"And. And so in kind of the universe, I'm right, I tend to live. Being able to look at A plus B and realize it's that destruction that all feeds off of the type system. And sometimes you can you can do this with sort of optimistic just-in-time coupon compilation, depending on how far you want to push that. So like the the JavaScript engine in Chrome is is absolutely astonishing for the the kind of core that they go through too optimistically. JavaScript code, but it's also very hard to do those kinds of tricks if you're trying to get into smaller devices. So, you know, there are there are Java compilers that work for machines that only have like. You know, to do that kind of compact distillation, you need every kind of hope that gives you every little every last drop of information. And the earlier, you know, what better job you can do.",,not-edited 73 | 00:34:20,00:34:32,00:00:11,"Right. So speaking of lots of information that one gets, typescript gives you a lot of flexibility and power. What's your general view that typing?",,not-edited 74 | 00:34:34,00:34:45,00:00:10,"Well, let me actually it's funny that you mention cycles and counting. How many? And whenever I do, I remember when I wrote Turbo Pascal, which was all written in C-A-T assembly code.",,not-edited 75 | 00:34:45,00:34:56,00:00:11,"And back in those days, you could literally look up the intel manual on the sidewalk or whatever, you know, and see how many clock cycles every construction took. And actually it would work out just like that.",,not-edited 76 | 00:34:56,00:35:12,00:00:16,I remember now everything takes zero clock cycles except when it takes a thousand clocks. The memory and it is absolutely impossible. The reason about what I've seen you use execute your code today. That that's just one.,,not-edited 77 | 00:35:13,00:35:19,00:00:06,"Well, it's not impossible, but it's much harder. Yeah, it is a complete pain in the ass.",,not-edited 78 | 00:35:21,00:35:35,00:00:14,"And they don't give you manuals. Not good at all. You don't want to actually understand that. If you need to get the chip diagrams. But but with respect to types, I've always worked on programing languages that have type systems.",,not-edited 79 | 00:35:35,00:36:29,00:00:53,"But it's interesting how it's gone from being type systems far for the code generators sake or type systems for four for, you know, generating errors too. Now I almost view type systems as as a tooling feature, and that's really sort of the thing that has been interesting. High automate for typescript. It is, you know, first of all, starting with a dynamically typed programing language like JavaScript and then trying to add a type system on top of it that that faithfully reflects the semantics of the programing language. And the reason for doing it is actually not because we think type systems are interesting, but because if you think about what it is that powers programmer productivity today, like everyone loves their I.T. like. Whatever you're using, I hope it's Visual Studio code.",,not-edited 80 | 00:36:29,00:37:03,00:00:34,"But putting that if it's not, you know, I am sure you're all like accustomed to things like state completion and refactoring code navigation and go to definition and so forth. And if you think about it, the things that the thing that powers that is semantic knowledge of your code. And the thing that provides the semantic knowledge of your code is a compiler with a type system. And once you add types, you can actually dramatically increase productivity, which in some ways seems counter counter intuitive. Right.",,not-edited 81 | 00:37:03,00:37:11,00:00:07,I thought like dynamic languages were easier to to to approach because you got rid of the types which was like a bother all the time.,,not-edited 82 | 00:37:11,00:37:22,00:00:11,"Well, look, when it turns out that you can actually be more productive by by adding types if you do it in a non-intrusive manner and if you work hard on doing good type inference and so forth.",,not-edited 83 | 00:37:23,00:37:32,00:00:09,"So, so, so, so, so, so. So I want to jump in here. And then I take over.",,not-edited 84 | 00:37:34,00:37:41,00:00:07,"So I really, really, really believe in that point in the in the in the power tools for power geeks.",,not-edited 85 | 00:37:44,00:37:57,00:00:13,"And one of the things that drives me nuts is the real man usvi movement. And, you know, it's it's really I just want to punch people who are.",,not-edited 86 | 00:37:57,00:38:07,00:00:09,"But I'm really inside state. I I'm a real developer because I use v.i. And it's like, you know, I do it the hard way. I think.",,not-edited 87 | 00:38:07,00:38:10,00:00:03,I think I make language developers lazy.,,not-edited 88 | 00:38:20,00:38:33,00:00:13,"IBRD Let me get a lot more done a lot faster, OK? I mean, I'm not I I mean, I'm really not into proving my manhood. I'm good at getting things done.",,not-edited 89 | 00:38:36,00:38:41,00:00:05,"Case in point, but I take the devil's advocate here first said he meant something like.",,not-edited 90 | 00:38:43,00:38:51,00:00:07,"Yeah, but you their notebooks, a lot of science people. Data scientists get a lot done.",,not-edited 91 | 00:38:51,00:39:00,00:00:08,It's actually a pretty simplistic I need a dynamic language. Most of the time.,,not-edited 92 | 00:39:00,00:39:12,00:00:11,"So you could get a lot more than that. I don't know. No, but I think typeset. I mean, it's not just a type system can help you.",,not-edited 93 | 00:39:12,00:39:33,00:00:21,"First of all, if you're uninitiated and you want to know here, here's my food and now I say food dot and then the ivy can show you. What can I type next? Right. As opposed to I gotta go read manuals and figure it out or know it. All right. I mean, your original developer of whatever piece of code might know it all, but then people move on and new people come in.",,not-edited 94 | 00:39:34,00:39:54,00:00:19,"You know, there's here's this project. There was there was no documentation written about it. And if you think about it, types or documentation to write, I mean, and then there just there's so many things about like like adding them that down the line give you increased productivity.",,not-edited 95 | 00:39:54,00:39:59,00:00:04,So there's productivity and then that's that's maintainability.,,not-edited 96 | 00:40:00,00:40:07,00:00:07,"Oh, well both. And maybe any different thoughts about how you get to talk about types. Well, talk.",,not-edited 97 | 00:40:09,00:40:22,00:00:12,"The colonel types out. Well, that story is very different for profile purposes. As you know, Girlfight, to sort of rural over time and the whole idea was sort of particularly idea.",,not-edited 98 | 00:40:22,00:40:55,00:00:32,"Everything you can pretend everything is a straight even if it's a number or floating point internally, it's stalled, you know, interchangeable. And that works out for bootstrapping people into a language. They're quite nicely. And it's it's a feature that we wanted to keep in Perl 6. But what we discovered in Perl 5 is part of the redesign was it's it's fine if the user is confused about the interchangeability to tell more for the Muslim to take the care of your standard.",,not-edited 99 | 00:40:55,00:40:59,00:00:04,Tikes But it's not so good if the computer is confused about.,,not-edited 100 | 00:41:01,00:42:15,00:01:13,"You know, for all the girl wanted, it was written way back in the dark ages. You had a schuberg, a bunch of stuff in, and it cheated a lot. So part of the redesign when we did girls school Perl 6 thing we wanted to do object oriented programing that is that these languages and we wanted to be functional programing that are the most functional programing languages. To do that you have to have a fundamental very sound type system of a sound object model underneath. And you really have to take seriously these slogans like everything is an object. Everything is like closure. Every feel the process, even blocks are closures. And he has got to optimize. Hard to get up, get them away from there. But but I I also agree with this idea that the tikes also are cultural. I talked about Pei's hanging things on pace. They're one of the one of the picks. We didn't have something to hang on the prettified. And now we we can Pangle. But all of that information and then just run a little program there. And then you have to have an idea. They say, well, this object. You know what methods.",,not-edited 101 | 00:42:15,00:42:23,00:00:08,"But what you know, they could do their own introspection. The whole thing. And people just you know, I'm baffled by the way we do also have an idea.",,not-edited 102 | 00:42:27,00:42:39,00:00:12,Good points all around. So most of the time programmers actually spend maintaining versus writing new code out in the wild and.,,not-edited 103 | 00:42:41,00:42:48,00:00:07,What things or elements of a programing language make it easier to maintain? And maybe we'll start with Fito.,,not-edited 104 | 00:42:52,00:43:11,00:00:18,"Well, I found that. TypeScript is actually incredibly useful, and so we're adding a very similar idea to Python, adding it in a slightly good way because. We are taxed.",,not-edited 105 | 00:43:28,00:43:59,00:00:30,"All right. Go. Anyway, we have time. I sort of learned a painful lesson of that before school programs. Seafair dynamic typing is great for large programs. You have to have a more disciplined approach and it helps if the language actually gives you that. It's rather than telling you, well, you can do whatever you want.",,not-edited 106 | 00:44:02,00:44:12,00:00:10,"Yeah, yeah. That was part of our scale up idea for Perl 6, the typist would help with programing in large because we didn't notice those limitations.",,not-edited 107 | 00:44:16,00:44:36,00:00:19,"One year ago, I started working really heavily on Unbury Factoring In. And, you know, being able to do like large scale refactoring is unlike millions of lines of code at once, that really changes the way you think about maintaining code.",,not-edited 108 | 00:44:37,00:45:32,00:00:55,"Because, you know, the world is filled with libraries that have things like stupid variable names, stupid method names, because, you know, when you started out, it meant one thing. But now you realize that you really didn't really understand what you were doing in the beginning. And so this this method name really should be different. But nobody ever Reding's methods because it's really hard to go over a piece of code and rename. Exactly. That's the right variable. But if you've got a good refactoring engine, you just you just type, you know, medic control are typing the new name, you know, hundreds and hundreds of files later, which takes about, you know, maybe 30 seconds if it's a lot of files. You're done. And so you basically be right.",,not-edited 109 | 00:45:34,00:45:43,00:00:09,"Seven-part series, I hope this is this is actually like you're describing, that's what we what.",,not-edited 110 | 00:45:43,00:45:59,00:00:16,"What was the genesis of the typescript project, which was these enormous JavaScript code basis that we were seeing customers. Right. And then in-house projects that they were getting bigger and bigger because JavaScript engines were getting good enough for you to write really big programs.",,not-edited 111 | 00:46:00,00:46:12,00:00:12,"But maintaining them was impossible because it turned into write only code. You know, you do dare not touch it. Once you've written it because it worked then and then. But, you know, there's this property called text.",,not-edited 112 | 00:46:13,00:46:35,00:00:21,"And I really want to change it to be like some other name, except there is like a million other properties called text. And if I'd just like to do a global search and replace for tax, then oh my God, it's like at all. So I can't change anything. But if you have semantic understanding up like this property call text is different from that other property over here.",,not-edited 113 | 00:46:35,00:47:04,00:00:29,"Call text. And if you want to rename this one, that doesn't mean you want to rename that one. But but that takes for something like a type system to be in place. And, you know, once you start adding that, you add documentation to the code and you add these capabilities where we're now seeing people like with regularity, refactor one hundreds of thousands of lines of JavaScript code, you know, we'd like ten minutes and end it and it just works afterwards. And people are like amazed that it's possible.",,not-edited 114 | 00:47:06,00:47:19,00:00:13,"But but but it's true. Said it takes a bit more work to begin with. And it's not maybe not right. If you're writing five lines of code that maybe more bother than you really care to. But but, you know, it started to pay off pretty quickly.",,not-edited 115 | 00:47:21,00:47:40,00:00:19,There are different types of really good lexical scoping helps with refactoring. It gets back into this. What's the right pick to hang the sign up and off and it's slope. It's a lexically skulked or dynamically scale. So now we're doing those right and not interfering with threading.,,not-edited 116 | 00:47:43,00:48:09,00:00:26,"So I have one more question now before the break in three minutes and we made sort of a reference to Donald New, one of the turning winners in this last section of conversation. And he wrote, Premature optimization is the root of all evil. So what's your approach to optimizing code and gaining efficiency, saying Python?",,not-edited 117 | 00:48:12,00:48:15,00:00:03,"Well, I I'm terrible at that. So I leave it to others.",,not-edited 118 | 00:48:17,00:48:24,00:00:07,That is a very wise language creator and they've lived up to the task.,,not-edited 119 | 00:48:26,00:48:30,00:00:04,Piceance hash table implementation has been rewritten so many times.,,not-edited 120 | 00:48:32,00:48:45,00:00:13,"I don't understand any part of it, but it is so much better than the thing I actually copied out of truth 30 years ago. Happy to have a clue.",,not-edited 121 | 00:48:46,00:49:14,00:00:28,"Okey doke. I kind of 50 percent believe that because they're, you know, the premature optimization in terms of algorithms and code. That part of it, I believe. But people often don't really think about the role of data structures in optimization and interpret data structures exposed.",,not-edited 122 | 00:49:16,00:49:50,00:00:33,"You have to know and you decide that, you know, this algorithm is a problem. But, you know, the reason that it's a problem is because, you know, this data structure was just slapped together and they thought, oh, they'd only ever be like 10 items in the list or 10 items in the set. And then and then you start, you know, having, you know, million eight million items sets all the time. And all of a sudden, you know, you're a little linkedlist is. And that is not gonna happen. Right.",,not-edited 123 | 00:49:50,00:50:01,00:00:10,"Ex-directory or a unit or. Yeah. And and so and so if you can you know, it's like you know hyd early hide.",,not-edited 124 | 00:50:01,00:50:06,00:00:05,Often. Right. Never tell the truth about what your data structures are.,,not-edited 125 | 00:50:09,00:50:14,00:00:04,"And on that note, we're going to take a quick look.",,not-edited 126 | 00:50:14,00:50:32,00:00:17,"I just want to say that I think like with anything, the important thing is to make sure that you actually have the right data before you you start optimizing. Right. By too often you have a hunch that, oh, I think finally I need to do this.",,not-edited 127 | 00:50:32,00:50:36,00:00:04,And I need to change this data structure from being a linkedlist to being overweight or whatever.,,not-edited 128 | 00:50:36,00:51:00,00:00:23,"But but if you measure, then you discover it doesn't matter. And but really, there's this other thing that you haven't even thought about that matters enormously. And maybe you should go look over there. So get perf., get it, use a profile or figure out where it is, the time actually spent. I am continually surprised and I write compilers for a living and I'm always surprised by where time is spent. All right.",,not-edited 129 | 00:51:01,00:51:07,00:00:06,And that is that we're out of time for this section. We're going to take a quick 15 minute break.,,not-edited 130 | 00:51:09,00:51:22,00:00:13,"And when we come back, the really hard questions are going to come out because the audience questions that have been submitted are going to be the ones that believe in you. So thank you.",,not-edited 131 | 00:51:55,00:52:00,00:00:04,And teach in every one of you has a community that is formed around the languages that you've created.,,not-edited 132 | 00:52:00,00:52:07,00:00:07,"I'm curious if you were talk two ways in which you've seen the design choices you've made for your language, so shaping the communities that are formed around.",,not-edited 133 | 00:52:11,00:52:22,00:00:11,"It really helps. Well, good. It really helps if you're trying to make everybody look what's here with your slogan here.",,not-edited 134 | 00:52:24,00:52:34,00:00:10,"Everybody comfortable? We're doing that right now. They think they can make all of all Americans, I heard.",,not-edited 135 | 00:52:37,00:52:46,00:00:08,"You know, feel like comfortable programing. You see it for all. Yes. To make sense of it. I guess you know what?",,not-edited 136 | 00:52:48,00:52:49,00:00:01,The sign was a clue.,,not-edited 137 | 00:52:51,00:52:57,00:00:06,"It's not see us for all of us, just Americans. No. There are many underserved populations in the world.",,not-edited 138 | 00:52:57,00:53:22,00:00:24,"And what we've really discovered that it really helps build international camaraderie and community to have world class literally support for unico. Yes. I would encourage any language designers out there. Don't do this halfway stuff with, you know, code points. Go all the graphics.",,not-edited 139 | 00:53:23,00:53:28,00:00:05,"I completely agree. Kita, you had something you were going to say.",,not-edited 140 | 00:53:29,00:53:31,00:00:02,I was trying to say.,,not-edited 141 | 00:53:33,00:54:32,00:00:59,"I how my design choices necessary to make choices about how to use energy certainly have. Did I? I was somehow a dude with the importance of user centered based something because by comparison. That was ABC long lost, its authors had a of things right, and one of those was listen to the users asking users what they think. And then again, you making a new one of their suggested solutions. And you first figure out what nobody spends. You gave users a voice. And I said, take that back and let the users help. And now they're raising of.",,not-edited 142 | 00:54:36,00:55:27,00:00:50,"I was going to say I always felt like it's important as a language society that you don't create unnecessary work for your community because it's it's very easy to in the name of purity or whatever. Go change something or or strive for the perfect language. And I've always said, like, I mean, show me the perfect language and I'll show you your language with no use or shoot over. Every every language has its functions. Has them because. Because it has evolved. And the hard part of language aside is actually not version one. It's like the older versions that come after you try to sneak things in without actually causing extra burdens on people who don't necessarily care about the things that you're trying to sneak in. Right. And so.",,not-edited 143 | 00:55:27,00:55:38,00:00:10,"So that's the hard part of language design, I think is is the evolution of the language and keeping your community with you as you have all.",,not-edited 144 | 00:55:40,00:57:24,00:01:43,"Yeah. And so and so with with Jarbawi like always followed that we've maybe been a little bit excessive about it. I mean, I've got binaries that I compiled like 20 years ago, but still run. And and it's it's, you know, on machines that were never invented when the code was compiled. And you only get there with with crazy discipline and and a a tolerance for living with your mistakes. But but it but it makes the you. It also help. It also ends up selecting who your users are because in the in the Java universe, pretty much everybody is is really disciplined because, you know, it's kind of like like mountain climbing. You know, you you don't get there, get sloppy with your gear when you're mountain climbing because it has a clear price. And, you know, when you you said something about Larry, you said it said something about Unicode Java's had Unicode since ninety two. So, you know, it's, you know, trying to be inclusive. Yeah. And and that really made a difference. I mean lots of folks thought it was like the lamest thing ever. But that was that that was during my my, you know, Lord of Java phase which. Yeah. Yeah. But that that phase of my life ended in about ninety five.",,not-edited 145 | 00:57:25,00:57:27,00:00:01,I'd like to say something possibilitythat.,,not-edited 146 | 00:57:30,00:57:40,00:00:10,And that is we did this perfect try to perfect compatibility. All the way through. I didn't really think.,,not-edited 147 | 00:57:45,00:58:03,00:00:18,"That eventually runs into the problem. But, you know, you can't I can't fix your mistakes. So one of the mistakes that we made was was kind of a mistake and that was assuming that you had to always have that kind of stability and not change anything.",,not-edited 148 | 00:58:04,00:58:17,00:00:12,How would it be to design a language where the language itself could be evolved from within by the community and the language we want?,,not-edited 149 | 00:58:17,00:58:32,00:00:15,"Twenty five or 50 years from now, this ties into what Polygram was talking about, a hundred year language. We kind of took that seriously. What is it that prevents languages from evolving, not being not having things still thrive?",,not-edited 150 | 00:58:34,00:58:54,00:00:19,"But fundamentally, the Perl 6 compiler is written in Perl 6. Most the runtime system is written in Perl 6. The users can extend it. Perl 6 itself does not care whether things are built in or not. It all works the same. So most of the buildings are written as if they were used or code.",,not-edited 151 | 00:58:55,00:59:31,00:00:36,"So users, even if we say no, we don't want that language right now. But put it in a module you can do. You can turn classes in two monitors with about that much code. You can put into implement actor model classes with about about how much code you can you take. Adding operators is just trivial. When it does, it does everything perfectly one pass and drops into the sub compiler. And with the end, it comes back out. So there's never, ever any ambiguity as to what language you are in.",,not-edited 152 | 00:59:32,01:00:02,00:00:29,"And so because this scoping of the exact language you're in is always like if we scoped any lexical scope can say use whatever language I want a feature version of Perl 6. You could say use COBOL, use Python. If someone actually people have written Python parsers in April 6, I don't think anybody's going to call for sure yet, but we'd like to think that, you know, a lot of language stuff like languages and Perl 6.",,not-edited 153 | 01:00:03,01:00:18,00:00:15,So I think that I think the third module of semantics would likely. But I think there is a way us. I think there is a way forward to get the stability and rehabilitation.,,not-edited 154 | 01:00:19,01:00:20,00:00:00,And I think.,,not-edited 155 | 01:00:23,01:00:26,00:00:03,Awesome. Do we want to take another audience question?,,not-edited 156 | 01:00:28,01:00:32,00:00:03,All right. Thanks.,,not-edited 157 | 01:00:36,01:00:41,00:00:04,Can you talk into the mike like you're eating the mike? Hi. Yeah. Can you hear me? Yeah.,,not-edited 158 | 01:00:42,01:00:58,00:00:16,"There's been a lot of talk tonight about the evolve ability of languages and the trouble with implementing things that might not be backwards compatible. What's something that you wish you could have implemented with your language? But for that, or maybe another reason that wasn't possible.",,not-edited 159 | 01:01:02,01:01:29,00:00:27,"A word, right? As all the words or these or other forms of naming is hard.",,not-edited 160 | 01:01:31,01:01:46,00:00:14,"Well, I'll I'll I'll go. I've. I mean I my favorite is always like d that the two billion dollar mistake of the billion dollar mistake of having Nall in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake.",,not-edited 161 | 01:01:48,01:01:51,00:00:03,But I mean if it did.,,not-edited 162 | 01:01:52,01:02:11,00:00:19,"And I mean what's done is done right. And and now now, you know, I spend a significant portion of my time actually working on ways to to make code null safe to and who's never who in here has ever had a null pointer exception.",,not-edited 163 | 01:02:12,01:02:40,00:00:28,"Right. There you go. It's it is by far the most problematic part of language design. It it's a single value that that if only that wasn't there. Imagine all the problems we wouldn't have. Right. If if type systems were designed that way and some type systems are and some type systems are getting there. But boy, trying to retrofit that on top of a type system that has normal in the first place is quite an undertaking.",,not-edited 164 | 01:02:41,01:02:54,00:00:12,"The features I wanted to add were negative features. I think all of us as language designers have borrowed things. You know, we all steal from each other's languages all the time.",,not-edited 165 | 01:02:55,01:03:00,00:00:04,And and it's often we steal good things.,,not-edited 166 | 01:03:00,01:03:08,00:00:08,"But for some reason, we also steal bad things. You know, like what? Like regular expression syntax.",,not-edited 167 | 01:03:08,01:03:15,00:00:06,"Oh, yeah. I did that one. Like the C precedence table. OK. Another.",,not-edited 168 | 01:03:15,01:03:25,00:00:09,OK. These are things that I could not fix in four or five. And we did fix it. Burleson's. Awesome.,,not-edited 169 | 01:03:25,01:03:31,00:00:05,All right. We do tend to be doing pretty well with the audience. So how would another audience question?,,not-edited 170 | 01:03:36,01:04:52,00:01:15,"Hi. Hello there. So, well, what I wanted to ask is you can sort of know what is these sort of pendulum effect in regards to tech and programing, throw it out. Time to Vinick's several different paradigms. There's a certain time where people were like, are we going to do things imperatively? Are we going to go object oriented or functional? And for example, right now there's a whole bunch of language used are sort of like very aggressively taking that standpoint of being very pro, being friendly with concurrency or being bery regardless of what immutability with memory. And I think that that kind of pendulum effect happens because technology has actually been evolving throughout time. Our machines are like beefier and we have more memory now. So that waste on we design programing languages now are probably a lot different than there were 20 or 30 years ago. So considering that, where do you think or how do you think the programing languages of 10 years into the future are going to look like? Or in your opinion, where where is language you design headed to in the future?",,not-edited 171 | 01:04:53,01:05:06,00:00:13,"So. So. So my favorite candidate for that is that, you know, these, you know, major breaks and things like that always happen because, you know, something major happens in the underlying technology.",,not-edited 172 | 01:05:07,01:05:29,00:00:21,"And, you know, one of the areas of underlying technology that is kind of like a computer that I think is really underserved is is writing code for GP use. Right. I mean, right now there are there are no languages worth that crap.",,not-edited 173 | 01:05:30,01:06:01,00:00:31,"And that's a technical for trademark that work well on GP use. And, you know, maybe because there's like a limited number of algorithms that people are willing to are really interested in, but they're really important ones. Or maybe it's because they're they're inherently all mathematical. And the number of people who care about writing numerical code is small. I'm one of those, though.",,not-edited 174 | 01:06:02,01:06:10,00:00:08,"And you know, and so every now and then, I spend time thinking about, you know, what would you do to make GPE you programing really easy.",,not-edited 175 | 01:06:17,01:06:35,00:00:17,"Yeah, but but but it's more than just vector operators. I mean that that's kind of my my problem with the whole thing is that most of these things are just libraries of hand coded assembly that do vector operators. And and surely there's something more clever than that.",,not-edited 176 | 01:06:38,01:06:48,00:00:09,"Maybe I'll just add one with language design. You know, one of one of the things that's interesting, you look at like all of us old geezers sitting up here and there they were, we're proof positive that languages move slowly.",,not-edited 177 | 01:06:49,01:07:29,00:00:39,"And I mean, it's not you know, like a lot of people make the mistake of thinking that languages move at the same speed as like hardware or like all of the other technologies that that that we live with. But but languages are much more like math and much more like the human brain. And, you know, and they all evolve slowly. And we're still programing and languages that were invented 50 years ago, like functional. But all of the principles of functional programing were thought of more than 50 years ago. I do think one of the things that that is luckily happening is that like as Larry said, everyone's boring from everyone and languages are becoming more multi paradigm.",,not-edited 178 | 01:07:29,01:07:38,00:00:09,"Yeah, I think it's wrong to talk about oh, I only like object oriented programing languages or I only like imperative programing or functional programing.",,not-edited 179 | 01:07:38,01:07:56,00:00:17,"I mean, it's important to look at where's the research or where the new where's the new thinking and where where are new paradigms that are interesting and then try to try to incorporate them. But do so tastefully in a sense and and work them in to work them into whatever is is there already.",,not-edited 180 | 01:07:56,01:08:06,00:00:09,And and I think we're all learning a lot from functional programing languages these days. I certainly feel like I am because a lot of interesting research has happened there.,,not-edited 181 | 01:08:06,01:08:26,00:00:20,"But functional programing is imperfect and no one writes pure functional programs. I mean because they they don't exist. So it's all about like how can you tastefully sneak in mutation in ways that you can better reason about as opposed to mutation and free threading for everyone, you know?",,not-edited 182 | 01:08:26,01:08:30,00:00:03,And that's like just a recipe for disaster. Right.,,not-edited 183 | 01:08:30,01:08:33,00:00:02,"So, yes.",,not-edited 184 | 01:08:40,01:08:43,00:00:03,All languages are imperfect. Let's just settle it right there. You know.,,not-edited 185 | 01:09:04,01:09:43,00:00:38,"Yes, we've been thinking a lot about the the the parallelism concurrency issue. This is one of those issues where we were waiting to be smarter. Uh, we we did borrow. I mean, steal a bunch of ideas from Haskell in terms of lazy lists and things like that. But in terms of how you actually are going to deal with the end of Moore's Law or if not the end of Moore's Law, at least, you know, multi, multi, multiple C.P.S., many, many cores. When you have a thousand cores, what are you gonna do with them?",,not-edited 186 | 01:09:44,01:10:27,00:00:42,"And so a lot of our early design on Perl 6 was we didn't understand how we wanted to do it yet, but we knew very we knew very deeply that we didn't want to do anything. It would prevent it. So a lot of the early design decisions were just saying, well, we have to keep this open. Then when the right smart people came along, they said, look, what you really have to look at is things that are composed. All threads are not composed of, well, we can't take two threads and turn it into a third thread. What you want is things like we stole from go from. We stole promises and channels from C-sharp. We stole functional reaction will programing.",,not-edited 187 | 01:10:29,01:10:58,00:00:28,"And with these sort of primitives which end up being duels of your regular list processing kind of primitives, they just happened to be working on events. And you're you can have loops, event loops that were just like regular loops that they're running on and same control flow. So that is easy to learn. There are ways of sneaking these things into a language, at least in the ways that we understand right now that I heard.",,not-edited 188 | 01:10:59,01:11:04,00:00:04,Was it. Who is talking about adding fibers to their runtime?,,not-edited 189 | 01:11:04,01:11:15,00:00:10,"I think you'd think it was a Java news item, but like lightweight threads that can you, as Erlang has done, has shown, you know, you can run a hundred thousand threads in your process.",,not-edited 190 | 01:11:15,01:11:27,00:00:11,That's another language that's been around for a long. Oh yeah. And we stole from them too. Yeah. Should we. We like their pattern matching. But one of the many therms is that all of that language design is theft of course.,,not-edited 191 | 01:11:28,01:11:30,00:00:02,Yeah. So yeah. I mean we're thinking about it.,,not-edited 192 | 01:11:30,01:11:38,00:00:08,"We don't know have all the answers yet but I think all these languages, you know, long term tend to converge on similar solutions.",,not-edited 193 | 01:11:39,01:12:06,00:00:26,So very sadly we are at the last question. I know you went so quickly and unfortunately all good things must end except for maybe good languages. So I'm going to start and maybe quickly wrap up as you look back over the long lives of the languages that you've written.,,not-edited 194 | 01:12:06,01:12:08,00:00:01,What have you found most rewarding?,,not-edited 195 | 01:12:10,01:12:10,00:00:00,The people?,,not-edited 196 | 01:12:11,01:12:13,00:00:02,The people by far after the.,,not-edited 197 | 01:12:16,01:12:45,00:00:29,"Oh, yeah. Yeah. I mean, that that's what keeps me coming back, that to work everyday is like the incredible excitement that the community shows. You and I I am so grateful for all the people who who have used that. I mean, it there's nothing more rewarding than have people just like on Twitter or wherever it is, go, oh, my God, this is so great. And it's like, yeah, that makes you want to just keep doing more of it. I mean.",,not-edited 198 | 01:12:46,01:12:54,00:00:08,"Oh, yeah. You know, somebody comes up to me in the street somewhere and says, you know, thanks for giving me a career.",,not-edited 199 | 01:12:54,01:12:55,00:00:01,Can I have a selfie?,,not-edited 200 | 01:12:57,01:13:01,00:00:04,"You know, that's like this is kind of like, you know, light and dark thing.",,not-edited 201 | 01:13:02,01:13:09,00:00:07,"But being this is really wonderful. This is all great. I mean, I have to be in Silicon Valley at a movie theater, the tire shop.",,not-edited 202 | 01:13:14,01:13:18,00:00:04,"Yeah. Well, what's really weird is when you're when your kids are with you when that happens.",,not-edited 203 | 01:13:20,01:13:27,00:00:07,"But but, yes, it's. It's when the when people say, you gave me a career, you get my livelihood. You fed my family. Yeah.",,not-edited 204 | 01:13:29,01:13:36,00:00:06,"That's the best. It's. And you know, and and not just.",,not-edited 205 | 01:13:36,01:13:46,00:00:09,"And we're not talking about a star relationship here. Each of us to those individuals, we're talking about the second order, Community 2.0 kind of effects.",,not-edited 206 | 01:13:47,01:13:54,00:00:07,"It's it's one thing to see them, you know, getting help from you. It's another thing to see them helping each other.",,not-edited 207 | 01:13:56,01:14:11,00:00:14,"That's a whole whole level above even the individual relationships. I feel to see a community that is learning how to love, you know, kind of building a little bit of heaven on earth. There's just nothing like it.",,not-edited 208 | 01:14:13,01:14:16,00:00:02,"Completely agree. Kita, you get the last word.",,not-edited 209 | 01:14:22,01:14:24,00:00:01,And we love learning from you as well.,,not-edited 210 | 01:14:24,01:14:32,00:00:08,"And with that, I want to say we've all learned so much from all of our wonderful panelists tonight.",,not-edited 211 | 01:14:33,01:15:09,00:00:35,"I want to thank you for allowing me to share and celebrate this moment with you. The little fifth grade kid in me that was plinking away on basic at Bell Labs who later watch the P.C. cell phone, Internet, Web and cloud computing and change our world. Never dreamed that I would be chatting with four individuals who profoundly impacted our world by doing what they love, creating and building languages. Please join me in a huge round of applause to thank Anders for inspiring this evening.",,not-edited 212 | 01:15:15,01:15:19,00:00:03,"Thank you, Carol. OK. OK.",,not-edited 213 | 01:15:19,01:15:24,00:00:04,"Was that epic? So, Marina, I have an idea.",,not-edited 214 | 01:15:24,01:15:44,00:00:19,"If you guys could step down right here, we're going to get a giant picture of everybody. You guys stand right there. We're going to get up here with your camera. All right. We're getting a picture of everybody in that room. All right. I need some excitement.",,not-edited 215 | 01:15:47,01:15:56,00:00:09,"Oh, my God. I met my idol. She can stand on the chair. You can use my shoulder. OK. All right. Show some excitement, people. Let's see it.",,not-edited 216 | 01:16:01,01:16:07,00:00:06,Monahan's. Three times it's kinda weird and lumpy.,,not-edited 217 | 01:16:11,01:16:23,00:00:11,"OK, thank you, everyone, for coming. Thank you to all of our speakers. Thank you to our organizers. Let's do something equally awesome next year.",,not-edited 218 | 01:16:23,01:16:28,00:00:04,"And if you want a robot there, 100 bucks. So come see me.",,not-edited -------------------------------------------------------------------------------- /trint/language-creators.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/fluentpython/language-creators/c1cad634eeb5e74bfd1fd34685fb80d84e799b0f/trint/language-creators.docx -------------------------------------------------------------------------------- /trint/language-creators.txt: -------------------------------------------------------------------------------- 1 | language-creators-edit-480p.mov 2 | 3 | [00:00:00] You guys ready some language creator. I have further to introduce Carol Willey. She is a python during counseling Project Jupiter Steering Council member. She blends the strings of pythonic. Jupiter notebook's to improve access to learning and education due to the worldwide foundation of the Pyfrom language. The hard work of the Jupiter team users worldwide. Carroll was awarded the Twenty Seventeen ACM Software System Award, recognizing the lasting influence of Jupiter, a broad collaboration to develop its open source tools for interactive computing with a language agnostic design. 4 | 5 | [00:00:38] Thank you. 6 | 7 | [00:00:47] Welcome, everybody, for being here. It is my absolute pleasure to share this evening. You and some of the people that actually influenced my career in software development. 8 | 9 | [00:01:01] So let's get through this. And for those of you that are watching us on the lifespan. Hello and welcome and hope you have a wonderful evening with us. We haven't really distinguished panel of language creators. And I'd like to invite them to the stage as we read their bios. I'm going to keep the bios really short because I think most of them need no introduction whatsoever. And that'll save us some time more. Do you see language design stuff? OK. So first we have been Rassam to develop the Python language that touches pretty much every corner of society today in some way. And it's. 10 | 11 | [00:01:51] He's the creator of Java, which is UK-EU, used across a broad variety of devices and deployments at scale. Well done. 12 | 13 | [00:02:00] And please get a. 14 | 15 | [00:02:07] Childcare has architected a number of languages over the past several decades, including Turbo Pascal, Delphi, C-sharp, and so you might know this little language typescript. 16 | 17 | [00:02:26] Definitely not these. 18 | 19 | [00:02:27] Larry Wall to combined his unique perspective on text and computing with his strong background in linguistics to Craig Pearl and its sister sibling Pearl 6. Welcome. 20 | 21 | [00:02:51] So just a couple of housekeeping things about this evening's format. You're in for an engaging and hopefully very lively discussion. More likely than we were at dinner. I think that's possible, right? 22 | 23 | [00:03:04] OK. The format. More beer. OK. We can do that. Keep it coming. 24 | 25 | [00:03:13] OK. So the format will be two sessions with a fifteen minute intermission. What I'll do is I will start by asking one of the panelists a question, and hopefully a response will be like one to two minutes and then kind of throw it open for other panelists to respond and hopefully get a really good discussion going. 26 | 27 | [00:03:34] And the more you discuss, the less I have to ask questions and the more in-depth we can go on the really cool stuff after the 15 minute intermission. We're going to take questions from the audience over a winner Twitter. 28 | 29 | [00:03:54] OK. So tweet out your questions. Hashtag is happy bbf out. And if you can get those in by 8:00, we'll kind of collect them and have some really great audience questions about language creation and language design. So I'm going to invite you to sit back, enjoy a cup of strong Java Sea, start offering responses and insights, learned pearls of wisdom and embrace. The Python program makes it. 30 | 31 | [00:04:33] We'll start the celebration with a question for Kito about principles of language design. You mentioned before, perhaps somewhat jokingly, the Harry Potter theory of language design. What is this theory and what do you see as the key principles of language design? I think you're good to me. Am I good? OK. 32 | 33 | [00:05:01] The Harry Potter theory of language design was close to. I do know that I cannot believe that every detail that J.K. Rowling puts on the first Harry Potter book was intended as. 34 | 35 | [00:05:20] Some important Wolf point game part 6 or 7. And even if J.K. Rowling was such a genius that he hadn't actually owned land, that and that was who I think we found out the FUTHI was. 36 | 37 | [00:05:44] But who won? It was just like a temporary diversion during the train ride. And otherwise, you didn't hear much about the rap with fingerprints in languages. 38 | 39 | [00:05:55] I often. That's exactly how things go. You you choose some detail because you have to commit. You sort of you have to pick keywords. You have to choose a style of coding like you maybe you choose indentation instead of curly braces or maybe you don't. You're a special case, but whatever you do in some way, you're stuck with them and you find new uses of that. That detail that you picked before you knew how important that would be and the sort of the craft of designing the language is on one hand pick your initial set of choices so that there are a lot of possible continuations of the story. The other half of the of the art of language design is going back to your story and inventing creative ways of continuing it in a way that you had not. 40 | 41 | [00:07:15] So I think each of you have languages that span multiple decades. 42 | 43 | [00:07:19] So what are some of the principles that made, you know, so so Javal would sort of on in the. It didn't come out of like a personal passion project or something. It was. From trying to build a prototype, you know, I mean, we were trying to understand it because the. A lot of time talking to people who build software or embedded systems. 44 | 45 | [00:07:59] And you know, what was it in the whole process? How did their systems fit into the universe? It wasn't because I was trying to worry when we were worrying about things outside of data centers. 46 | 47 | [00:08:22] This was a project that had about a dozen people on it and my little. Yeah, but it was my my little piece was what it was was sort of like. 48 | 49 | [00:08:36] You know, we we we we sort of figured out that part of the problem was that. See has issues. And and so I started out so. So out of this like large pie of a project, my slice was. 50 | 51 | [00:09:01] To make things a little easier from a programing language point of view and fix the pain points that came from the programing language part. 52 | 53 | [00:09:10] And it started out as kind of do a better see. And then it and it got out of control. The rest of the project really ended up just providing context. You know, the only thing out of that project that survived was was Java. 54 | 55 | [00:09:31] But but but the fact that it was sort of directed at a set of pain points. But it happened to be it, you know, about people who were living outside of data centers and people who were. Getting shredded by problems with networking and security and reliability. 56 | 57 | [00:09:56] They had to build things that ran in hostile environments like in the homes, which in any home with a child in it is a it is a hostile environment. Speaking of hostile environments, feral. What are some of the guiding principles for designing for a business? I love you, Larry. 58 | 59 | [00:10:40] More and more coming out of this. A computer scientist. So I sort of actively ignored some of the computer science literature of the time and said, well, what can we just talk together? One part of the brain will work more like a natural language instead of. But instead of putting on a campus university campus and deciding world, the walkways would go, we're just going to see where people want to walk. And they put shortcuts in all those places and know that more as a network, not as a terribly orthogonal or computer science or mathematical thing. 60 | 61 | [00:11:20] And then that turned out to be in the right place at the right time for bootstrapping a lot of the web and. 62 | 63 | [00:11:31] It also got used a lot for system administration and so various principles that relate to trying to provide API eyes to everything. I'm trying to be both a good text processing language linguistically, but also a quick Google language. Here's why it was. Kind of very useful, was hasty and there was text and, you know, database seconds that's that needs. And so it was in the right place at the right time. We were very fortunate to have that time because in the 90s it became very stable, a lot of a lot of widespread use. Lot of people were you know, the language itself was stabilizing in the form that it was. But there were a lot of issues and salat. And so in the year 2000, we we took a step back and and and basically said, we're gonna break everything he's breaking. 64 | 65 | [00:12:33] So we kind of did the same thing. You know, it's done the pipeline to the step, except instead of breaking a few things, we decided to break everything here. So we came up with a whole raft of design principles and 50 years since then. By the way, forensics did come up two years ago. It's getting faster. And it's suddenly at the beginning we said we were going to do something impossible and and fail at it could be a very big failure. And so far, this proved me to be that. But in the course of the fail. Yeah. In the course of that, we came up some really interesting list of about 60 different design principles. 66 | 67 | [00:13:19] When read, even though I think many of them have already, you know, you know, kill two birds with one stone, pick the right people, you know. 68 | 69 | [00:13:29] It's possible like that. But we came up with some cute ones, like, you think that's cute today? 70 | 71 | [00:13:38] Oh, oh, know. 72 | 73 | [00:13:43] Conserve your brackets because SFE, even Unicode does not have enough brackets that don't reinvent object orientation queerly, which arguably provided no substitute strong features for weak buttons, late binding sometimes oposite programs be. But some of the major ones are, you know, a lot of the stuff is just perfect to screw over time. And, you know, there were a lot of weird magical variables I'm going to. And so. A great deal of the redesign was to say, OK, what is the right peg to hang everything on? Is it off to Korea? Is it something in the works for school or in a larger school? Or what is the right to have each piece of information on? And if we don't have that thing, how do we create it? Great question. 74 | 75 | [00:14:48] And since it's such a great question, Anderson, the spot and Terrence Parr had a quiz about while programmers value simplicity, they more often value powerful functionality. 76 | 77 | [00:15:02] An amazing one liners incurring the cost of complexity. So for express. Yes. So what are your thoughts about simplicity versus complexity and some of the principles that might guide you, as you know? Really? 78 | 79 | [00:15:22] Suppose I. I was always late in doing the language, saying that I've done. Always tried to make it so that there was only one way. 80 | 81 | [00:15:37] So a lot of languages have four different ways of doing something and you pick the wrong one. And then only later you realize you went down the wrong branch and now you've got it back up. 82 | 83 | [00:15:49] And so. So it's not it's not always easy. And I think there's like often we're guilty of creating what I call this thing I call simplex. Take something from blacks, you grab a single wrapper on top of it. That's make the complexity go away, but you're really creating is simplicity. You know, it's just like a bad abstraction on top of another bad abstraction that is simpler. So I don't know. I mean, it's it's we think that as picking up correct default overly complex thing. Yeah. But but I mean, the thing about that, about language design is like like any any decision you have to live with forever. 84 | 85 | [00:16:38] I mean that and in languages you you can always add, but you can never take away. And so you've got to actually, as a language sign up to be very judicious. About reasoning over not so much what to put in, but what not to put it, an army because people come to you all the time. Wouldn't it be great if you could do this with that? Are you going to? Well, yeah, but you can't fundamentally change the nature of the beast. If you created an empirical and an imperative programing language, you can't turn it into a functional program. Show me you can you can borrow from functional programing. But it is what it is. And you gotta stay true to the nature of the beast, or you gotta create a new beast so-to-speak. Right. 86 | 87 | [00:17:27] Any other thoughts? Excuse me? Can we interrupt you or you may have to interrupt any time. So. 88 | 89 | [00:17:38] This is sort of the point about what what do you leave out? And the what I remember in the early days of Python's design, there were so many people who thought they had a good idea. Is sufficiently critical to say no. 90 | 91 | [00:18:03] And so there are a few things that didn't work out at the time, I I haven't learned to say no. And I quickly enough did learn to say no. And I sort of felt like several lines of defense. Like the first line of defense is, hey, you think you need a new language feature, but actually you can already write that typo if you needed the locked right to function or a module. Well, if they say, yeah, but everybody needs that. Well nowadays we say put it on the package repository in those days. I said well maybe you can propose a new standard library module. That's a lot cheaper for the language design than the new language feature. And another line of defense was, well, you can actually write extensions in C or Fortran if you really care to. And you can help yourself that you can modify the behavior of the language in ways that aren't accessible when you just write the pure language. But you can still sort of you can extend it in a way that doesn't fundamentally alter the core language. And if you've tried all those things and and you failed, then maybe you could argue for, well, you have to change something in the core language. Hi, I'm interrupting. 92 | 93 | [00:19:39] I find that whenever I get feedback on whatever whatever it is, program makers, I've been working on it. It's people come to you with a with a particular instance of a problem. And it's your job as a language assignment to tease out the class problem they're talking about and then try to understand whether there is a feature there underneath that you could put in place that is broadly applicable, not just to that one crawl. You're putting in place a class, not an instance suit. So that damn slide. And if all you're talking about is an instance, then you're probably better off. Save your money for power. 94 | 95 | [00:20:32] Actually found this. In the early design of the Perl 6, we asked our CS I expected. Since we got 361, so we have this in spades lately. And, you know, it's completely overwhelming. Until I hit upon this principle, which Anderson alluded to, which is basically a lot of the proposed solution. Yeah, but there is a pain point underneath. 96 | 97 | [00:21:01] And if you look at more enough of these RFD and they haven't seen pain point, there is something you should address. There's some fundamental unification you should do underneath or something that is is clunky that could be fixed. And especially if you're doing a complete redesign that you can think about the sort of. To fix it. How do you know? There were a lot of problems where. Difference that just won a victory with themselves. You get like 40 different. 98 | 99 | [00:22:35] Released. It was really clear in the way that this was like a big issue and you feel dry and I came about as close to spilling blood on this topic as I've got. And, you know, I would much rather. Do something much, rather leave something out there, do something stupid. One of our principals planned to visit Margaret later. Yeah. Well, well, what that means is that that means the opening answer is no. No. Right. 100 | 101 | [00:23:14] And one of the things that happened with like a whole bunch of different outfits and their job was that they kind of turned into competitions and generics and closer to work both. Probably the most hard fought competition. People were writing pretty steep pieces on the topic. And I was like trying them all out. I mean, some had no shortage of smart people at the time, but it's really hard to be a planet full of grad students, even grad students. At some point, I think most kids who were in grad school. That's correct. And in linguistics and linguistics. But it's. 102 | 103 | [00:24:00] Oh, probably 20, 30 years ago to say I'm going to write my own language. And people are very different. Back then, the Internet was sort of starting. Maybe not that they're single. I think we have computers. We have cell phones. 104 | 105 | [00:24:20] Nobody cared, but nobody cared. What's all that about? 106 | 107 | [00:24:24] Nobody cared what you did with the eighth that. 108 | 109 | [00:24:31] Decades. But these are languages that persisted. Many changes and they're on different hardware. 110 | 111 | [00:24:45] When you started designing your language, what was the key goal that you were trying to meet versus using some other extinguishment? Well, I mean, for me, it's never been people. And one of the secrets of success is try to solve as many problems at once as you can. And, you know, if there's just one problem, there's probably an easier way. 112 | 113 | [00:25:17] Right. Right. You think that way you'll never have a new program. 114 | 115 | [00:25:25] Well, there's always a better solution in the 300. Well, it depends on how much you pay. Chasing down memory, corruption. 116 | 117 | [00:25:34] But the three virtues of the program are. Blasi This impatience and cupids takes Kupers. 118 | 119 | [00:25:46] The world needs another program like. Is that a code? But the thing about programing language is that I think a lot of people don't realize that every programing language is about 90 percent the same and maybe 10 percent if you're lucky. 120 | 121 | [00:26:06] And a lot of people get very focused on the 10 percent new and forget about the 90 percent of the same. That makes it at great length. Right. 122 | 123 | [00:26:14] I mean, there's a lot of hard or you work in creating programing language, loss, semantics that it's got to worry about. 124 | 125 | [00:26:21] And like everyone and loves to talk about syntax and syntax is the easy part. Semantics is the hard part. 126 | 127 | [00:26:30] You know, like how do the types of work and one of one only dogbone supported promotions and one of the different kinds of type constructors that the language, as etc. said are these are the hard things to do to design. But, but but not the things that people people love to bike shed on the syntax, you know, shouldn't be a colon or or comma. 128 | 129 | [00:26:52] You know, it's like, oh my God, it's have a long thread about that. So talking about people having opinions and syntax and typing. 130 | 131 | [00:27:08] These languages don't all take the same approach to typing. Maybe we'll start with veto and talk about typing in Python and then kind of work our way around. 132 | 133 | [00:27:30] I mean, I just remember that when Pyfrom first happened, it was not a class. It was a little conversion function. There was an internal object type, which was really just kind of a Zite table that represented integer objects. And there was a built in function if you needed to convert the string to an integer and that was we had a bunch of those functions and we realized that we we had made a mistake. 134 | 135 | [00:28:11] We had given users classes that were different from the built in object types. And for a long time, it was like, oh, well, like the real stuff is implemented in C and the user writes a little bit of blue top of that. And when when I found out that we had 80 different competing web frameworks, it was sort of time to to realize that people were writing much larger programs. And that's a different approach. Two types was needed. And that's where we sort of reinvented the whole approach to types in Python. And there was a bunch of cleanup that didn't happen until 5 3, actually. But one of the things we introduced and we were lucky that there weren't actually despite those 80 web frameworks, there weren't enough users that we were completely stymied by backwards compatibility. Yet like we are now. So we just one day we changed the function into a designated for the class. And sort of followed that calling, the class would be constructing an instance of the class so that if you had simple code that wrote in left brand some expression right. And would work exactly the same way that we have the same effect. But the workings inside were completely different. There was one particular file that's sort of implemented the that's sort of the basic functionality of types in the language and it in for one to it was like 50 lines of code. And at some point I rewrote it and it was five thousand by. 136 | 137 | [00:30:16] That's great. What about Titus in Dublin? I got this this this one history of caring about things like. Building robot software often that that that comes out about, you know, I'm much more worried about what it takes to build production quality software than about what it takes, just like you like a quick thing and chuckles not a great language for. 138 | 139 | [00:30:59] Things, but it's it's OK, it's not for me. One of the one of the things that I love to do and maybe I'm weird, but being able to do automatic or improving on hunks of cup and and. Type system is a really great place to be, one of the foundations there begin they're improving it for. Four months of code turns out to be really useful for things like building optimized. And doing it ahead of time. To be able to hear improvable way as many things as possible, so satellite like like, you know, one of the not well-known things about about Java is that, you know, in the jobless pack, you know, it says Ouray, subscript checking is always on. But, you know, it's only conceptually all of his all right. But the truth is that there are there's more than on my books or the compiler to improve away almost all index checks. And same thing with like null pointer checks and all kinds of things that look like they're heavy weight, but they're really cheap, you know, so it's a one of the things that I like. I really cared about it. 140 | 141 | [00:32:37] The time was that A plus B should almost always be at most one instruction bonus points for zero instructions. What about after? Well, the thing about zero instructions is often you can like fold them into some weird addressing mode. Right. 142 | 143 | [00:32:59] And. And so in kind of the universe, I'm right, I tend to live. Being able to look at A plus B and realize it's that destruction that all feeds off of the type system. And sometimes you can you can do this with sort of optimistic just-in-time coupon compilation, depending on how far you want to push that. So like the the JavaScript engine in Chrome is is absolutely astonishing for the the kind of core that they go through too optimistically. JavaScript code, but it's also very hard to do those kinds of tricks if you're trying to get into smaller devices. So, you know, there are there are Java compilers that work for machines that only have like. You know, to do that kind of compact distillation, you need every kind of hope that gives you every little every last drop of information. And the earlier, you know, what better job you can do. 144 | 145 | [00:34:20] Right. So speaking of lots of information that one gets, typescript gives you a lot of flexibility and power. What's your general view that typing? 146 | 147 | [00:34:34] Well, let me actually it's funny that you mention cycles and counting. How many? And whenever I do, I remember when I wrote Turbo Pascal, which was all written in C-A-T assembly code. 148 | 149 | [00:34:45] And back in those days, you could literally look up the intel manual on the sidewalk or whatever, you know, and see how many clock cycles every construction took. And actually it would work out just like that. 150 | 151 | [00:34:56] I remember now everything takes zero clock cycles except when it takes a thousand clocks. The memory and it is absolutely impossible. The reason about what I've seen you use execute your code today. That that's just one. 152 | 153 | [00:35:13] Well, it's not impossible, but it's much harder. Yeah, it is a complete pain in the ass. 154 | 155 | [00:35:21] And they don't give you manuals. Not good at all. You don't want to actually understand that. If you need to get the chip diagrams. But but with respect to types, I've always worked on programing languages that have type systems. 156 | 157 | [00:35:35] But it's interesting how it's gone from being type systems far for the code generators sake or type systems for four for, you know, generating errors too. Now I almost view type systems as as a tooling feature, and that's really sort of the thing that has been interesting. High automate for typescript. It is, you know, first of all, starting with a dynamically typed programing language like JavaScript and then trying to add a type system on top of it that that faithfully reflects the semantics of the programing language. And the reason for doing it is actually not because we think type systems are interesting, but because if you think about what it is that powers programmer productivity today, like everyone loves their I.T. like. Whatever you're using, I hope it's Visual Studio code. 158 | 159 | [00:36:29] But putting that if it's not, you know, I am sure you're all like accustomed to things like state completion and refactoring code navigation and go to definition and so forth. And if you think about it, the things that the thing that powers that is semantic knowledge of your code. And the thing that provides the semantic knowledge of your code is a compiler with a type system. And once you add types, you can actually dramatically increase productivity, which in some ways seems counter counter intuitive. Right. 160 | 161 | [00:37:03] I thought like dynamic languages were easier to to to approach because you got rid of the types which was like a bother all the time. 162 | 163 | [00:37:11] Well, look, when it turns out that you can actually be more productive by by adding types if you do it in a non-intrusive manner and if you work hard on doing good type inference and so forth. 164 | 165 | [00:37:23] So, so, so, so, so, so. So I want to jump in here. And then I take over. 166 | 167 | [00:37:34] So I really, really, really believe in that point in the in the in the power tools for power geeks. 168 | 169 | [00:37:44] And one of the things that drives me nuts is the real man usvi movement. And, you know, it's it's really I just want to punch people who are. 170 | 171 | [00:37:57] But I'm really inside state. I I'm a real developer because I use v.i. And it's like, you know, I do it the hard way. I think. 172 | 173 | [00:38:07] I think I make language developers lazy. 174 | 175 | [00:38:20] IBRD Let me get a lot more done a lot faster, OK? I mean, I'm not I I mean, I'm really not into proving my manhood. I'm good at getting things done. 176 | 177 | [00:38:36] Case in point, but I take the devil's advocate here first said he meant something like. 178 | 179 | [00:38:43] Yeah, but you their notebooks, a lot of science people. Data scientists get a lot done. 180 | 181 | [00:38:51] It's actually a pretty simplistic I need a dynamic language. Most of the time. 182 | 183 | [00:39:00] So you could get a lot more than that. I don't know. No, but I think typeset. I mean, it's not just a type system can help you. 184 | 185 | [00:39:12] First of all, if you're uninitiated and you want to know here, here's my food and now I say food dot and then the ivy can show you. What can I type next? Right. As opposed to I gotta go read manuals and figure it out or know it. All right. I mean, your original developer of whatever piece of code might know it all, but then people move on and new people come in. 186 | 187 | [00:39:34] You know, there's here's this project. There was there was no documentation written about it. And if you think about it, types or documentation to write, I mean, and then there just there's so many things about like like adding them that down the line give you increased productivity. 188 | 189 | [00:39:54] So there's productivity and then that's that's maintainability. 190 | 191 | [00:40:00] Oh, well both. And maybe any different thoughts about how you get to talk about types. Well, talk. 192 | 193 | [00:40:09] The colonel types out. Well, that story is very different for profile purposes. As you know, Girlfight, to sort of rural over time and the whole idea was sort of particularly idea. 194 | 195 | [00:40:22] Everything you can pretend everything is a straight even if it's a number or floating point internally, it's stalled, you know, interchangeable. And that works out for bootstrapping people into a language. They're quite nicely. And it's it's a feature that we wanted to keep in Perl 6. But what we discovered in Perl 5 is part of the redesign was it's it's fine if the user is confused about the interchangeability to tell more for the Muslim to take the care of your standard. 196 | 197 | [00:40:55] Tikes But it's not so good if the computer is confused about. 198 | 199 | [00:41:01] You know, for all the girl wanted, it was written way back in the dark ages. You had a schuberg, a bunch of stuff in, and it cheated a lot. So part of the redesign when we did girls school Perl 6 thing we wanted to do object oriented programing that is that these languages and we wanted to be functional programing that are the most functional programing languages. To do that you have to have a fundamental very sound type system of a sound object model underneath. And you really have to take seriously these slogans like everything is an object. Everything is like closure. Every feel the process, even blocks are closures. And he has got to optimize. Hard to get up, get them away from there. But but I I also agree with this idea that the tikes also are cultural. I talked about Pei's hanging things on pace. They're one of the one of the picks. We didn't have something to hang on the prettified. And now we we can Pangle. But all of that information and then just run a little program there. And then you have to have an idea. They say, well, this object. You know what methods. 200 | 201 | [00:42:15] But what you know, they could do their own introspection. The whole thing. And people just you know, I'm baffled by the way we do also have an idea. 202 | 203 | [00:42:27] Good points all around. So most of the time programmers actually spend maintaining versus writing new code out in the wild and. 204 | 205 | [00:42:41] What things or elements of a programing language make it easier to maintain? And maybe we'll start with Fito. 206 | 207 | [00:42:52] Well, I found that. TypeScript is actually incredibly useful, and so we're adding a very similar idea to Python, adding it in a slightly good way because. We are taxed. 208 | 209 | [00:43:28] All right. Go. Anyway, we have time. I sort of learned a painful lesson of that before school programs. Seafair dynamic typing is great for large programs. You have to have a more disciplined approach and it helps if the language actually gives you that. It's rather than telling you, well, you can do whatever you want. 210 | 211 | [00:44:02] Yeah, yeah. That was part of our scale up idea for Perl 6, the typist would help with programing in large because we didn't notice those limitations. 212 | 213 | [00:44:16] One year ago, I started working really heavily on Unbury Factoring In. And, you know, being able to do like large scale refactoring is unlike millions of lines of code at once, that really changes the way you think about maintaining code. 214 | 215 | [00:44:37] Because, you know, the world is filled with libraries that have things like stupid variable names, stupid method names, because, you know, when you started out, it meant one thing. But now you realize that you really didn't really understand what you were doing in the beginning. And so this this method name really should be different. But nobody ever Reding's methods because it's really hard to go over a piece of code and rename. Exactly. That's the right variable. But if you've got a good refactoring engine, you just you just type, you know, medic control are typing the new name, you know, hundreds and hundreds of files later, which takes about, you know, maybe 30 seconds if it's a lot of files. You're done. And so you basically be right. 216 | 217 | [00:45:34] Seven-part series, I hope this is this is actually like you're describing, that's what we what. 218 | 219 | [00:45:43] What was the genesis of the typescript project, which was these enormous JavaScript code basis that we were seeing customers. Right. And then in-house projects that they were getting bigger and bigger because JavaScript engines were getting good enough for you to write really big programs. 220 | 221 | [00:46:00] But maintaining them was impossible because it turned into write only code. You know, you do dare not touch it. Once you've written it because it worked then and then. But, you know, there's this property called text. 222 | 223 | [00:46:13] And I really want to change it to be like some other name, except there is like a million other properties called text. And if I'd just like to do a global search and replace for tax, then oh my God, it's like at all. So I can't change anything. But if you have semantic understanding up like this property call text is different from that other property over here. 224 | 225 | [00:46:35] Call text. And if you want to rename this one, that doesn't mean you want to rename that one. But but that takes for something like a type system to be in place. And, you know, once you start adding that, you add documentation to the code and you add these capabilities where we're now seeing people like with regularity, refactor one hundreds of thousands of lines of JavaScript code, you know, we'd like ten minutes and end it and it just works afterwards. And people are like amazed that it's possible. 226 | 227 | [00:47:06] But but but it's true. Said it takes a bit more work to begin with. And it's not maybe not right. If you're writing five lines of code that maybe more bother than you really care to. But but, you know, it started to pay off pretty quickly. 228 | 229 | [00:47:21] There are different types of really good lexical scoping helps with refactoring. It gets back into this. What's the right pick to hang the sign up and off and it's slope. It's a lexically skulked or dynamically scale. So now we're doing those right and not interfering with threading. 230 | 231 | [00:47:43] So I have one more question now before the break in three minutes and we made sort of a reference to Donald New, one of the turning winners in this last section of conversation. And he wrote, Premature optimization is the root of all evil. So what's your approach to optimizing code and gaining efficiency, saying Python? 232 | 233 | [00:48:12] Well, I I'm terrible at that. So I leave it to others. 234 | 235 | [00:48:17] That is a very wise language creator and they've lived up to the task. 236 | 237 | [00:48:26] Piceance hash table implementation has been rewritten so many times. 238 | 239 | [00:48:32] I don't understand any part of it, but it is so much better than the thing I actually copied out of truth 30 years ago. Happy to have a clue. 240 | 241 | [00:48:46] Okey doke. I kind of 50 percent believe that because they're, you know, the premature optimization in terms of algorithms and code. That part of it, I believe. But people often don't really think about the role of data structures in optimization and interpret data structures exposed. 242 | 243 | [00:49:16] You have to know and you decide that, you know, this algorithm is a problem. But, you know, the reason that it's a problem is because, you know, this data structure was just slapped together and they thought, oh, they'd only ever be like 10 items in the list or 10 items in the set. And then and then you start, you know, having, you know, million eight million items sets all the time. And all of a sudden, you know, you're a little linkedlist is. And that is not gonna happen. Right. 244 | 245 | [00:49:50] Ex-directory or a unit or. Yeah. And and so and so if you can you know, it's like you know hyd early hide. 246 | 247 | [00:50:01] Often. Right. Never tell the truth about what your data structures are. 248 | 249 | [00:50:09] And on that note, we're going to take a quick look. 250 | 251 | [00:50:14] I just want to say that I think like with anything, the important thing is to make sure that you actually have the right data before you you start optimizing. Right. By too often you have a hunch that, oh, I think finally I need to do this. 252 | 253 | [00:50:32] And I need to change this data structure from being a linkedlist to being overweight or whatever. 254 | 255 | [00:50:36] But but if you measure, then you discover it doesn't matter. And but really, there's this other thing that you haven't even thought about that matters enormously. And maybe you should go look over there. So get perf., get it, use a profile or figure out where it is, the time actually spent. I am continually surprised and I write compilers for a living and I'm always surprised by where time is spent. All right. 256 | 257 | [00:51:01] And that is that we're out of time for this section. We're going to take a quick 15 minute break. 258 | 259 | [00:51:09] And when we come back, the really hard questions are going to come out because the audience questions that have been submitted are going to be the ones that believe in you. So thank you. 260 | 261 | [00:51:55] And teach in every one of you has a community that is formed around the languages that you've created. 262 | 263 | [00:52:00] I'm curious if you were talk two ways in which you've seen the design choices you've made for your language, so shaping the communities that are formed around. 264 | 265 | [00:52:11] It really helps. Well, good. It really helps if you're trying to make everybody look what's here with your slogan here. 266 | 267 | [00:52:24] Everybody comfortable? We're doing that right now. They think they can make all of all Americans, I heard. 268 | 269 | [00:52:37] You know, feel like comfortable programing. You see it for all. Yes. To make sense of it. I guess you know what? 270 | 271 | [00:52:48] The sign was a clue. 272 | 273 | [00:52:51] It's not see us for all of us, just Americans. No. There are many underserved populations in the world. 274 | 275 | [00:52:57] And what we've really discovered that it really helps build international camaraderie and community to have world class literally support for unico. Yes. I would encourage any language designers out there. Don't do this halfway stuff with, you know, code points. Go all the graphics. 276 | 277 | [00:53:23] I completely agree. Kita, you had something you were going to say. 278 | 279 | [00:53:29] I was trying to say. 280 | 281 | [00:53:33] I how my design choices necessary to make choices about how to use energy certainly have. Did I? I was somehow a dude with the importance of user centered based something because by comparison. That was ABC long lost, its authors had a of things right, and one of those was listen to the users asking users what they think. And then again, you making a new one of their suggested solutions. And you first figure out what nobody spends. You gave users a voice. And I said, take that back and let the users help. And now they're raising of. 282 | 283 | [00:54:36] I was going to say I always felt like it's important as a language society that you don't create unnecessary work for your community because it's it's very easy to in the name of purity or whatever. Go change something or or strive for the perfect language. And I've always said, like, I mean, show me the perfect language and I'll show you your language with no use or shoot over. Every every language has its functions. Has them because. Because it has evolved. And the hard part of language aside is actually not version one. It's like the older versions that come after you try to sneak things in without actually causing extra burdens on people who don't necessarily care about the things that you're trying to sneak in. Right. And so. 284 | 285 | [00:55:27] So that's the hard part of language design, I think is is the evolution of the language and keeping your community with you as you have all. 286 | 287 | [00:55:40] Yeah. And so and so with with Jarbawi like always followed that we've maybe been a little bit excessive about it. I mean, I've got binaries that I compiled like 20 years ago, but still run. And and it's it's, you know, on machines that were never invented when the code was compiled. And you only get there with with crazy discipline and and a a tolerance for living with your mistakes. But but it but it makes the you. It also help. It also ends up selecting who your users are because in the in the Java universe, pretty much everybody is is really disciplined because, you know, it's kind of like like mountain climbing. You know, you you don't get there, get sloppy with your gear when you're mountain climbing because it has a clear price. And, you know, when you you said something about Larry, you said it said something about Unicode Java's had Unicode since ninety two. So, you know, it's, you know, trying to be inclusive. Yeah. And and that really made a difference. I mean lots of folks thought it was like the lamest thing ever. But that was that that was during my my, you know, Lord of Java phase which. Yeah. Yeah. But that that phase of my life ended in about ninety five. 288 | 289 | [00:57:25] I'd like to say something possibilitythat. 290 | 291 | [00:57:30] And that is we did this perfect try to perfect compatibility. All the way through. I didn't really think. 292 | 293 | [00:57:45] That eventually runs into the problem. But, you know, you can't I can't fix your mistakes. So one of the mistakes that we made was was kind of a mistake and that was assuming that you had to always have that kind of stability and not change anything. 294 | 295 | [00:58:04] How would it be to design a language where the language itself could be evolved from within by the community and the language we want? 296 | 297 | [00:58:17] Twenty five or 50 years from now, this ties into what Polygram was talking about, a hundred year language. We kind of took that seriously. What is it that prevents languages from evolving, not being not having things still thrive? 298 | 299 | [00:58:34] But fundamentally, the Perl 6 compiler is written in Perl 6. Most the runtime system is written in Perl 6. The users can extend it. Perl 6 itself does not care whether things are built in or not. It all works the same. So most of the buildings are written as if they were used or code. 300 | 301 | [00:58:55] So users, even if we say no, we don't want that language right now. But put it in a module you can do. You can turn classes in two monitors with about that much code. You can put into implement actor model classes with about about how much code you can you take. Adding operators is just trivial. When it does, it does everything perfectly one pass and drops into the sub compiler. And with the end, it comes back out. So there's never, ever any ambiguity as to what language you are in. 302 | 303 | [00:59:32] And so because this scoping of the exact language you're in is always like if we scoped any lexical scope can say use whatever language I want a feature version of Perl 6. You could say use COBOL, use Python. If someone actually people have written Python parsers in April 6, I don't think anybody's going to call for sure yet, but we'd like to think that, you know, a lot of language stuff like languages and Perl 6. 304 | 305 | [01:00:03] So I think that I think the third module of semantics would likely. But I think there is a way us. I think there is a way forward to get the stability and rehabilitation. 306 | 307 | [01:00:19] And I think. 308 | 309 | [01:00:23] Awesome. Do we want to take another audience question? 310 | 311 | [01:00:28] All right. Thanks. 312 | 313 | [01:00:36] Can you talk into the mike like you're eating the mike? Hi. Yeah. Can you hear me? Yeah. 314 | 315 | [01:00:42] There's been a lot of talk tonight about the evolve ability of languages and the trouble with implementing things that might not be backwards compatible. What's something that you wish you could have implemented with your language? But for that, or maybe another reason that wasn't possible. 316 | 317 | [01:01:02] A word, right? As all the words or these or other forms of naming is hard. 318 | 319 | [01:01:31] Well, I'll I'll I'll go. I've. I mean I my favorite is always like d that the two billion dollar mistake of the billion dollar mistake of having Nall in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake. 320 | 321 | [01:01:48] But I mean if it did. 322 | 323 | [01:01:52] And I mean what's done is done right. And and now now, you know, I spend a significant portion of my time actually working on ways to to make code null safe to and who's never who in here has ever had a null pointer exception. 324 | 325 | [01:02:12] Right. There you go. It's it is by far the most problematic part of language design. It it's a single value that that if only that wasn't there. Imagine all the problems we wouldn't have. Right. If if type systems were designed that way and some type systems are and some type systems are getting there. But boy, trying to retrofit that on top of a type system that has normal in the first place is quite an undertaking. 326 | 327 | [01:02:41] The features I wanted to add were negative features. I think all of us as language designers have borrowed things. You know, we all steal from each other's languages all the time. 328 | 329 | [01:02:55] And and it's often we steal good things. 330 | 331 | [01:03:00] But for some reason, we also steal bad things. You know, like what? Like regular expression syntax. 332 | 333 | [01:03:08] Oh, yeah. I did that one. Like the C precedence table. OK. Another. 334 | 335 | [01:03:15] OK. These are things that I could not fix in four or five. And we did fix it. Burleson's. Awesome. 336 | 337 | [01:03:25] All right. We do tend to be doing pretty well with the audience. So how would another audience question? 338 | 339 | [01:03:36] Hi. Hello there. So, well, what I wanted to ask is you can sort of know what is these sort of pendulum effect in regards to tech and programing, throw it out. Time to Vinick's several different paradigms. There's a certain time where people were like, are we going to do things imperatively? Are we going to go object oriented or functional? And for example, right now there's a whole bunch of language used are sort of like very aggressively taking that standpoint of being very pro, being friendly with concurrency or being bery regardless of what immutability with memory. And I think that that kind of pendulum effect happens because technology has actually been evolving throughout time. Our machines are like beefier and we have more memory now. So that waste on we design programing languages now are probably a lot different than there were 20 or 30 years ago. So considering that, where do you think or how do you think the programing languages of 10 years into the future are going to look like? Or in your opinion, where where is language you design headed to in the future? 340 | 341 | [01:04:53] So. So. So my favorite candidate for that is that, you know, these, you know, major breaks and things like that always happen because, you know, something major happens in the underlying technology. 342 | 343 | [01:05:07] And, you know, one of the areas of underlying technology that is kind of like a computer that I think is really underserved is is writing code for GP use. Right. I mean, right now there are there are no languages worth that crap. 344 | 345 | [01:05:30] And that's a technical for trademark that work well on GP use. And, you know, maybe because there's like a limited number of algorithms that people are willing to are really interested in, but they're really important ones. Or maybe it's because they're they're inherently all mathematical. And the number of people who care about writing numerical code is small. I'm one of those, though. 346 | 347 | [01:06:02] And you know, and so every now and then, I spend time thinking about, you know, what would you do to make GPE you programing really easy. 348 | 349 | [01:06:17] Yeah, but but but it's more than just vector operators. I mean that that's kind of my my problem with the whole thing is that most of these things are just libraries of hand coded assembly that do vector operators. And and surely there's something more clever than that. 350 | 351 | [01:06:38] Maybe I'll just add one with language design. You know, one of one of the things that's interesting, you look at like all of us old geezers sitting up here and there they were, we're proof positive that languages move slowly. 352 | 353 | [01:06:49] And I mean, it's not you know, like a lot of people make the mistake of thinking that languages move at the same speed as like hardware or like all of the other technologies that that that we live with. But but languages are much more like math and much more like the human brain. And, you know, and they all evolve slowly. And we're still programing and languages that were invented 50 years ago, like functional. But all of the principles of functional programing were thought of more than 50 years ago. I do think one of the things that that is luckily happening is that like as Larry said, everyone's boring from everyone and languages are becoming more multi paradigm. 354 | 355 | [01:07:29] Yeah, I think it's wrong to talk about oh, I only like object oriented programing languages or I only like imperative programing or functional programing. 356 | 357 | [01:07:38] I mean, it's important to look at where's the research or where the new where's the new thinking and where where are new paradigms that are interesting and then try to try to incorporate them. But do so tastefully in a sense and and work them in to work them into whatever is is there already. 358 | 359 | [01:07:56] And and I think we're all learning a lot from functional programing languages these days. I certainly feel like I am because a lot of interesting research has happened there. 360 | 361 | [01:08:06] But functional programing is imperfect and no one writes pure functional programs. I mean because they they don't exist. So it's all about like how can you tastefully sneak in mutation in ways that you can better reason about as opposed to mutation and free threading for everyone, you know? 362 | 363 | [01:08:26] And that's like just a recipe for disaster. Right. 364 | 365 | [01:08:30] So, yes. 366 | 367 | [01:08:40] All languages are imperfect. Let's just settle it right there. You know. 368 | 369 | [01:09:04] Yes, we've been thinking a lot about the the the parallelism concurrency issue. This is one of those issues where we were waiting to be smarter. Uh, we we did borrow. I mean, steal a bunch of ideas from Haskell in terms of lazy lists and things like that. But in terms of how you actually are going to deal with the end of Moore's Law or if not the end of Moore's Law, at least, you know, multi, multi, multiple C.P.S., many, many cores. When you have a thousand cores, what are you gonna do with them? 370 | 371 | [01:09:44] And so a lot of our early design on Perl 6 was we didn't understand how we wanted to do it yet, but we knew very we knew very deeply that we didn't want to do anything. It would prevent it. So a lot of the early design decisions were just saying, well, we have to keep this open. Then when the right smart people came along, they said, look, what you really have to look at is things that are composed. All threads are not composed of, well, we can't take two threads and turn it into a third thread. What you want is things like we stole from go from. We stole promises and channels from C-sharp. We stole functional reaction will programing. 372 | 373 | [01:10:29] And with these sort of primitives which end up being duels of your regular list processing kind of primitives, they just happened to be working on events. And you're you can have loops, event loops that were just like regular loops that they're running on and same control flow. So that is easy to learn. There are ways of sneaking these things into a language, at least in the ways that we understand right now that I heard. 374 | 375 | [01:10:59] Was it. Who is talking about adding fibers to their runtime? 376 | 377 | [01:11:04] I think you'd think it was a Java news item, but like lightweight threads that can you, as Erlang has done, has shown, you know, you can run a hundred thousand threads in your process. 378 | 379 | [01:11:15] That's another language that's been around for a long. Oh yeah. And we stole from them too. Yeah. Should we. We like their pattern matching. But one of the many therms is that all of that language design is theft of course. 380 | 381 | [01:11:28] Yeah. So yeah. I mean we're thinking about it. 382 | 383 | [01:11:30] We don't know have all the answers yet but I think all these languages, you know, long term tend to converge on similar solutions. 384 | 385 | [01:11:39] So very sadly we are at the last question. I know you went so quickly and unfortunately all good things must end except for maybe good languages. So I'm going to start and maybe quickly wrap up as you look back over the long lives of the languages that you've written. 386 | 387 | [01:12:06] What have you found most rewarding? 388 | 389 | [01:12:10] The people? 390 | 391 | [01:12:11] The people by far after the. 392 | 393 | [01:12:16] Oh, yeah. Yeah. I mean, that that's what keeps me coming back, that to work everyday is like the incredible excitement that the community shows. You and I I am so grateful for all the people who who have used that. I mean, it there's nothing more rewarding than have people just like on Twitter or wherever it is, go, oh, my God, this is so great. And it's like, yeah, that makes you want to just keep doing more of it. I mean. 394 | 395 | [01:12:46] Oh, yeah. You know, somebody comes up to me in the street somewhere and says, you know, thanks for giving me a career. 396 | 397 | [01:12:54] Can I have a selfie? 398 | 399 | [01:12:57] You know, that's like this is kind of like, you know, light and dark thing. 400 | 401 | [01:13:02] But being this is really wonderful. This is all great. I mean, I have to be in Silicon Valley at a movie theater, the tire shop. 402 | 403 | [01:13:14] Yeah. Well, what's really weird is when you're when your kids are with you when that happens. 404 | 405 | [01:13:20] But but, yes, it's. It's when the when people say, you gave me a career, you get my livelihood. You fed my family. Yeah. 406 | 407 | [01:13:29] That's the best. It's. And you know, and and not just. 408 | 409 | [01:13:36] And we're not talking about a star relationship here. Each of us to those individuals, we're talking about the second order, Community 2.0 kind of effects. 410 | 411 | [01:13:47] It's it's one thing to see them, you know, getting help from you. It's another thing to see them helping each other. 412 | 413 | [01:13:56] That's a whole whole level above even the individual relationships. I feel to see a community that is learning how to love, you know, kind of building a little bit of heaven on earth. There's just nothing like it. 414 | 415 | [01:14:13] Completely agree. Kita, you get the last word. 416 | 417 | [01:14:22] And we love learning from you as well. 418 | 419 | [01:14:24] And with that, I want to say we've all learned so much from all of our wonderful panelists tonight. 420 | 421 | [01:14:33] I want to thank you for allowing me to share and celebrate this moment with you. The little fifth grade kid in me that was plinking away on basic at Bell Labs who later watch the P.C. cell phone, Internet, Web and cloud computing and change our world. Never dreamed that I would be chatting with four individuals who profoundly impacted our world by doing what they love, creating and building languages. Please join me in a huge round of applause to thank Anders for inspiring this evening. 422 | 423 | [01:15:15] Thank you, Carol. OK. OK. 424 | 425 | [01:15:19] Was that epic? So, Marina, I have an idea. 426 | 427 | [01:15:24] If you guys could step down right here, we're going to get a giant picture of everybody. You guys stand right there. We're going to get up here with your camera. All right. We're getting a picture of everybody in that room. All right. I need some excitement. 428 | 429 | [01:15:47] Oh, my God. I met my idol. She can stand on the chair. You can use my shoulder. OK. All right. Show some excitement, people. Let's see it. 430 | 431 | [01:16:01] Monahan's. Three times it's kinda weird and lumpy. 432 | 433 | [01:16:11] OK, thank you, everyone, for coming. Thank you to all of our speakers. Thank you to our organizers. Let's do something equally awesome next year. 434 | 435 | [01:16:23] And if you want a robot there, 100 bucks. So come see me. 436 | 437 | --------------------------------------------------------------------------------