### Doug McIlroy
- Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
- Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information.
- Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
- Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

### Peter H. Salus
- 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.

### Rob Pike
- 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.

### Dennis Ritchie and Ken Thompson
- Make it easy to write, test, and run programs.
- Interactive use instead of batch processing.
- Economy and elegance of design due to size constraints
- Self-supporting system: all Unix software is maintained under Unix.

### ESR
- Modularity - Write simple parts connected by clean interfaces.
- Readable - Programs that are clean and clear.
- Composition - Programs connected to programs.
- Separation: Separate policy from mechanism; separate interfaces from engines.
- Simplicity: Design for simplicity; add complexity only where you must.
- Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
- Transparency: Design for visibility to make inspection and debugging easier.
- Robust: Robustness is the child of transparency and simplicity.
- Representation: Fold knowledge into data so program logic can be stupid and robust.
- Least Surprise: In interface design, always do the least surprising thing.
- Silence: When a program has nothing surprising to say, it should say nothing.
- Repair: When you must fail, fail noisily and as soon as possible.
- Economy: Programmer time is expensive; conserve it in preference to machine time.
- Generation: Avoid hand-hacking; write programs to write programs when you can.
- Optimization: Prototype before polishing. Get it working before you optimize it.
- Diversity: Distrust all claims for “one true way”.
- Extensibility: Design for the future, because it will be here sooner than you think.

### Does The Unix Philosophy Still Matter?
- Yes?
- We can still learn
- Do what makes sense
- Simplify everything
- Abstraction isn't the answer