A summary of the UNIX design philosophy, this book is a bit out of date and needs a more abstract and less dogmatic second edition.
I was rather disapointed by ‘The UNIX Philosophy’ (TUP). First of all, the book feels out of date. This feeling is partly due to the fact that TUP was published in 1995 and thus many of the examples are anachronistic. However, the datedness of TUP also stems from a second flaw — some of the tenets of the UNIX philosophy outlined in the book are too concrete and thus appear to conflict with some present-day practices which many ‘UNIX people’ would not, I think, consider improper. Finally, the book sometimes presents practical (and thus adaptable) design principles as unshakeable articles of faith in the UNIX Religion.
It is a measure of the speed of change in technology and the world at large that a technical book published in 1995 can seem so behind the times. For example, the chapter on the principle of software leverage and the utility of ‘borrowing’ the work of others doesn’t mention the Free Software/Open Source phenomena, perfect examples of the power of sharing work with others to gain leverage. Of course those two movements were, respectively, relatively unknown and non-existent at the time. In the chapter on the “small is beautiful” principle, an example using the popularity of compact cars becomes a quaint reminiscence given the current (in the US at least) consumer predilection for SUVs.
Gancarz should not be blamed for failing to predict the future, but these anachronisms point to the need for a fresh edition. Furthermore, there are more serious problems in TUP.
Gancarz considers only two possibilities for implementation languages (C and shell scripts) whereas today we are presented with a host of common alternatives such as Perl, Python, and numerous others. This limitation in the variety of example languages would not be a problem if the philosophical “Tenets” presented in TUP could be applied to new languages to get the ‘UNIX slant’ on their utility.
However, consider Tenet 7: “Use Shell Scripts to Increase Leverage and Portability”. Although Gancarz presents his Tenets as abstract principles, it is hard to imagine a more concrete engineering principle. (Use *Bourne* shell scripts? Use *this* Bourne shell script?) I think that interpreted languages like Perl have many of the same advantages that Gancarz attributes to shell scripts, but Tenet 7 seems to rule out Perl and friends as potential alternatives to C.
Then there is Tenet 5: “Store Numerical Data in Flat ASCII Files”. Gancarz compares flat ASCII files with proprietary binary formats and concludes that ASCII solutions are more portable and thus more powerful. Simple enough, but what about open binary formats (such as the datastore for a freely available open-source database) or hierarchical text file formats (such as the increasingly popular XML)? An open binary format seems to circumvent at least some of Gancarz’s objections, but certainly not all. XML, although stored in ASCII, is not amenable to manipulation with standard UNIX tools like ‘cut’ and ‘paste’. Does the Unix philosophy rule out every data format except for flat ASCII? Tenet 5 seems to say that it does.
It seems to me that Tenet 5 and Tenet 7, rather than being “Tenets” at all, are really particular applications of the more general design principles of Portability (Gancarz’s Tenet 4) and Software Leverage (Tenet 6). Those last two tenets are general principles that can be applied in a wide range of situations and are thus useful as engineering rules of thumb. And, I should mention, Gancarz ably argues their merits.
But the idea that portability and leverage lead inevitably to shell scripts and flat ASCII files seems suspect. Surely there are some engineering situations where, say, a Perl script would provide all the portability and leverage that a shell script could. If you have ever tried to write a truly portable shell script, you know that it’s not necessarily easier than writing portable Perl!
In other words, traditional rules of thumb must be re-evaluated in the light of new situations and new experience. But Gancarz seems to place the UNIX philosophy beyond reproach. Consider the following passage (p. 103).
They [the Tenets] are the bedrock upon which the UNIX world sits. No one could strongly contest them and rightfully consider oneself a “UNIX person.” To do so would invite suspicion by the UNIX community that you lack commitment to UNIX and what it stands for.
I would hope that level-headed members of the UNIX community would accept criticism with open-minded skepticism, not suspicion! Any engineering philosophy that discourages questioning the basis of itself is more like a cult than an engineering discipline. Engineering always involves tradeoffs and tradeoffs require a cost-benefit analysis. The UNIX philosophy outlined by Gancarz is the distillation of many years of cost-benefit analyses and engineering experiences of the members of the UNIX community, not a set of maxims proclaimed by the very first UNIX Zen Master that the rest of the community now follows without question.
But the UNIX community, and software engineering in general, is still relatively young and therefore still has much to learn. A book on the UNIX philosophy should emphasize the practical and adaptable nature of its teachings as a living (and thus changing) design philosophy and not as unquestionable orthodoxy.