Difference between revisions of "Unix philosophy/Eric S. Raymond"
From Maths
(Created page with "<noinclude> {{Stub page|grade=C|msg=I link to this so much it'd actually be good to have my own version. This is taken from the OLD wiki page [https://en.wikipedia.org/w/index...") |
m (They didn't link properly! Fixing links) |
||
| Line 4: | Line 4: | ||
==Rules of the philosophy== | ==Rules of the philosophy== | ||
</noinclude># '''[[/Rule of Modularity|Rule of Modularity]]'''{{rTAOUPESR}} - write simple parts connected by clean interfaces | </noinclude># '''[[/Rule of Modularity|Rule of Modularity]]'''{{rTAOUPESR}} - write simple parts connected by clean interfaces | ||
| − | # '''[[/Rule of Clarity|Rule of Clarity]]'''<ref name="TAOUPESR"/> - Clarity is better than cleverness | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Clarity|Rule of Clarity]]'''<ref name="TAOUPESR"/> - Clarity is better than cleverness |
| − | # '''[[/Rule of Composition|Rule of Composition]]'''<ref name="TAOUPESR"/> - Design programs to be connected to other programs | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Composition|Rule of Composition]]'''<ref name="TAOUPESR"/> - Design programs to be connected to other programs |
| − | # '''[[/Rule of Separation|Rule of Separation]]'''<ref name="TAOUPESR"/> - Separate policy from mechanism, separate interface from engines | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Separation|Rule of Separation]]'''<ref name="TAOUPESR"/> - Separate policy from mechanism, separate interface from engines |
| − | # '''[[/Rule of Simplicity|Rule of Simplicity]]'''<ref name="TAOUPESR"/> - Design for simplicity; add complexity only when you must | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Simplicity|Rule of Simplicity]]'''<ref name="TAOUPESR"/> - Design for simplicity; add complexity only when you must |
| − | # '''[[/Rule of Parsimony|Rule of Parsimony]]'''<ref name="TAOUPESR"/> - Write a big program only when it is clear by demonstration that nothing else will do | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Parsimony|Rule of Parsimony]]'''<ref name="TAOUPESR"/> - Write a big program only when it is clear by demonstration that nothing else will do |
| − | # '''[[/Rule of Transparency|Rule of Transparency]]'''<ref name="TAOUPESR"/> - Design for visibility to make inspection and debugging easier | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Transparency|Rule of Transparency]]'''<ref name="TAOUPESR"/> - Design for visibility to make inspection and debugging easier |
| − | # '''[[/Rule of Robustness|Rule of Robustness]]'''<ref name="TAOUPESR"/> - Robustness is the child of transparency and simplicity | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Robustness|Rule of Robustness]]'''<ref name="TAOUPESR"/> - Robustness is the child of transparency and simplicity |
| − | # '''[[/Rule of Representation|Rule of Representation]]'''<ref name="TAOUPESR"/> - Fold knowledge into data so program logic can be stupid and robust | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Representation|Rule of Representation]]'''<ref name="TAOUPESR"/> - Fold knowledge into data so program logic can be stupid and robust |
| − | # '''[[/Rule of Least Surprise|Rule of Least Surprise]]'''<ref name="TAOUPESR"/> - In interface design, always do the least surprising thing | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Least Surprise|Rule of Least Surprise]]'''<ref name="TAOUPESR"/> - In interface design, always do the least surprising thing |
| − | # '''[[/Rule of Silence|Rule of Silence]]'''<ref name="TAOUPESR"/> - When a program has nothing surprising to say it should say nothing | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Silence|Rule of Silence]]'''<ref name="TAOUPESR"/> - When a program has nothing surprising to say it should say nothing |
| − | # '''[[/Rule of Repair|Rule of Repair]]'''<ref name="TAOUPESR"/> - When you must fail, do so noisily and as soon as possible | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Repair|Rule of Repair]]'''<ref name="TAOUPESR"/> - When you must fail, do so noisily and as soon as possible |
| − | # '''[[/Rule of Economy|Rule of Economy]]'''<ref name="TAOUPESR"/> - Programmer time is expensive, conserve it in preference to machine time | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Economy|Rule of Economy]]'''<ref name="TAOUPESR"/> - Programmer time is expensive, conserve it in preference to machine time |
| − | # '''[[/Rule of Generation|Rule of Generation]]'''<ref name="TAOUPESR"/> - Avoid hand-hacking; write programs to write programs when you can | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Generation|Rule of Generation]]'''<ref name="TAOUPESR"/> - Avoid hand-hacking; write programs to write programs when you can |
| − | # '''[[/Rule of Optimisation|Rule of Optimisation]]'''<ref name="TAOUPESR"/> - Prototype before polishing. Get it working before you optimise it | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Optimisation|Rule of Optimisation]]'''<ref name="TAOUPESR"/> - Prototype before polishing. Get it working before you optimise it |
| − | # '''[[/Rule of Diversity|Rule of Diversity]]'''<ref name="TAOUPESR"/> - Distrust all claims for "one true way" | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Diversity|Rule of Diversity]]'''<ref name="TAOUPESR"/> - Distrust all claims for "one true way" |
| − | # '''[[/Rule of Extensibility|Rule of Extensibility]]'''<ref name="TAOUPESR"/> - Design for the future, because it will be here sooner than you think<noinclude> | + | # '''[[Unix philosophy/Eric S. Raymond/Rule of Extensibility|Rule of Extensibility]]'''<ref name="TAOUPESR"/> - Design for the future, because it will be here sooner than you think<noinclude> |
==Notes== | ==Notes== | ||
Revision as of 02:11, 20 September 2016
Stub grade: C
This page is a stub
This page is a stub, so it contains little or minimal information and is on a to-do list for being expanded.The message provided is:
I link to this so much it'd actually be good to have my own version. This is taken from the OLD wiki page here which I STILL link to! Eric S. Raymond was/is one of my heroes but I did loose a tiny bit of awe/respect when I saw him trolling on the GCC mailing list once!
Rules of the philosophy
- Rule of Modularity[1] - write simple parts connected by clean interfaces
- Rule of Clarity[1] - Clarity is better than cleverness
- Rule of Composition[1] - Design programs to be connected to other programs
- Rule of Separation[1] - Separate policy from mechanism, separate interface from engines
- Rule of Simplicity[1] - Design for simplicity; add complexity only when you must
- Rule of Parsimony[1] - Write a big program only when it is clear by demonstration that nothing else will do
- Rule of Transparency[1] - Design for visibility to make inspection and debugging easier
- Rule of Robustness[1] - Robustness is the child of transparency and simplicity
- Rule of Representation[1] - Fold knowledge into data so program logic can be stupid and robust
- Rule of Least Surprise[1] - In interface design, always do the least surprising thing
- Rule of Silence[1] - When a program has nothing surprising to say it should say nothing
- Rule of Repair[1] - When you must fail, do so noisily and as soon as possible
- Rule of Economy[1] - Programmer time is expensive, conserve it in preference to machine time
- Rule of Generation[1] - Avoid hand-hacking; write programs to write programs when you can
- Rule of Optimisation[1] - Prototype before polishing. Get it working before you optimise it
- Rule of Diversity[1] - Distrust all claims for "one true way"
- Rule of Extensibility[1] - Design for the future, because it will be here sooner than you think
Notes
References
- ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 The Art of Unix Programming - Eric S. Raymond
