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

But if you really are trying to move a needle and you don’t know exactly what you’re doing, rewrite. It’s going to take several tries to know what the hell you’re doing. And then when you have a design more firm you’ll stick with it and you’ll start patching it more, and you’ll get to this mature state where we creak with patches. It’s kind of an evolutionary dead-end for code. You know, maybe it’s a good sunk cost and you can stand on it for years. Maybe it’s this thing that’s crying out for replacement. Maybe in the open-source world some better standard library has emerged.

And that gets back to the craft of programming, I think. You don’t just write code based on some old design. You want to keep practicing, and the practicing involves thinking about design and feeding back your experience in coding to the design process.

I have this big allergy to ivory-tower design and design patterns. Peter Norvig, when he was at Harlequin, he did this paper about how design patterns are really just flaws in your programming language. Get a better programming language. He’s absolutely right. Worshipping patterns and thinking about, “Oh, I’ll use the X pattern.”

Seibel:So newer experiences can show you better ways going forward. But what about when writing the code shows you big flaws in your existing design?

Eich:That does happen. It happens a lot. Sometimes it’s difficult to throw out and go back to square one. You’ve already made commitments, and you get into this trap. I did this with JavaScript. In a great big hurry, I wrote a byte-code interpreter. Even at the time I knew I was going to regret some of the things I’d done. But it was a design that was understandable to other people and I could hope to get other people helping me work on. So I question design all the time. I just realize that we don’t always get the luxury of revisiting our deepest design decisions. And that is where we then attempt to do a big rewrite, because you really would have a hard time incrementally rewriting to change deep design decisions.

Seibel:How do you decide when it’s right to do a big rewrite? Thanks to Joel Spolsky, Netscape is in some ways the poster child for the dangers of the big rewrite.

Eich:There was an imperative from Netscape to make the acquisition that waved the Design Patterns book around feel like they were winners by using their new rendering engine, which was like My First Object-Oriented Rendering Engine. From a high level it sounded good; it used C++ and design patterns. But it had a lot of problems.

But the second reason we did the big rewrite—I was in mozilla.org and I really was kind of pissed at Netscape, like Jamie, who was getting ready to quit. I thought, you know, we need to open up homesteading space to new contributors. We can’t do it with this old hairball of student code from 1994. Or my fine Unix kernel-style interpreter code.

We needed to do a fairly big reset. Yeah, we were going to be four years from shipping. At that point I don’t think we were telling upper management that because they didn’t want to hear it, so we were optimizing to them. And that cost some of the management their heads. Though they all made out fabulously on the options—much better than I did. But for Mozilla that was the right trade.

We were lucky in hindsight, because we could have had a more rapid evolution of the Web. Microsoft was—some people claim this was due to the antitrust case more than their nature—inclined to sit on the Web and stagnate it. So that gave us time to wave the standards flag—which is twoedged and half bullshit—and go rewrite. Like Joel, I’m skeptical of rewrites. I think it’s rare to find that kind of an alignment of interests and get enough funding to live through it and not miss the market. The exceptions are very rare.

The rewrites I was speaking of earlier, though, were when you’re prototyping. That’s critical and smaller-scale. It may be a cross-cutting change to a big pile of code so it’s small in lines, but it’s big in reach and all the invariants you have to satisfy. Or maybe it’s a new JIT or whatever, and that you can get away with.

Seibel:Have you ever done any literate programming, a la Knuth?

Eich:I followed the original stuff. It was very neat. I liked it. It was word retrieval. He had some kind of a hash-trie data structure and it was all literately programmed. Then Doug McIlroy came along and did it all with a pipeline.

Our programs are heavily commented but we don’t have any way of extracting the prose and somehow making it be checked by humans, if not automatically, against the code. Python people have done some more interesting work there. I have not done anything more than heavily comment. I do go back and maintain comments—it’s a real pain and sometimes I don’t do it and then I regret it because somebody gets a bum steer.

I actually like McIlroy’s rejoinder. It wasn’t a rebuttal of literate programming—but it was kind of. You don’t want to write too many words, prose or code. In some ways the code should speak for itself at the small level. It’s at the bigger level, the big monster function or the module boundary, that you need docs. So doc comments or things like them—doc strings. Embedding the test in the comment. I guess that’s the big Python thing. That’s good.

There is something to literate programming, especially these integrated tests and doc strings. I’d like to see more of that supported by languages. We tried to add doc comments of some sort to ES4 with first-class metadata hooks or reflection hooks and it was just impossible to get everybody to agree.

Seibel:Do you read code you’re not working on?

Eich:I do it as part of my job. Code review is a mandatory pre-check-in step, mostly to compensate for Netscape’s bad hiring, but we kept it and still use it for integration review. We have a separate “super review” for when you’re touching a lot of modules and you don’t know all the hidden invariants that Joe Schmoe, who no longer works on Mozilla, knew in his head. Somebody else may have figured them out so you have somebody experienced to look at the big picture. Sometimes you can bypass it if you know what you’re doing and you’re in the sort of Jedi council, but we’re not trying to cheat on it too much.

We don’t have design reviews, so sometimes this causes a delayed design review to happen. They say, “Oh, back to the drawing board. You wrote too much code. You should have designed it this other way.” That’s the exception. We aren’t going to impose any kind of waterfall, design then implementation. That was the big thing when I was getting into the industry in the early ’80s and it was a nightmare, frankly. You spend all this time writing documents and then you go to write the code and often you realize that it’s really stupid and you totally change the code and put the documents down the memory hole.

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

Eich:Open source is great. I love looking at other people’s code that’s in some other part of the world. I don’t spend enough time on it but I do look at 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 Ajax libraries—and it’s heartening to see how clever people can be and how this small set of tools—closures, prototypes, and objects—can be used to create reasonable, convenient, sometimes very convenient abstractions. They’re not always hardened or safe but they’re awfully convenient.