First, let me tell two stories.
The first one is one Japan soap factory had a problem that they sometimes shipped empty boxes to the customer without soap inside. So they spend much time and money to invent a X-ray machine to check whether the soap box is empty.
The same thing happens in a small factory which doesn't have too much money. The solution of them to solve this problem is they use a desk fan to blow the empty boxes out of the belt and into a bin.
The second story is NASA finds that in space with 0 gravity, astronauts cannot use pen to write. So they spend much money on developing a pen which can be used in 0 gravity space. Have a guess, how do Russians solve this problem? The answer is at the end of the article.
===========================
Many people are talking about "Unix Philosophy" which is the guidelines of developing Unix operating system.
Wikipedia has listed a few versions of Unix Philosophy, different people have different understandings about it. The pipe command inventor Doug McIlroy summarized three points, Eric S.Raymond summarized 17 points in the book The Art of Unix Programming.
But all of them agree that Keep it Simple(Use simple method to solve problems) is the fundamental of Unix Philosophy. This is also what the famous statement KISS(keep it simple, stupid) says.
Here are some notes of mine on Keep it Simple principle. If you want to complete a task with a simple way, four aspects you need to pay attention to.
1. Rule of Clarity
Because maintenance is so important and so expensive, write programs as if the most important communication they do is not to the computer that executes them but to the human beings who will read and maintain the source code in the future (including yourself).
In the Unix tradition, the implications of this advice go beyond just commenting your code. Good Unix practice also embraces choosing your algorithms and implementations for future maintainability. Buying a small increase in performance with a large increase in the complexity and obscurity of your technique is a bad trade — not merely because complex code is more likely to harbor bugs, but also because complex code will be harder to read for future maintainers.
Code that is graceful and clear, on the other hand, is less likely to break — and more likely to be instantly comprehended by the next person to have to change it. This is important, especially when that next person might be yourself some years down the road.
2. Rule of Modularity
Each program does just one thing, don't try to finish over one task in one program. In programs, we need to separate font end and back end modules because front end changed faster. We can connect each module with clean interface, it's easy for people to maintain and reuse the modules.
3. Rule of Composition
Different modules or programs should be connected with interfaces. The communication among different interfaces involve data exchange, we should use text as the data exchange format since they are easier to process. It means we should avoid using binary data to communicate among interfaces, avoid using binary data as input and output.
4. Rule of Optimization
Before the function modules are completed, don;t do optimization. The most important thing is to first make it run, then we can consider the efficiency. Make it run, then make it right, then make it fast. First we should make a prototype, then find out what functions are not necessary, then we no need to do optimizations on those unnecessary codes. The most powerful optimization tool is Delete on keyboard.
===========================
Russians use pencil.
Original author : 阮一峰 Source : http://www.ruanyifeng.com/blog/2009/06/unix_philosophy.html
