Seibel: Do you often read code, literate or otherwise, for fun?

Crockford: Yeah. There’s not much code out there that’s good enoughthat you could read it for fun. Knuth wrote some. Fraser and Hanson have aC compiler that is literate; it’s very good. But there are not a lot ofexamples of that yet. That’s kind of a shame. That could indicate that maybeliterate programming has failed, because there aren’t very many examples ofit.

Seibel: What about Knuth’s magnum opus, The Art of ComputerProgramming? Are you the kind of person who read it cover to cover, whodips into it for reference, or who put it on the shelf and never looked at it?

Crockford: All except the last one. When I was in college, there were acouple of months where I didn’t pay rent in order to buy copies of hisbooks. And I read them and found jokes in them, like there’s a TUG joke inthe index of Volume I. I have not been able to make sense out of all of it.There are places where he goes really a lot deeper than I can go, but I enjoythe books a lot, and I’ve also used them as reference books.

Seibel: Did you literally read them cover to cover, skimming over the maththat you couldn’t understand?

Crockford: Yeah, the part when there are too many stars, I would read itvery quickly. I tried to make familiarity with Knuth a hiring criteria, and I wasdisappointed that I couldn’t find enough people that had read him. In myview, anybody who calls himself a professional programmer should haveread Knuth’s books or at least should have copies of his books.

Seibel: To read Knuth, it seems to me, you have to be able to read themath and understand it. To what extent do you think having that kind ofmathematical training is necessarily to be a programmer?

Crockford: Obviously it’s not, because most of them don’t have it. In thesorts of applications that I’m working on, we don’t see that muchapplication of the particular tools that Knuth gives us. If we were writingoperating systems or writing runtimes, it’d be much more critical. But we’redoing form validations and UIs. Generally performance is not that importantin the things that we do. We spend most of our time waiting for the user orwaiting for the network.

I would like to insist that it’s absolutely necessary for people to understandthis stuff, but it’s not. And maybe that’s why web programming has taken offand why it’s so accessible and why JavaScript works. This stuff really isn’tthat hard. And most of the things that make it hard are unnecessarily hard. Ifwe just cleaned up the platform a little bit, this work gets a lot easier.

Seibel: So there’s the nitty-gritty stuff that Knuth will teach you how to doand then there’s the big picture. Even if you clean up the platform, buildingbig systems and designing them in a way that’s comprehensible will still behard. How do you design your code?

Crockford: It’s not so much about writing the program as makingiterations on the program’s survival. Generally the reason we’re doingsoftware is because we know we’re going to have to change it and changinganything is hard because there’s a likelihood that, in changing it, you’re goingto break it.

You can’t anticipate everything that’s going to be done with it but you try tobuild in enough flexibility that it’s likely to adapt to whatever you’re going todo. So that’s what I’m thinking. How do I not write myself into a corner toomuch? How do I give myself the flexibility to adapt as I need to?

That’s one of the things that I discovered I really like about JavaScript.Refactoring in JavaScript, I find, is really easy. Whereas refactoring a deepclass hierarchy can be really, really painful.

For example, JSLint has transformed quite a lot since I started writing it in2000, 2001. And its goals have changed significantly—it’s doing a lot of stuffnow that I never thought it would do. And a lot of that’s because JavaScriptis so flexible. I can fiddle with it and allow the program to grow withoutbecoming sloppy.

Seibel: What makes it so much easier?

Crockford: I’ve become a really big fan of soft objects. In JavaScript, anyobject is whatever you say it is. That’s alarming to people who come at itfrom a classical perspective because without a class, then what have yougot? It turns out you just have what you need, and that’s really useful.Adapting your objects… the objects that you want is much morestraightforward.

Seibel: Presumably the problem, working with a class-based language, isthat it’s too static—you’ve got a big class hierarchy and if you want tochange that structure you’ve got to take it apart and put it back together. InJavaScript it seems the danger is that it can be too dynamic—you’ve stucklittle kludges everywhere and the actual structure of your program isdetermined by lots of things that happen at runtime; there’s no static thingyou can look at and say, “OK, this is the program and how it’s structured.”

Crockford: That is the scary part of it and it’s good to be scared because itis scary and it is real. It requires discipline. In most of the classical languages,the language is the thing imposing the discipline. In JavaScript you have tobring your own discipline.

Part of what I do to keep my code from falling apart is to be really rigorousmyself in how I put it together because I know the language is not providingthat rigor for me. So today I would not consider undertaking something ascomplicated as JSLint without JSLint. JavaScript does not scale very well onits own, but with that tool I become a lot more confident that I’m going tobe able to keep it working.

Seibel: So the softness of JavaScript objects can be dangerous. But if younever availed yourself of the ability to augment objects, then you might aswell just be writing classes in Java. Is there some way you think aboutstructuring your JavaScript programs to take good advantage of theflexibility the language gives you?

Crockford: For me it was years of trial and error. When I started workingwith JavaScript, I didn’t read anything about it. I just started. I found a sampleprogram, which was awful, and started fiddling with it until it worked morelike the way I thought it should. So I began programming in the language,having no understanding about what the language was, or how it worked, orhow you needed it to think about it.

I understand why people are frustrated with the language. If you try to writein JavaScript as though it is Java, it’ll keep biting you. I did this. One of thefirst things I did in the language was to figure out how to simulatesomething that looked sort of like a Java class, but at the edges it didn’twork anything like it. And I would always eventually get pushed up againstthose edges and get hurt.

Eventually I figured out I just don’t need these classes at all and then thelanguage started working for me. Instead of fighting it, I found I was beingempowered by it.

Seibel: When you’re designing software, do you prefer to think top-downor bottom-up or middle-out?

Crockford: All at once. That’s the thing about keeping the system in yourhead. Ultimately you need to divide and conquer and get it down intosomething you can manage. I find I’m on all parts of the problem and usingall those techniques simultaneously. And I keep struggling with it until Ibecome clear on what the structure is. Once you figure out what thestructure is, then the rest of it falls out.

Seibel: How do design and coding relate for you? Do you start codingimmediately and then iteratively refine it, or do you do something that’sseparate from writing code?

Crockford: They used to be separate. They’re becoming more similar now.I used to work in a design language or a meta language—something semi-English,a little structured, which is more descriptive of what you’re going towrite. But if I’m writing in JavaScript, that language has turned intoJavaScript.