Basics of the Unix PhilosophyBasics of the Unix PhilosophyPrevChapter1.PhilosophyNext<br>Basics of the Unix Philosophy
The ‘Unix philosophy’ originated with Ken<br>Thompson's<br>early meditations on how to design a small but capable operating<br>system with a clean service interface. It grew as the Unix culture<br>learned things about how to get maximum leverage out of Thompson's<br>design. It absorbed lessons from many sources along the way.<br>The Unix philosophy is not a formal design method. It wasn't<br>handed down from the high fastnesses of theoretical computer<br>science as a way to produce theoretically perfect software. Nor is<br>it that perennial executive's mirage, some way to magically extract<br>innovative but reliable software on too short a deadline from<br>unmotivated, badly managed, and underpaid programmers.<br>The Unix philosophy (like successful folk traditions in other<br>engineering disciplines) is bottom-up, not top-down. It is pragmatic<br>and grounded in experience. It is not to be found in official methods<br>and standards, but rather in the implicit half-reflexive knowledge, the<br>expertise that the Unix culture transmits. It<br>encourages a sense of proportion and skepticism — and shows both<br>by having a sense of (often subversive) humor.<br>Doug McIlroy, the inventor of<br>Unix pipes and one of the<br>founders of the Unix tradition, had this to say at the time [McIlroy78]:<br>(i) Make each program do one thing well. To do a new job, build<br>afresh rather than complicate old programs by adding new<br>features.<br>(ii) Expect the output of every program to become the input to<br>another, as yet unknown, program. Don't clutter output with<br>extraneous information. Avoid stringently columnar or binary input<br>formats. Don't insist on interactive input.<br>(iii) Design and build software, even operating systems, to be<br>tried early, ideally within weeks. Don't hesitate to throw away the<br>clumsy parts and rebuild them.<br>(iv) Use tools in preference to unskilled help to lighten a<br>programming task, even if you have to detour to build the tools and<br>expect to throw some of them out after you've finished using<br>them.
He later summarized it this way (quoted in A Quarter<br>Century of Unix [Salus]):<br>This is the Unix philosophy: Write programs that do one<br>thing and do it well. Write programs to work together. Write<br>programs to handle text streams, because that is a universal<br>interface.
Rob Pike, who<br>became one of the great masters of C, offers a slightly different angle<br>in Notes on C Programming [Pike]:<br>Rule 1. You can't tell where a program is going to spend its<br>time. Bottlenecks occur in surprising places, so don't try to second<br>guess and put in a speed hack until you've proven that's where the<br>bottleneck<br>is.<br>Rule 2. Measure. Don't tune for speed until you've measured, and<br>even then don't unless one part of the code overwhelms the<br>rest.<br>Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big<br>constants. Until you know that n is<br>frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)<br>Rule 4. Fancy algorithms are buggier than simple ones, and<br>they're much harder to implement. Use simple algorithms as well as<br>simple data structures.<br>Rule 5. Data dominates. If you've chosen the right data<br>structures and organized things well, the algorithms will almost<br>always be self-evident. Data structures, not algorithms, are central<br>to programming.[9]<br>Rule 6. There is no Rule 6.
Ken Thompson, the man who designed and implemented the<br>first Unix, reinforced Pike's rule 4 with a gnomic maxim worthy of a<br>Zen patriarch:<br>When in doubt, use brute force.
More of the Unix philosophy was implied not by what these elders<br>said but by what they did and the example Unix itself set. Looking<br>at the whole, we can abstract the following ideas:<br>Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism;<br>separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add<br>complexity only where you must.
Rule of Parsimony: Write a big program only when it is<br>clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debuggingeasier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program<br>logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do<br>the least surprising thing.
Rule of Silence: When a program has nothing surprising<br>to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and<br>as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in<br>preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs<br>to write programs when you can.
Rule of Optimization: Prototype before polishing. Get...