Raymond's Rules of Cosmic Order

Eric S. Raymond is a UnixGod with no shortage of controversial ideas. That's the nature of Unix Gods. Strip the t-shirt off a UnixGod and you'll as likely find Mars as Jove. (Rarely, if ever, Venus.)

Curmudgeonly, scratchy and brilliant, Raymond is the author of numerous articles and several books which have a wide influence outside the arcane field of Unix programming. His most well known works are:The Cathedral & the Bazaar and The New Hackers' Dictionary AKA The Jargon File.

Last month, Raymond published a new book, The Art of Unix Programming which, according to Raymond,

attempts to capture the engineering wisdom and philosophy of the Unix community as it's applied today not merely as it has been written down in the past, but as a living "special transmission, outside the scriptures" passed from guru to guru. Accordingly, the book doesn't focus so much on "what" as on "why", showing the connection between Unix philosophy and practice through case studies in widely available open-source software."

All well and good and I am sure that all those like myself who cannot write a line of Unix wish those that can well in their endeavors. But, while not Unix literate myself, I do know guttural Unix as a consequence of many years dealing with various commands in the shell of a conferencing system called The Well. While frittering my years away on this limping, wheezing system I found I had to learn a few very basic Unix commands. I was also introduced to my first Unix Wizard, one "jef," who always seemed to know everything one could want to know about Unix and would share it in his gruff and blunt way. I liked his gruff bluntness, especially when it was directed against the personalities of others on the Well who yearn for bluntness like the landed fish yearns for the club.

Years of online communication with jef gave me some insight into the kind of personality that is either drawn to Unix and to programming, or is shaped by Unix and programming. I've come to believe it is a symbiotic relationship, at best. So, even though I can't code, I was interested to see what lay at the core of Raymond's Unix epic. And what seemed closest to the core was his: Basics of the Unix Philosophy ) -- a series of 'rules' derived from a number of different programmers over the years that Raymond boiled down into a simple and elegant list. But, as is easy to see with only a brief perusal, this is not just some list to be pasted next to a programmers work station, this is a list that can function on many other levels. In short, it is a list with more to teach than just how craft Unix.

The Raymond Rules for Unix

• 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 oftransparency and simplicity.


• Rule of Representation: Fold knowledge into data, soprogram logic can be stupid and robust.


• Rule of Least Surprise: In interface design, always do theleast 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.

Lets see how these rules work when applied to writing:

The Raymond Rules for Writing

• Rule of Modularity: Write simple sentences and paragraphs connected by clean transitions.


• Rule of Clarity: Being clear is always the clever way to write.


• Rule of Composition: Design paragraphs or chapters to be connected to others in a logical manner. The career of William Burroughs does not make this false. Remember that not all junkies can be writers, but all writers can write like junkies. Easily.


• Rule of Separation: Separate sense from sensibility; separate style from story. In this way you can easily toss out sensibility and style and still have a pretty sensible story.


• Rule of Simplicity: Write towards simplicity; add complexity only where you must and you mustn't add often.


• Rule of Parsimony: Write a big book only when it is clear by demonstration that nothing else will tell the story. Not everything youve found out has to be told. Its called backstory because it needs to be kept in the back. Way back. (P.S. Will everyone please forward this rule to Neal Stephenson before he commits another book? Thank you.)


• Rule of Transparency: Make them see. Write for visibility to make reading and comprehension easier. Do not dispense diaphanous shrouds of lilting loquaciousness that stultify and anesthetize the eternally enervated and torpid reader.


• Rule of Robustness: Robustness is the child oftransparency and simplicity and the herald of readability.


• Rule of Representation: Show. Do not tell.


• Rule of Least Surprise: In writing, always choose theleast surprising word.


• Rule of Silence: When youve made your point, shut up.


• Rule of Repair: Repair what you can in the second draft but if it still fails, cut it. If it all fails, shelve it.


• Rule of Economy: Writing time is always too short; take all you can when you can.


• Rule of Generation: Avoid making it up all over again; write in notebooks in order to have something to write when you can.


• Rule of Optimization: Prototype before polishing.Do an entire first draft before rewriting the first chapter.


• Rule of Diversity: Distrust all claims for one true way to write including this way and this rule.


• Rule of Extensibility: Write and revise as if your work will be published with your name on it, because it may well be.

Not bad and thats only one draft. What this should suggest is that these rules are clever and useful well beyond the realm of Unix programming. Which, I believe, is one of Raymonds aims in drafting them; that they suggest not just a way of programming but a way of life.

But dont take my word for it. Apply them yourself to the realms of law, of politics, of love and of war. Youll find they hold true in all of these areas. I suppose Raymond could have called these rules the Commandments of Unix, but why would a UnixGod do that?

Posted by Vanderleun at January 5, 2004 4:18 PM