Crockford: I think of myself as a writer. Sometimes I write in English and sometimes I write in JavaScript.
It all comes down to communication and the structures that you use in order to facilitate that communication. Human language and computer languages work very differently in many ways, but ultimately I judge a good computer program by its ability to communicate with a human who reads that program. So at that level, they’re not that different.
Seibel: And if it can communicate well to a human, you feel like the communicating-with-the-computer part will fall out?
Crockford: You hope so. Computers are arbitrary and not very smart, so you have to make special efforts to make sure that they get it. Because that’s so hard, it’s easy to overlook the other part, but I think it is at least as important.
Seibel: So Dijkstra had a famous paper, “On the cruelty of really teaching computing science,” that basically said computer programming is a branch of applied math. Do you agree?
Crockford: Mathematics is important in programming, but it’s just one of a lot of things that are important. I think if you overemphasize the math then you underemphasize stuff which might be even more important, such as literacy.
I mentioned I wanted to have the hiring requirement that they had to have read Knuth and I couldn’t do that because I couldn’t find enough people who had. The other thing I wanted was that they be really literate in whatever language they write to other humans. I want people who can write, because we spend a lot of time writing to each other. We’re writing email or documentation. We’re writing plans. We’re writing specifications. I want to know that the people on my team are capable of doing that, and that turns out to be a really difficult skill. So I would actually rather see people 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, “If you 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 up against is that while we are unbound by physical constraints we get tied down by accidents of history. A lot of your proposals for subsetting JavaScript and your version of HTML5 seem to be attempts to fix these kinds of historical accidents.
Crockford: Yeah, and some of it is quixotic. I know that a lot of the things that I’m hoping to accomplish are not achievable. I’m aware of that. But every once in a while something works. Like when XML was proposed as a data-interchange format, my first impression of that was, “My god, this is way, way, way too complicated. We don’t need all of this stuff just to move data 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 applications and it’s winning in a whole lot of other applications. And it’s just really simple. So that restores my faith in humanity, that maybe we can finally get some of these things right.
But you can’t have everybody going off, making up their own thing. That doesn’t work. That doesn’t do anybody any good. But one person has to make up a thing and everyone else has to figure out how to agree which one of those we’re all going to get behind. JSON was a different kind of accident of history.
Seibel: Overall, do you think that the software industry is a brilliant engine of innovation or a horrible mess?
Crockford: I’m trying to think of a nice way to say, “Horrible mess.” I’d think generally software has gotten better. Not at the same pace that Moore lets the hardware got better. We track way, way slow compared to him, so it takes us 20 years to double our efficiency in software development. But we have seen improvement. Most of our improvement is due to the fact that we don’t have to make it fit anymore. We don’t have to make it fast anymore. So that should have liberated us to just making it good. 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 could we 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 do with the way that we create standards. The reason why things are working as 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 pretty reliably.
But you don’t have to scratch it very deep to find places where we got that wrong, where we could’ve got it better. The dilemma is, how do we fix this stuff in place? Anytime we change a software standard, it’s an act of violence. It is disruptive. It will cause stuff to fail. It will cause cost and harm to people. So we need to be really careful when we revise the standards because there is that cost. We have to make sure that we’re adding so much value to offset that cost. From what I see of the way that standards are being manipulated right now, that’s not occurring. Standard changes are being motivated by “we want to do it” or “because it’d be neat” or some other motivation which is not necessarily closely related to creating a lot of value for the world. So I’m struggling with that. How do we get better at that?
Seibel: You seem to lean toward specifying less. That, obviously, is a way to avoid over specifying things and standardizing things that you’re going to regret later. But if less is specified in standards, then people have to make more stuff up and you’re going to have a big pile of de facto standards as people try to settle on OK ways of getting stuff done. Is making standards simpler really going to fix the problem, if the complexity just pops up elsewhere?
Crockford: What we really need to be doing is getting better at predicting what we’re really going to need in the future. Maybe we have to wait for time travel before we finally start getting this stuff right. In the meantime, I look on that experimentation and proliferation of possible approaches as a positive thing in that maybe the right approach to take to standardization is to figure out which of those are the best thought out, which are the most maintainable, which are the most growable, and pick that. Rather than a standards committee trying to guess the best way to do it, we pick from examples in the marketplace what is actually demonstrably the best way to do it.
Seibel: But you feel like overall we’re making some progress?
Crockford: Progress isn’t always forward. Sometimes we’re leaping forward and sometimes we’re leaping backwards. When we leaped to the PC, we lost a whole lot of stuff. In the timesharing era, we had social systems online. A timesharing system was a marketplace. It was a community and everybody who was a part of that system could exchange email, 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. It took another 20 years or so to get that back.
We also took a huge step backwards in terms of security. Timesharing systems were starting to understand how to defend the system and the users of the system from each other. When we went to PCs, you owned your machine and everything running in that machine had the same privileges, the same rights to do whatever it had to do, and it turned out that 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 into the PC operating systems, but we’re still not at the point where some of the more forward-looking timesharing systems were way, way back.
Seibel: Which ones are you thinking of?
Crockford: MULTICS was doing some really interesting stuff in cooperative processes, and having multiple address spaces which were able to 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 cooperative computing. And we’re now trying to figure out how to get that into the browser. It’s a long time between MULTICS and here. We’re starting now to catch up to insights that were being acted on way back then.