Basics of the Unix Philosophy
From Eric Raymond's "The Art of Unix Programming
" i picked here the 17 rules described as the Basics of the Unix Philosophy. For me these are also rules for writing high quality software:
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected with other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for one true way.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.
Or even rules for living a high quality life !
The Art of Unix Programming is indispensable reading for ALL developers, not just Unix ones.
Eric Raymond's writing is very clear, concise, transparent, and easy to read, just like the Unix coding and design styles he advocates.
Digg this story
" i picked here the 17 rules described as the Basics of the Unix Philosophy. For me these are also rules for writing high quality software:Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected with other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: Repair what you can — but when you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for one true way.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.
Or even rules for living a high quality life !
The Art of Unix Programming is indispensable reading for ALL developers, not just Unix ones.Eric Raymond's writing is very clear, concise, transparent, and easy to read, just like the Unix coding and design styles he advocates.
Digg this story
posted by Ronny De Winter at Monday, December 05, 2005
18 Comments:
well done, thanks.
good list...
well said
Ahhh Yes, the *simplicity* of Unix. Here's a simple example for you, the man page for the find command. http://unixhelp.ed.ac.uk/CGI/man-cgi?find
Could it be more simple or intuitive....
Nice. "Least Surprise" reminds me of Ruby.
Chris
http://amateureconblog.blogspot.com/
man page for find is
# man find
not http://unixhelp.ed.ac.uk/CGI/man-cgi?find
Now we need someone to put these in an order that form a neat mnemonic device.
gee, I thought the unix philosopy was: 1) treat everything like a file, and 2) never use capital letters ;-)
The Microsoft "Way"...
Our customers are criminals. Let us treat them as such.
Just because you bought the software doesn't mean it's yours.
ALL blue screens are caused by 3rd party drivers.
Quality of Marketing over Quality of Software.
Customers need not concern themselves with known security holes.
Linux/Unix sucks. Even though Google, Amazon and Yahoo seem to make it work and prefer it over Windows.
.NET 1.1 is so bad even we won't use it in our products... But feel free to use it in YOUR apps.
Bloat? What bloat?
Read your EULA... We now own your computer.
I think that if more programmers lived by these rules software and the industry as a whole would be in a lot better place. Thank you.
vt
The rule of diversity. That son of a gun has wasted more of my time.
Ther generally is a correct and an incorrect way to do things.
Granted, its situational.
To me the rule of diversity is a lazy programmers excuse so that they can do it thier way instead of learning a new or proven effective way.
I didn't see the part about "using DLL's containing undocumented API's that can only be registered by installing a massive application that is not needed." No doubt it will be fixed in the next version.
Rule of Economy will lead to systems that don't scale, be careful with it.
Rule of Generation will lead to systems that are not comprehensible, maintainable or extensible or are only readable and modifiable in the tool that generated the code, which may itself become outdated and useless.
Rule of Optimization means optimize the code afterwards, not figure out efficient and//or scalable algorithms and implementations after the fact. Before a single line of code is written, the algorithm should be well thought out.
Rule of Diversity leads to wasted money, duplicate effort and lazy programmers. For every right way to do something there is an infinite number of wrong ways to do it. If a discussion around what way to do something comes up, make it pluggable.
Unfortunately, a lot of software products and companies are born from prototyped software that someone who hasn't even graduated college developed. Some of the most innovative products come from programmers who don't even know the "rules", thus creating interesting programs that no existing software company even thought of doing. This is typically how bad code and design starts.
If current corporations gave their experienced programmers the opportunity to spend part of their time on some creative ideas, then maybe we'd see more robust code bases.
I've seen rules like this for jumping around for the past 15 years. Most people I work with follow them, but unfortunately it's not always easy an easy practice considering that the current code base that we're working on was developed by someone who is inexperienced. Most execs won't even think of re-writing code that does the same thing just to tidy it up with better coding and desgn.
An inexperiened programmer may not follow these rules because he/she doesn't even know what they mean in the first place. All he/she knows is the language syntax, the platform, and what he/she wants to do. Period.
The person who linked to the man page for the find command has an excellent point. Eveyone wants to think that *their* O.S. or philosophy is special, that it's simpler than all the others out there. Ask an average computer user to add hardware to a *nix system, and ask him if it's "simple."
If Unix is simple, why are there 17 rules? Why not 10, or 3 for that matter?
""Ask an average computer user to add hardware to a *nix system, and ask him if it's "simple.""
An average user of what? Windows? Of course they won't find it simple because it is different. Granted, it could be simpler, but it is still not difficult providing that the device is supported... and before anyne points that out as a unix fault, it isn't. It is the device manufacturers fault for not providing drivers.
I don't really agree with 'generation' except for replicated data or interface / facade creation because it can quite often create more work than it would solve, keeping the tool up to date and such.
Thanks for all the replies and comments!
For your further exploration I linked every rule to the original text.
For more on "using DLL's containing undocumented API's that can only be registered by installing a massive application that is not needed."
You can read the section on Windows NT in "The Art of Unix Programming"
http://www.faqs.org/docs/artu/ch03s02.html#nt_contrast
where also "DLL hell" is mentioned.
mdennis wrote:
"Rule of Economy will lead to systems that don't scale, be careful with it."
Wouldn't agree here. EricRaymond suggest to use higher level languages (perl, python, java, lisp ...) instead of c that ease the programmer's burden by doing their own memory management. Don't see why this should not scale. If you refer to performance issues, the rule is first make it right, then make it fast. rewrite in lower level languages the slow parts (only if you found them after profiling)
"Rule of Generation will lead to systems that are not comprehensible, maintainable or extensible or are only readable and modifiable in the tool that generated the code, which may itself become outdated and useless."
see chapter 9: Generation http://www.faqs.org/docs/artu/generationchapter.html
Pushing the specification level upwards.
And also (intro chapter 8): One of the most consistent results from large-scale studies of error patterns in software is that programmer error rates in defects per hundreds of lines are largely independent of the language in which the programmers are coding. Higher-level languages, which allow you to get more done in fewer lines, mean fewer bugs as well.
"An inexperiened programmer may not follow these rules because he/she doesn't even know what they mean in the first place. All he/she knows is the language syntax, the platform, and what he/she wants to do. Period."
With this blog I hope i can help to create a better software development world. At least i am happy that 10000+ people read this post (thanks to everyone who digg it!). If only a minority of them learns from it and applies the best practices, we made a small step forward.
"Eveyone wants to think that *their* O.S. or philosophy is special, that it's simpler than all the others out there. Ask an average computer user to add hardware to a *nix system, and ask him if it's 'simple.'
If Unix is simple, why are there 17 rules? Why not 10, or 3 for that matter?"
Simple OSs do not exist. A powerful operating system is complex. So also unix is not simple and it cannot be compressed in 10 or even 3 (or even 17!) rules. In its 10s of years of history a lot of good ideas popped up (and also some bad ones). Let's learn from these and don't make the same mistakes in the future ourselves.
I finish with a comment that was posted on digg:
"Brilliant. Programming in general would be easier if everyone followed these rules."
Enjoy,
Ronny
Good summary and a good topic for a blog. I've linked to it from my blog's sidebar since software quality is always relevent to developing programmers.
This comment has been removed by the author.
Post a Comment
Read more about Software Quality at the <<Software Quality Weblog Home