JavaScript: Good Parts & Bad Parts

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

[00:00:03]
>> Douglas: That brings us to JavaScript, the world's most misunderstood programming language. JavaScript has some of the best parts ever put into any programming language. That's extraordinary how good the good parts of this language are, and we're going to spend a lot of time exploring that. JavaScript also famously has more bad parts than any other programming language.

[00:00:24]
And in the next hour, we'll talk about why that happened, but it does, now it turns out every programming language has good parts and bad parts. But very few languages have as much goodness as JavaScript or as much badness as JavaScript. JavaScript has everything from the sublime to the completely ridiculous.

[00:00:45]
And the analysis I'm about to do, you could do on and should do on every language. But it's especially telling with JavaScript. So because JavaScript has so many bad parts in it, I wrote a program called JSLint. It's written in JavaScript it reads JavaScript programs and it warns you, you're messing with the bad parts.

[00:01:07]
And by cleaning that up and sticking to the good parts, you end up with programs which are substantially better. Which are gonna be more maintainable, closer to perfect, that's all good stuff. And it's free and everybody should be using it. All of your code should pass JSLint without exceptions, you really want your code to be that good.

[00:01:29]
But a lot of people don't want to do that because it comes with this warning, JSLint will hurt your feelings. And it's true, and I hear from people constantly crying, whining, JSLint you fix it, so it doesn't complain about me because I'm awesome in that and after a few years a star wonder, well, wait a minute, there's no crying in programming.

[00:01:54]
We imagine ourselves to be the most rational computers in the world or that most rational people in the world, right? Because we're the ambassadors to the computer, you can't bullshit computers, we imagine ourselves to be totally completely logical about everything superior to all ordinary mortals. But it turns out, we get really emotional about things, about how we write our programs.

[00:02:18]
Questions like tabs or spaces. Turns out there's not a lot of data to support one versus the other, but we get really emotional about it or do curly braces go on the left or on the right?
>> Douglas: You can toss that question into a room with programmers and all work is gonna stop.

[00:02:38]
And they're gonna have these really emotional arguments, because it turns out there is no data at all to support either argument. There's no data which shows you get better productivity or lower error rates. Any important difference, but that doesn't matter. The arguments will be there and they'll be intense.

[00:02:59]
And they won't stop. And for this, I blame Ken Thompson. Ken Thompson is one of the most important programmers to have ever of lived. We'll talk more about him later. He designed a language called B. Which inspired the language called C, which inspired virtually all languages to happen since then.

[00:03:20]
Really, really important contributions. And in those languages, you could put the curly brace on the left or on the right. Thompson put them on the right. Just seemed right to him and his partner Richie also put them on the right but there are other people in their lab, who want to put them on the left.

[00:03:39]
And I'm sure they had a meeting and it probably went on for days and at some point, Thompson said, leave me alone. I don't care, just, I don't care. Leave me alone. Which is a shame because he could have said, I'm fixing my compiler so that you have to put them on the right and if you put them on the left, it's gonna be a syntax error.

[00:03:57]
If he had done that, who knows how many man-centuries of time we could have saved.
>> Speaker 2: [LAUGH]
>> Douglas: But he didn't, so we are still arguing about it. And it's a really an emotional argument. So there are some things that we can agree on. Everyone would agree that you should be consistent, that you should always put them on the left or you should always put them on the right, you shouldn't mix it up because it looks stupid.

[00:04:18]
We're trying really hard not to intentionally look stupid, so you don't want to do that. And everyone will agree that however they do it, everyone else should do it that way too, that it's easy, but we can't agree on what that way is. So if you have someone who is used to putting them on the left, and he goes to work for a shop that puts them on the right and again say, well, that's how we do it.

[00:04:39]
Gotta put them on the right. He's gonna start to cry. He goes, no, and he's gonna start trying to come up with reasons for why this is wrong. And the gut is saying, this is wrong, this is wrong, and system two is going, yeah, I know that's wrong, why is that?

[00:04:53]
And it starts rationalizing, it's trying to come up with reasons to support its deeply held belief. But there are no reasons and so, he hear yourself saying things which are completely ridiculous, and and it just makes you madder. And the madder you get the more, and it's just this and it ultimately doesn't make any sense.

[00:05:12]
Now it's sort of like driving. In some countries they drive on the left, and in some countries they drive on the right. There's no data to support one versus the other. You don't get better fuel efficiency or lower accident rates on one side or the other. But wherever you are, it's a really good idea that everybody be driving on the same side.

[00:05:31]
And this is kind of like that. We know that there should be one answer. coming up with the one answer is really hard and leaving it to chance or leaving it to personal taste is not a good predictor of any kind of outcome. And so, we can keep wasting time on this.

