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
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
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.