The Unix Philosophy

I was first drawn to this book by the title and by the following in the introduction: “The creators of the Unix operating system started with a radical concept: They assumed that the users of their software would be computer literate from the start.” Of course, it is just this assumption that helped keep Unix from being used very much outside the technical, university, computer-literate environment for many years. This book satisfactorily explains how and why the Unix operating system developed as it has; compelling arguments explain why the Unix philosophy allows for good software design and why, in the author's opinion, Unix will become the world's operating system.

The book is geared mostly toward readers who haven't yet used Unix, but the author also intended that experienced Unix programmers would reread it several times so as not to forget the nine main tenets of the Unix Philosophy, as well as the less stringently “enforced” minor tenets. (I think enforcement is accomplished by “true” Unix programmers looking down their noses at those who go astray from the true Unix philosophy.)

The book credits Stephen Bourne, William Joy, Brian Kernighan, and Dennis Ritchie, among the many people who contributed to the Unix Philosophy, each by giving some major contribution to Unix in the early days. For example, William Joy brought text editing and C-like command language (he developed vi and the C-shell); Dennis Ritchie brought us the C programming language.

The main tenets (each of which have sub-tenets) of the Unix philosophy are as follows:

The author introduces each tenet with a simple, real-world example (or “case study”) , then further explains why the tenet is important by including non-technical computer-world examples.

Tenet 1. Small is beautiful.The book offers an example of how Volkswagen ran an ad campaign with the phrase “small is beautiful” in the US to promote the VW bug, but the idea was generally ignored in the US until the price of oil went up and Americans learned the advantages of small cars. The author draws an analogy to these nouveau small-car-appreciators to programmers at AT&T Bell Labs discovering that small programs were also easier to handle, maintain, and adapt than large programs.

In a non-Unix environment, a program to copy one file to another file might include, as in an example given in the book, twelve steps which do more than perform a file copy. The twelve steps perform extra tasks, some of which are considered “safety features” by some. The steps might include checking to see if the file exists, if the output files are empty, and prompting users to see if they know what they're doing (for example, “Are you really really sure you want to do this, and does your mother know you're doing this?”), etc. Just one step of the sequence might be the actual copy command. A Unix program (or command) would only include the one copy command step. Other small programs would each do the other 11 steps and could be used together if the Unix user wanted to use these extra steps. Although the author purposefully steers away from giving Unix examples until near the end of the book, I would have liked to see several Unix commands strung together to accomplish all the tasks described by the twelve steps.

Tenet 4. Choose portability over efficiency.The example given here is of the Atari 2600 which was the first successful home video game. Most of the code for the game cartridges was very efficient but nonportable. With the advent of new hardware (the “5200”), the code had to be rewritten to run on the 5200 which took time and money. The author proposes that Atari would have been the largest supplier of software in the world if its code had been portable.

There is a three-page analogy of selling Tupperware to the “use software leverage to your advantage” tenet. Who would have realized a multilevel marketing scheme is a good way to write software?

A sub-tenet of the leverage tenet is allow other people to use your code to leverage their own work. Many programmers hoard their source code. The author states that “Unix owes much of its success to the fact that its developers saw no particular need to retain strong control of its source code.” Unix source code was originally fairly inexpensive compared to the cost of developing a new operating system, and companies started choosing Unix as the platform to build their software on. Companies who chose Unix spent their effort and money on developing their applications, rather than on maintaining and developing an operating system.

There were a few too many pages in this book attempting to reach the stubborn Unix-haters, for example trying to soothe the ego of the programmer who measures him/herself by the number of pages to their large programs. I was slightly put off the book by the psychological explanations of how programmers might behave until I realized these were gentle nudges—and Unix-aficionados are not known for gentleness in talking about other operating systems—that might actually get through to even a lifetime-Brand X operating system user.

I'd strongly recommend this book for people from all operating system environments.