For the past couple of weeks I have been doing some research on best practices for software development. Along the way, I came across the term Unix Philosophy. Its basically a set of design decisions and practices adopted by the architects of Unix in early days. Whether Unix actually implements these practices is questionable, but they are definitely worth exploring.
Unix and other Operating Systems
The Unix philosophy is clearly very different from the philosophy behind the Microsoft Windows operating systems. The authors on Unix assumed that its users will be computer literates. Hence there primary focus was on robustness, maintainability and extensibility of code modules; rather than on user experience. On the other hand, Microsoft Windows and other commercial Operating Systems are governed by a very different set of priorities. That is, the emphasis is on gaining or maintaining market share and maximizing profits. As a result, these systems often generate very large, monolithic (lack of modularity), complex and closely guarded source code.
What are the philosophies?
The most prominent philosophy guiding Unix is the concept of modularity. Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, elaborates this concept: Design programs to do only a single thing, but to do it well, and to work together well with other programs.
The Art of Unix Programming by Eric Steven Raymond provides an excellent discussion on the historical and philosophical aspects of Unix. I found the Chapter 1 of the book absolutely fascinating to read. From there I am posting the 17 rules of Unix design abstracted by the author.
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.
Most of us are already using many of these concepts in development. However, its always nice to have a good reference for supporting your opinions.
Further Reading
To learn more, read the book at http://www.faqs.org/docs/artu/.
You can also download a PDF version Download PDF.
Read More:
No comments:
Post a Comment