JavaScript the Good Parts The Programming Thought Process

Transcript from the "The Programming Thought Process" Lesson

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

[00:00:04]
>> Douglas Crockford: So that's the brain we use to write computer programs. And computer programs are the most complicated things that humans make. Computer programs are composed of more elements, which are more Intricately connected than anything else we've ever done. Maybe anything else we'll ever do. Programs are really complicated and early on it was recognized that programming is hard and wouldn't it be nice if we could figure out a way to get the computers to write the programs for us.

[00:00:35] Because while we can do it, It's really slow and error-prone. Maybe the machines could do a better job. So, that kicked off the experimentation in artificial intelligence. One of the goals of AI was to be able to build a program that could write programs. Now, AI has achieved a lot of things.

[00:00:54] It can play brilliant chess now. Pretty good game of jeopardy, but you cannot give a set of requirements and some customer interviews to a program and say write that program. You can't do that. So instead, we're still writing programs by hand, that's the best we've been able to figure out to do.

[00:01:14] Programs can't do that for us. What programs can do, is translate one formal language into another formal language, that's something computers are really good at. And so our programming languages continue to improve over the years, slowly, but they do improve, constantly raising the level of abstraction to where we get more leverage.

[00:01:38] But it turns out, the number of lines of code we can write a day is pretty much fixed so that the higher level that we can program, the more effective we can be. And so programming languages are still our best tool for managing programs. One of the things that makes programming so hard is the need for perfection.

[00:01:57] A program has to be perfect in every aspect for all possible inputs. And even inputs that were not anticipated at the time that the program was designed. The contract we have with the computer is that if the program is not perfect in every detail, for all states, for all possibilities, the computer has license to do the worst possible thing at the worst possible time.

[00:02:23] And it's not the computer's fault. Who's fault is it? It's your fault, right? You're the ones who get the call why did you put out this piece of software that has a bug in it? That doesn't make sense, why do you do that? So given that, you would think that we would never release a piece of software until we knew it was perfect.

[00:02:43] And we don't do that. Because if we did we would never release anything. And so that certainly would be counterproductive. In fact we would not recognize perfection if it ever occurred. It's unlikely it'll ever occur. But if it did, we wouldn't know it. There's no test for it.

[00:03:00] How would we know if something is perfect? We can know something passed all of its tests but only a fool would think that passing all the tests means it's perfect, right? Tests cannot cover everything, so we just don't know. So given that what we do instead is we release software early knowing that it's full of bugs.

[00:03:19] Hoping that we'll discover them before they cause any damage or before anybody else finds them. Which is crazy, but it's the best we've been able to figure out how to do. That's the state of the art. So we're doing this with the brains of hunters and gatherers. We are hunters and gatherers.

[00:03:36] There's been no human evolution since at least the last ice age, and there is nothing in that experience to have prepared us for doing programming. Somehow we can do it anyway, which is sort of miraculous.
>> Douglas Crockford: So evolution likes to make use of dual use technologies and I have to figure this happened here too.

[00:03:59] Since there was no preparation for programming, we're making use of facilities that we had for other purposes. So, programming obviously makes use of system two, right? Because that, it's analytical where algorithms work, all that. But I have to figure system one has an effect here too. Sometimes a negative one but I think there's a positive effect, that we cannot describe how we do programs.

[00:04:25] You cannot write down a algorithm for programming something which will take the problem statement and turn it into code. We don't know how to do that. We all have this process that we do where we'll take something and we'll analyze it. And we'll look at it top down and we'll look at it bottom up, and inside out and outside in, and micro and macro.

[00:04:47] We're constantly changing our point of view the thing until suddenly [SOUND] a program happens. And we do not know how we do that, you cannot write down the steps by which that's accomplished. Somehow all of us have figured that out. But not to the extent that we could tell a program how we did it.

[00:05:06] It's magical and I have to figure system one has something to do with that. It somehow is kind of intuitively, you know intuition is in system one, right. Intuitively pushing us around, helping us to solve problems for which we don't have enough information, system one is great at that.

[00:05:27] Allowing us to find those flashes of insight that make the whole thing possible. So I think programming would be impossible if it were not for system one. Now I have no evidence to support that statement, but system one tells me it's true so I believe it.
>> Speaker 2: [LAUGH]

[00:05:47]
>> Douglas Crockford: No, programming is all about making trade-offs. Cuz there are always multiple ways of doing something, and each of those has a cost. And often, those costs are not known or recognized at the time that we're writing the program, so we're guessing as we're making the trade-offs. And some of the trade-offs we make are good, and some are bad, but that's the process, that's what we're doing.

[00:06:10] And it turns out system one is terrible at trade-offs, because it evaluates things wrong. And we'll show you some examples of that. So I'm gonna be showing you examples of programming style in JavaScript. But this analysis could be applied, should be applied to every programming language. Every language has good parts and every language has bad parts, it's just inevitable.

[00:06:35] Every designer intends to create a language composed of only good parts, but things always go wrong unexpectedly. Now JavaScript is unique in that it's good parts are some of the best good parts ever put into a programming language. And later we'll talk about what those are. And it's bad parts of some of the worst parts ever put into a programming language.

[00:06:56] It's much more extreme in the goodness and badness than other languages, but all languages have that in common. So because JavaScript has so many bad parts in it, and because they are so treacherous, and because I'm trying to achieve perfection, and there is so much in the language which is working against me, I wrote a program called JSLint.