# HG changeset patch
# User meillo@marmaro.de
# Date 1266057470 -3600
# Node ID 48f1f3465550c96ab1298721df92097ed1842974
# Parent  c707b0c5c8491ca09e6e593ee26c8f6fdf1a8e63
new content about interfaces and toolchests

diff -r c707b0c5c849 -r 48f1f3465550 unix-phil.ms
--- a/unix-phil.ms	Fri Feb 12 19:30:13 2010 +0100
+++ b/unix-phil.ms	Sat Feb 13 11:37:50 2010 +0100
@@ -169,7 +169,8 @@
 .LP
 The origins of the Unix Philosophy were already introduced.
 This chapter explains the philosophy and shows concrete examples of its application.
-.NH 2
+
+.SH
 Examples
 .LP
 Following are some examples to demonstrate how applied Unix Philosophy feels like.
@@ -215,7 +216,8 @@
 to get the desired output.
 There are also other ways to get the same output.
 It's a user's decision which way to go.
-.NH 2
+
+.SH
 Pipes
 .LP
 The examples show that a lot of tasks on a Unix system
@@ -232,26 +234,93 @@
 that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
 .[
 %T Unix: An Oral History
-%O http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm
+%O .CW \s-1http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm
 .] 
 .PP
 Being able to specify pipelines in an easy way is,
 however, not enough by itself.
-It is only one part.
+It is only one half.
 The other is the design of the programs that are used in the pipeline.
-They have to be of an external shape that allows them to be be used in a pipeline.
+They have to be of an external shape that allows them to be be used in such a way.
+
+.SH
+Interface architecture
+.LP
+Unix is, first of all, simple: Everything is a file.
+Files are sequences of bytes, without any special structure.
+Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
+and write a stream of bytes to ``standard output'' (stdout).
+.PP
+If our files \fIare\fP sequences of bytes,
+and our programs \fIare\fP filters on byte streams,
+then there is exactly one standardized interface.
+Thus it is possible to combine them in any desired way.
+.PP
+Even a handful of small programs will yield a large set of combinations,
+and thus a large set of different functions.
+This is leverage!
+.PP
+If the programs are orthogonal to each other \(en the best case \(en
+then the set of different functions is greatest.
+.PP
+Now, the Unix toolchest is a set of small programs that
+are filters on byte streams.
+They are to a large extend unrelated in their function.
+Hence, the Unix toolchest provides a large set of functions
+that can be accessed by combining the programs in the desired way.
+
+.SH
+Advantages of toolchests
+.LP
+A toolchest is a set of tools.
+Instead of having one big tool for all tasks, one has many small tools,
+each for one task.
+Difficult tasks are solved by combining several of the small, simple tools.
+.PP
+It is easier and less error-prone to write small programs.
+It is also easier and less error-prone to write a large set of small programs,
+than to write one large program with all the functionality included.
+If the small programs are combinable, then they offer even a larger set
+of functions than the single large program.
+Hence, one gets two advantages out of writing small, combinable programs.
+.PP
+There are two drawbacks of the toolchest approach.
+First, one simple, standardized, unidirectional Interface has to be sufficient.
+If one feels the need for more ``logic'' than a stream of bytes,
+then a different approach might be of need, or, more likely,
+he just did not came to a design where a stream of bytes is sufficient.
+The other drawback of a toolchest affects the users.
+A toolchest is often more difficult to use for novices.
+It is neccessary to become familiar with each of the tools,
+to be able to use the right one in a given situation.
+Additinally, one needs to combine the tools in a senseful way on its own.
+This is like a sharp knive \(en it is a powerful tool in the hand of a master,
+but of no good value in the hand of an unskilled.
+.PP
+Luckily, the second drawback can be solved easily by adding wrappers around the single tools.
+Novice users do not need to learn several tools if a professional wraps
+the single commands into a single script.
+Note that the wrapper script still calls the small tools;
+the wrapper script is just like a skin around.
+No complexity is added this way.
+.PP
+A wrapper script for finding the five largest entries in the current directory
+could look like this:
+.DS
+.CW
+#!/bin/sh
+du -s * | sort -nr | sed 5q
+.DE
+The script itself is just a text file that calls the command line
+a professional user would type in directly.
+
+
+
 
 
 
 .NH 2
-Architecture
-.LP
-the most important design decision.
-
-the topic here
-
-.NH 2
-Interface architecture
+foo
 .LP
 standalone vs. tool chain
 .LP