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.
译：优先使用工具来做不熟练的任务来减轻编程任务，甚至当你使用完后，不
得不绕道来重建工具，并期望抛弃其中的一些特性
He later summarized it this way (quoted inA Quarter Century of Unix[Salus]):
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 inNotes on C
Programming[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.
译：漂亮的算法当n很小时是很慢的，然而n通常很小，漂亮的算法很难修改。
直到你知道n经常会很大，不要被漂亮的算法所迷惑，（即使n的确很大，
先用原则2）
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.
译：漂亮的算法比简单的算法更多的bug，并且很难实现，使用简单的算法和
简单的数据结构
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.
译：没有规则6。
对编程规则评价：
Ken Thompson, the man who designed and implemented the first Unix, reinforced Pike’s rule 4 with
a gnomic maxim worthy of a Zen patriarch:
When in doubt, use brute force.->如果我对他有怀疑，就蛮干
更多的Unix哲学介绍：
More of the Unix philosophy was implied not by what these elders said but by what they did and the
example Unix itself set. Looking at the whole, we can abstract the following ideas:
1.Rule of Modularity: Write simple parts connected by clean interfaces.
译：模块性规则：:编写简单的模块用清晰的接口把它们连接起来
2.Rule of Clarity: Clarity is better than cleverness.
译：清晰性准则：清晰性优先于巧妙。
3.Rule of Composition: Design programs to be connected to other programs.
译：协作原则：设计可以被其他程序连接的程序
4.Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
译：分离准则：把政策和机制相分离；把接口和引擎相分离。
5.Rule of Simplicity: Design for simplicity; add complexity only where you must.
译：简单性准则：设计追求简单性，只在绝对必须时加入复杂性
6.Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing
else will do.
译：节俭准则：只在通过原型澄清后才编写大的程序。
7.Rule of Transparency: Design for visibility to make inspection and debugging easier.
译：透明准则：设计的可见性使检查和除错更容易。
8.Rule of Robustness: Robustness is the child of transparency and simplicity.
译：健壮性原则：健壮性是透明性和简单性的孩子
9.Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
译：表现准则：将知识包入数据，程序可以笨拙和健壮。
10.Rule of Least Surprise: In interface design, always do the least surprising thing.
译：最小惊奇准则：在接口设计中，总是做最少的令人惊讶的事儿，即不要画蛇添足。
11.Rule of Silence: When a program has nothing surprising to say, it should say nothing.
译：安静原则：当一个程序没有重要的输出时，应该保持沉默
12.Rule of Repair: When you must fail, fail noisily and as soon as possible.
译：修复准则：如果你必须出错，尽可能响亮和快速的出错。
13.Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
译：经济性准则：程序员的时间是宝贵的，用机器时间来保护程序员的时间，即如果和机器时
间比较，程序员的时间是昂贵的。
14.Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
译：生成准则：避免手工编程，如果可能，编写编写程序的程序。
15.Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
译：优化准则：在打磨前建立原型，在你优化前先使他工作。
16.Rule of Diversity: Distrust all claims for “one true way”.
译：多样性准则：怀疑一切声称“只能如此”的说法
17.Rule of Extensibility: Design for the future, because it will be here sooner than you think.
译：扩展性原则：为未来设计，因为它往往来的比你想得
欢迎大家提供建议，如果可行，我将修改，这将受益与你我，更涉及他人，谢谢你的建议！