Bayle Shanks's website: notes-computer-programming-unixPhilosophy

---

"small but capable..with a clean service interface"

"that perennial executive's mirage, some way to magically extract innovative but reliable software on too short a deadline from unmotivated, badly managed, and underpaid programmers."

" Doug McIlroy?, the inventor of Unix pipes and one of the founders of the Unix tradition, had this to say at the time [McIlroy?78]:

    (i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

    (ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

    (iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

    (iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

He later summarized it this way (quoted in A Quarter Century of Unix [Salus]):

    This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."

don't prematurely optimize
use simple algorithms, even brute force

"Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming"

some of these are paraphrased, and i removed some of them:

Modularity: simple parts connected by clean interfaces.

Clarity is better than cleverness.

Composition: Design programs to be connected to other programs.

Separation: Separate policy from mechanism; separate interfaces from engines.

Simplicity and parsimony: Design for simplicity and small programs; add complexity only where you must.

Transparency: Design for visibility to make inspection and debugging easier.

Representation: Fold knowledge into data so program logic can be stupid and robust.

Least Surprise: In interface design, always do the least surprising thing.

Silence: When a program has nothing surprising to say, it should say nothing. But when you must fail, fail noisily and as soon as possible.

Economy: Programmer time is expensive; conserve it in preference to machine time.

Optimization: Prototype before polishing.

Diversity: Distrust all claims for “one true way”.

Extensibility

“Controlling complexity is the essence of computer programming” -- Brian Kernighan

"Debugging dominates development time, and getting a working system out the door is usually less a result of brilliant design than it is of managing not to trip over your own feet too many times."

"there is no silver bullet" -- Fred Brooks

"The only way to write complex software that won't fall on its face is to hold its global complexity down — to build it out of simple parts connected by well-defined interfaces, so that most problems are local and you can have some hope of upgrading a part without breaking the whole."

"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)."

"The notion of “intricate and beautiful complexities” is almost an oxymoron. Unix programmers vie with each other for “simple and beautiful” honors — a point that's implicit in these rules, but is well worth making overt." -- Doug McIlroy?

"...where you see a choice between complexity in data structures and complexity in code, choose the former."

"The original HTML documents recommended “be generous in what you accept”, and it has bedeviled us ever since because each browser accepts a different superset of the specifications. It is the specifications that should be generous, not their interpretation."

-- Doug McIlroy?

"Premature optimization is the root of all evil" -- Donald Knuth (Knuth himself attributes the remark to C. A. R. Hoare)

"Rushing to optimize before the bottlenecks are known may be the only error to have ruined more designs than feature creep."

"One of my most productive days was throwing away 1000 lines of code." -- Ken Thompson

"Make it work first, then make it work fast"

"Prototyping is important for system design as well as optimization — it is much easier to judge whether a prototype does what you want than it is to read a long specification." -- Mike Lesk

"...multiple languages, open extensible systems, and customization hooks everywhere."

"leave room for your data formats and code to grow; otherwise, you will often find that you are locked into unwise early choices because you cannot change them while maintaining backward compatibility.

"When you design protocols or file formats, make them sufficiently self-describing to be extensible. Always, always either include a version number, or compose the format from self-contained, self-describing clauses in such a way that new clauses can be readily added and old ones dropped without confusing format-reading code. Unix experience tells us that the marginal extra overhead of making data layouts self-describing is paid back a thousandfold by the ability to evolve them forward without breaking things. When you design code, organize it so future developers will be able to plug new functions into the architecture without having to scrap and rebuild the architecture. This rule is not a license to add features you don't yet need; it's advice to write your code so that adding features later when you do need them is easy. Make the joints flexible, and put “If you ever need to...” comments in your code."