the UNIX Philosophy

The UNIX Philosophy: Main Principles
Small is beautiful. Small things could be combined with other small things to create unique and flexible systems. Downside: people could have troubles interfacing with small things.
Make each program do one thing well. Focusing on a single functionality can eliminate much of unnnecessary code and promote flexibility.
Build a prototype as soon as possible. It allows generation of efficient design.
Portability is more important than efficiency. Portable programs have larger customer base and longer lifecycle.
Store data in flat ASCII files. It keeps the data portable, data which is not portable is dead.
Use software leverage to your advantage. Good programmers write good code, great programmers borrow good code.
Shell scripts have an advantage over compiled programs. They are portable and leverage compiled programs.
Avoid captive user interfaces. These interfaces need constant user input, thus locking the user or machine from doing anything else.
Make every program a filter that operates on data.
Side Principles:
Allow the user to customize the interface.
Keep the system kernel small and lightweight.
Use lower case and keep it short.
Keep data in electronic format - save trees.
Silence is golden - do not produce unnecessary output.
Think parallel.
Sum of parts is greater than the whole.
Look and implement 90% of the solution.
Worse is better, least common denominator is most likely to survive.
Think hierarchically.
Source: M. Gancarz (1995) The UNIX Philosophy. Digital Press, Boston, MA.
____________________________________________________________________________

The Unix Philosophy in a Nutshell

-----------------------------------

(The tenets are taken from Mike Gancarz, The Unix philosophy, Digital Press (1995). ISBN 1-55558-123-4. An excellent book which should be required reading for all software engineers! The commentaries are mine, paraphrasing Mike's in most cases.)

The major tenets

 

Small is beautiful. Small things have tremendous advantages over their larger counterparts. Among these is the ability to combine with other small things in unique and useful ways.

Make each program do one thing well. By focusing on a single task, a program can eliminate much extraneous code that often results in excess overhead, unnecessary complexity, and a lack of flexibility.

Build a prototype as soon as possible. Most users looking for a new piece of software won't know what they really want until they see it, so requirements documents are often misleading about the users' real needs. The Unix design philosophy makes prototyping a central part of the methodology: give the user something, anything, up-front to criticise, and work from there.

Choose portability over efficiency. If today's hardware just about runs a program with just about adequate efficiency, tomorrow's will run it with power to spare. So the developer's task is to make sure his program will run on that new hardware with minimal effort.

Store data in flat ASCII files. Valuable data will generally out-live any one program, machine, programming language or use. Data is only useful as long as it's being used, and flat files help ensure that data is usable for the longest possible time. For complex data structures where flat text really isn't appropriate, use a structured text format like XML instead: you can always strip-out the mark-up to get at the raw data.

Use software leverage to your advantage. Many programmers have only a superficial understanding of the importance of re-usable code modules. Code re-use helps one take advantage of software leverage, a powerful concept that some Unix developers use to create numerous applications in a comparatively short time.

Use shell scripts to increase leverage and portability. Scripts generate huge leverage - every line of script can invoke several "proper" programs each with several thousand lines of code. A programmer who can't re-use other programs is condemned to re-write them.

Avoid captive user interfaces. A program which prevents to user using any other commands for the duration "captures" the user and prevents him from taking advantage of other commands. A program should be usable in many modalities to maximise its usefulness.

Make every program a filter. The fundamental nature of all software programs is that they can only modify data, never create it. Therefore they should be written to function as filters since they are filters.
The minor tenets

Allow the user to tailor the environment. No single decision will suit all users - so don't force one upon them. The more tailorable an environment is, the more users can match it to their needs and the more they'll like it.

Make operating system kernels small and lightweight. Despite the never-ending push for new features, Unix developers prefer to keep the most central part of the operating system small. They don't always succeed at this, but this is their goal.

Use lower case and keep it short. Using the lower case is a tradition in the Unix environment that has persisted long after the reason for doing so (that it's easier to read text with descenders on a teletype) disappeared.

Save trees. Data committed to paper is essentially dead. There are good reasons for keeping all text on-line and using powerful tools to manipulate it.

Silence is golden. A silent command is often more usable, providing the function asked for and nothing more. You can always provide wrappers for people who prefer a more conversational tone.

Think parallel. Most tasks are composed of sub-tasks which may be attacked in parallel. This also applies to user interactions. Parallelism can save a great deal of time and frustration.

The sum of the parts is greater than the whole. A large application built from a collection of smaller programs is more flexible and hence more useful than a single large program. The same functional capability may exist in both solutions, but the collection-of-small-programs approach is the more forward-looking of the two.

Look for the 90% solution. Doing 100% of anything is difficult. Doing only 90% is far more efficient and cost-effective. Handle the 90% and let the 10% fend for themselves - often they'll handle their own special requirements far better than you would anyway.

Worse is better. That which is cheap but effective is far more likely to proliferate than that which is high quality and expensive. The PC-compatible world borrowed this idea and made quite a go of it....

Think hierarchically. Hierarchies allow tasks and attributes to be applied uniformly across nested elements. This is a powerful idea that encourages decomposition and modularity.