Arguments Against the Good Parts

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

[00:00:04]
>> Douglas: And so I wrote my own book about my experience with JavaScript and with JSLint which is called JavaScript: The Good Parts. And the surprising thing about this book is it is still a bestseller in its category, which is extremely rare for software books. Most software books are obsolete before they're printed, and it's because things tend to change and roll over so quickly in software.

[00:00:27]
But it turns out the things that I was saying in this book are for the most part right. And so it's still a relevant book even though JavaScript has gone through two major standard revisions, this book is still pretty good. So it's not universally adored though, there are lots of arguments against the idea of good parts and I'd like to run through some of those if I may.

[00:00:55]
The first one, it's just a matter of opinion, it's your opinion, my opinions different, one opinions as good as another. So there, turns out that's not the case, that I am the maintainer of JSLint. And as such I get bug reports from people from all over the world telling me I just spent two weeks chasing this thing down.

[00:01:16]
And it was due to some weird edge case in the grammar of the language that no one had ever noticed, and it just crippled us, hurt us at a bad time and could you have JSLint look for that? Cuz, if you can then no one else will ever have to endure that.

[00:01:33]
So whenever it makes sense to, I incorporate those things. So if you're using JSLint, then you will never experience those things, that is not an opinion, that is a fact. Every feature is an essential tool, I need every tool available in order to do my work. But that's simply not true when we can show that you can write better programs by not using all of the features.

[00:01:57]
So if you can write a better program without using a feature that feature is not essential. But this feature is sometimes useful and that sounds like an important thing, I need to be able to use it because it's sometimes useful. Except it turns out everything is sometimes useful.

[00:02:14]
You cannot identify anything which is so dangerous, so toxic, so disgusting, that is not also sometimes useful. Sometimes useful is about as strong a statement as it exists. It sounds like it's a lot more than that but it isn't, it actually is not an argument. So if the reason for using a feature is because it's sometimes useful, you simply do not have an argument.

[00:02:39]
I have a right to use every feature. Now at this point the argument has changed. We're no longer talking about what's the best way to write programs, we're now talking about our rights. And it sounds really important and righteous to be talking about rights and defending [SOUND], except if you follow this argument to its conclusion.

[00:03:00]
Ultimately it goes like this, do you have the right to write crap? Yes I have the right to write crap. So now we're arguing about do you have the right to write crap is that true or not, I don't know, I don't care it's not important. What's more important is you have a responsibility to write code that works well and is free of error.

[00:03:21]
>> Douglas: I need the freedom to express myself, I'm a poet in the way I express my poetry is by leaving out my semicolons.
>> Douglas: I need to reduce my keystrokes. This is a really insidious one big again because we imagine that we spend most of our time typing but we don't.

[00:03:41]
So if you were to take all the clean finished code you finish in a year, you could type it in a day. So that raises a question, what are you doing with the other 99% of your time? Keystrokes is not the important thing. If I could figure out a way to increase your keystrokes by a factor of ten and cut your errors in half, that would be a huge win.

[00:04:07]
Unfortunately, I don't have that formula for you but that's the sort of ratios we're looking at. It is an insult to suggest that I would ever make a mistake with a dangerous feature. Inferior people could obviously have problems by doing that but I must have satisfaction.
>> Douglas: And then there's a good reason those features were added to the language and I can tell you from experience, that is absolutely not true.

[00:04:33]
I've seen how things get put into languages, and those things happen for all kinds of reasons, and they're not all good ones. The creator of JavaScript, Brendan Eich talks about foot guns. A foot gun is a feature of the language that you use to shoot yourself in the foot [SOUND] and he put a lot of those in JavaScript and I think he regrets it.

[00:04:56]
And from time to time he would tell the standards committee, let's not be adding too many more foot guns and they don't always listen to him. So you can always find more but there are guys who look [SOUND], I almost always miss watch this.
>> [SOUND]
>> Speaker 2: [LAUGH]

[00:05:15]
>> Douglas: [LAUGH] So the purpose of a programming language is to aid programmers in producing error-free programs, that's the whole deal. So we used to think that it was not possible to write good programs in JavaScript because the language was such a mess that just wasn't possible, so no reason to even try.

[00:05:35]
Turned out that was not true that it is not only possible to write good programs in JavaScript, it is necessary. It is so easy to go off the rails with this language it requires tremendous discipline, maybe more discipline than any other language. So you really have to bring it when you're using this language.

[00:05:54]
So there's a lot of confusion still about Java in JavaScript because they kind of look similar and they have the same name. Sometimes I'm introduced as a Java experts which I am but I'm usually invited because I'm a JavaScript expert and it's similar to the confusion we have between Star Trek and Star Wars.

[00:06:15]
>> Speaker 2: [LAUGH]
>> Douglas: We've got two science fiction franchises with basically the same name. And from ten feet away, they kinda look like the same show. But we know they're not the same thing, right? The differences are really significant. In Star Trek, you've got phasers, and photon torpedoes, you've got uniforms, down regulations, everything's regulations, right?

[00:06:37]
Whereas in Star Wars, you've got light sabres and blasters. You've got proton torpedoes, completely different torpedoes. You've got sand, I don't like sand and chaos. So you know which one of these is JavaScript, well obviously Star Wars right. In fact when you're working with JavaScript, JavaScript presents you with a choice.

[00:07:03]
You can go Jedi or you can go Jar Jar.
>> Speaker 2: [LAUGH]
>> Douglas: And quite a lot of our brothers like to go Jar Jar so.
>> Speaker 2: [LAUGH]
>> Douglas: So one thing I've observed, two things I've observed are the fantasy of infallibility and the futility of faultlessness. I see the fantasy of infallibility especially in younger guys, who think they have such that skills.

[00:07:35]
That they can write just any crap in it and they're gonna get away with it, that they can just do stupid and that it's gonna be all right. Then, the futility of faultlessness, I see this more among older guys. Guys have been doing this for a long time.

[00:07:48]
I've never seen a girl write, it's never gonna go right, why even try? Just so two very different perspectives but they both lead to the same thing. Danger driven development where you doing crazy reckless stuff in the code just to keep it interesting cuz hey we don't do that.

[00:08:12]
And don't forget your semicolons, right. So one of the things that makes programming difficult to manage, is the difficulty of scheduling. That usually when we're doing something, we're doing it for the first time we've ever done it. And so we don't know, there's no way we could know how long it's gonna take but we'll make guesses and our guesses.

[00:08:32]
Cuz we're optimists are usually wildly wrong but that's the way it goes but what's even harder is scheduling the second time. Which is the time B, the time it takes to make the code work right, now that should be zero right. You should write it and it should be right and we're done.

[00:08:51]
But that's not the case, that often time B is greater than time A, I've seen cases where time B is infinite. That's what happens when the codes finished but then the project is cancelled before they can get it to work. That happens way too often actually, so if you do anything in time A that increases the likelihood of time B being bigger, you're doing it wrong.

[00:09:19]
That's not the time to be saving time. So we should always take the time to code well. Sometimes there's this idea that, well we're just doing this quick and dirty thing so let's just be really sloppy and get it done fast. Except getting it done still means it has to work and getting it to work is still going to be easier if you write it well.

[00:09:43]
That the time it takes to write it well is going to be less time that takes to make it work right if it's not written well.