The Art of UNIX Programming
Rating: 6 out of 7.
The standard book about all technical meta-topics around software development in general, not only applicable to UNIX. Covers project organization (directory structure, essential files), community communication, important requirements, domain specific languages and more. A MUST have for all programmers, not only UNIX programmers.
This book really would deserve two separate ratings. If I'd rate its importance and contributions, I'd rate it 7 out of 7. If I'd rate its accuracy and selection of case studies, I'd rate it 5 out of 7.
The book's title is correct though misleading. The book was written with a UNIX background, yes. But its content is applicable to software development in general, not only to a UNIX resp. POSIX environment. I may sound a bit evangelistic now, but there's much the Windows and Mac worlds can learn from the UNIX world. Because of that it doesn't hurt that most of the case studies are from the UNIX world. The issues covered by the book are generic.
Content
The book is parted in 4 sections. The first section, Context
, covers software development philosphies and cultures. It starts with describing its background, the UNIX world, and what Unix gets right and what it gets wrong. Eric deduces basic rules from the Unix Philosophy like modularity, clarity or simplicity, rules which have their origins in Unix but are worth applying in non-Unix environments as well. The tales of the Unix and Hacker cultures give a detailed sight on Eric's background, a background he shares with most of what's seen as todays freaks amongst software developers - hackers, tuxers, open source developers. The first section is round up by contrasting the unix philosphies with others in two ways, once for elements of operating system styles and once for operating systems, Windows NT and Linux being the most prominent.
The second section, Design
, shifts and details the rules found in the basics of the Unix philosophy. The design issues covered are partly on an abstract level like modularity or complexity, academic level like minilanguages, or a practical level like interfaces or configuration, but always described with their cultural background as well as practical examples or sometimes even lists suitable as checklists or reference.
The third section, Implementation
, starts with the question whether or not to use C as a programming language, discussing the strengths and weaknesses of C and comparing it to other languages like Java and Perl. The tools chapter in this section covers applications directly related to software development from text editors over code generation and build automation up to version control systems.
The fourth and last section, Community
, covers programming issues that are directly related to the users. Two technical chapters are concerned with portability and documentation of software. The chapter about open source describes best practices for working with open source developers and describes some of the more popular open source licenses. The final chapter Futures: Dangers and Opportunities
is delightfully critical about Unix and presents Plan 9, the official successor of Unix.
The book has a good backmatter with a glossary of abbreviations, references, contributors and Rootless Root: The Unix Koans of Master Foo
. Even if you'd not be interested in the rest of the book, Rootless Root
alone already is worth buying the book.
Critique
I found the book very easy to read. It has a simple yet scientific style of writing with a good amount of humour and sarcasm that makes it easy to read the book in multiple ways. Being not a native English speaker, I'd rate myself as more susceptible to sluggish writing styles. On the other hand I don't like books that read as if they'd been written for idiots. And in general, I prefer a book with a good amount of humour. At 99% of the time, Eric gets this right.
What I didn't like were the parts of the book where Eric is overly biased and starting to lie or at least being extremely unscientific. While being quite neutral and scientific most of the time, there are two topics on which Eric shows his bias more than I'd say is appropriate.
One topic is the holy war Vi vs. Emacs. I'm on the Vi side, Eric is on the Emacs side. I'm biased, too, and that's likely to be the reason why I'm sensitive for that issue. When Eric compares Vi's features with Emacs' features, he's sometimes not true about the featureset of modern vi implementations like Vim and describes it smaller than it is. And Eric's comparison about the size of a Vi executable vs. the size of an Emacs executable is complete nonsense without knowing their configurations: GUI? Mutlibyte support? Support of right-to-left text? X-Clipboard-in-Terminal support?
The other topic is Java. The book is Copyright 2004. The information he gives about Java is at a level of something like 1998 or 1999.
Therefore, if you read about vim or Java in this book, don't take it too serious, either he was too biased or too lazy to do proper research and illustration of those topics.
Conclusion
This book is a book that I'd nominate as one of the five must-have-read books for software developers of all platforms (even embedded, mainframe, computer games etc.).
Links
View this book at
