JavaScript the Good Parts Audience Questions

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Douglas Crockford: Well, that is it. So I think we are at the end of the day, so how is everybody feeling? We should do bunch of questions before we all go home.
>> Douglas Crockford: Anybody?
>> Douglas Crockford: Or we can do more problems?
>> Speaker 2: What text editor do you use in case someone wants to build your context code?

[00:00:25]
>> Douglas Crockford: Yeah, what text editor do I use? I use geany, G-E-A-N-Y, which is a really a basic, simple editor. Does code folding, but it doesn't do it right. And it does coloring, but it doesn't do that right. But it's a simple editor, that's all I need. I don't necessarily need that one fixed, I just need one that works right.

[00:00:52] So, yeah.
>> Speaker 3: You said the triple documentation was, I think, the second most?
>> Douglas Crockford: My second most favorite, yeah.
>> Speaker 3: Yeah, what's your first?
>> Douglas Crockford: Proper tail calls. What the hell is that? So one of the things that they discovered in scheme was that, actually this was known for a long time.

[00:01:17] But scheme took the idea and said this has to be standard equipment in the language, this is not an option. So if you have a subroutine call, like a JSR in some machines, followed immediately by a return, you can replace that with a jump and that has a couple of results.

[00:01:38] One is that the program goes faster, because you're not putting something on the stack and taking something off the stack and having a couple of jumps which CPUs don't like to do. You just go in there, and so that's a simple optimization. They found that the same thing applies to functional programming.

[00:01:55] So if the last thing a function does is return the result of calling another function, they can replace that with a jump. So that has the obvious performance benefit, but it turns out it enables new styles of programming. For one thing, we can't do deep recursion in JavaScript today, because the browsers all have fairly shallow stack limits.

[00:02:19] But with this tail recursion thing, because those calls turn into jumps, there's no stack cost, right? So we can go as deep as we want without blowing the stack. So you can literally change loops into functions with no performance penalty. That's pretty neat. But even neater is there's another style of programming called continuation passing style.

[00:02:44] Which I would have shown you at the very end of the problems today, but I doubt that anyone would have been awake at that point. And in continuation passing style functions never return, instead you pass to each function the parameters that it needs plus one more which is the function that it should send the result to.

[00:03:08] Okay, it's sort of like a call back except it's calling forward and it will probably do a similar thing. And so you have this big stream of computation that is always going forward, nothing ever returns. Okay, it's all going like that, and it's wonderful and amazing. And we can't do it in JavaScript today, because eventually, you run out of stack, right?

[00:03:28] Since nothing ever returns, you consume all the memory, and everything dies. But in continuation passing style, the way you write these things is, return function thing going forward forever. And the compiler knows okay, we're doing that and the code just gets those streamlined and the garbage collector knows how to get rid of all its stuff and all stays clean and fast and wonderful.

[00:03:54] And we can do things which are even more amazing than what we did this afternoon. So I'm looking forward to that. One of the benefits of that is that JavaScript has now become a compilation target, right? We used to think that the JavaVM was gonna be the virtual machine of the Internet, turns out it's JavaScript.

[00:04:15] So people are now writing compilers which generate JavaScript code instead of writing bicode or anything else. Google is translating Java into JavaScript, so it can run everywhere. And there are whole new languages being invented, specifically to be executed by JavaScript. So if you're a language designer, you don't have to create a virtual machine anymore.

[00:04:42] You don't have to write a compiler, you just have to write parser that generates JavaScript. And a lot of people are doing that, so there is pressure on JavaScript to become a better compilation target. If you're trying to create control structures that don't map exactly onto the silly set that JavaScript has, your code gets really bad, right?

[00:05:03] And so you would like as a language designer to have a goto in the language, because you want to be able to synthesize your own stuff, treating JavaScript like a low level machine language. But we know that that would be a disaster if we had goto directly to the language.

[00:05:21] Duxtler wrote back in the 60s, was it? Yeah, I think it was in the 60s that goto is considered harmful. It took us 20 years to get rid of goto, and in that time we had endless stupid debates about should we get rid of the goto or not?

