Crockford: I think of myself as a writer. Sometimes I write in English andsometimes I write in JavaScript.

It all comes down to communication and the structures that you use inorder to facilitate that communication. Human language and computerlanguages work very differently in many ways, but ultimately I judge a goodcomputer program by its ability to communicate with a human who readsthat program. So at that level, they’re not that different.

Seibel: And if it can communicate well to a human, you feel like thecommunicating-with-the-computer part will fall out?

Crockford: You hope so. Computers are arbitrary and not very smart, soyou have to make special efforts to make sure that they get it. Becausethat’s so hard, it’s easy to overlook the other part, but I think it is at least asimportant.

Seibel: So Dijkstra had a famous paper, “On the cruelty of really teachingcomputing science,” that basically said computer programming is a branch ofapplied math. Do you agree?

Crockford: Mathematics is important in programming, but it’s just one of alot of things that are important. I think if you overemphasize the math thenyou underemphasize stuff which might be even more important, such asliteracy.

I mentioned I wanted to have the hiring requirement that they had to haveread Knuth and I couldn’t do that because I couldn’t find enough peoplewho had. The other thing I wanted was that they be really literate inwhatever language they write to other humans. I want people who canwrite, because we spend a lot of time writing to each other. We’re writingemail or documentation. We’re writing plans. We’re writing specifications. Iwant to know that the people on my team are capable of doing that, andthat turns out to be a really difficult skill. So I would actually rather seepeople start as English majors than as math majors to get into programming.

Seibel: I think Dijkstra had another quote about that along the lines of, “Ifyou can’t write in your native language, give it up.”

Crockford: I agree with that one.

Seibel: An aspect of programming that you seem to keep running upagainst is that while we are unbound by physical constraints we get tieddown by accidents of history. A lot of your proposals for subsettingJavaScript and your version of HTML5 seem to be attempts to fix thesekinds of historical accidents.

Crockford: Yeah, and some of it is quixotic. I know that a lot of the thingsthat I’m hoping to accomplish are not achievable. I’m aware of that. Butevery once in a while something works. Like when XML was proposed as adata-interchange format, my first impression of that was, “My god, this isway, way, way too complicated. We don’t need all of this stuff just to movedata back and forth.” And so I proposed another way to do it, and it won.JSON is now the preferred way of doing data transfer in Ajax applicationsand it’s winning in a whole lot of other applications. And it’s just reallysimple. So that restores my faith in humanity, that maybe we can finally getsome of these things right.

But you can’t have everybody going off, making up their own thing. Thatdoesn’t work. That doesn’t do anybody any good. But one person has tomake up a thing and everyone else has to figure out how to agree whichone of those we’re all going to get behind. JSON was a different kind ofaccident of history.

Seibel: Overall, do you think that the software industry is a brilliant engineof innovation or a horrible mess?

Crockford: I’m trying to think of a nice way to say, “Horrible mess.” I’dthink generally software has gotten better. Not at the same pace thatMoore lets the hardware got better. We track way, way slow compared tohim, so it takes us 20 years to double our efficiency in softwaredevelopment. But we have seen improvement. Most of our improvement isdue to the fact that we don’t have to make it fit anymore. We don’t have tomake it fast anymore. So that should have liberated us to just making itgood. But we don’t spend enough time doing that, I think.

Seibel: So if we are, however nicely you put it, a horrible mess, what couldwe do to not be such a mess?

Crockford: That’s what I’m trying to figure out. A lot of it I think has to dowith the way that we create standards. The reason why things are workingas well as they are now is because the Net works; all the benefits that came,came from being able to tie everything together and have that happen prettyreliably.

But you don’t have to scratch it very deep to find places where we got thatwrong, where we could’ve got it better. The dilemma is, how do we fix thisstuff in place? Anytime we change a software standard, it’s an act ofviolence. It is disruptive. It will cause stuff to fail. It will cause cost and harmto people. So we need to be really careful when we revise the standardsbecause there is that cost. We have to make sure that we’re adding somuch value to offset that cost. From what I see of the way that standardsare being manipulated right now, that’s not occurring. Standard changes arebeing motivated by “we want to do it” or “because it’d be neat” or someother motivation which is not necessarily closely related to creating a lot ofvalue for the world. So I’m struggling with that. How do we get better atthat?

Seibel: You seem to lean toward specifying less. That, obviously, is a way toavoid over specifying things and standardizing things that you’re going toregret later. But if less is specified in standards, then people have to makemore stuff up and you’re going to have a big pile of de facto standards aspeople try to settle on OK ways of getting stuff done. Is making standardssimpler really going to fix the problem, if the complexity just pops upelsewhere?

Crockford: What we really need to be doing is getting better at predictingwhat we’re really going to need in the future. Maybe we have to wait fortime travel before we finally start getting this stuff right. In the meantime, Ilook on that experimentation and proliferation of possible approaches as apositive thing in that maybe the right approach to take to standardization isto figure out which of those are the best thought out, which are the mostmaintainable, which are the most growable, and pick that. Rather than astandards committee trying to guess the best way to do it, we pick fromexamples in the marketplace what is actually demonstrably the best way todo it.

Seibel: But you feel like overall we’re making some progress?

Crockford: Progress isn’t always forward. Sometimes we’re leapingforward and sometimes we’re leaping backwards. When we leaped to thePC, we lost a whole lot of stuff. In the timesharing era, we had socialsystems online. A timesharing system was a marketplace. It was acommunity and everybody who was a part of that system could exchangeemail, they could exchange files, they could chat, they could play games.They were doing all this stuff and all that got lost when we went to PCs. Ittook another 20 years or so to get that back.

We also took a huge step backwards in terms of security. Timesharingsystems were starting to understand how to defend the system and theusers of the system from each other. When we went to PCs, you ownedyour machine and everything running in that machine had the sameprivileges, the same rights to do whatever it had to do, and it turned outthat not all the software running in your machine is acting in your interest.We’re still struggling with that. We’ve seen lots of improvements going intothe PC operating systems, but we’re still not at the point where some of themore forward-looking timesharing systems were way, way back.

Seibel: Which ones are you thinking of?

Crockford: MULTICS was doing some really interesting stuff incooperative processes, and having multiple address spaces which were ableto communicate with each other but couldn’t get into each other’s stuff.That’s the basic baseline you need in order to start doing cooperativecomputing. And we’re now trying to figure out how to get that into thebrowser. It’s a long time between MULTICS and here. We’re starting nowto catch up to insights that were being acted on way back then.