Unix Programming - Compactness and Orthogonality - The Value of Detachment
We began this book with a reference to Zen: “a special
transmission, outside the scriptures”. This was not mere
exoticism for stylistic effect; the core concepts of Unix have always
had a spare, Zen-like simplicity that continues to shine through the
layers of historical accidents that have accreted around
them. This
quality is reflected in the cornerstone documents of Unix, like
The C Programming Language [Kernighan-Ritchie] and the 1974 CACM paper that introduced
Unix to the world; one of the famous quotes from that paper observes
“...constraint has encouraged not only economy, but also a
certain elegance of design”. That simplicity came from trying
to think not about how much a language or operating system could do,
but of how
little
it could do — not by
carrying assumptions but by starting from zero (what in Zen is called
“beginner's mind” or “empty mind”).
To design for
compactness and
orthogonality,
start from zero. Zen teaches that attachment leads to suffering;
experience with software design teaches that attachment to unnoticed
assumptions leads to non-orthogonality, noncompact designs, and
projects that fail or become maintenance nightmares.
To achieve enlightenment and surcease from suffering, Zen
teaches detachment. The Unix tradition teaches the value of
detachment from the particular, accidental conditions under which a
design problem was posed. Abstract. Simplify. Generalize. Because
we write software to solve problems, we cannot completely detach from
the problems — but it is well worth the mental effort to see how
many preconceptions you can throw away, and whether the design becomes
more compact and
orthogonal as you do that. Possibilities for code reuse often
result.
Jokes about the relationship between Unix and Zen are a live
part of the Unix tradition as well.[45]
This is not an accident.
[an error occurred while processing this directive]
|