[00:05:35] And particularly, most of the talking come from the old guys saying, you can't take it away from us without goto, we can't write efficient programs. Why are you doing this to us? We need our tools. So I think the reason it took 20 years was we had to wait for all those guys retire or die.

[00:05:53]
>> Speaker 4: [LAUGH]
>> Douglas Crockford: And once they were gone it was like, okay, can we get rid of it now? And say yeah, okay, good, and we got rid of it, and we don't miss it, right? But I know for a fact if we put goto back into JavaScript, and we can because it's still a reserved word.

[00:06:08] So we could put it in the language, some idiot web developers gonna blog, wow, did you know can make your programs go super fast if you use goto? And then certainly we're gonna have to wait for them to die, before we get rid of it again.
>> Speaker 4: [LAUGH]

[00:06:22]
>> Douglas Crockford: So we can't put anything into the language for one class of people, without exposing it to everybody. And we know that would cause harm, so we're not gonna do that. But proper tail calls allows us to have goto with this syntactic form which is not dangerous, which is actually extremely beneficial.

[00:06:41] So compiler writers would probably be the first to benefit from the continuation passing style, cuz that turns out to be a brilliant way to implement programming languages. So that's gonna be my favorite-most feature, anybody else?
>> Speaker 5: I have one question.
>> Douglas Crockford: Yeah.
>> Speaker 5: You mentioned that if the class system used by Java, C#, etc.

[00:07:10] And then would JavaScript, do you have the prototyping that you preferred and thought that the prototyping was more powerful?
>> Douglas Crockford: Mm-hm.
>> Speaker 5: Could you reflect a little bit on what I'm talking about that?
>> Douglas Crockford: Yeah, so I believe that, so a little bit of history. So Randy Smith was a researcher, I guess he was at Xerox park at that time.

[00:07:32] I met him Atari lab earlier. And he was working on a system called Morphix. Morphix were objects which had stated behavior like other objects, but also a visual presentation. And he had this wonderful little demo set up where he could take objects which were on the screen. And open them up and reprogram them dynamically as the thing was running, and all this amazing behavior would occur.

[00:08:01] It was really great, and he showed this to David Unger, who earlier have been working on trying to make Smalltalk go really fast. He was designed a risk processor specifically to run Smalltalk. And he was amazed at the stuff Randy was doing, so we got to do that, so how can we make this better?

[00:08:24] And so they started collaborating and the thing that they came up with was the self language. So it turned out the morphics were much easier to compose if there were no classes, if you could just assign functions directly to the things everything was so much easier and faster.

[00:08:39] And then Unger spent a lot of time looking at, okay, how do we take the implementations of that, and make them go really fast? So a lot of what we know now about how we make things go fast, came from the self project, for example how to make virtual machines like the Java virtual machine go fast.

[00:08:56] That came out of self, generation of scavenging in order to make garbage collection go really fast, that came out of self. And but the prototype idea nobody paid much attention to it except for Branden, he thought all that's cool. I'll throw them in large script and see what happens, and it's brilliant.

[00:09:20] So a lot of people work on it as being a step backward, that JavaScript isn't even object oriented, it's object based or some or worse or some silly thing like that. It's actually the next evolutionary step in object oriented programming. It's sort of taking the thing that simular proposed and saying no, they weren't right about that one and sort of going from that, taking the core of the good ideas in a more expressive way and going forward.

[00:09:49] And that JavaScript has, it's brilliant. And it is so powerful that you might never find out about it. Because it's so powerful, you can use the other paradigms. You can do the classical style and it works pretty well. But if you stick with that, you'll never make the breakthrough into what it can really do.

[00:10:16] So my prediction is that future languages will actually look a lot like JavaScript, and a lot less like Java. Although it's a daring prediction to make right now, because there is tremendous pressure still on making JavaScript look more like Java. So in the short term that might not turn out to be true, but I think the long term it does.

