Unix philosophy

Unix philosophy describes the design choices and overall construction of the framework of Unix and Unix-like operating systems.

Overview of Unix philosophy

Some of these decisions that have been made into implementing Unix can be described as the Unix philosophy: these include

• small tools to achieve big things - allowing users fine, but wide ranging control over the system enables them to interact, effectively constructing greater and automated functionality.
• creating a common stream-based interface between programs - this allows a great degree of modularity between programs, allowing them to connect together to work in tandem. The Unix construct to join programs is called piping, and is guaranteed to work if the programmer uses the interface of standard input, standard output, and standard error streams properly.
• not reporting any more than you have to - for example, copying a file will not print out anything if it occurs successfully, but will only say something if there is a problem in the process. This aids with shell scripting, and more specifically, piping.

Comments on Unix philosophy

Several Unix programmers have commented on Unix philosophy.

From Doug McIlroy, the man who invented piping

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.""

From Rob Pike, one of the greatest C programmers ever:

• Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.

• Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.

• Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)

• Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.

• Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

• Rule 6. There is no Rule 6.

From Ken Thompson, who designed and implemented the first Unix

• When in doubt, use brute force.

(This could be taken to be a summary of the first 4 of Pike's rules.)

Eric S. Raymond summarises his take on the UNIX philosophy as 17 Principles, in his book The Art of UNIX Programming.

See also

• programming