The UNIX Philosophy

• Mac/OS is visually based with all options presented to the user
• DOS attempts to create ``a taste of the mainframe''
• DEC VMS assumes users fear the machine and should be given a few powerful choices

A Little History

The UNIX Philosophy

1. small is beautiful
2. make each program do one thing well
3. build a prototype as soon as possible
4. choose portability over efficiency
5. store numerical data in flat files
6. use software leverage to your advantage
7. use shell scripts to increase leverage and portability
8. avoid captive user interfaces
9. make every program a filter

The Ten Lesser Tenets

1. allow the user to tailor the environment
2. make operating system kernels small and lightweight
3. use lower case and keep it short
4. save trees
5. silence is golden
6. think parallel
7. the sum of the parts if greater than the whole
8. look for the ninety percent solution
9. worse is better
10. think hierarchically

Small is Beautiful

In most traditional software a large portion of the code is devoted to something other than the task which that program is intended. This can lead to greater complexity.

Example: A copy command can easily perform twelve different tasks, only one of which is copying a file.

Small Programs are Easy to Understand

Small Programs are Easy to Maintain

Small Programs Consume Fewer System Resources

Small Programs are Easier to Combine with Other Tools

Make Each Program Do One Thing Well

Build a Prototype as Soon as Possible

This idea runs counter to many software engineering methods which state that a majority of the design must be completed before any code is written. It is really an extreme form of prototyping and is intended to aid in the development of the final system. Prototyping is used to learn about the system and to reduce the risk of major problems in the final system.

Three Systems

The First System is built:

• with the developers back against the wall (some constraint, usually time, forces the developer to try something drastic)
• when there is no time to ``do it right''
• usually by a single person or at most a small group
• and is a lean, mean, computing machine.

The second system is built when the first system has been seen as something good. The Second System is:

• built by ``experts'' using ideas proven in the first system
• designed by committee
• fat and slow
• gains a great deal of commercial acclaim

The Third System is:

• often built by people who have been ``burned'' by the second system
• often given a name change to disassociate it with the original obsolete technology
• still contains the original concept intact and is regarded as commonplace

Choose Portability over Efficiency

• Next year's hardware will run faster -- performance may not be an issue in a short amount of time.
• Don't spend too much time making programs run faster -- tuning a program is expensive and the gains are often not worth the time.
• The most efficient way is rarely portable -- programs tied to hardware are rarely portable. Hardware which is state-of-the-art when you create a program will soon be outdated and the worth of the program will drop quickly. It is better to have drivers for hardware which take advantage of advanced features but which also provide a consistent/stable programming interface.
• Portable software reduces the need for user training.
• Good programs will be imitated by others if you cannot port them.

Store Numerical Data in Flat ASCII Files

• ASCII text is a common interchange format -- it is not the best or most efficient, but it is the most likely to be understood on a variety of machine. Data which cannot be readily moved to another machine has limited value, and the act of converting data can be very expensive in time and money.
• ASCII is easily read and edited -- specialized tools to manipulate the data are not required.
• There already exists a wide array of text manipulation tools -- awk, cut, diff, grep, head, lex, more, perl, sed, sort, tail, test, wc.

Use Software Leverage to Your Advantage

• Good programmers write good code; great programmers ``borrow'' good code -- incorporating other people's modules and programs into your project has several advantages. It frees large amounts of development time, the obtained code is tested and debugged by the author, and it makes you look efficient.
• Avoid the not-invented-here syndrome -- there is no reason to reconstruct software which already exists. Most common applications are now standardized and produced by companies which specialize in their production.
• Allow other people to use your code to leverage their work -- the most successful software is the one which appears on the most computers. Proprietary software is usually more difficult to integrate into a system and if your product is too much trouble to use then competitors will develop a better version.
• Automate everything -- simply put, take advantage of the computing environment to do as much work for you as possible. Learn the shortcuts which the shell and many commands provide.

Use Shell Scripts to Increase Leverage and Portability

• Shell Scripts provide great amounts of leverage -- they provide you with the ability to use many previously developed and tested programs with little effort.
• Scripts save development time -- they are interpreted which eliminates compile time. However, they do not have a very good debugging system for scripts which can lead to time wasted searching for a problem.
• Scripts are more portable than 3GLs -- and will likely work on any machine with little to no modification.
• Resist the urge to rewrite shell scripts in a compiled language -- the components used by the shell have been developed by smart people and are probably more efficient than the ones you will write.

Avoid Captive User Interfaces

• CUIs assume the user is human -- they do not allow the program to be run in a non-interactive mode which can be very inefficient for large throughput systems. Similarly, they cannot be combined with other programs easily.
• CUIs and big and difficult to write -- they often require large amounts of system resources, and are very complex.
• CUIs don't scale well -- limitations are usually placed upon the operations which a CUI will allow you to perform to make the system easier to use. When too many instances of an operation must be repeated the interaction with the interface becomes a burden.

Make Every Program A Filter

If programmes are capable of producing output given a stream of input then they have the added flexibility of being used in non-interactive systems.

The Lesser Tenets

Make operating system kernels small and lightweight -- keeping the kernel devoted to the basic system services makes the system robust. Added features do not have the ability to halt the system if they are not working correctly.

Use lower case and keep it short -- lower case provides more visual cues to the reader which makes it easier to read and correspondingly less stressful.

Save trees -- data which is in a form that cannot be manipulated is near useless. Keeping data online allows for more processing to be done with it.

Silence is golden -- Unix provides ``just the facts'' when executing a program and does not address the user in a conversational tone. If a program says nothing (ls on an empty directory) then it means there is nothing.

Think parallel -- the CPU is seldomly busy for long and should be kept busy with parallel tasks whenever possible.

The sum of the parts is greater than the whole -- many small components can be combined to produce a greater program.

Look for the ninety percent solution -- it is easier to solve most problems by ignoring the most difficult ten percent. If operations in a program are costly and will be used by few people it is better to drop them from the project.

Worse is better -- the niche which Unix occupied was never on the ``industrial strength'' systems of the world. It grew to fill the low end minicomputer and later workstation market.