188 Programming
- Why should the debugger do that?
Why not write some “tool” that does it instead? - If the debugger dumps core, you should forget about
debugging your application and debug the debugger. - It’s too hard to understand.
- Where are the Twinkies?
- Why fix things now?
- Unix can’t do everything right.
- What’s the problem?
The statement “fixing bugs would break existing code” is a powerful
excuse for Unix programmers who don’t want to fix bugs. But there might
be a hidden agenda as well. More than breaking existing code, fixing bugs
would require changing the Unix interface that zealots consider so simple
and easy-to-understand. That this interface doesn’t work is irrelevant. But
instead of buckling down and coming up with something better, or just fix-
ing the existing bugs, Unix programmers chant the mantra that the Unix
interface is Simple and Beautiful. Simple and Beautiful. Simple and Beau-
tiful! (It’s got a nice ring to it, doesn’t it?)Unfortunately, programming around bugs is particularly heinous since it
makes the buggy behavior part of the operating system specification. The
longer you wait to fix a bug, the harder it becomes, because countless pro-
grams that have the workaround now depend on the buggy behavior and
will break if it is fixed. As a result, changing the operating system interface
has an even higher cost since an unknown number of utility programs will
need to be modified to handle the new, albeit correct, interface behavior.
(This, in part, explains why programs like ls have so many different
options to accomplish more-or-less the same thing, each with its own slight
variation.)If you drop a frog into briskly boiling water it will immediately jump out.
Boiling water is hot, you know. However, if you put a frog into cold water
and slowly bring it to a boil, the frog won’t notice and will be boiled to
death.The Unix interface is boiling over. The complete programming interface to
input/output used to be open, close, read, and write. The addition of net-
working was more fuel for the fire. Now there are at least five ways to send
data on a file descriptor: write, writev, send, sendto, and sendmsg. Each
involves a separate code path through the kernel, meaning there are five
times as many opportunities for bugs and five different sets of performance
characteristics to remember. The same holds true for reading data from a
file descriptor (read, recv, recvfrom, and recvmsg). Dead frog.