What the Unix philosophy incorporates
I heard of the term Unix philosophy, often abbreviated as “Write programs that do one thing and do it well”, more than once but never could really grasp its meaning.
Then I stumbled upon The Art of Unix Programming explaining this philosophy in more detail.
Here are guidelines (some are put into my own words) and quotes from the book that I find helpful to understand this philosopy better.
Modularity
A program should consist of simple, ideally independent, modules that are connected by clean interfaces. For example, separate front ends from back ends (if you need high performance, consider writing the front end in a scripting language and the back end in C).
Composition
Design programs to be connected to other programs. Be generous in what you accept and rigorous in what you emit. Use simple text streams for input and output.
Complexity
Keep global complexity to a minimum. Small is beautiful. The way to make robust programs is to make their internals easy for human beings to reason about.
Shut up or Scream
If the program doesn’t have to say anything interesting it should shut up. If it must fail, it should fail noisily and as soon as possible.
Clarity
Prefer clarity over cleverness. Buying a small increase in performance for a large increase in complexity is a bad trade. Programs are meant to be read by humans.
Prototype before Polishing
Make it run, then make it right, then make it fast . Don’t rush into
coding when you should be thinking. Be systematic when tuning: measure for the places where you can buy big performance wins with the smallest possible increases in complexity. Fancy algorithms add complexity and are often slow for a small n (and n is usually small). When in doubt, use brute force.
Data vs. Logic
Try to shift complexity from code to data. Complex data structures are fairly easy to model and reason about compared to complex logic. Choosing the right datastructure is central, however, try choosing simple datastructures.
Extensibility
Never assume you have the final answer. Design the code such that future developers (including yourself) will be able to plug new functions into the architecture without having to rebuild it.
One True Way
Have a healthy mistrust of ”one true way” approaches to software design or implementations. Embrace multiple languages, extensible systems, and customization hooks.
UI of Least Surprise
Design user interfaces in a familiar way to the intended audience. Holding on to traditions (often) tames the learning curve.
— The list buils down to the famous: K.I.S.S (Keep It Simple, Stupid) —
In case you liked the article and/or are feeling particularly awesome today, I’d appreciate if you would …
However you decide, have a great day :)
