We don’t have design reviews, so sometimes this causes a delayed designreview to happen. They say, “Oh, back to the drawing board. You wrotetoo much code. You should have designed it this other way.” That’s theexception. We aren’t going to impose any kind of waterfall, design thenimplementation. That was the big thing when I was getting into the industryin the early ’80s and it was a nightmare, frankly. You spend all this timewriting documents and then you go to write the code and often you realizethat it’s really stupid and you totally change the code and put the documentsdown the memory hole.

Seibel: So that’s code that is going into Mozilla; do you ever read otherpeople’s code, outside Mozilla, just for edification?

Eich: Open source is great. I love looking at other people’s code that’s insome other part of the world. I don’t spend enough time on it but I do lookat server frameworks or I look at things like Python and Ruby.

Seibel: The implementations of those things?

Eich: Implementations and also library code. I look at the Ajaxlibraries—and it’s heartening to see how clever people can be and how thissmall set of tools—closures, prototypes, and objects—can be used to createreasonable, convenient, sometimes very convenient abstractions. They’re notalways hardened or safe but they’re awfully convenient.

Seibel: When you read a big piece of code, how do you get into it?

Eich: I used to start top-down. If it’s big enough you get function pointersand control flow gets opaque. I sometimes drive it in the debugger and playaround with it that way. Also, I look for bottom-up patterns that Irecognize. If it’s a language processor or if it’s got something that makessystem calls that I understand, I can start looking at how those primitivesare used. How does that get used by higher levels in the system? And thathelps me get around. But really understanding it is this gestalt process thatinvolves looking at different angles of top and bottom and different views ofit, playing in the debugger, stepping through in the debugger—incrediblytedious though that can be.

If you can understand what’s going on a little bit in the heap—chasepointers, walk through cons cells, whatever—that can be worth the troublethough it gets tedious. That, to me, is as important as reading source. Youcan get a long way reading source; you can also get stuck and get bored andconvince yourself you understand something that you don’t.

When I did JavaScript’s regular expressions I was looking at Perl 4. I did stepthrough it in the debugger, as well as read the code. And that gave me ideas;the implementation I did was similar. In this case the recursive backtrackingnature of them was a little novel, so that I had to wrap my head around. Itdid help to just debug simple regular expressions, just to trace theexecution. I know other programmers talk about this: you should stepthrough code, you should understand what the dynamic state of theprogram looks like in various quick bird’s-eye views or sanity checks, and Iagree with that.

Seibel: Do you do that with your own code, even when you’re not trackingdown a bug?

Eich: Absolutely—just sanity checks. I have plenty of assertions, so if thosebotch then I’ll be in the debugger for sure. But sometimes you write codeand you’ve got some clever bookkeeping scheme or other. And you test itand it seems to work until you step through it in the debugger. Particularly ifthere’s a bit of cleverness that only kicks in when the stars and the moonalign. Then you want to use a conditional break point or even a watch point,a data break point, and then you can actually catch it in the act and checkthat, yes, the planets are all aligned the way they should be and maybe testthat you weren’t living in optimistic pony land. You can actually look in thedebugger, whereas in the source you’re still in pony land. So that seemsimportant; I still do it.

Seibel: Is the way you discover a problem that you’re stepping throughlooking at the source with your mental model of what’s about to happen,and then you see it not happen?

Eich: You see it not happen, or—and this is my problem—I was in ponyland. I’m getting older and more skeptical and I’m doing better, but there’sstill something that I was optimistic about. In the back of my mind this JiminyCricket is whispering, “You probably have a bug because you forgot aboutsomething.” That kind of problem happens to me still.

And sometimes I know about it, I swear—somewhere in there I know I’mwrong. I have this sort of itch in my hind-brain—well, not in my hind-brain; Idon’t know where it is; the microtubules. Anyway, I kind of feel like there’ssomething that I should watch out for, and being in debugger helps mewatch out for it and it helps me force the issue or see that the test vector,though it covered the code in some sense, didn’t cover all the combinations,because it’s a huge, huge hyperspace. And if you just change this one valuethen you’d go into a bad place.

Seibel: In addition to reading code, lots of programmers read books aboutprogramming—are there any books that you would recommend?

Eich: I should be a better student of the literature. But I think it’s sort oflike music in that you have to practice it. And you can learn a lot readingother people’s code. I did like Brian Kernighan’s books; I thought they wereneat, because they would build up a small amount of code, and start reusingit as you go, and modularizing. And Knuth’s Art of Computer Programming,Volumes 1–3, especially the seminumerical stuff. Double-hashing—I lovethose parts. The lemma about the golden ratio with the proof left as anexercise.

But I’m a little skeptical of book learning for programming. Programming ispartly engineering; there’s maybe some math on a good day. And thenthere’s a lot of practical stuff that doesn’t even rise to the level ofengineering in the sense of civil engineering and mechanical engineering.Maybe it’ll be formalized more over time.

There’s definitely a good corpus of knowledge. Computer science is ascience. I remember somebody on Usenet 20 years ago said, “Science lite,one-third the rigor.” There’s still a lot of stuff that doesn’t look like it reallyholds up over time—there are these publish-or-perish ten-page, ten-pointfontpapers that often have holes in them. The journal publications arebetter because you get to interact with the referee; it’s not just a truth ordare. And they get reviewed more carefully. The areas of mechanizedproofs, that’s getting impressive. But it’s still not reaching programmers. Sothere’s something a little bit missing in computer science in my view thatmakes me skeptical of book learning. I should probably not go so far on thisLuddite track. But there it is.

There is science there, and there are important things to learn. You couldspend a lot of time studying them, too. I know a lot of people on thetheoretical side of it from work on JavaScript language development, and alot of them are hackers, too, which is good. Some of them don’t program.

They’re not really practical people. They have amazing insights, which cansometimes be very productive, but when you have to actually writeprograms and ship them to users and have them be usable and have themwin some sort of market contest, you’re far removed from theory. But I aminterested in theory, and it does help improve our lives.

Seibel: There are other kinds of books too. There are books thatintroduce you to the craft of programming, without a lot of theory.

Eich: And that’s the kind of book I like. We talked about Knuth’s literateprogramming paper. And there was a whole area of programming as craftthat I like. I like the Smalltalk books. Now that I think about it, those werepretty influential. The Adele Goldberg book. And before that, the Byte issue.