[00:10:39] Yeah.
>> Speaker 6: Along that same thing, what are your thoughts on TypeScripts?
>> Douglas Crockford: What do I think about TypeScript? So TypeScript is a tool that was developed in Microsoft in order to make Visual Studio work more effectively with JavaScript. One of the difficulties with JavaScript is, because it's so dynamic things like code completion don't work well for it.

[00:11:02] Because you say variable dot, you don't have a short list of methods that come off of that, because it could be anything. So about the best you can do is take the list of all known methods and say, do you want one of those? And so they were looking at doing something better.

[00:11:21] So they have another language which is now being called TypeScript, which compiles into JavaScript. Which adds typing to JavaScript, so you can annotate your variables and say, this one is a number and this one is a string. And this one is a function that takes a method that has this signature, and so on.

[00:11:42] And it takes all of that and then runs it through a compiler, and generates very nice JavaScript code. There are a lot of language processors that transpile into JavaScript, it's probably the nicest. Most of them generate code, which is just horrible and awful. And TypeScript went to a lot of trouble to make code which is actually pretty good.

[00:12:05] So for my money, it is the best of all of the JavaScript frontends out there. But I'm not gonna use it for a couple reasons. One is, it doesn't solve the problem I have. I don't need autocomplete, I can type my own programs fine, and so I don't need that capability.

[00:12:28] I'm not willing to pay the cost in order to get it. And people who are used to Java and other strongly typed languages are confused by that, cuz they say there is no cost. But there is, and so when I started with JavaScript I was alarmed at how flimsy the language seem to be.

[00:12:50] And where are my types? How am I gonna know that everything is working? And my experience with the language was that, also the theory with strong typing is the type system can find all sorts of errors early. And the earlier you can find an error, the less its gonna cost.

[00:13:06] And that's good, we want to have early detection of errors and that's absolutely true. But what I found working with JavaScript was, having a type system doesn't relieve you of the need to test. Cuz the class of potential errors is much, much, much bigger than the class of errors that are detected by type checking.

[00:13:28] All right, so you still have to write all the tests, and you still have to test. And I found the amount of testing I was doing in JavaScript was comparable to what I had done in Java, so I wasn't seeing much of a benefit. On the other side, I found that not having to deal with types was a huge relief, cuz it meant I was doing a lot less work in the programming, I was doing about the same amount of work in testing, that looked like a wind to me.

[00:13:53] And ultimately, my analysis was that the type checking just wasn't paying for itself. That the freedom of being able to express stuff the way I want. And also any type system in which you ever have to cast, and my opinion that was not a type system, it's just an annoyance.

[00:14:12] Anytime you have to break the system in order to accomplish something useful means the type system is not working. So I reluctantly eventually got used to the idea that JavaScript actually got it right. This is something that the Lisp guys have known all along, at least they had never had strong typing in it.

[00:14:31] And it always worked great, and they do some of the most complex programs ever written and have not been burdened by the absence of a type system at all. So everybody has a different opinion on this, and most of the opinions are not based on any kind of data or experience.

[00:14:48] Most opinions are based on having programmed on one side but not on the other. I've been on both sides, and I have to tell you, I was surprised to find that I think JavaScript got it right. And so for that reason, TypeScript doesn't offer much for me, it provides a few conveniences.

[00:15:06] And again, of the things of that class, it is by far, the best. But if I use TypeScript I can't use JSLint anymore, cuz JSLint doesn't understand that language and JSLint buys me a lot more than TypeScript does. So I'm sticking with it.
>> Douglas Crockford: Okay, one more? Any one more?

[00:15:28] Anybody? Someone doesn't ask a question you're all gonna have to go home.
>> Speaker 7: Did you have-
>> Douglas Crockford: Yeah.
>> Speaker 7: More information on Ajax and DOM manipulation that you're gonna talk about?
>> Douglas Crockford: I was gonna do one more, but I think we're all pretty burnt at this point. So you guys will get the slide and that talk is online somewhere, so we'll probably be able to give you a link to it.

[00:15:54]
>> Douglas Crockford: Okay, go home everybody.
>> Speaker 8: [APPLAUSE]