[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: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: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: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: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:43] You should prefer forms that are error resistant. You should be coding in a way which makes it harder to form new errors.