Select text to annotate, Click play in YouTube to begin
00:00:01
[Applause] [Music] welcome back this is the second day of code dive 2017 let me kick start the day
00:00:19
by introducing their first speaker of the day and the first speaker is Douglas Crockford now Douglas is a very interesting person on many levels you may not know that he turned his back on
00:00:33
a promising career in television because well he discovered computers at some point so he has worked in learning systems small business systems office automation games interactive music
00:00:48
multimedia location-based entertainment social system and of course programming languages he is the inventor of Tilton and Tilton is the ugliest programming
00:01:01
language that was not specifically designed to be an ugly programming language he is best known for having discovered something that happened at the beginning of the 21st century I'm
00:01:14
going to tell you about the discovery in a bit he also discovered Jason the world's most loved data interchange format and he's currently working on
00:01:26
making the web a secure and reliable software delivery platform so as you can see and guess he has his work cut out for him now two key facts about Douglas
00:01:40
are that first he was born in check this he was born in frost bile sorry frostbite falls in Minnesota so that place is called again frostbite falls but he left the place
00:01:54
when he was only six months old because it was too damn cold and the second thing and it's about the discovery is that Douglas really is known for for
00:02:06
having made her first important discovery of the 21st century and his discovery was that JavaScript has some good parts so with this I'd like to
00:02:20
invite you to watch and listen and enjoy Douglass's talk and it's called the better parts let's give a warm welcome to Douglas Crockford good morning so let's start the day with
00:02:40
some better parts shall we so I'm gonna start with this guy this is Antoine de saint-exupéry please excuse my French he was an aviator at a time when we called pilots aviators when aviation was
00:02:54
really dangerous aviation was really dangerous because the planes would crash and in his career as an aviator he experienced several crashes and survived almost all of them
00:03:06
he was once trying to set a speed record from Paris to Saigon but his plane failed and he crashed in the sahara desert just outside of Cairo and he was not prepared for desert survival so he
00:03:19
suffered terrible dehydration he dehydrated so much that he stopped sweating which is a really dangerous thing to do in a desert and he suffered horrible hallucinations fortunately he
00:03:33
was rescued by someone who knew how to treat severe dehydration and he survived and he recovered then World War 2 starts he's exiled to America where he becomes a writer and it turns out he's a really
00:03:46
good writer he is best remembered for having written a children's book called the little prince it's about an aviator who is stranded in the desert who is visited by a strange little boy who
00:03:58
lives on an asteroid and his suicidal like most of the great children's books it's not really a children's book but it's it's really really good he wrote other books of more grown-up kinds of
00:04:12
books and one of them contained one of the best sentences ever written he said it seems that perfection is attained not when there is nothing more to add but when there is nothing more to take away
00:04:24
it's just a brilliant sentence I've seen it copied and quoted all over the place it's used in talking about design and architecture anything that combines creativity and discipline
00:04:37
he was talking about the design airplanes but it seems to talk about everything and I think it's particularly important in thinking about computer programming because we have a special
00:04:48
relationship with perfection our trade requires more perfection than anything else our programs have to be perfect or they fail so he gives us some insight
00:05:00
into how perfection is obtained it's not obtained by adding things it's attained by subtracting things by removing things by simplifying things and I think we can apply that to the design of programming
00:05:13
languages as well which leads to the principle of the good parts the good parts idea is that if a feature is sometimes useful and sometimes dangerous and if there is a better option than
00:05:26
always use the better option it surprises me that this is still considered controversial and it seems to me that this is obviously true but there are a lot of people who complain you
00:05:39
can't force me to use the better option it's like why are we arguing about this and I think it's due to a fundamental misunderstanding of what it is that we're supposed to do we are not paid to
00:05:52
use every feature of the language at the end of the project there isn't a manager with a clipboard who says did you use Plus+ did you use a with statement did you use comma as an operator did you
00:06:06
leave out any semicolons excellent know that nobody cares about that we are paid to write programs that work well and are free of error that's what we're supposed
00:06:18
to be doing now free of error when did that become part of the deal well it turns out it it has always been part of the deal it's the most important part of the deal but we do it so rarely that it's easy to forget that that's the
00:06:32
really important part so I recommend to everybody learn as many programming languages as you can because a good programming language will teach you it'll change the way you think about things and you can use that improved
00:06:46
model of thinking in other languages as well so you know a good language will teach you and the language which has taught me the most in my career has been JavaScript which really surprised me
00:07:00
because the first time I saw JavaScript I thought it was the stupidest thing I'd ever seen and so IB I made every mistake that you can make in JavaScript starting with the
00:07:13
first one the worst one I didn't bother to learn the language before I started writing in it because I thought I understood what it did and I also thought that there was so much wrong
00:07:24
with it I didn't want to damage my brain by being aware of how it worked and that turned out to be a really foolish thing to do and JavaScript punished me severely for that and then continued to
00:07:37
punish me until finally I just to try to learn the language and once I learned the language suddenly I had this epiphany that this language was not at all what I thought and as I started learning it made me
00:07:50
smarter about how to be a programmer one thing that concerned me about JavaScript though is that it contains a lot of design errors because the thing was designed and implemented in ten days and it turns out you can make a lot of
00:08:04
mistakes in 10 days and those mistakes are still preserved in the standard of the language and so you need to be aware of that and work around it so I developed a program called jeaious lint
00:08:17
which I wrote in JavaScript which reads my JavaScript programs and tells me when I'm using the features of JavaScript which are more likely to create errors and JavaScript is also instructive about
00:08:29
programming style when I started it I had no intention of of trying to enforce a programming style because my idea is a programming style at the time were completely wrong over the years
00:08:41
JavaScript or jeaious lint taught me to be much smarter about that that there are certain ways of writing programs which are more likely to cause errors or more likely to hide errors and so if you
00:08:54
can avoid doing that stuff and your programs are better that the mistakes tend to stand out and it's easier to get things right so I wrote my own book about my adventures javascript and janice linton and what i
00:09:06
learned on that journey and it's called java the good parts and it's still in print and it still sells well which is surprising for a software book to be sold ten years later most software books
00:09:18
are obsolete at the time that they're printed so this one is still relevant because what i recognized as being good parts in javascript turns out still are good parts in javascript even so there
00:09:32
are lots of arguments against using the good parts and i think it'd be a good time to review some of those arguments the first one is it's just a matter of opinion that you know you say something's good i say something's good
00:09:45
we you know we don't have to agree that all opinions are equally valid and that turns out not to be true so I am the maintainer of jazz lint so I get reports
00:09:58
from people all over the world and it doesn't happen very often but occasionally someone will write to me and say we just had this terrible bug and we spent two weeks chasing it down and with some weird corner case in JavaScript that nobody recognized and we
00:10:11
lost a lot of time and a lot of money on this and could you please put a warning into jazz lint so that you know this doesn't happen again so look at their report and if it makes sense I'll
00:10:22
incorporate it into jslint so if you're using jeaious lint it means that that will never happen to you that is not an opinion that is a fact every feature is
00:10:35
an essential tool and I need to have access to every possible tool in order to do my work it turns out that's not true that there's some tools that just don't work very well and there's a small set of tools which work really well and
00:10:48
those are the ones you should be using so if you can produce better programs by using a subset of the tools than the tools that are unnecessary are not
00:10:58
essential but a tool is sometimes useful and this sounds like a good argument you know I should be able to use something if it's sometimes useful but it turns out this isn't actually an argument
00:11:13
everything is sometimes useful we are really good at finding you of things and there is nothing so damaged so vile so toxic so disgusting that we cannot find a use for it so
00:11:26
everything has the property that it is sometimes useful so you if your only argument for including a feature is that it's sometimes useful you don't even have an argument I have a right to use
00:11:39
every feature okay the you know have a right that sounds really important and good but we've now changed the conversation we're no longer talking about what is the best way to write programs we're now talking about our
00:11:51
rights and it turns out this argument bottoms out at do you have the right to make crap yes I have the right yeah I
00:12:03
have the right who cares yeah it's not important that you have the right to write crap what's much more important is you have a responsibility to write programs that work well in our free of error I need the freedom to express myself I
00:12:17
am an artist I am a poet and I express my poetry by leaving out the semicolons I need to reduce my keystrokes you know so we imagine you know that we spend most of our time typing you know what I
00:12:33
do today I was typing I typed a program that's good that's how I spend my time but that's not actually how we spend our time we spend most of our time staring into the screen saying my god what have
00:12:45
I done that's where the time is going but we're obsessed with trying to figure out how to cut out as many keys as we can if you could multiply the number of keys by 10 and cut your errors in half
00:12:59
that would be a good trade-off moving keystrokes is a waste of time it is an insult to suggest that I would make a mistake with a dangerous feature obviously someone who's incompetent or less skilled less brilliant than I am
00:13:13
could make a mistake doing that kind of things but it's an insult to me personally to say that that's yeah that's silly and there's a good reason those features in the language and having participated in the standards
00:13:25
process I can tell you for a certainty that is not true there are lots of reasons that can get into a standard and being good
00:13:37
is not necessarily an important one Brendan Eich who's the guy who designs JavaScript brilliant I talks about foot guns a foot gun is a feature of a language that you can use to shoot
00:13:48
yourself in the foot and he put a lot of foot guns into JavaScript and he I think he regrets that and would probably suggest that we not put any more foot
00:14:01
guns in there but they're folks who think okay watch this I almost always miss watch so the purpose of a programming language is to aid
00:14:14
programmers in producing error free programs that's that's what it's for so we used to think that it was not possible to write good programs in JavaScript so there's no point in even
00:14:25
trying you just you can't do it so just write whatever you want and that turns out not to be true it's not only possible to write good programs in JavaScript it is necessary it is so easy
00:14:38
to go off the rails with JavaScript there's so many invitations to write bad code then you have to bring more discipline to JavaScript than you would bring to other languages so one of the
00:14:50
things that's confusing about javascript is it has the same name as Java and there are two different languages and people are still confused about what's the difference between Java and JavaScript it's similar to the confusion
00:15:03
we have between Star Trek and Star Wars you know two successful science fiction franchises with spaceships and stuff and and they both have basically the same name but the fans know that they're not
00:15:17
the same that they're very different for example in Star Trek you've got phasers photon torpedoes uniforms dam regulations and in Star Wars you've got lightsabers and blasters
00:15:30
proton torpedoes sand and chaos so javascript is obviously the Star Wars of programming languages and when you're working with JavaScript you have a choice you can go Jedi or you
00:15:49
can go Jar Jar and sadly a lot of our brothers have decided that they want to go Jar Jar so a couple of programming
00:16:04
patterns I've seen are the FAL ability or the fantasy of infallibility and the futility of Follis nests so the first one the fantasy of infallibility I see this bone lenient mostly in young guys who think that they have these
00:16:17
extraordinary skills and they can write just really crazy wild reckless code you know enough that they can pull it off because they've got such mad skills then the futility of thoughtlessness I see
00:16:28
more in older guys who have seen that it never works it's never going to work why even try so two very different attitudes but they both lead to the same thing
00:16:42
danger driven development where they'll take unnecessary risks in writing their code just to keep it interesting so one of the things that makes software
00:16:55
difficult to manage is the difficulty of scheduling the the first problem is how long will it take to write a piece of code and asking a programmer how long that's going to take is not going to
00:17:08
work because we are optimists we have to be optimists in order to do this work and as a result of that we can't schedule a worth crap it's just of that
00:17:21
you know because you know that's how long will it take to write that code and gonna think well it's probably about that many keystrokes and go at it you should be taking about that long and because we forget about that time right because we black that out it's just the
00:17:35
typing time and that turns out to be a wildly wrong estimate but then there's time be the time it takes to make the code work well ideally that should be zero right time a you write the code be
00:17:48
it works you're done accept and that turns out not to be the case that often time B is huge sometimes time B is bigger than time a sometimes time B is infinite that's
00:18:02
what happens if a project is canceled after the code is finished because they never get it to work and that happens way too often so if you're doing anything cutting any corners taking any
00:18:17
risks in time a to make time a smaller that increases time B you're doing it wrong in time time a is the time to try to force time B to go to zero you should
00:18:30
always take the time to code well sometimes you're doing something that's only gonna have to run once so go let's just be sloppy just get it done really fast cheap and dirty except you still have to make it work there's no point in
00:18:43
writing the code if it's not going to work and it's going to be easier to make it work if you code it well in all cases we should always code well so there's some new parts in es6 es6 was approved
00:18:54
by the ahmed general assembly a couple of years ago and it's now finally starting to find its way into browsers and into node not everything is there yet for example my most favorite new
00:19:05
feature of es6 proper tail calls not there yet but this is a brilliant thing it allows for an optimization called continuation passing style in which you
00:19:18
have functions which are always going forward never practically returning it's a brilliant way of doing things we'll talk a little bit more about that in a minute the ellipsis operator which
00:19:30
sometimes called rest content sometimes called spread which provides a much better way of dealing with functions with a variable number of parameters than what we got in es5 with the
00:19:43
arguments array so here are two versions of the curry function which each can take any number of arguments in any position and that's the way you write it and you have six and that's where you wrote it in es5 which one would you have
00:19:55
to maintain anybody mmm-hmm I think it's pretty clear I really like that one so the dot dot dot means any number of things can go in that position that's pretty nice modules so one in the browser in the
00:20:12
original implementation of JavaScript every code unit used global variables to communicate with all of the other code units and that turned out to be a really bad pattern and no they found that to be
00:20:26
intolerable so they replaced it with a crappy require system which unfortunately is blocking and so that's not good and it's also way too complicated so ESX provides a module
00:20:37
system which works asynchronously and it can give you secure reliable module boundaries which is what we need unfortunately the design turned out to be way more complex than I think it
00:20:49
should have been but there's a subset of the module syntax which is just fine and so I'm very pleased that that's becoming available we have let and const in the
00:21:01
language now let is the new VAR that in VAR do essentially the same thing except let respects block scope and var didn't so you want to be using one of them now
00:21:14
and I recommend the one you use now is let only because it doesn't confuse the Java guys so much the Java guys got really confused about var but with let they'll be less confused and I think
00:21:28
anything we can do to cause the Java community to be less confused would be a really good thing oh we've got a new D structuring syntax which i think is pretty nice so you can see that this let
00:21:41
statement is a shorthand for this one where each of these variable names will be initialized with a property from this object which has the same name and it doesn't let us do anything that we
00:21:54
couldn't do before but it's a nice shortcut and there are some patterns which are nicely expressed this way but you can go way out of hand and do stupid stuff with that as well so I recommend
00:22:06
you not do that then weak map weak map doesn't fix a major problem in JavaScript it sort of puts another thing there so one of the design errors in JavaScript is
00:22:20
that the keys of an object have to be strings if you try to pass in an object or something it'll try to convert it into a string before it'll use it as a key which is a shame because there are a lot of applications which really want an
00:22:33
object in that position and we couldn't fix it because they're programs on the web that depend on that bad behavior so instead of fixing it we added another kind of object called a week map and
00:22:45
with a week map it's like an object except that the keys can be other objects and so there are classes of functions that can only be written using week map that cannot be written in the
00:22:59
language as it is and it works really well with the garbage collector so that if an object that's being used as a key wants to be garbage collected it automatically gets removed from the week
00:23:10
map which is really really nice the biggest problem with week map is it has the worst name of any feature added to a programming language because nobody wants to put something week in their program but it's really good and then
00:23:26
we've got mega string literals which are literals which can be many lines long so we'll look more at those in a moment so this is a regular expression literal this is a regular expression literal
00:23:39
which matches the number literals that are available in es6 did anybody guess that guessing not because these things are virtually impossible to read and
00:23:53
understand which really concerns me because we often use them for input validation and for security filtering but if they're longer than an inch or two it's really hard to know what they're actually doing so there's a
00:24:06
thing we can do now I've got I'm gonna make my wrapper around the regular expression constructor and so I can pass in a string and I'll remove all the whitespace and then try to turn it into
00:24:17
a regular expression and so that lets me write like this so up there that little tick is the beginning of a mega string literal and there's a little tick there down at the bottom which closes it so
00:24:28
everything in between is one string and now I can easily read the regular expression I can see if it starts with a zero it might be a binary or an octal or a hex or a floating-point number this is
00:24:42
a much no which one you want to maintain the top one that one so I think this is much much much better but even so I'm still not confident that I can
00:24:55
accurately predict what a regular expression will do so there's a tool available on the web called regulates or you can give it a regular expression and it will give you a railroad diagram so
00:25:08
you can see graphically what this thing is going to match and I love that so I will never write another regular expression without running it through regular x so these are some of the other
00:25:23
new features that we have in es6 I think these were probably bad parts proxies started as a well intentioned thing that we want to have a no such method method
00:25:36
so if you have a thunk an object and someone calls a method that it doesn't have instead of throwing an exception you would like the object to be able to handle it somehow but that turned into
00:25:49
this proxy thing which is really complicated and kind of changes the behavior of everything that kind of scary we have generators which are sort of a good idea except they're completely unnecessary if you understand how
00:26:02
JavaScript works you know that you can write generators simply by having a function that returns a function you've got a factory that returns a generator and each time you call that generator you get another value and that's a
00:26:16
really straightforward way of doing things in JavaScript much better than what was actually put into es6 because that has really weird syntax um it's very inefficient it's and it's not
00:26:27
necessary iterators are part of the same deal the symbols are unnecessary because we have week maps the things that symbols allow you to do week maps do I think an even better way reflection also
00:26:40
work with those things then we got that arrow functions or farts and hipsters love but I'm not such a fan so the idea is that we can make a function in a much
00:26:54
smaller way so instead of having to type the word function you just write a fart and that's all you have to do I didn't think typing function was all
00:27:08
that hard but so we put this in so we've got our parameter list on one side and we've got a an expression on the other side so when you call the function you'll bind an argument to that
00:27:21
parameter and return that result yeah it's pretty good except for this case this looks like it's going to construct a little object with an ID property except this is actually going to return undefined because there was an
00:27:35
intentional error made in the way that this was designed and I don't know why we keep putting this crap into this language it's just it's got too many things where you can write something that looks completely reasonable that
00:27:48
fails in a silent way which is the worst way you can fail so I don't recommend using these things and until this gets fixed I'm going to continued writing the word function so the worst bad part in
00:28:01
es6 is obviously class this was the most requested feature in es6 it was mostly requested by Java guys who were having to write in JavaScript because that's where the jobs were going but they
00:28:15
didn't want they have to learn it and so by putting class in there they don't have to learn they can just keep doing the stuff that they were doing in Java except it turns out that we didn't
00:28:28
actually add classes to JavaScript this is just syntactic sugar on top of the prototypal stuff that was always there and so it doesn't work the way a Java programmer might think it works and so it's sort of a trap and also if you keep
00:28:42
stuck in this paradigm you will never learn the object-oriented paradigm where you can do things by having functions that take functions as arguments and return functions you know higher-order functions that stuff is brilliant and if you're doing
00:28:55
this you will never find this out so the people writing with we'll go to their graves never knowing how miserable they were so I've been
00:29:09
thinking about what I wrote in my book about what I consider to be good parts and what I got right and what I got wrong about that and so in the book I recommended not
00:29:20
using new using object.create instead that's more direct way of of setting up the prototypal inheritance chain and I managed to get object.create added to
00:29:33
es5 just so that I could use it so I was surprised when I noticed that I'd stopped using object.create because I put it in there just for me and I don't use it so why is that it's because of ad
00:29:47
safe so in 2007 there were a number of research projects that we're trying to find safe subsets of JavaScript there was FPGAs at Facebook there was web
00:30:00
sandbox at Microsoft there was the caja project at Google my own ad safe project and others and one of the hard problems we all had to solve was what to do about
00:30:10
this if you have a function and you call it as a function this will be bound to the object of interest and that's exactly what you want that's a good thing but if you call that same function
00:30:23
as a function this will be bound to the global object which is a security compromise and we have to prevent that so how do you stop that from happening and the approach that all the other
00:30:35
projects took was to have translators so they'd have a program that would read your program and spit out a different JavaScript program that had lots of indirection and runtime checking built
00:30:47
into it to prevent this from being down to the global object and they all had the result of making the code much bigger much slower much harder to debug so I took a different approach I said
00:31:00
let's just make this illegal if we see this in a program we will reject it and we're done that's much easier and my assumption was that if you take this out of JavaScript
00:31:13
still left with a functional programming language it's still turing-complete so you should be able to do everything that you need to do so to test that hypothesis I started writing in that dialect of JavaScript and I was really
00:31:26
surprised to discover that it wasn't harder it was actually easier that was easier to write programs my programs were smaller and better so I thought huh that's pretty neat so I don't use this anymore
00:31:41
um and I stopped using null so JavaScript has to bottom values null and undefined there's an argument in in language design should you even have a
00:31:54
bottom value but there's nobody who thinks you should have two of them and JavaScript has two and some people use them interchangeably but they are not interchangeable that they behave
00:32:06
differently in certain circumstances so I decided I need to get rid of one of them and so when I decided to get rid of was null I stopped using false unis I
00:32:18
decided that the falsie idea the bullish value in javascript was a bad idea it was intended to reproduce something that was in C in C C is a an under typed
00:32:31
language so C will use the same value to represent zero false null end of string in a few other things and so all the condition of an if is concerned with is
00:32:44
are you zero or not and Brendon wanted to have the same kind of idioms in his attainments in JavaScript I think that was a mistake so I stopped using false eNOS I now want
00:32:57
to have everything try to resolve to a boolean as Java did I think Java got that right I don't use for loops anymore because he in es5 we got these wonderful new array methods which will iterate
00:33:10
over arrays so there's no read really four fours anymore I don't use 4 in because I managed to get object keys into es 5 so that now gives you a nice
00:33:23
array of all view numeral enumerable own properties of an object so and then I can use the nice array methods on those if six will have proper tail calls and at that point I will stop
00:33:34
using loops entirely so here are two versions of the repeat statement the one up there is using a while loop the one down here is using tail recursion so es6
00:33:48
requires that when the last thing a function does is return the result of calling another function instead of generating a call return sequence it will generate a jump and so that means
00:34:01
that these two functions should run at the same speed with the same memory pressure that because this is jumping back to the top of the function it's reusing its current activation object so it doesn't have to generate more stuff
00:34:13
we're not going to see any stack overflows this can run as deep as we want without any performance penalty which is great so for a long time we've had a performance argument for why you
00:34:26
shouldn't use tail recursion that goes away so I'm really pleased about that one of the benefits of this is that it enables continuation passing style and
00:34:38
also gives us a form of go-to which is safe so the designers of transpilers have been asking for a go to because they have languages which might want to have a different set of control structures or flows than what you can
00:34:52
get in the standard JavaScript set and so they wanted to be able to met their own go-to so that they could have control over that and we didn't want to do that because we knew it would happen if we put goto back into the language so
00:35:05
instead we have tail recursion or proper tail calls which are a much better structured higher discipline basically it's goto with an argument list really
00:35:17
good stuff I've been thinking a lot about the next language about the language that replaces JavaScript I feel that there's got to be a next language because if it turns out javascript is
00:35:30
the last language that would be really sad I mean the children right you don't want to leave JavaScript to your children that mama Papa what happened and you know how
00:35:43
would you explain that you know so there's got to be a next language and I've been trying to identify it what are the signs whatever what are its properties how will we know when it is
00:35:55
here the only thing I'm certain of is that when the new language does appear we will reject it out of hand because we are as irrational and emotional as normal people now this may sound like an
00:36:07
insult but I believe it is true so here's my evidence so it took a generation to agree that high level programming languages for a good idea the first generation of
00:36:20
programmers were all writing machine language which is really really difficult and then Fortran and the other first generation of high level languages occur and these languages made programming so
00:36:34
much easier and the programmers of the day mostly rejected them because we cannot afford to give up this level of control we need to be able to get down to the metal in order to do our work we
00:36:47
can't afford the potential loss of performance that we might get it took a generation to agree that go-to was a bad idea Pike sturb publishes his letter in the C
00:37:01
ACM and that starts a really vicious emotional argument that goes on for two decades and then they're fighting and fighting and fighting and the two sides can't really hear each other and it's
00:37:14
just noisy and it just goes on and on it took a generation to agree that objects were good idea classes first occur in Simula in Norway really really important
00:37:27
discovery which nobody takes any notice of except one grad student at the University of Utah who thinks that this idea could be so powerful we could use it in a programming language that
00:37:39
children could use to program their own personal computers which is a really amazing idea to have in the late sixties that leads to a cycle of experimentation which leads to small talk which inspires
00:37:54
C++ and pretty much everything that that came after and so the industry had to choose what its problem its dominant object-oriented language was going to be was it going to
00:38:08
be small talk which was the best design programming language in history or was gonna be C++ and the industry as you know went with C++ because it had the
00:38:20
advantage that you did not need to understand what object-oriented programming was in order to use it and that decision was made by people who didn't understand what object-oriented programming was the C++ got some things
00:38:33
fundamentally wrong but every language since then has copied those mistakes and it took a generation to agree that lambdas were a good idea lambdas as functions with lexical closure with
00:38:47
static scoping were discovered in the scheme language and it took two generations for that idea to finally get to the mainstream anybody know what language it was that brought that idea to the mainstream any guesses because we
00:39:01
see it all over the place now because it actually solves a lot of problems that were now experiencing the language was JavaScript JavaScript was the first language to do that so the reason these things take a generation is because we
00:39:14
don't change minds we have to wait for a generation of programmers to retire or die before we can get critical mass on the next good idea now I was there when this happened to go to there's this
00:39:28
argument that was going on and on you can't take my gotu away from me go-to is how I express myself I'm a go-to guy you know there's all this performance that we get from go-to I'm an artist
00:39:40
look at my go-to art just and it just went on and on and on you can't take it away from me I need it to do my work it's an essential tool and and predictions of all the terrible failures
00:39:55
and all the problems that are going to happen if they took the go-to away my cold dead hand and then one day it was quiet it's like are they gone can we get rid of the
00:40:08
go-to now yeah we got rid of the go-to and everything's great all the predictions about all the terrible things that were going to happen didn't happen it turns out that getting rid of go-to made it easier to write programs
00:40:21
with greater complexity with go-to complexity can easily get out of control and you get spaghetti code and by going to structured programming we could get more complex before being overwhelmed by
00:40:34
the complexity so who benefits from that the people who are arguing against it and that's the way it is with all of these paradigm shifts each of these is a paradigm shift and it's really hard to get to the next one and I believe that
00:40:48
the next language will represent another paradigm shift and that's why we will reject it so I would sort all languages into two categories I think they should either be systems
00:41:00
languages or application languages the dominant system language is still C which i think is a problem because C has been around since the 70s we know that there were mistakes made in C we have
00:41:15
learned a lot since then but we haven't replaced it yet I think that's really a problem we seem to have lost the ability to n to innovate in system languages but I'm more concerned with application
00:41:28
languages because that's where most of us live there's some application some languages that I think make the mistake of not knowing which side of the line they want to be on I think the biggest design mistake in Java was that it was
00:41:40
trying to be both and as a result of that confusion threads are required in application programs which was a huge mistake I think that was inexcusable so I would take application languages and
00:41:54
I'd split them into two categories those that do classical inheritance which is almost everything and those that do prototypal inheritance which is pretty much just JavaScript and for a long time
00:42:07
I was an advocate of prototypal inheritance but um I'm not so much anymore so prototypal inheritance definitely has advantages over the classical model when
00:42:19
you're doing classical programming you have to design your objects and then make them into classes you have to decide you know that's going to be one of those and that's gonna be one of those that's not too hard but then you
00:42:31
have to come up with your taxonomy the taxonomy is where you decide how they are all related to each other what's going to inherit from what what's going to implement what what's going to interface what and it turns out that is
00:42:43
really hard it's really really complicated and you're doing it at the point of the project at the beginning when you have the least understanding of how it's going to work and so inevitably you get it wrong you you just get it
00:42:57
wrong because you don't know yet what the correct solution is and as you work you start noticing how it's wrong that things don't compose the way you want them to compose that you start wishing that you had multiple inheritance
00:43:10
because you just can't get these things to fit right and as you start layering more more classes on top of it you find that that breakage is seeping up into all of the levels and eventually it may
00:43:23
get so bad that you decide we need to refactor which is really scary because that means you're going to tear all the code apart and you don't want to do that because it might not ever come back
00:43:34
together again and in the prototypal model that doesn't happen and I tell this story to people who do the classical stuff and go wow that's really interesting except you're still gonna have to refactor sometime right no you
00:43:46
don't have to do that go well but you're still gonna refactor right I mean just no no so the principle advantage we get from the prototypal model versus
00:43:57
something that just copies functions from one object to another is memory conservation that using object dot create instead of object assign the
00:44:11
value we get is memory conservation which is something that made sense in 1995 but since then Moore's Law has been so incredibly generous on every capacity that that's not a reasonable trade-off
00:44:24
anymore you now have literally gigabytes of RAM in your pocket right now you just cannot imagine how much memory you're walking around with so trying to shave bits off of an object just it's in
00:44:37
the noise it doesn't matter anymore when's the last time you saw a browser given out of memory error it just doesn't happen there are now two kinds of properties their own properties and inherited
00:44:50
properties which sometimes work exactly the same but sometimes work differently whenever you have things which are almost the same but different that's a source of confusion and confusion leads
00:45:01
to bugs we get retroactive heredity so what an object inherits can change after it's constructed which I've not found any good uses for that but I've seen
00:45:15
very bad uses of that one of them is that it is performance inhibiting so modern JavaScript engines go very fast by making assumptions about the shapes of objects but they have to be pessimistic about prototype chains
00:45:27
because they cannot see when the things in the chain are being modified so I'm no longer an advocate of prototypal inheritance anow advocate of class free object-oriented programming i think
00:45:41
class free object-oriented programming is JavaScript's gift to humanity so here's how I think it should work so we'll start with the idea of block scope I assume that everybody's familiar with block scope we've got two blocks in each
00:45:55
block we can create variables but the variables are only visible in the inner blocks they're not visible to the outer blocks but the inner block can see the variables of the outer blocks and we can
00:46:07
do the same thing with functions because a function is just a block with some extra plumbing around it which allows it to be executed in the future and so we've got the same relationship and we
00:46:19
can express that relationship as a Venn diagram so this is the set of the variables that the outer function can see and this is the set of variables that the inner function can see and we can see that the inner function encloses
00:46:32
the set of the outer function and that's why we call this closure I think it's unfortunately we call it closure because at least in English closure is very overloaded some people think it means retribution or vengeance
00:46:45
and we're just saying one set closes over the other set so it took a long time for this idea to get to the mainstream because of this case now suppose the inner functions survives
00:47:00
the execution of the outer function which would happen if we returned it so the inner function wants to have access to a so when the green function is called a is put onto the stack it
00:47:13
returns the yellow function and then we'll call the yellow function yellow function wants to go to a but a is no longer on the stack so boom and it took us like 40 years to figure out how to fix this it turns out the solution is
00:47:27
trivial that you don't allocate on a stack you allocate on a heap you know with the garbage collector you just clean it all up and this is what javascript figured out which and now all of the languages are trying to do this
00:47:40
even Java and this is such a powerful pattern that having a function that returns a function higher-order functions there is so much power so much expressive power in this this is how we
00:47:55
should be writing programs so this is how I recommend making objects in a class free way so I've got a constructor function I recommend passing in a specification object you could still pass in the
00:48:08
individual parameters if you want to but I think this is a more powerful way to do it you could because you can just put an object literal inside the call to the constructor and that essentially lets
00:48:20
you have named properties so you can have the property is in any order some years ago I wrote a constructor that had ten arguments in it which was a problem because nobody could remember what order
00:48:31
they went in and after a while we discovered that nobody used the third argument but we couldn't take it out because that would have broken all the code so if I'd been smart I would have just passed in an object and
00:48:45
than missing arguments we could fill in reasonable defaults extra arguments we could just ignore and again the order wouldn't matter so I would use that to create my member variables this again is
00:48:58
using the destructuring syntax so I can name as many member variables as I want and initialize them with properties of the object that have the same value then
00:49:10
I can't if I need to I can call other constructors passing in the same specification object because we'll be using the union of all of the specifications that's what the user will
00:49:22
will pass in and they'll make something and pass it back and we will extract from it just the methods that we need this is a solution to the banana problem have you heard about the banana problem you want to inherit a banana but you end
00:49:37
up also inheriting the gorilla who's holding the banana and all of the rest of the jungle you just wanted the banana well now you can say banana and you'll just get the banana and because we're
00:49:50
copying the methods out you can call as many of these as you want so we can have a compositional form where we'll call other things and get all of the stuff that will make our object better and just incorporate it into our own local
00:50:03
variables then we'll create our own methods and because of closure our own methods will have access to all of that goodness without using this and then we
00:50:16
will have an outgoing object will where we'll simply list the new public methods and we'll freeze the object so now the
00:50:29
object will be immutable incorruptible in confusable it'll an object of high integrity that we can use to build secure reliable systems so when we
00:50:43
started doing object Orion programming it sort of starts with Pascal records where we've got a simple data type with named fields in it and we have a name which gets us to a value and we extend
00:50:56
that idea by saying the names can also represent methods or functions that will act on those values and that was a an important step forward but it should not have been the last step because it leads to a
00:51:10
style programming where you're focused on the individual properties and not on the whole and so it's hard for the whole to have integrity when you allow access
00:51:21
to the individual members so what I recommend instead is that we raise the level of the interface more in terms of actions and less in terms of the specific data items so that they'll now
00:51:35
be two distinct types of objects there will be objects containing just data one shall be collections of values which we can pass around as parameters
00:51:47
to objects and there'll be objects that contain only methods which will act on those objects the immutable data will be held in variables in the constructor
00:52:01
function and I think that's how we should be writing stuff so I need to confess I made a bug in 2001 and it's really been bothering me and I need to tell you about it so I wrote a
00:52:15
jsonparser in Java to show how easy it was to write JSON parsers had it included this declaration of a variable called index that was an INT and that
00:52:28
was intended to count the number of character positions you were in to a string or a stream in case there was a syntax er than it could report at what position the error occurred and a int is
00:52:41
pretty big that'll get you to about two billion and at the time I'd never made a JSON object that was bigger than a couple of K's so I thought this is future proof this is going to work fine until a few years ago I got a bug report
00:52:55
from someone who found who was trying to parse a JSON text that was several gigabytes in size and there was a syntax error past two and they got a wildly
00:53:08
wrong error message that goes negative and but they were very smart and they very quickly recognized what I got wrong and it was because of this int thing I hate ants I think intz are the one of the worst things
00:53:22
we've done to ourselves and programming and the problem with them is overflow now what happens if int overflows they do the worst possible thing you throw
00:53:34
away all the most important significance and there's no report and so it's really hard to have integrity in your application if you have a number system that can go wildly wrong without
00:53:47
notification so why did this happen it's because it made sense in the 50s in the 50s we were making computers out of vacuum tubes vacuum vacuum tubes are big and they're hot they draw a lot of power
00:54:01
they burn out really quickly and so if you can figure out a way to reduce the number of tubes in your design and that's really good and some genius I believe he was a genius figured out that
00:54:14
if we use complement arithmetic then we don't need to build a subtract circuit we just complement before add and ignore the overflow and that was so much easier
00:54:27
and we're still doing that it's not that 50s anymore but that's how our system still work also memory used to be really expensive and scarce I don't know if
00:54:40
anyone remembers the Atari 2600 VCS that machine had a hundred 28 bytes of RAM in it 128 bytes so the guys that program that machine were heroes they had to
00:54:53
figure out how to make a video game work in 128 bytes and so they would want to use memory really really carefully but today you've got gigabytes in your pocket it's a different world so when
00:55:07
you're programming and byte in Java every time you create a new variable or property or parameter you have to ask byte char short and long float or double which one you have to pick one of those
00:55:19
and if you get it right then the program will work and if you get it wrong the program is eventually going to fail but it will probably not fail in your tests because your tests assume that the
00:55:31
test that the types are right but your type is wrong and tests don't find those sorts of type errors you expect the compiler to find them but the compiler is not finding it and there's no benefit
00:55:46
from choosing the right one the the reason Java gave you all those choices was again because a long time ago there wasn't much memory but trying to shave bits off of a variable now is a complete waste of time
00:55:57
javascript on the other hand has only one number type that means you don't waste any time trying to decide what the type of a number is and you cannot make a mistake by choosing the wrong number type which is good in that way
00:56:10
javascript is strictly superior to JA and most of the other languages the only problem is it's the wrong type and the reason it's the wrong type is because of this there are some people who think
00:56:23
this is ok I think this is not okay Java scripts problem is it's using the I Triple E 754 floating point standard which is a binary floating-point standard which cannot accurately
00:56:35
represent the decimal fractions which is only a problem if you're on a planet that uses a decimal system but we are and so it doesn't work so it's binary
00:56:49
floating-point so why are we using binary floating-point because it made sense in the 50s again so in the 40s when the first 1 million machines start coming online there are integer only
00:57:00
machines but they were built and used by mathematicians who want to be doing math on the real numbers so they start by doing scaled arithmetic which is really
00:57:12
difficult and someone figures out we can do floating-point we can represent a number as two numbers one is the collection of digits and the other is where the decimal point is and they could have libraries which would let you
00:57:26
add and subtract and multiply and divide using that representation which made programming much easier and much more accurate but it was really slow so when machines start to become mass-produced
00:57:38
there's interest in putting that into hardware but the problem is intestinal floating-point in order to adjust numbers you have to be able to divide by 10 and dividing by 10 with vacuum tubes
00:57:49
is really hard so some genius thought if we change the basis from 10 to 2 we only have to do a shift and we can do shifts for free so it's like brilliant we'll do that and we're still doing it now the
00:58:04
business programmers at the time said we cannot use that you cannot represent money and we have to add up with me correctly or people go to jail so we're not going to do that so they came up
00:58:17
with their own system called BCD binary coded decimal so when you ordered your mainframe you would either get the floating-point package and run Fortran or you get the BCD package and run COBOL
00:58:28
and so it was sort of two worlds but then computing kind of grew up and swallowed everything COBOL disappeared and Java became the successor to COBOL but Java is a child of Fortran and not
00:58:42
COBOL so it gets the numbers wrong and everybody's been getting the numbers wrong ever since so I proposed to fix it and my solution is called Dec 64 where I
00:58:54
have a 64 bit quantity which represents numbers and it's very much like the representation that was used in the 40s the coefficient is a 56 bit number which
00:59:07
can contain sixteen point three digits approximately and the exponent is eight bits so that gets us over 100 in either direction which i think is enough for most applications and the value of a
00:59:22
number is simply the coefficient times tend to the exponent so it's that's all of the encoding it's really simple so you can take any existing int shift at eight bits it's now at deck 64 in a
00:59:34
hardware implementation numbers with the same exponent which would include all of the integers every integer will have an exponent of zero they will add in one cycle which will completely eliminate
00:59:47
the need for Ince because hints will no longer give a performance advantage over floating-point these will do those numbers very very fast and because it's a decimal representation it can exactly
01:00:00
represent all of the numbers that are important to humanity which is something a binary floating-point cannot do there's a software implementation of it
01:00:09
and available for the x64 or in the 64 series and I might hope for this is that this will be the one number type in all
01:00:24
future application languages now it may seem an audacious thing to say I'm gonna try to convince everybody in the world to change their number types but it turns out I don't have to convince everybody in the world I only have to
01:00:36
convince one person and that's the man or the woman who designs the next language if I can convince that genius that they want to make a language which represents numbers the same way that
01:00:48
humans think about numbers in order to reduce confusions that we can make fewer mistakes then this is the way to go now it turns out I have some experience at convincing everybody in the world to do
01:01:01
the right thing for example there's the json data interchange format this is Google Trends showing XML versus Jason and he can see that the world has steadily been losing interest in XML
01:01:13
since 2004 and Jason's been very very quietly creeping up again there's no Chase in industry nobody who's making money on Jason and except for the people are using Jason and you know in google
01:01:27
shows that finally Jason becomes more interesting than XML this is a more recent snapshot you can see that it's going and today is snapshot you know
01:01:39
Jason's just up there and you did that and the reason this happened was there was no paradigm shift necessary because in 2005 when suddenly the web became interesting again there were a lot of
01:01:51
people who came in to the web to start using javascript and they were told you have to use XML and you very quickly decided that's too hard let's use this other thing instead and so we didn't have to wait for a
01:02:05
generation to die because a new generation came into the market so I didn't intend for Jason to be the last data interchange format it's really good for the thing that was designed to do
01:02:17
which was to allow programs written in different languages to communicate data back and forth and it does that really well but um it's being used for other things and for some of those
01:02:30
applications it's not ideal so it may be that other data formats should be invented so if anyone here is thinking of creating one of those let me give you some advice
01:02:41
first is please don't break Jason Jay the best thing I did in Jason Jason is not perfect but the best thing I did was I did not put a version number on it so
01:02:55
there is no way of changing it without breaking it so please don't try to break it don't try to amend the jason standard to add some new stuff make a new standard and make it better
01:03:07
I recommend don't just make it better make it significantly better don't just be Jason with one little thing on it because if you have something which is Jason like but not quite Jason then you're adding a
01:03:21
confusion tax which can turn into errors and be a problem for people so if you're going to do that add enough value to it to justify that cost and please give it
01:03:34
a better name because the worst thing about Jason for sure is the name for one thing nobody knows how to pronounce it I say Jason most people say Jason it turns
01:03:46
out that correct pronunciation is real soul everybody I've seen people take
01:03:59
Jason and put a letter in front of it or a letter behind it or a number or something don't do that give it a completely different name because the names not good so it stands for JavaScript object notation which
01:04:11
means well so I that name itself is confusing so having JavaScript in there well there's already confusion about what is JavaScript and you know that Java is at
01:04:25
what and then having javascript in the name it suggests that the javascript standard is what defines what jason is or it only works with javascript and none of that's true there's a Jason
01:04:36
standard which is what Jason is so I put the word JavaScript in there to give recognition to JavaScript you know because it existed in nature I didn't invent Jason I just identified it as
01:04:52
already a feature of JavaScript and suggested it could be used independently so I was trying to give JavaScript credit but it wasn't like I was trying to get on JavaScript coattails because at the time JavaScript was the most
01:05:04
hated language in the world so you know yeah we're we're part of that that wasn't getting us much love then the idea of object here is JavaScript's idea of object which i think is a good one of
01:05:16
a collection of properties the casual thing whereas in most of the other languages that's not what an object is an object is an instance of a class and it's a very rigid thing so people in those
01:05:32
languages get confused why are they calling this thing an object notation is okay I can't find any problems with the word notation so if you want to use that that's fine so finally I want to talk
01:05:45
about responsibility and this is my personal view Who am I responsible to when I'm writing a program my number one responsibility is to the people to the poor bastards
01:05:58
you're gonna have to use my software I want it to be really good for them I don't want it to to error out I don't want it to fail I don't want to be slow I don't want to frustrate them I don't want to damage their lives I don't want
01:06:11
to hurt them in any way I want them to benefit for using my software I want to be good now I've seen programming teams who hate their users who think those people are stupid they're the source of
01:06:24
all our if they don't understand how to use our stuff they ask for new features that don't make any sense they do not appreciate our genius we hate them that is a terrible attitude as completely
01:06:36
toxic unacceptable we should never ever ever do that everything we do should be in service to humanity we have this idea in our profession that we are making the world a better place
01:06:48
ignoring all of the evidence that shows that we're not but I want to at least make it better for the people who are using my software when they are using my software the number two is the team I
01:07:01
want to write good stuff for the team so that someone else on my team can take my code and make it better I don't want to be putting traps or hazards or confusions into my code which are likely
01:07:14
to make my team members fail including team members who we haven't hired yet who I haven't met yet including future me that future me may may not remember why I did the things that I did and
01:07:26
struggled to maintain my own code word our software has gotten so complex that it's now a team effort that it used to be one person could write an operating
01:07:39
system I don't think that's likely to ever happen again so we have teams building stuff and it's similar to team literature you know if you have a team that's writing a magazine or writing an
01:07:51
encyclopedia you would like to have everybody on that writing team right with the same voice so to a reader it looks like this was written by one writer and that in no way
01:08:03
restricts the creativity of the writers because the important thing is not how you use your punctuation but how clearly you express your ideas and having a
01:08:17
house style does not restrict that in any way that's the way you display genius so I on my team I want everybody on the team to be writing in the style of the
01:08:30
best most professional programmer who ever lived I want everybody to be writing at that level I don't want anybody coming down the code because they need to express themselves and number three management
01:08:43
if management asks for it and it makes sense okay we'll do that too now some managers will go oh wait a minute we're supposed to be in charge here shouldn't we be number one and I think no I think
01:08:56
I got this right so one of the most important jobs of a CEO or a president is to focus the company on the outside there's a tendency particularly in large companies everything becomes inward
01:09:09
focused we're all about our own process competition for our own resources and the CEO kind of turns everybody around and will say things like be the customer be a customer champion everybody is
01:09:22
doing customer service they're turning people outward we need to be aware and serving the people on the outside because that's what we're all about and so you know that's the people and number
01:09:35
two there's a tendency in companies that the software is not an asset it becomes a liability that there's so much crap and clutter in the code that it is the
01:09:49
reason why we can't compete effectively in the marketplace we've got a new idea that we could implement it software but it means we have to get the old stuff to work and it's just really really hard it slows everything down but if we wrote
01:10:03
everything for the team at that level of quality then the software is not a liability it is an asset and we can go to market much faster so before we go I just want to leave you with one piece of
01:10:17
advice I'm really serious about this please do not make bugs thank you no come on I'm going to do it properly this gentleman here is the discoverer of
01:10:36
Jason please sit down thank you very much Douglas would you be happy to take a question or two please
01:10:53
why do you think the other j/s alternatives haven't succeeded like dart the problem with dart and all of the other would be next languages so far is
01:11:10
if they're not the next language that they are really the previous language so I think the next language is going to represent a new paradigm it's not going to be going backwards so it's going to be forward so it's going to be doing
01:11:23
things that were not familiar with yet I think most likely it's going to be concerned with distributed programming because for the beginning of programming it's always been sequential stuff within
01:11:34
one machine and that's not how the world works anymore it's now distributed machines we've got lots and lots of machines we got clouds now we've got lots of stuff so I think the next
01:11:47
language wants to be much better at distributed programming so I think it wants to not be about classes I think it wants to be about messages so a message oriented language in which you're just
01:11:59
firing messages not necessarily waiting for returns but having mechanisms for dealing with with the consequences of that I think that will probably be the next language so it will probably be
01:12:11
actor based or if not actors another similar idea but something that's really really good at handling distribution we've got no more questions from online
01:12:25
but we've got one from the room if you mentioned during a presentation that you prefer to use awry for each and object case what about the case is when you have to remove the key from the object
01:12:39
or when you to remove the an element from an RI I never do that I can't think of any time
01:12:53
when I've had to do that I'm always building stuff so instead of trying to mutate something I will make maybe a new thing which is the same as the old one but not having that but I can't think of cases where I'm actually trying to
01:13:05
remove stuff like remove I don't know you have a cache dictionary and you want to remove some entries after certain amount of time and then you remove elements you you from your structure
01:13:19
yeah I think instead I would want to use a weak map and just put stuff in the weak map and then let the garbage collector clean it up you mentioned numbers and that you strive to get just just one number type
01:13:33
which would be also able to represent floats so what would your recommendation be for places were only integers are
01:13:45
allowed and we are trying to pass a float like for example in the indexing and array so do you recommend like throwing an exception sort of the the language throw an exception or should
01:13:59
there be some standard rounding up or down do you recommend anything oh I think it probably wants to be an exception so with deck 64 that's a pretty easy thing to do you look to see if the exponent is zero and if it's not then
01:14:13
you would reject JavaScript I'm not sure what what JavaScript will do is it'll try to turn that floating point number into a string and so you know if you
01:14:25
tried to go to 1.0 you'll get quote 1.0 which i think is weird so I think arrays should not behave that way but you know that would be for the next language
01:14:40
thank you we've got one more question over here I think it's going to be the last one as Douglas now needs to move to the next room do you think that unit
01:14:52
testing is important in JavaScript like is it in your toolbox I do do unit testing but I think unit testing is overrated because most of the errors happen not in
01:15:05
the units it's in the connection between the units and so I'm more interested in sort of system testing because I've seen unit testing frameworks where you've got
01:15:16
all of these mocks and props and and stuff and it turns out all the all that you're really testing are the mocks and the props and the stubs and everything that so I have a test system that I
01:15:29
wrote called Chasse check in which I can write a proposition about what my system would be doing if it's correct then I can write as a function and it will then generate random values that it will
01:15:43
throw at that function and try to disprove my assertion that my systems working correctly and I find that to be much more reliable than unit tests this was the better parts and I think this is
01:15:56
the moment where we really energetically thank Douglas Crockford for his talk Thank You Douglas [Applause]
End of transcript