Basic UNIX Philosophy

From http://blog.chinaunix.net/u2/87718/showart_1838217.html

 

-- From "Unix programming art"

UNIX philosophy originated from Ken Thompson's early thoughts on how to design a simple, compact, and sophisticated service interface operating system. As UNIX culture continues to grow in the process of learning how to explore Thompson's design ideas as much as possible, at the same time, we have gained traction from many other places along the way.

UNIX philosophy is not a formal design method. It does not intend to produce theoretically perfect software from the theoretical perspective of computer science. Those unmotivated, loose, and poorly paid programmers can create stable and novel software in just a short period of time, just as the gods attach themselves-it's just the manager's dream forever.

UNIX philosophy (like the folk traditions in other engineering fields) is bottom-up, not top-down. UNIX philosophy focuses on effectiveness and is based on rich experience. You will not find it in formal methodologies and standards. It is closer to the tacit half-instinct knowledge, that is, the professional experience spread by UNIX culture. It encourages you to prioritize and doubt everything, and encourages you to treat this with a humorous attitude.

Doug McILROY, inventor of the UNIX pipeline and one of the founders of the UNIX tradition, once said in [mcilroy78:

(I) Let every program do one thing well. If there is a new task, start again and do not add new features to the original program to make it complicated.

(Ii) assume that the output of each program is the input of another program, even if the program is still unknown. Do not interfere with irrelevant information in the output. Avoid entering the partition format and binary format strictly. Do not stick to interactive input.

(Iii) try out the software designed and compiled as early as possible, even the Operating System. Ideally, it should be within a few weeks. Don't hesitate to overwrite the code.

(Iv) Give priority to tools rather than poor help to relieve the burden on programming tasks. To do well, you must first sharpen your tools.

Later, he concluded that (derived from the 1/4 century of Unix (a quarter century of UNIX [salus]):

UNIX philosophy is like this: a program only does one thing and does well. Programs must be able to collaborate. The program must be able to process text streams because this is the most common interface.

Rob Pike, one of the greatest masters of C language, expressed the Unix philosophy from a slightly different angle in notes on C Programming [Pike]:

Principle 1: You cannot determine where the program will take time. The bottleneck often appears in unexpected places, so don't rush to find a place to change the code unless you have confirmed that it is the bottleneck.

Principle 2: Estimate. Do not optimize the speed before you estimate the Code, especially before finding the most time-consuming part.

Principle 3: Fancy algorithms are generally very slow in N hours, while N is usually very small. The constant complexity of fancy algorithms is very high. Unless you are sure that N is always large, do not use fancy algorithms (even if n is large, priority is given to principle 2 ).

Principle 4: Fancy algorithms are easier to generate bugs and implement than simple algorithms. Try to use simple algorithms with simple data structures.

Principle 5: data is overwhelming. If a correct data structure is selected and everything is organized in a well-organized manner, the correct algorithm is self-evident. The core of programming is the data structure, not the algorithm [7].

Principle 6: No principle 6.

Ken Thompson, the designer and implementer of the original unix version, emphasizes Pike Principle 4 in a Zen-like manner:

If you are not sure about it, you can make a poor effort.

In UNIX philosophy, more content is not expressed orally by the philosophers, but is embodied by what they do and the example set by UNIX itself. Overall, it can be summarized as follows:

1. Module principle: use simple interfaces to Assemble simple components.

2. Clear principle: Clear is better than clever.

3. Combination Principle: Consider splicing and combination during design.

4. separation principle: policy and mechanism separation, and interface and engine separation.

5. Concise Principle: The design should be concise, and the complexity should be low.

6. stingy principle: Do not write large programs unless you do not have it.

7. transparency principle: design should be visible for review and debugging.

8. robustness principle: Robustness stems from transparency and conciseness.

9. expression principle: Fold knowledge into data to make the logic simple and robust.

10. Popular principles: interface design to avoid innovation.

11. Silence principle: if a program has nothing to say, it will be silenced.

12. remedy principle: if an exception occurs, exit immediately and provide sufficient error information.

13. Economic Principles: rather than spending a second on machines, it will take a second on programmers.

14. Generation Principle: Avoid manual hack and write programs to generate programs as much as possible.

15. Optimization Principle: The original type should be available before the carving, and the original type should be learned before running.

16. Principles of diversity: never believe in the so-called "no two methods" assertions.

17. Expansion principle: design focuses on the future, and the future is always faster than expected.

If you are new to Unix, these principles are worth noting. Most of these principles are often recommended in software engineering articles, but most other operating systems lack proper tools and traditions to put these principles into practice, most programmers cannot implement these principles from start to end. Poor tools, poor design, overwork, and bloated code are already common to them; they wonder what UNIX players are so tired.