# HG changeset patch
# User meillo@marmaro.de
# Date 1270809848 -7200
# Node ID 13ef7042fa289cb29a3ab21a5ccae4f5d130e6f2
# Parent  422679bdf384e88255c15f3b9d17ce5e6f5f489e
some rework in ch01; nicer formating

diff -r 422679bdf384 -r 13ef7042fa28 unix-phil.ms
--- a/unix-phil.ms	Thu Apr 08 23:11:28 2010 +0200
+++ b/unix-phil.ms	Fri Apr 09 12:44:08 2010 +0200
@@ -1,13 +1,5 @@
-.\".if n .pl 1000i
 .nr PS 11
 .nr VS 13
-.de XX
-.pl 1v
-..
-.em XX
-.\".nr PI 0
-.\".if t .nr PD .5v
-.\".if n .nr PD 1v
 .nr lu 0
 .de CW
 .nr PQ \\n(.f
@@ -35,8 +27,6 @@
 Knowing and following the guidelines of the Unix Philosophy makes software more valuable.
 .AE
 
-.\".if t .2C
-
 .FS
 .ps -1
 This paper was prepared for the ``Software Analysis'' seminar at University Ulm.
@@ -64,6 +54,7 @@
 %O .CW \s-1http://en.wikipedia.org/w/index.php?title=Unix_philosophy&oldid=351189719
 .]
 .QP
+.ps -1
 The \fIUnix philosophy\fP is a set of cultural norms and philosophical
 approaches to developing software based on the experience of leading
 developers of the Unix operating system.
@@ -111,21 +102,30 @@
 The Unix Philosophy tells how to design and write good software for Unix.
 Many concepts described here base on facilities of Unix.
 Other operating systems may not offer such facilities,
-hence it may not be possible to design software is the way of the Unix Philosophy.
-
-FIXME
-
-This paper discusses the recommendations of the Unix Philosophy about software design.
+hence it may not be possible to design software in the way of the
+Unix Philosophy for them.
 .PP
-The here discussed ideas can get applied by any development process.
-The Unix Philosophy does recommend how the software development process should look like,
-but this shall not be of matter here.
-Similar, the question of how to write the code is out of focus.
+The Unix Philosophy has an idea of how the process of software development
+should look like, but large parts of the philosophy are quite independent
+from the development process used.
+However, one will soon recognize that some development processes work well
+with the ideas of the Unix Philosophy and support them, while others are
+at cross-purposes.
+Kent Beck's books about Extreme Programming are valuable supplimental
+resources.
 .PP
-Before we will have a look at concrete concepts,
-we discuss why software design is important
-and what problems bad design introduces.
-
+The question of how to actually write code and how the code should looks
+like internally, are out of focus here.
+``The Practice of Programming'' by Kernighan and Pike,
+.[
+%A Brian W. Kernighan
+%A Rob Pike
+%T The Practice of Programming
+%I Addison-Wesley
+%D 1999
+.]
+is a good book that covers this topic.
+Its point of view matches to the one of this paper.
 
 .NH 1
 Importance of software design in general
@@ -255,7 +255,7 @@
 Knowledge of using the Unix shell is assumed.
 .PP
 Counting the number of files in the current directory:
-.DS I 2n
+.DS
 .CW
 .ps -1
 ls | wc -l
@@ -268,7 +268,7 @@
 counts the number of lines.
 .PP
 Counting the number of files that do not contain ``foo'' in their name:
-.DS I 2n
+.DS
 .CW
 .ps -1
 ls | grep -v foo | wc -l
@@ -279,7 +279,7 @@
 The rest is the same as in the previous example.
 .PP
 Finding the five largest entries in the current directory.
-.DS I 2n
+.DS
 .CW
 .ps -1
 du -s * | sort -nr | sed 5q
@@ -431,7 +431,7 @@
 .PP
 A wrapper script for finding the five largest entries in the current directory
 could look like this:
-.DS I 2n
+.DS
 .CW
 .ps -1
 #!/bin/sh
@@ -441,7 +441,7 @@
 a professional user would type in directly.
 Making the program flexible on the number of entries it prints,
 is easily possible:
-.DS I 2n
+.DS
 .CW
 .ps -1
 #!/bin/sh
@@ -495,6 +495,7 @@
 %C Amsterdam, The Netherlands
 .]
 .QP
+.ps -1
 The hardest single part of building a software system is deciding precisely what to build.
 No other part of the conceptual work is so difficult as establishing the detailed
 technical requirements, [...].
@@ -644,9 +645,11 @@
 %T sendmail
 .]
 .QP
+.ps -1
 Second, I limited myself to the routing function [...].
 This was a departure from the dominant thought of the time, [...].
 .QP
+.ps -1
 Third, the sendmail configuration file was flexible enough to adopt
 to a rapidly changing world [...].
 .LP
@@ -906,18 +909,19 @@
 are two design goals that are directly visible in \s-1MH\s0.
 Gancarz actually presents \s-1MH\s0 as example under the headline
 ``Making UNIX Do One Thing Well'':
+.[
+%A Mike Gancarz
+%T unix-phil
+%P 125
+.]
 .QP
+.ps -1
 [\s-1MH\s0] consists of a series of programs which
 when combined give the user an enormous ability
 to manipulate electronic mail messages.
 A complex application, it shows that not only is it
 possible to build large applications from smaller
 components, but also that such designs are actually preferable.
-.[
-%A Mike Gancarz
-%T unix-phil
-%P 125
-.]
 .LP
 The various small programs of \s-1MH\s0 were relatively easy
 to write, because each of them is small, limited to one function,
@@ -1064,7 +1068,11 @@
 Bruce Borden may have not convinced the management of \s-1RAND\s0
 to ever create \s-1MH\s0.
 In Bruce' own words:
+.[
+%O FIXME
+.]
 .QP
+.ps -1
 [...] but they [Stockton Gaines and Norm Shapiro] were not able
 to convince anyone that such a system would be fast enough to be usable.
 I proposed a very short project to prove the basic concepts,
@@ -1077,9 +1085,6 @@
 [...]
 With these three, I was able to convince people that the structure was viable.
 This took about three weeks.
-.[
-%O FIXME
-.]
 
 .NH 2
 Problems