%% Mostly from Wikipedia' "Unix Philosophy" page
%% ( https://en.wikipedia.org/wiki/Unix_philosophy )
%
Make each program do one thing well. To do a new job, build afresh
rather than complicate old programs by adding new "features".
		-- Doug McIlroy, "Bell System Technical Journal,
                   Vol. 57, No. 6", July-August 1978"    
%
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.
		-- Doug McIlroy, "Bell System Technical Journal,
                   Vol. 57, No. 6", July-August 1978"    
%
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.
		-- Doug McIlroy, "Bell System Technical Journal,
                   Vol. 57, No. 6", July-August 1978"    
%
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.
		-- Doug McIlroy, "Bell System Technical Journal,
                   Vol. 57, No. 6", July-August 1978"    
%
Write programs that do one thing and do it well.
		-- Peter H. Salus, "A Quarter-Century of Unix", 1994
%
Write programs to work together.
		-- Peter H. Salus, "A Quarter-Century of Unix", 1994
%
Write programs to handle text streams, because that is a universal
interface.
		-- Peter H. Salus, "A Quarter-Century of Unix", 1994
%
Make it easy to write, test, and run programs.
		-- Dennis M. Ritchie and Ken Thompson,
		   "The UNIX Time-Sharing System", 1974
%
Interactive use instead of batch processing.
		-- Dennis M. Ritchie and Ken Thompson,
		   "The UNIX Time-Sharing System", 1974
%
Economy and elegance of design due to size constraints
("salvation through suffering").
		-- Dennis M. Ritchie and Ken Thompson,
		   "The UNIX Time-Sharing System", 1974
%
Self-supporting system: all Unix software is maintained under Unix.
		-- Dennis M. Ritchie and Ken Thompson,
		   "The UNIX Time-Sharing System", 1974
%
The whole philosophy of UNIX seems to stay out of assembler.
		-- Michael Sean Mahoney
%
Even though the UNIX system introduces a number of innovative programs
and techniques, no single program or idea makes it work well. Instead,
what makes it effective is the approach to programming, a philosophy of
using the computer. Although that philosophy can't be written down in a
single sentence, at its heart is the idea that the power of a system
comes more from the relationships among programs than from the programs
themselves. Many UNIX programs do quite trivial things in isolation,
but, combined with other programs, become general and useful tools.
		-- Brian Kernighan and Rob Pike,
		   "The UNIX Programming Environment", 1984
%
Much of the power of the UNIX operating system comes from a style of
program design that makes programs easy to use and, more important, easy
to combine with other programs. This style has been called the use of
software tools, and depends more on how the programs fit into the
programming environment and how they can be used with other programs
than on how they are designed internally. [...] This style was based on
the use of tools: using programs separately or in combination to get a
job done, rather than doing it by hand, by monolithic self-sufficient
subsystems, or by special-purpose, one-time programs.
		-- Brian Kernighan and Rob Pike,
		   "Program Design in the UNIX Environment", 1984
%
The design of cat is typical of most UNIX programs: it implements one
simple but general function that can be used in many different
applications (including many not envisioned by the original author).
Other commands are used for other functions. For example, there are
separate commands for file system tasks like renaming files, deleting
them, or telling how big they are. Other systems instead lump these into
a single "file system" command with an internal structure and command
language of its own. (The PIP file copy program found on operating
systems like CP/M or RSX-11 is an example.) That approach is not
necessarily worse or better, but it is certainly against the UNIX
philosophy.
		-- Brian Kernighan and Rob Pike,
		   "Program Design in the UNIX Environment", 1984
%
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.
		-- Doug McIlroy
%
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
%
Adoring admirers have fed Linux goodies to a disheartening state of
obesity.
		-- Doug McIlroy
%
Everything was small... and my heart sinks for Linux when I see the size
of it. [...] The manual page, which really used to be a manual page, is
now a small volume, with a thousand options... We used to sit around in
the Unix Room saying, 'What can we throw out? Why is there this option?'
It's often because there is some deficiency in the basic design - you
didn't really hit the right design point. Instead of adding an option,
think about what was forcing you to add that option.
		-- Doug McIlroy
%
Rule #1: Build modular programs
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #2: Write readable programs
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #3: Use composition
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #4: Separate mechanisms from policy
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #5: Write simple programs
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #6: Write small programs
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #7: Write transparent programs
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #8: Write robust programs
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #9: Make data complicated when required, not the program
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #10: Build on potential users' expected knowledge
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #11: Avoid unnecessary output
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #12: Write programs which fail in a way that is easy to diagnose
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #13: Value developer time over machine time
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #14: Write abstract programs that generate code instead of writing
code by hand
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #15: Prototype software before polishing it
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #16: Write flexible and open programs
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Rule #17: Make the program and protocols extensible.
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
The Unix philosophy can be summarized as the KISS Principle
("Keep it Simple, Stupid").
		-- Eric S. Raymond, "The Art of Unix Programming", 2003
%
Precept #1: Small is beautiful.
		-- Mike Gancarz, "The UNIX Philosophy", 1994
%
Precept #2: Make each program do one thing well.
		-- Mike Gancarz, "The UNIX Philosophy", 1994
%
Precept #3: Build a prototype as soon as possible.
		-- Mike Gancarz, "The UNIX Philosophy", 1994
%
Precept #4: Choose portability over efficiency.
		-- Mike Gancarz, "The UNIX Philosophy", 1994
%
Precept #5: Store data in flat text files.
		-- Mike Gancarz, "The UNIX Philosophy", 1994
%
Precept #6: Use software leverage to your advantage.
		-- Mike Gancarz, "The UNIX Philosophy", 1994
%
Precept #7: Use shell scripts to increase leverage and portability.
		-- Mike Gancarz, "The UNIX Philosophy", 1994
%
Precept #8: Avoid captive user interfaces.
		-- Mike Gancarz, "The UNIX Philosophy", 1994
%
Precept #9: Make every program a filter.
		-- Mike Gancarz, "The UNIX Philosophy", 1994
%
Worse is better!
		-- Richard P. Gabriel
%
UNIX System Philosophy Simply Stated

    For as long as you are writing programs on a UNIX system you should
keep this motto hanging on your wall:

    ***********************************
    *                                 *
    *   Build on the work of others   *
    *                                 *
    ***********************************

    Unlike computer environments where each new project is like starting
with a blank canvas, on a UNIX system a good percentage of any program-
ming effort is lying there in bins, and lbins, and /usr/bins, not to
mention etc, waiting to be used.
    The features of the UNIX system (pipes, processes, and the file
system) contribute to this reusability, as does the history of sharing
and contributing that extends back to 1969. You risk missing the
essential nature of the UNIX system if you don't put this to work.
		-- UNIX System V Release 3.2 Programmer's Guide, Vol. 1
%
