 Thank you all so much, all of you, for coming out tonight. It's really great to see you. I'm going to find out who the post-JavaScript populace. I need to explain this title. There are some experts who say that this title is wrong, that I should call it the put-JavaScript populace. And there are other experts who say, no, no, it's the hatch of JavaScript populace. And this confusion, post-put-and-patch, is due to HTTP. HTTP is the hypertext transport protocol. It's what the web uses to meet.net's data level. And it has three verbs in it. And they seem to be synonyms. They all mean the same thing. And often they do the same thing, but there are a few cases where the experts say, no, if you use the wrong one, disaster will occur. It's the end of the world populace. And that makes it really hard to use. I think in a well-designed system, it should be one. Or if there are more, it should be obvious which one is the correct one to use. But having all this mess in the protocol, I see that as a symptom of clutter. Clutter is when you've got too much stuff well-organized and it gets in the way and slows things down. So in our lives, we can think of life as the opposition of stuff. Every day we go out and we work and we get money and we use that money to buy stuff. We only start to fill up with stuff and stuff. We get more and more stuff. And we think of the value of the stuff that we have in terms of its acquisition cost, or maybe its cost of replacement. But often the stuff we have actually has a negative value. For example, you might have some stuff that's really valuable to you, but you can't find it because you've got other stuff that's in the way. So the stuff that's in the way is decreasing the value of other things. Sometimes you've got stuff piled on top of other stuff and the stuff on top is literally destroying the stuff that's on the bottom. So having too much stuff can actually decrease the quality of your life. And so you want to knowledge it. You want to get rid of it. And it turns out there is an authority on how to organize stuff and how to remove clutter. It's a wonderful Japanese woman named Marie Kondo for Komari. She is, I think, the world's greatest living authority on how to make a home a nice place to be. She's really good at organizing things and filing and putting things away. She's great. So one of the things she teaches is how to figure out how to get rid of stuff. And what she'll do is she'll go into a room and she'll pull everything out of the closets, out of the doors, off of the shelves and put it in the middle of the room. And then she will go piece by piece to pick up each thing and she will ask her a question. She'll say, Tokimiku desu ka? Which means do you thrive? Do you vibrate? Does it give some signal that this is something important to me? And if not, you should get rid of it. You should put it on eBay or you should recycle it or gift it to somebody or get rid of it. But if it vibrates, then that means it has value to it. Now when she's teaching in English, she doesn't say, thrive or vibrate because it makes some people giggle. So instead, she says, does it spark joy? Which is delightful, right? So you pick the thing up. Does it spark joy? What does that mean? Well, it must mean something to you if it does and if it does, then you'll keep it. So I want to apply her strategy for organizing things and getting rid of clutter to our programming systems. Unfortunately, as much as I love the concept of spark joy, it doesn't work because we love all of the stuff. You can look at, you know, whether there's programming languages in the world, say JavaScript, for example. It has more bad parts than any other language and yet there are people who love every feature of the language. You won't find any one person who loves all the features, but there is no feature that is not loved by somebody. Every feature sparks joy. So when we start looking at the design of the web and the internet and computers in general and everything, spark joy is not enough for deciding how to get rid of stuff. We need other criteria to clean things up to make it easier for us to do the stuff that we need to do. So, yeah, so I want to get rid of clutter and programming. We've got too much clutter. If we can get rid of the clutter, our systems will be much more straightforward. We won't be arguing about quick and post. It should be obvious how to do the right thing and then we can spend more of our time doing the right thing and not having time to do the consequences of having done the wrong thing. So I'm going to start by looking at ASCII. ASCII is one of the fundamental things that we all work with every day. It's the American Standard Code for Information Interchange. It was originally designed for teletypes, but it then became the standard character set for computers. It still exists today. It's the first 128 characters of Unicode, so it's around us all the time. But it was designed at a different time for a different purpose and it's full of clutter. So let's look at some of the things. For example, it has tap and space. Space came from the space bar, the thing you press on the typewriter to move the carriage one click over. Tap, which was short for tabulate, would release the carriage and let it swing freely until it was obstructed by a physical tap stop. You would set little screws on the carriage which were prevented from moving when you pressed the tap key. And the ASCII set includes that because they wanted to do at least everything that a typewriter could do. But they didn't consider what a tap stop was. They didn't provide any way of defining tap stops. There was no default for how much a default tap stop should be. And so we still argue about how big should tabs be or even should we have tabs at all. And it's a pointless argument which is just a tremendous waste of time. And it's because of this pattern that we have two character codes that do kind of the same thing, that are almost interchangeable but not quite and so we argue about them all the time. And that arguing is a huge waste and the value of having both of them is no value but it's just total negative. So have any of you seen Silicon Valley? You need to buy HBO to get Silicon Valley. Silicon Valley is the best TV show ever made about programming. It's really, really good. It's about this guy Richard Hendricks who is a brilliant programmer and his adventure is in trying to start a software company in California. And he's a brilliant guy. He works really hard. He works so much that you can't find a girlfriend. You probably know the type or maybe you are the type. So anyway, in season three he finally finds someone and she's great. She's smart, she's nice, she's a programmer. She seems to like him for some reason but she uses spaces instead of tabs. And it makes Richard crazy. It turns out his affection for an invisible control character is greater than anything he can ever feel for another human being. So he destroys their relationship. So clearly having tabs on spaces costs so much human misery and I want to end it. So this is my proposal. I want to get rid of one of them and I can't get rid of space so we're getting rid of tab. This moment forward, tab does not spark joy. Right, so Asti also gave us two quote marks, the single quote and the double quote. And Chalester uses both of these and he uses them both to do exactly the same thing. And so that leads to arguments about which one should be used and complicated rules about when we should use one or the other. I invented a set of rules that I thought made sense but I saw other people had different rules which made just as much sense and there was no mechanical way of determining if it was being used correctly by any set of rules. So I finally decided this is clutter. We don't need two of these, we should just have one. So I'm going to get rid of one of them and the one I'm going to get rid of is the single quote because it is overloaded as apostrophe, right? So it causes problems if you're writing contractions or possessors in English. So we'll just use double quote for students because it sparks joy. Asti introduced the idea of separate codes for uppercase and lowercase. So the original design for Asti was it was going to be a six-bit character set which meant it could contain at most 64 characters. So there wasn't enough space in the character set to represent both uppercase and lowercase. But typewriters could. The way typewriters did it was they had a shift code. So the committee that was creating Asti decided we'll have two shift codes, one for shifting up and one for shifting down and that's how you'll get uppercase and lowercase. And that would have worked. But they decided not to do that and the reason they did that was that at the time teletypes would communicate over noisy telephone lines. And if you got hit with some line noise a character could get garbled and turn into some weird noise character when it got received on the other hand. And so it was common for teletype printouts to have typos in them because of the line noise. And their concern was that if the shift character gets garbled then the rest of the page is going to look stupid and it's going to look like the star is showering or something to miss out. So for that reason they decided they would add a seventh bit to Asti moving it up to 128 characters and give a separate code for each of the lowercase characters. That had never happened before. All characters set prior to Asti just had letters and that would actually have been better for us because we have this we would have determined case in exactly the same way that we today determine color and style and slant and decoration all of that stuff case would just be another one of those but we didn't do that because of the influence of Asti so as a result we now have case sensitivity which is a concept that never existed before now so I would really like to go back and fix Asti but it is too late we're stuck with it and so we're going to have this uppercase-lowercase thing I think until extinction so that's a bit of clutter that we'll just never get rid of. JavaScript in ES6 added the let statement which is an alternative to the bar statement the difference is let respect block scope which isn't really all that important but you can write good programs with bar you can write good programs with let the advantage of let is it doesn't confuse the Java guy so much so there's actually value in having those guys be less confused so we don't need two of them we only need one so I'd say the one we should keep is the let we don't need the bar unless you have to run on Internet Explorer but we shouldn't do that anymore stop writing for Internet Explorer Internet Explorer does not spark joy so we have const now which is a companion to let which creates a variable that you cannot then assign to but a lot of people get confused about the difference between const and freeze it's a really important difference one applies to variables and the other applies to values it's my opinion that you shouldn't be able to get the JavaScript license unless you understand the difference between const and freeze so get on that JavaScript has two bottom values the bottom value is something which represents nothingness and there's some argument among language designers should we even have a bottom value but there is nobody who thinks you should have two of them and JavaScript has two of them they are not interchangeable they are slightly different but if you have two things which look to be the same which sometimes are interchangeable but sometimes not there are lots of errors and problems this is clutter I want to get rid of one usually the one I would get rid of is the one that is longer but in this case I have to get rid of null we've got problems with null in this language type of null is object which is completely broken and that's never going to get rid of this if you're using undefined and not null that's never going to be an issue so unfortunately we have undefined now the concept of null null is a the concept of a null pointer as a programming language is due to Tony Gore a brilliant British programmer who proposed the idea of having a pointer value which represents nothing he has since determined that that was a mistake it was a billion dollar mistake he did that by estimating the cost of all of the accumulated null pointers all of the accumulated null pointer exceptions have ever happened to all of his fault he's really sorry about it so we're stuck within JavaScript but hopefully someday after JavaScript we'll have a better language which won't have null which works as a pointer what I think makes more sense is known as an immutable empty object and in JavaScript today it's possible to make such a thing we make a const which would be an object which is empty that inherits nothing which we would freeze so if you go to that object and ask for a property and it doesn't have it the rule of property access in JavaScript says that you get the undefined value which I would like to fix and say no you get this new kind of null value instead I think you have a long dotted expression it doesn't matter if at some point we run out of objects and it stops you can go down the whole thing and even if it doesn't make sense you'll just get null of it which is just what you should get so I'd like to see this in the next language whatever that might be so functional programming is suddenly becoming a really big thing functional programming solves some of the problems that we're now having in distributed systems so it's good stuff it took a long time for it to get to the mainstream but it's finally starting to happen and a lot of it was due to JavaScript JavaScript was the first language to bring round in the way that scheme did them to the mainstream which was great but there's a more extreme version of functional programming which is pure functional programming where you have analogies of functions to mathematical functions mathematical functions are not really about computation, they're about mapping of mapping in one set of values to another set and in those sorts of functions there can be no side effects there's no mutation nothing is changing just discovering what the values of things are so the idea is we bring that to programming so in that world a given input to a function will always yield exactly the same outcome which is not true for most of the functions that we write but in this pure model it has to be the right time so there's no mutation allowed no side effects nothing changes all we do is discover values so why wouldn't we do that first reason is testability if input to a function that it always gives you exactly the same output always guaranteed then testing becomes a whole lot easier because you don't need to worry about the context of anything because no matter how you call it no matter when you call it it should return the same thing so your testing burden should go way, way, way down composability that when you have pure functions it's possible to compose functions together in really interesting and very powerful ways things which make us much more expressive much more productive that's really good stuff and maybe the best reason to be interested in that is parallelism that you might want to have multiple things going on at the same time that's how you make things faster and in conventional mutating languages like Java for example we try to do that with threads but there's a really big problem if a thread is mutating it does read, modify, write, memory and another thread is trying to access that same memory at the same time and if you try to prevent that with synchronization you get deadlocks which control your systems all of that is really, really bad stuff but if you never mutate then all the threads can be running full speed all the time with no races, no deadlock, no nothing everything goes really fast that's the only way to make a run we just go fast so can you write this way in JavaScript it turns out, yeah you can you just need to remove the impurities of the language you don't have to add anything to JavaScript to get pure functions we just have to remove the stuff that's not pure for example the date function every time you call the date function it gives you a different day that's not pure function you could have the random function you get a different number so that's gotta go for the delete operator that mutates objects, we can't be mutating objects so that's gotta go I'll just assign in any other built-in methods that modify objects can't have those, those aren't pure and they're similar methods that do the same thing to arrays the sort method in JavaScript unfortunately it's the array, it didn't have to it could have been defined to create a new array which is sorted but it didn't so that's gotta go regular expressions or complex regular expression execution that's got some state that changes the regular expression object so that can't have that assignment so we gotta give it assignment so the equal sign has the assignment operator anyway so it's good that we're getting rid of that bar statement can't have bars those things can't be changing can't have left either const is actually great so that means that you can put a value into a variable once so get it right and get it in there and you're done so const is good for statement can't have for statements it wants to change conduction variable that's mutating gotta get rid of that users, turns out every time they'll do something different humans are not we don't map them out we just don't confuse so gotta get rid of the users and gotta get rid of the network because it turns out every time you go out on the network something else could happen so the problem with the pure model is that it doesn't respect the fact that the universe is mutating and so we need some sort of hybrid model there's a debate going on right now about where the dividing line is but what's clear is that we should try to have purity wherever we can as much as we can for all of the benefits that we get from purity and then for the places where we have to interact with the world then we'll do the dirty stuff an account balance cannot be an mathematical constant it's gotta be able to change somehow generators were added to ES5 and I think that was a mistake because they weren't necessary but generators that ES6 added are too complicated they've got weird nasty syntax and change the model of the language and you don't even need them all you need to do generators is a function that returns a function if you can handle that you can do much better on your own so let me demonstrate that so to make a generator you have a factory function factory function is a thing that makes generators and it can have parameters you can pass into it to customize the generator that it's going to make you then declare your generator state variables and you return the generator function the generator function will compute a new value based on what the current state variable is and modify the state variable and return a new value that's it, that's all you need so here's an example this is the element function the element factory creates a generator which takes an array and each time you call the generator it will be during the next element of the array it's really easy so we've got a counter which tells us where we are in the array that is in the scope of the factory but the generator function closes over it so it has access to it that's flexible closure that's great, that's the best feature ever with the programming language and JavaScript was the language that brought that idea to the mainstream so we should use it so if we haven't reached the end of the array yet we'll get the next value from the array, we'll increment it high return the value that's a generator really easy stuff callbacks are a really important thing they are how we manage a synchronicity in our language often they're misused because they're a low level thing you need to acquire level stuff on top of them in order to make them work well but as a fundamental mechanism they are essential and important but there's a problem a function that takes a callback or a continuation bc is an extra argument that argument is the function to call when you know the result of whatever this is or callbacks do and there are two places where you can put it in a parameter list it could be the first thing or it could be the last thing so you can do it either way but people do it both ways that's what we can and that's clutter so anytime we give people an option to do what might be a wrong thing we'll do it and then defend our rights to do and then they'll argue about it and the basis of the argument is nobody knows what the right thing is so pick something and maybe it's right but it turns out ES6 told us what the right answer is if we have a variable number of arguments and we want to use the new ellipsis operator and that says the callback has to be first because ellipsis wants to gather everything that's last so that's it so anybody who's doing it wrong you're unnoticed you need to fix that the callbacks have to be first we're adding ES6 I think they're on the same promises were discovered or invented in a company that I founded 20 years ago called Electric Communities in a language called E and they were a brilliant mechanism for doing distributed and secure programming and they somehow leaps from from E into Python and then into JavaScript and unfortunately in the process we're kind of limited I'm not a big fan but it's there and there are a lot of people using it but it was not designed to manage a certain ethnicity which is the thing that we're using it for I recommend instead using RQ which is a library that I wrote it has four functions in it so it's not a big library but it can deal with sequences and doing things in parallel sequences and callbacks it's really easy to use and straightforward if you understand how to write a function that can return a function and I assume you all know how to do that now but let me just show you how to do it syntax the most controversial part of programming language design it turns out syntax really doesn't make much difference the important thing is the semantics what does the language actually empower you to do some of us don't understand that we have a deeply emotional relationship with the syntax and we will argue about it and we will depend on stuff which is actually causing us problems there's no end to it it's fashion it seems strange that fashion dominates the most nerdily of all the arts but it does programming language design and syntax it's just fashion so let's look at some syntax through the ages the first one there is Fortran 4 that was my first program Fortran was created before a lowercase was discovered in Fortran spaces were not significant so if a looked the same to Fortran so in order to separate the if part they required the use of the params just to separate the components of the statement they had that EQ operator for determining is PA equal to B which is nice but they introduced the terrible terrible idea of using the equal sign for a sign they should have been using equal sign for equality BCPL was the first good parts language BCPL was began as a subset of CPL which was a language that was designed by committee that got way too big and complicated and a brilliant designer took it and made just the good parts it's the first curly brace language and in his language spaces are significant which was not a new idea but it was a good one he's using the equal sign for equality which was brilliant he was using Assignment operator for assignment which was also brilliant and he required the use of curly braces in the consequence of the if this was the first curly brace language and he did it correctly JavaScript was based on a series of languages Java C++ C and then B B plugs an interpretation of BCPL which unfortunately got it wrong that the parentheses are required and the curly braces around the consequence are optioned which turned out was a really awful mistake because they're programmers like since the compiler doesn't care I have a right to leave the curly braces out which means it's likely that errors are going to creep into the code as a result of that so always put the curly braces in every time on every if, on every while, on every for, put the curly braces in just go it's not hard it doesn't work how about 60 was the best design by committee of a programming language in the history of the world in fact it may be the only successful design by committee of a programming language ever they just got some billion people together and the stars aligned and they did something which really propelled the state of the art it was really amazing work it was so successful that they thought again so they brought together another committee of really bright people and created elbow 68 which was not nearly as brilliant as elbow 60 was it was big it was complicated it was loaded there was just a lot of bad stuff but I really liked their if state so even though they were modeled after elbow 60 which was the language that introduced blocks to programming they didn't have blocks so no begin and no curly braces instead they delimited the if statement with by so by is if at word so they sort of symmetry to it and I just like that I think that looks nice to me also given if you look at our programs particularly in all the C ish languages especially in JavaScript we've got so many curly braces it's really hard to figure out what does this curly brace close if you leave one out someplace then matching things up becomes really really hard but if your ifs aren't playing that game if they're made out of a different piece of syntax then the programs become a lot easier to read and manage so I like that I think we could make a little bit better so I'm hoping in the next language we can simplify this even further I think python had the right idea in making line breaks line breaks significant so if line breaks are significant we don't need the then we don't need the semicolon so we can just slim it down a little bit there's a lovely language called rebel which used colon as the assignment operator which I'm thinking looks really really nice that there's analogous to that line by line I also like Yalba but just a colon so some milk leather there, that sparks joy certainly so let's look at the try statement this is not the way you use try in JavaScript obviously because we're smarter than that this is Java in Java it's very common to have try with a large number of catches and finally we don't need any of that in JavaScript but Java has it because of the brokenness of its types that the Java heads claim that Java is the superior language of the two because it's got these types and the way it manages the types not recognizing that in fact the types are causing errors in the design of the language itself and in the way the language is used so the reason they have finally is because they don't really didn't have functions so there was no place where you could put some code which gets run no matter what path you take for this in fact if you look at the design of the JVM and how finally it's implemented it's implemented as a subroutine call in return they didn't expose that to you so you don't get to use it but that's what they're doing and finally is an implied an implied function and I don't like implied stuff generally in programming because I like stuff to be explicit I'd like to be really clear this is what's going on I don't want to be some syntax which is disguising what's going on I think that actually causes a lot then why are there so many catch clauses it's because of the typesystem that often there are multiple different kinds of things that might get returned from a function or a method but the typesystem doesn't allow for that multiple bunch of stuff it only allows one type to be delivered but there are other things that you have to deliver that aren't errors that aren't really exceptions they're just another thing that sometimes has to be returned and so they overload the exception mechanism to make up to compensate for the fact that the typesystem weren't a problem so so that's a mess so comparing this to how we do it in JavaScript if you're thinking in JavaScript you don't do any of that stuff you try something you'll try plan A if it works great you're done if it doesn't work try plan B you don't even care what plan A didn't work so you don't even need to look at whatever exception object or error object got passed to you you don't care it doesn't matter just that didn't work try something else that's much better that's a language in which the typesystem is working for you not against you there are other places in the design of Java where you can see the typesystem failing so when you're searching for something using index up and you don't find it Java can't return normal it can't return an object it can't return anything it can only return an int and so it picked an int that was going to be an unlikely place but this could cause errors right expect that something to go negative and you pass it in to something else and you get a mutation with it and you get a really weird error what what JavaScript can do because it's a better language they couldn't return null or undefined in this case which would have been much better but that didn't happen instead Java was copied so things that are wrong in the Java's type system somehow affected the JavaScript so let's talk some more about types hyperequips so we're going to add an int 32 to an int 32 what is the type of result? no, there's actually a right answer so anybody know? anyone? int 32? int 62 no, that's not correct it's int 33 yes, int 33 is the right answer it's because if you add a possibility that it's going to roll over and it's going to have an extra bit of significance and Java is not aware of that and so there's this idea that the type system is protecting us from mistakes but it's actually causing mistakes and this is a pretty nasty mistake where a number can go wildly negative and without warning or explanation let's try another one int 32 times int 32 what's the type? anybody? int 64 int 64 we're close, it's int 63 int 63 but if you're 64 GASP is much better than the one Java did it's 31 bits off you can hide some really significant errors so again there's this pretense that it's protecting us from errors but it's actually causing us errors so this is the most reported bug in JavaScript and I think this is off particularly if you're trying to deal with money because we counter money in the decimal system on this planet at least and you expect this to work and it doesn't because we're using binary floating and it gets even worse than this for example because these are not exact values associative use broken which means the order in which you add things together can change the result which is appalling that's extremely bad stuff so I propose to fix this with, I'm proposing a new decimal format called DEC64 it's a word in a 64-bit word it has a 56-bit coefficient you can turn an 8-bit exponent I put the exponent on this end because on Intel architecture you can unpack that for free you can turn any ordinary int into one of these simply by shifting the 8 bits and storing it in this thing in a software implementation most integers can be added in 5 instructions which sounds like 5 times more than you would want except that you also get man's and overflow protection in those 5 instructions which is a nice thing to have in a hardware implementation 2 numbers with the same exponent could be added in one cycle so that eliminates the performance argument for why we need points and it eliminates a large class of errors that it can have including the DEC63 error and it fixes the 0.1 plus 0.2 equals 0.3 error so this is what we should have if there's anybody who's working on the next language to be posting a JavaScript language you want to put this into your product this is an implementation DEC64 to build one get how it runs on DEC64 it's an assembly language it's as fast as I know how to make it I imagine that someone else could make it even faster but it seems to produce correct results certainly much better results than we're getting in by every point so I think the next language should have this as its only number type because if you have multiple number types you can make errors by choosing the wrong type that's a source of clutter we don't need clutter we need joy so let's talk some more about numbers 0 divided by 0 what should happen if you try to define 0 by 0 but yeah it's complicated so if you ask a mathematician he will likely say it's undefined and what they mean is not that JavaScript means undefined what they mean is it doesn't even make sense to ask this question I don't hear you when you say 0 divided by 0 it's impossible it can't happen but we know as programmers that if there's a way to say it somehow we'll get set programs need to deal with that so what should a computer do if you try to define 0 by 0 one argument says it should catch fire because it should never happen so it doesn't matter if the machine catches fire it happens because it doesn't happen except we know that it does happen catching fire will not give us the 5 lines it's not what we want to do another argument says you should get a nano value that's a reasonable thing that's certainly better probably than catching fire another thing says it should be 0 business applications 0 is the right answer 0 is what they want you didn't sell anything but you still need to know how much money you made 0 is as close as you can get to the return number man's or he won't mean anybody mean anything to a business person 1 you got n over n and over n is 1 I once worked on a mainframe where you got 2 it was a computer that was designed by Seymour Cray maybe the best computer designer in history and I can imagine a conversation that happened that controlled data someone said Seymour you just found out when you divide 0 by 0 you get 2 you said yeah well should you fix it you said no I'm not going to fix it I'll tell you why I'm not going to add another cycle to it just for a case that should never happen I don't want to slow down everybody's division just because some idiot wants to divide 0 by 0 so and I think he was right because as far as I know I'm the only person who ever tried that so why do I care about what 0 divided by 0 is because I'm actually more concerned with this case what is 0 times n any guesses as to what that should be 0 0, yeah I think 0 is the right answer and in fact compiler writers used to use that knowledge so that if they have a multiplication to do and they know that they can determine a compiler time if one of the operands is 0 they don't have to evaluate the other operand if it has no side effects if it's pure which is great because not only does it make the program run faster it even makes the compiler run faster so it's a win all around but that changed when the IEEE floating point standard came along because it says if n is n the answer has to be n which means you have to go ahead compile that code generate that code and execute it anyway and then look at it to see if it's n it can't just accept that 0 and I think that was wrong it's slowing things down the motivation was they wanted to punish the wicked anybody who's doing stuff with nams they need to be punished and so now I'm more concerned with making good programs run faster and I don't want to pay that apparently I'm siding with C more on this one I think C more about it right so who writes code that multiplies things by 0 anyway not a lot of humans do that because we tend to do a lot of pre-optimization but definitely machines do so code generators, macro processors partial evaluators they definitely do this and they will generate better faster programs if we allow them to multiply by 0 also it turns out that one of the slowest things you can do in modern CPUs is a conditional jump we've got so much pipelining going on in this instruction that any time you do a conditional jump it's like everything's small it takes a long time for the computer to get back up to speed again you can avoid that by using multiplication where you've got a value which is either 0 or 1 you multiply one thing by that number and you multiply the other thing by that number minus 1 so you can do that stuff you can do it to multiplies in a decrement where it does some track and no conditional jumps so the code actually goes faster so I would like to allow us to have better idioms for writing our programs so because of that and related arguments I want all of these forms to produce 0 all the time because that's it makes sense and I'm not interested in punishing anybody I want to make our programs good and fast and this is compatible so deck 64 to get back to that does this so it's another reason why we want deck 64 reserved words added later as a consequence of computers with very small memories for example the first version of B round of machine that had like 16K really really small the whole operating system and the compiler had to run in this tiny tiny space and so languages did things to make it easier to get work done in these tiny memories and one of the things was having a reserved word policy so the compiler doesn't have to reason what does this collection of letters mean in this context I can just say that is always an if statement so we don't even have to worry about context that made them a little smaller that's not the case anymore you don't have gigabytes of RAM in your pocket it's likely soon you're going to have terabytes of RAM in your pocket but we're still thinking about machines that are measured out in K at least in the way we design our programming languages so I think we should fix that one problem with reserved words is it's a hazard for programmers you declare a variable and use a method name or that matches a keyword that you are not aware of your program is going to fail that's annoying and it's also bad for the people who make languages they may want to add a new feature but they can't because if they do then that's going to break any program that is trying to use that word so they make up really ugly nasty little symbols instead you see what C has been doing with that stuff right it's really awful because they have no alternative because they're stuck with this broken reserved word policy so one example of what's happened with that is when exceptions were first being proposed the word which would cause an exception to happen was raise okay to raise an exception but raise was already being used to raise things to powers and similar things so they used throw instead because nobody thought throw meant anything useful so it wasn't used so that's why we throw exceptions not raise exceptions now most of you have never seen anything except throw so you've gotten used to it but in fact it was a really bizarre notion when it first came out so I propose a new policy so if any function in any function the word may be used as a language keyword such as if or as the name of the variable but not both and the programmer gets to choose which one it's going to be this is good for programmers because you won't trip over features you don't use and it's good for language communicators because they can have new features without breaking anything and it turns out you don't need terabytes of memory to implement it's actually very efficient count case or under bar this is another of those things we have two ways that we can make variable names and because we have two ways some people will do it one way some people will do it the other and then they'll argue about it and the argument is never going to stop because it turns out in this case everybody is wrong the right answer is names with spaces we have a space bar in ASCII and we can use it so why don't we use names with spaces it's the same thing computers used to have tiny memories and it would be harder to write the compiler but here's an algorithm where we can very easily adapt so we'll start matching words and pick the longest set of words that seems to match or make sense so these you can implement so we should do that in the next language something which was a brilliant idea that somehow got lost was the idea of contracts we're programming by contract this was the feature of the Eiffel language it was brilliant for any function or any method you could list preconditions when this function is called these things must be true and if they're not true then an exceptional happen or catch fire or whatever you want to have happen but the function will not run unless everything is as it should be and you can also have post conditions after this function runs these things must be true and you can turn those things on and off they help document the program they make it clearer what the expectations are they provide much better information than title systems do for what the expectations of the program are and how everything should work I would really like to see these come back I think this is a brilliant idea that somehow got lost and I hope they become a standard feature of the next language the language that hopefully soon replaces JavaScript security is a really big concern the world has gotten so interconnected and we are all out there everything now is exposed and our languages were not designed for this environment the next language should do a much better job of security and allowing us to write secure programs so that we can all have confidence in we tend to go in the opposite direction that we look for features that are fine expressive fashionable without considering their impact on the security of what we are trying to do and it turns out now security is the most important aspect of our program it's more important than performance it's more important than anything we got to do better with security and in order to do that we need better tools we need better programming languages we need much better control over distribution all of our programming languages since Fortran is mainly concerned with sequential processing one then one after another and you know even looking at new languages with only a couple of famous exceptions that's pretty much still what they are concerned with her language being maybe the best example to the contrary we need to go with the other one so we need better control over distribution because our programs aren't just running in one CPU sequentially until finished our programs want to get distributed over many cores within a machine and run effectively in that space and the programs also want to distribute themselves over many machines over the internet and our languages are also sequential they don't do a good job of this so the next language should give us much better tools for managing distribution so that brings me to the end before we go I just want to acknowledge you please be careful out there the web is cluttered thank you so we have time for questions go ahead we have time for questions anyone has a question yes you say that now that I have two more actors that I need to look at instead of configuring us looking at it as compared to when I look at it I couldn't raise them I don't know if you at home heard this sorry question he's asking if you have the pie on the end of an if is that more work to read the two letters than to read the one curly phrase no it's not it's actually easier reading is not hard understanding is hard and it actually aids understanding anybody else yes so as you said you were anticipating a new language that would take over JavaScript so how long do you think that JavaScript would be alive for how many more years to come how much longer are we going to be stuck with JavaScript people still write cobalt from this yeah a while ago I met a programmer who was working at UCLA and he was writing in cobalt and I said well that must be like working in colonial building or turn the water lower so I'm certain that when Brenda and I designed JavaScript you never imagined that it would have lasted as long as it did and my expectation was that when the Netscape failed the language would have come with it and it didn't JavaScript saved the web from extinction and as a result of that the web is saving JavaScript from extinction so there's this thing going on there so I don't know that we're actually going to get rid of it but I'm a programmer so I'm necessarily an optimist I'm a programmer or a massive it's true because you can't do debugging unless you're an optimist well that's why we can't schedule right because we're optimists how long is it going to take that no there's no sign out there that JavaScript is in any danger of being replaced by but being an optimist I have to believe we can do better than that if only for our kids right if JavaScript is the last language that would be really sad we've got to do better for the kids the kids deserve a better legacy than JavaScript so that's what transpilers are for I mean transpiling doesn't fix the worst things in JavaScript it doesn't fix the number system for example we need a new better language I don't know who's going to make it maybe one of you some brilliant man or woman is going to figure this out and I'm hoping that the rest of us have enough wisdom to recognize yes that's it we need to figure out how to get this into the internet yeah do you think the languages or the to be languages should be far different than something like a smirk or a bow language for a little bit different for us especially the ones that we use for web development or on the web on the web for this should it be different than do you foresee them becoming the language that we you were talking about no those languages can't because they've got too much of the old package there's too much clutter in those languages as a result of when and how they were created we need a new language which is created without the clutter reasonable people can disagree on what the clutter is if anyone needs to understand what the truth is they can just ask me the other part of the question is should that thought of building a language for the browser solution be very different than how we do it for something on the other side it's just about the interaction well I think the distinction should be much less so one of the most interesting things to happen recently on the server side is we now have JavaScript on both ends and we thought that one of the benefits of that would be that you could be running the same code on both ends of the network and we haven't really figured out how to do that well but I think there's still a benefit in that right now it's we've got a sequential program on that end and a sequential program on that end I think Erlang had the right idea and that we want to bust things up into lots of lightweight processes lots of them some of them are running here, some of them are running there they're all talking to each other across the internet that's the architecture that we need to get to and there's no language yet that does that but it was designed a long time ago and it has accumulated a lot of clutter as well what do you think of Elixir as opposed to Erlang I've not looked at Elixir enough to have an opinion but it's running on the Erlang machine and so it's still going to be constrained by that I again I haven't looked at it closely enough to know how big a problem it's going to be I do know looking at Scala there is so much relief since Scala but I can also see how it was limited by having to run at the JDM so I wish Scala had been brave enough to be fresh and new they made a choice and it was a reasonable choice they thought we could get a lot of leverage if we go on the JDM and that was right but it came at a terrible terrible cost yes so I'm sorry okay as far as I know nobody in the world is using cat 64 I could be wrong about that no one has notified me that they are using it so you talk about callbacks and promises what's about the new kit on the block like the observables do you have anything about them the new series too I think it's talking about RxJ RxJs yeah so Rx is really clever stuff I like it a lot I do not think it should be built into JavaScript because it doesn't need to it works really well as a library things that work well as libraries should be libraries it doesn't need to be in the language but if it solves a problem that you have then that's great for those of you who don't know Rx is a package that came out of Microsoft that allows for the composition of against streets I don't think it's a solution to all problems but there are definitely problems to solve in that tool so you tend to argue for that as a produce to async and wait and ES27 came or do you see them as complementary they're complementary although I really don't like async and wait the thing that they're trying to do is to make our asynchronous programs look like synchronous programs so we don't have to understand how asynchronous works and I think that's going in exactly the wrong direction I want to be doing more in the early line direction where we're splitting things up and spinning it all over the universe not trying to figure out how to force a single model program to a week so I think it's the wrong problem it's really important that we understand asynchronous because it turns out the universe is asynchronous and we're all asynchronous and so we need to somehow figure out how to adapt to that and I think async and wait are crippling that you will not understand if you have those questions yes so I think you emphasized on getting rid of water from JavaScript and I was quite surprised that you don't mention classes do we sell place for classes I don't use it so I didn't even think about that yeah you're right I think it was having the classes into the language about half of the stuff that gets out into the language was obviously a mistake and the other stuff we're not so sure about yet what does it take on Roland's deeper what do I think about go lang go lang's deeper it's a function of a deeper and go lang I don't know that feature generally I like go a lot and I think there's a brilliant stuff in there that it's also an interesting experiment of trying to deal with there are no routines I think are not quite I don't like them quite as much as the Erlang processes but that's definitely the right direction they clean up the syntax a lot compared to the C languages I think their syntax is quite lovely but I don't think they do the distributed thing as well as the Erlang does but it's definitely the right cut it's not just one thing after another so I like go a lot yes it's things that GPU hates at fail I've not been in GPUs for a long time I think it's very different than what I remember I'm not qualified to talk about languages in GPUs but their model is so radically different than what we're doing in application languages so yeah we need better GPU languages for sure I don't know that one language could do well I think it needs to be more specialized yeah do you think if in the next version of this or future language we get this clutter and baggage there will be a substantial increase in performance or reduction reduction in errors or do we just move to writing better integrators like probably Google does being an optimist I think that if we can get rid of clutter then we become better programs we'll stop tripping over stuff and we can focus on making good programs and I see I see us wasting so much time on the clutter it causes errors and we refuse to understand what caused the error and so we keep making those mistakes over and it makes it creates our communities, makes it harder for us to work together hard to share code you know someone imports some code into a project style and everybody else then everybody gets angry and it would be better if we could just design a really good style and have it be enforced by the language and we don't just do that and stop wasting time about the stuff that doesn't happen hoping that a new language could accomplish that then there's a question of how long does the language stay free of clutter how long will it take us to start because we do that you know probably a week or two what's your favorite yes 6 feature my favorite yes 6 feature proper tail calls proper tail calls were invented in scheme they're the really important idea of that was in scheme that didn't get into JavaScript immediately we need that in order to do functional programming in JavaScript and I'm so glad we got it in the yes 6 and I'm really annoyed that it hasn't been implemented yet so if you're a browser maker get on it we need the proper tail calls please get that done Fonto what's your opinion Fonto often don't JavaScript framework kind of fail after the act yeah what's my opinion your JavaScript frameworks like React and Angular and stuff like that I'm very fortunate that I get to work on what I want to work on so I don't have to deal with any of that stuff so I don't know I have no opinion because I've never used it in one slide you were saying that we need to make become powerful faster and I was saying that we have like dynamize a brand in our pocket in two slides kind of contrasting to each other the point was that there were design decisions made in language design based on how much memory was available for compiler to run that doesn't matter that's a non-issue so we should not be adding or removing the features of languages based on what we can do in 16k it doesn't matter we should allow we should design the languages instead in terms of what helps us write good programs that's a much more important alright thank you very much again for coming out