Unix 设计哲学基础
参考：
The ‘Unix philosophy’ originated with Ken Thompson's early meditations on how to design a small but
capable operating system with a clean service interface. It grew as the Unix culture learned things about
how to get maximum leverage out of Thompson's design. It absorbed lessons from many sources along the way.
Unix哲学起源于Ken Thompson早期关于如何设计一个小巧而精干，服务接口清晰的冥想。而它也正成长为如何获从
Thompson的设计中获取最大影响力的Unix文化。它一路走来也从许多源码中吸收了经验。
The Unix philosophy is not a formal design method. It wasn't handed down from the high fastnesses of theoretical
computer science as a way to produce theoretically perfect software.
Unix 哲学不是一个正式的设计方法。它并没有被用作指导生产理论上完美软件的牢不可破的理论计算机科学。
The Unix philosophy (like successful folk traditions in other engineering disciplines) is bottom-up, not top-down.
Unix 哲学是自底向上的，而不是自顶向下。
Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, had this to say at the time：
(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
(iii) 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.
(iv) 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.
Doug McIlroy，unix 管道的创始人同时也是Unix传说的缔造者，如下说到：
1）让一个程序做一件事情，并做好。开展新工作时，重写新代码而不是由于添加新特性而使老的程序变得复杂。
2）尽量使每个程序的输出成为另一个程序的输入。不要让无关的信息令输出显得杂乱无章。避免严格的分栏或者二进制输入形式。不要坚持采用交互式输入。
3）设计和编译软件，即便是操作系统，也要及早进行测试，理想状态下在几周内实现。对于笨拙的实现要直接丢弃。
4）优先使用工具而不是不熟悉的帮助以减轻程序员的工作量，即使你不得不避开这些工具或者使用结束直接丢掉它们。
He later summarized it this way (quoted in A Quarter Century of Unix
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.
他后来这样总到：
这就是Unix 哲学：写只做一件事并把它做好的程序。写可以协同工作的程序。写可以处理文本流的程序，因为那是通用接口。
Rob Pike, who became one of the great masters of C, offers a slightly different angle in Notes on C Programming
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.
Rob Pike, 这个精通C的人在 Notes on C Programming 中提出了一些稍许不同的观点：
1）你不能确定程序将在哪里耗时。瓶颈发生于令人惊奇的地方，所以不要试图再去猜想以及添加速度设置直到你能确认瓶颈在哪里
2）测量。不要调速直到你已经测量出来，只有那一部分代码已经压垮了其它地方的运行才做调整。
3）当规模很小时 花式的算法总是慢的，而规模通常来说是小的。
4）花式的算法总是比简单算法容易产生bug，而且他们常常难以实现。使用简单的算法以及简单的数据结构。
5）数据占优。如果你已经选择了正确的数据结构且整理的很好，数据结构才是编程的中心而不是算法。
6）没有规则6.
