Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Pre-review thoughts on TAOUP

Eric Raymond is writing a book called The Art of Unix Programming. It is coming out in August 2003, but a late draft (?) manuscript, version 0.86, is on his web site. In everything below, bear in mind that the book is not finished yet.

Overall, it is a pretty good book. It is interesting enough and a worthwhile contribution. There are some irritating bits where esr is too insistent on his particular view of the world, but they are outweighed by parts that can be broadly appreciated.

The momentary initial impression is of hubris. However good you think you are, should you really explicitly compare yourself to Knuth? Should something "dashed off" in a couple of years compare to somebody's life work? Too late now, I suppose. Perhaps I'm too harsh: it is after all a tip of the hat, and in scope and focus on the aesthetics it is not so far away from The Art of Computer Programming.

The Practice of Programming is quite similar in content, though more oriented towards practical tips for programmers on any platform than exaltation of Unix.

The Basics of the Unix Philosophy are nicely summarized, perhaps better than has ever been done before in one place:

• Rule of Modularity: Write simple parts connected by clean interfaces.
• Rule of Clarity: Clarity is better than cleverness.
• Rule of Composition: Design programs to be connected with other programs.
• Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
• Rule of Simplicity: Design for simplicity; add complexity only where you must.
• Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
• Rule of Transparency: Design for visibility to make inspection and debugging easier.
• Rule of Robustness: Robustness is the child of transparency and simplicity.
• Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.
• Rule of Least Surprise: In interface design, always do the least surprising thing.
• Rule of Silence: When a program has nothing surprising to say, it should say nothing.
• Rule of Repair: Repair what you can ? but when you must fail, fail noisily and as soon as possible.
• Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
• Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
• Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
• Rule of Diversity: Distrust all claims for one true way.
• Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Another thing that bugs me is the slightly preachy tone at times. I think if a thing is good, it enough to merely describe its good features and allow audiences to draw their own conclusions. Pounding on about it will irritate your friends and alienate neutral readers. But this is largely redeemed by this epigram:

If you have any trouble sounding condescending, find a Unix user to show you how it's done.
-- Scott Adams Dilbert newsletter 3.0, 1994

for example, in discussing Windows NT Raymond doesn't discuss NT's Domain Security model, which I think is one of their most interesting design features and one to which Linux still has no complete answer. Is he unaware of it, or is it not important to him, or is he supressing it to make Unix look better?

There are however genuinely interesting ideas behind his analysis of operating systems. There is a feedback effect on ease of "casual programming", which generates a larger developer base. (c.f. the Angry Monkey Dance)

It can be hard to argue for a particular design school. Leaving aside religious/emotional attachments, aesthetics by definition make sense only mostly on their own terms. Showing that a particular design approach has produced a good outcome in a particular example makes the reader wonder if the example was accidental or specially chosen. TAOUP is at its best when it explains the Unix philosophy with examples.

TAOUP does recognize and discuss in a useful way the tension between the desirability of small programs and the existence of desirable large programs.

Discussion of the problems with OO is also good, and as clear an explanation of the problem as I can remember.

posted Tue 1 Jul 2003 in /books/taoup | link

Copyright (C) 1999-2007 Martin Pool.