The Art of Unix Programming
In 1994 I stuck a Yggdrasil Computing, Inc. Plug-and-Play Linux CD in the drive of my 486 and rebooted it and soon was hooked. Before booting the CD I had never used Unix. Today with the exceptions of games and a little web browsing I don't use anything but Unix. There was something about Unix that I loved but until I read Eric Raymond's book I had not given a lot of thought to what exactly it was that was so wonderful.
In The Art of Unix Programming, Eric S. Raymond talks about the ideas that made Unix what it is. He tells us about Unix culture and practice, how to apply the lessons and philosophy of Unix in our own projects and designs. In his own words:
"This book has a lot of knowledge in it, but it is mainly about expertise. It is going to try to teach you the things about Unix development that Unix experts know, but aren't aware that they know. It is therefore less about technicalia and more about shared culture than most Unix books — both explicit and implicit culture, both conscious and unconscious traditions. It is not a "how-to" book, it is a "why-to" book."
The book is divided into four main sections: Context, Design, Implementation, and Community.
The Content section talks about the philosophy, culture, and history of Unix and then compares it to VMS, MacOS, OS/2, WIndows NT, BeOS, MVS, VM/CMS, and Linux.
The Unix philosophy in the words of Doug McIlroy :
"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
Eric abstracts the following rules from the Unix is put together and the actions of the "Elders" (When I read this I wondered what they thought about being called "The Elders"):
- Rules 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 to 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: 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.
The chapter covering the history of Unix is very readable and one of the best if not the best summaries I have read. As an added bonus the chapter has comments scattered through out the chapter by people who where there such as Ken Thompson, Ken Arnold, Marshall McKusick, and Keith Packard.
The Design section has chapters on Modularity, Textuality (Text based protocols), Transparency, Multiprogramming, Mini-languages, Generation (automated code generation), configuration, interfaces, optimization, and complexity (as simple as possible but no simpler). It contains case studies of many different applications ranging from ed, emacs, and vi; to audacity, fetchmail, and Freeciv.
For example in the chapter on transparency a case study of kmail talks about how kmail echos each line of the SMTP transaction to its status line in the bottom of the window.
"Instead, they designed for transparency — they made the transaction messages show, but also made them visually easy to ignore. By getting the presentation right, they managed to please both Aunt Tillie and her geeky nephew Melvin who fixes her computer problems. This was brilliant; it's a technique other GUI interfaces could and should emulate."
In the implementation section there is a chapter on languages that evaluates c, c++, shell, Perl, Tcl, Python, Java, and Emacs Lisp; a chapter on tools that looks at editors, code generators, make, version control systems, run time debugging, profiling, and how to use Emacs (the one true ... ah never mind) to control all these tools; and a chapter on code reuse. I use both emacs and vi. The longer the task the more likely I am to use emacs but I have to say that the following statement is the most evangelical emacs statement that I have ever read.
"Earlier in this chapter we asserted that Emacs can give you capabilities resembling those of a conventional integrated development environment, only better. By now you should have enough facts in hand to see how that can be true. You can run entire development projects from inside Emacs, driving the low-level mechanics with a few keystrokes and saving yourself the mental effort and disruption of constantly switching contexts.
The Emacs-enabled development style trades away some capabilities of advanced IDEs, like graphical views of program structure. But those are frills. What Emacs gives you in return is flexibility and control. You're not limited by the imagination of the IDE designer: you can tweak, customize, and add task-related intelligence using Emacs Lisp. Also, Emacs is better at supporting mixed-language development than conventional IDEs."
I think that we can safely assume which side of the emacs / vi religious war Eric is on. As a side note I recommend that all vi users read this chapter at least twice :)
The section on community spends a lot of time of time talking about standards and best practices for developers. It covers the c language and its history and standards process, Unix standards, Internet standards such as the IETF and RFC documents, code documentation, a very good chapter on how to program in the New Unix Community, how to select a license and what standard licenses are available, and then talks about the future.
The Art of Unix Programming is a great book for a new user who wants to learn more about Unix. It will teach them more about why Unix is the way it is and why that is a very good thing than any other book I have seen. It is also a great book for an experienced Unix user. The book goes through why things are the way they are in wonderful detail and covers so many areas that the reader is sure to fill in some blanks in their knowledge. It is very well written and I would recommend it to anyone who works in Unix or thinks they may want to start.