Applying the Unix Philosophy

Applying the Unix Philosophy
Prev	Chapter 1. Philosophy	Next

These philosophical principles aren't just vague generalities. In the Unix world they come straight from experience and lead to specific prescriptions, some of which we've already developed above. Here's a by no means exhaustive list:

Everything that can be a source- and destination-independent filter should be one.
Data streams should if at all possible be textual (so they can be viewed and filtered with standard tools).
Database layouts and application protocols should if at all possible be textual (human-readable and human-editable).
Complex front ends (user interfaces) should be cleanly separated from complex back ends.
Whenever possible, prototype in an interpreted language before coding C.
Mixing languages is better than writing everything in one, if and only if using only that one is likely to overcomplicate the program.
Be generous in what you accept, rigorous in what you emit.
When filtering, never throw away information you don't need to.
Small is beautiful. Write programs that do as little as is consistent with getting the job done.

We'll see the Unix design rules, and the prescriptions that derive from them, applied over and over again in the remainder of this book. Unsurprisingly, they tend to converge with the very best practices from software engineering in other traditions.^[12]

^[12]One notable example is Butler Lampson's Hints for Computer System Design [Lampson], which I discovered late in the preparation of this book. It not only expresses a number of Unix dicta in forms that were clearly discovered independently, but uses many of the same tag lines to illustrate them.

Prev	Up	Next
The Unix Philosophy in One Lesson	Home	Attitude Matters Too