as one of its Innovators of the Year. This year he and his colleagues were awarded the Usenix STUG (Software Tools User Group) award for DTrace.

STEVE BOURNE Let’s begin by discussing tools. Eric, what’s your current set of tools and what do you like or dislike about them?

ERIC ALLMAN I have to admit to being kind of old-fashioned. It’s just like in my kitchen, where I’d rather have a few really sharp knives that I know how to use than a whole bunch of appliances that don’t do anything particularly well. Part of this is because of bad experiences in the past. I remember spending a certain amount of time with a symbolic debugger, which I believe was not adb, spending close to a week trying to find a bug in a program only to finally realize it was a bug in the debugger. That soured me on symbolic debuggers for several years, so I went back to using binary debuggers. That was on a PDP- 11 where you could actually read the assembly language.

There are certainly tools today, such as symbolic editors, that I haven’t really gotten used to, either, in part because of the simple GUI issues. Moving your hand over to a mouse and then back to the keyboard when you’re typing text is to me not a good optimization, so I still use vi. Emacs is fine, except I don’t have that many fingers, so it doesn’t work for me.

I guess I have finally gotten over some of my hang-ups. I do use symbolic debuggers now; they seem to be reliable enough. BRYAN CANTRILL Yes, welcome to the 1970s. But I’m similar in that I very much adhere to the Unix philosophy of having a small number of tools that do their jobs very well. For me, the holy trinity would be vim—which is basically vi, but with improvements—to edit; the compiler to compile; and mdb to debug. Mdb is an adb derivative with very powerful extensions that allow for powerful debugging methodologies to be developed. And then DTrace to debug in situ for performance problems.

Beyond that I use cscope a lot for source-code navigation, and Team Ware, which is one of the best things no one has ever heard about. It’s a Sun program that’s really the granddaddy of the bring-over/modify/merge model of development. BitKeeper and Team Ware are very much in the same vein, in part because Larry McVoy is behind both of them.

I don’t use Eclipse, not necessarily because I have anything against it or NetBeans or these other kinds of higher-level IDEs. It’s more that they are not appropriate for the problems that we’re solving. So I’m still old school in that regard.

SB Can you elaborate on that?

BC I think that each of these IDEs was designed with a particular problem in mind and that the success of the IDE really depends on the ability to outgrow that single problem to other problem spaces. If you look at Eclipse and NetBeans, what they both have in common is their pluggable architectures, which are not mated to any one language or operating-system environment. They have both done an admirable job. What they both have in common in terms of their limitations is that they’re designed around developing a single program or entity of a program that they have defined—a servlet or what have you—that fits within their model.

When you start developing a larger system, they break down a little bit. Certainly for C they break down because a lot of their added value involves things like code completion. With code completion, not only are you able to implement in Java, it’s really a requirement. But in C, code completion is much trickier to do dynamically, so it’s of more dubious utility.

I don’t want to be curmudgeonly, but one of the things that concerns me about using code completion is it’s the kind of tool that can become a crutch insofar as it becomes a replacement for understanding the system. I no longer have to understand the system because I can auto-complete all this stuff. I’m able to quickly stagger my way to code that compiles, but if that code reflects less understanding of the system, it makes me nervous.

One of the things I love about the Unix philosophy is that I don’t have to read the man (manual) pages. I don’t need to read the man page for open, for read, for write. I don’t need to read the man page for Awk or for the shell because these things have simple abstractions that are powerful but simple enough that I’m able to retain them. The thing I worry about with code completion is that it allows for this kind of metastasis of complexity.

Steve, you designed some of these basic essential tools like adb and the shell. Are they simple by design, or are they simple because they had to be, because of the limitations of the 16-bit address space? SB A little bit of both, but I think the environment then was not as complicated as it is today. For example, one of the things I liked about the Unix development environment back in those days was that you could find things. If you said “man x,” then it either said it was there or it wasn’t there. If it wasn’t there, it wasn’t there, and if it was there, you found it. The problem today is finding methods and libraries that do things you want to do. Maybe it’s easier to do if you’re in a development shop that has already been set up.