[00:05:51]
So ultimately, I don't know what the correct solution to this is except in JavaScript. And in JavaScript I'm absolutely convinced, you should always put them on the right and never on the left, and here is why. So one of the really nice things about JavaScript is, we can have a function that returns an object.

[00:06:10]
Sometimes you call those constructors. And JavaScript provides this really nice thing called an object literal, where we can return a new object. That's very, very nice. And if you put the curly brace on the right, it does exactly what you expect. But if you put the curly brace on the left, you get a silent error.

[00:06:30]
These are the worst kinds of errors. You don't get an error at compiler time, you don't get an error at run time. What'll happen is your function instead of returning a new object, will return the undefined value. So it doesn't fail here, it's gonna fail somewhere downstream from here, where something will go to operate on an object, and it's not there and boom, program blows up.

[00:06:54]
And so, you're gonna have to debug this thing. And you may eventually trace it back to this line. And that looks right, where did my object go? You can easily waste a lot of time on this. So let's look at what happens, let's zoom in on this. So as we're gonna find out in the next hour, JavaScript was designed as a language for beginners.

[00:07:16]
That was the original goal, was to make a beginner's programming language. But it also looks like C. And C was not designed for beginners. C syntax is really fuzzy, it's way too complicated. Especially, if you're gonna give it to people who haven't had much training. So how do you deal with that?

[00:07:36]
But I think the correct answer would be, design a new syntax which is simple and clear. He didn't do that. Instead, there was a feature called automatic semi-colon insertion, which would attempt to insert semi-colons in places, where the beginners wouldn't know that they had to go. And unfortunately, it sometimes doesn't put them in places where you think it should, and it sometimes puts them in places where you think it shouldn't.

[00:08:02]
And this is one of those times. So automatic semicolon insertion will put a semicolon after that return. Now we've got all this other stuff. You would hope that something's gonna snag a syntax error, so we can get some warning. For example, we've got the curly brace which opens up the object literal.

[00:08:22]
Except when you move that curly brace into statement position, it becomes a block. So there's a syntactic ambiguity. Now JavaScript Doesn't have block scope. So there is no value in having naked top level blocks but it does, so that masks this error. Then we've got ok calling, ok colon doesn't look like a statement but it does look like a label.

[00:08:47]
Now the C language had a go to statement in it, which meant that you could transfer control from one statement to any other statement. And we have since determined that goto is harmful, so we don't use it anymore. It does not exist in JavaScript. Hurray for JavaScript. It's better than C in that respect.

[00:09:06]
But JavaScript syntax still allows every statement to have a label, even though there are only four statements that make sense having labels. Because they'd make use of label break and that is not one of them, so that's bad. Although we've got a false statement, of false statement doesn't make any sense, but there's another other thing we inherit from C which is the useless expression statement.

[00:09:32]
Now we can take any expression, put it in statement position, put a semicolon on the end of it, and it's now a statement. Now in my view, there are only two expressions that make sense in statement position, assignment and invocation. Everything else, I think, should be a syntax error, but it's not.

[00:09:51]
So this is allowed in the compiler will look at it go false. Yet you're still constant, good, I'll just go on. But if it's a statement, it needs a semicolon. Our problem we've got some semicolon insertion, so it comes in and inserts that. Now there's a semicolon at the end of the block, blocks do not end with semicolons.

[00:10:12]
But there's another feature that we inherit from C, which is the empty statement. So anywhere you want, you can have extra semi-colons and they all get soaked up. Then, all of this is unreachable code. That you can't possibly execute something that comes after disruption. But JavaScript is okay with that.

[00:10:31]
It allows anything you want, after return statement without any warning. So if you write code that looks like that, the compiler thinks you're writing code that looks like that. You might be thinking, this is the stupidest thing I've ever seen. And you're probably not wrong. But that's how it exists.

[00:10:53]
That's what this silly language does. If you put your curly brace on the right, you will never experience this. And if you put your curly braces on the left, this is waiting for you. So in thinking about programming style, let's look at the trade offs here. So what is the cost of putting a curly brace on one side versus the other?

[00:11:18]
Zero, there's no cost, it's just punctuation, there's no cost. What's the benefit? The benefit is you will never waste time on this bug, this bug will never exist in your program. Is that a good benefit? If you can get it for free, yeah, absolutely. So that's why in JavaScript, I recommend always put your curly braces on the left or on the right, never on the left.

[00:11:43]
You should prefer forms that are error resistant. You should be coding in a way which makes it harder to form new errors.