Peter Seibel - Coders at Work - Reflections on the craft of programming

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 pointers and control flow gets opaque. I sometimes drive it in the debugger and play around with it that way. Also, I look for bottom-up patterns that I recognize. If it’s a language processor or if it’s got something that makes system calls that I understand, I can start looking at how those primitives are used. How does that get used by higher levels in the system? And that helps me get around. But really understanding it is this gestalt process that involves looking at different angles of top and bottom and different views of it, playing in the debugger, stepping through in the debugger—incredibly tedious though that can be.

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

When I did JavaScript’s regular expressions I was looking at Perl 4. I did step through 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 backtracking nature of them was a little novel, so that I had to wrap my head around. It did help to just debug simple regular expressions, just to trace the execution. I know other programmers talk about this: you should step through code, you should understand what the dynamic state of the program looks like in various quick bird’s-eye views or sanity checks, and I agree with that.

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

Eich:Absolutely—just sanity checks. I have plenty of assertions, so if those botch then I’ll be in the debugger for sure. But sometimes you write code and you’ve got some clever bookkeeping scheme or other. And you test it and it seems to work until you step through it in the debugger. Particularly if there’s a bit of cleverness that only kicks in when the stars and the moon align. 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 check that, yes, the planets are all aligned the way they should be and maybe test that you weren’t living in optimistic pony land. You can actually look in the debugger, whereas in the source you’re still in pony land. So that seems important; I still do it.

Seibel:Is the way you discover a problem that you’re stepping through looking 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 pony land. I’m getting older and more skeptical and I’m doing better, but there’s still something that I was optimistic about. In the back of my mind this Jiminy Cricket is whispering, “You probably have a bug because you forgot about something.” That kind of problem happens to me still.

And sometimes I know about it, I swear—somewhere in there I know I’m wrong. I have this sort of itch in my hind-brain—well, not in my hind-brain; I don’t know where it is; the microtubules. Anyway, I kind of feel like there’s something that I should watch out for, and being in debugger helps me watch 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 value then you’d go into a bad place.

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

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

But I’m a little skeptical of book learning for programming. Programming is partly engineering; there’s maybe some math on a good day. And then there’s a lot of practical stuff that doesn’t even rise to the level of engineering 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 a science. 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 really holds up over time—there are these publish-or-perish ten-page, ten-pointfont papers that often have holes in them. The journal publications are better because you get to interact with the referee; it’s not just a truth or dare. And they get reviewed more carefully. The areas of mechanized proofs, that’s getting impressive. But it’s still not reaching programmers. So there’s something a little bit missing in computer science in my view that makes me skeptical of book learning. I should probably not go so far on this Luddite track. But there it is.

There is science there, and there are important things to learn. You could spend a lot of time studying them, too. I know a lot of people on the theoretical side of it from work on JavaScript language development, and a lot 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 can sometimes be very productive, but when you have to actually write programs and ship them to users and have them be usable and have them win some sort of market contest, you’re far removed from theory. But I am interested in theory, and it does help improve our lives.

Seibel:There are other kinds of books too. There are books that introduce 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 literate programming paper. And there was a whole area of programming as craft that I like. I like the Smalltalk books. Now that I think about it, those were pretty influential. The Adele Goldberg book. And before that, the Byte issue.

Seibel:With the hot-air balloon on the cover?

Eich:Yeah. That turned me around in a big way. That was big. That was like ’80 or so. So I wasn’t really doing a lot of programming then. I was thinking about it and I was reading about it and I was playing around on this old iron at undergraduate university. The purity of the Smalltalk environment, the fact that it was so highly bootstrapped—all that really hit me in a way that made me want to be involved in programming—languages and virtual machines. Going into Unix was physical machines and operating systems, and that was where the action was. But even then I was reading—there was a Springer-Verlag book that had a bunch of papers, and people back then were fantasizing about universal object file formats and Java byte-code, essentially, before its time. But yes, Smalltalk was huge. I didn’t actually get to use it until years later at U of I, when they finally released something that ran on the Suns of the time and it was slow.

Seibel:On another topic, how do you recognize programming talent?