The Good Parts

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

[00:00:03]
>> Douglas Crockford: And now the better parts. So this is Antoine de Saint-Exupery. He was an aviator back at the time when aviation was really dangerous. That's what we used to call pilots, but he was an aviator. It was really dangerous because the planes crashed. And he experienced several crashes during his career and survived almost all of them.

[00:00:28]
He was once trying to set the air speed record from Paris to Saigon and his plane crashed in Egypt, near Cairo out in the Sahara Desert. And he was not prepared for survival in the desert. He did very badly there, suffered terrible dehydration. Dehydrated so much that he stopped sweating, which is a really dangerous thing to do in the desert.

[00:00:52]
Suffered terrible hallucinations. Fortunately he was rescued by someone who understood how to treat severe dehydration and he survived and recovered. Moved to America as the war is beginning, becomes a writer and turns out he's a brilliant writer. He writes one of the most famous children's books, The Little Prince.

[00:01:15]
Which is about an aviator who is stranded in the desert who is visited by a strange little boy who lives on an asteroid and is suicidal. Like all the best children's books, it's not really a children's book, yeah. And he wrote other books, too. He wrote some very good books about aviation books and books aimed at grownups.

[00:01:36]
In one of them, he has one of the best sentences ever written. He says it seems that perfection is attained not when there is nothing more to add, but when there is nothing more to subtract, which is just brilliant. I've seen this quoted requoted over and over again.

[00:01:52]
It's used all over the place and in engineering design, anything that's creative that requires some kind of discipline. It's just a brilliant quote and he's talking about the design of airplanes but it seems to talk about everything. And I think it's especially telling for programming, because we have a special relationship with perfection, right?

[00:02:18]
That our programs have to be perfect or they're not gonna work correctly. And he gives us some insight as to how perfection is attained. It's by removing things, it's not by adding things. And I think we can also apply it to programming languages. Because we have similar things going on there that most of our programming languages tend to want to add things.

[00:02:39]
But I think most of them could be improved by removing things. And that's where the principle of the good parts comes from. That if a feature is sometimes useful and sometimes dangerous and if there is a better option. Always use the better option. And it surprises me that this is a controversial statement.

[00:03:00]
Now there are lots of people out there who say I don't wanna use a better option. You can't make me use the better option. It's like it being better should be enough,but it's not. I think that comes from a fundamental misunderstanding about what it is that we do.

[00:03:19]
We are not paid to use every feature of the language. At the end of a project there is never a manager with a clipboard saying did use a with statement, did you leave out any semicolons? Did you use commas in operator XII?. No, no, nobody's doing that. We are paid to write programs that work well and are free of error, but that's what it's all about.

[00:03:42]
Now free of error, where did that come from? What turns out free of error has always been the first requirement. It's just we so rarely attain it, it's easy to forget that it's the most important thing.
>> Speaker 2: It's why it's never gotten paid, I guess.
>> Douglas Crockford: So good programming language should teach you.

[00:03:59]
I recommend everybody learn as many languages as you can. Because every language will give you some new perspective on something, maybe push you into a new paradigm. And you can take the things that you learned and apply it to all the other languages you know. Everybody should learn as many languages as they can.

[00:04:16]
And the language in my career that has taught me the most has been JavaScript. And it took a while for me to to learn from the language, because well, I made every mistake in JavaScript that you could make. Starting with the first one, the worst one. I didn't think I needed to learn the language before I started writing in it, that I had so much contempt for it.

[00:04:39]
The first time I saw JavaScript I thought it was the stupidest thing I'd ever seen. And it turns out, I wasn't completely wrong, but I wasn't completely right either. Eventually, I did and I was cursing all the time I was writing a JavaScript that made me very, very angry.

[00:04:54]
So eventually, I decided to learn the language. So I got the standard, which you get free off of the site and read it, and was surprised to discover that it had lambdas in it. If it had functions with first class as first class values with lexical closure, which I had no idea that it was in there.

[00:05:17]
Brendan put it in there intentionally. That's not something that gets into the language by accident, but he didn't tell anybody. And so I discovered it in reading the standard and was wow, this changes everything. And at that point my relationship with the language changed. And at that point, he was able to finally start teaching me things and he has taught me a lot.

[00:05:40]
So one of the things I did with JavaScript was I wrote JSLint. Because I needed a tool to help me avoid all of the traps that are in that language. That are there to defeat me. And JSLint turns out is much smarter about JavaScript than I am. My initial intuitions about what were good features of languages what were bad were extremely unreliable.

[00:06:04]
Whereas JSLint was always very good at always directing me to the correct point of view. What is it that we can do mechanically in order to find mistakes? Because that's what I need to do in order to try to make my programs more perfect. And JSLint has taught me an enormous amount about programming.