docs/unix-phil

changeset 41:13ef7042fa28

some rework in ch01; nicer formating
author meillo@marmaro.de
date Fri, 09 Apr 2010 12:44:08 +0200
parents 422679bdf384
children 303e8f449e77
files unix-phil.ms
diffstat 1 files changed, 41 insertions(+), 36 deletions(-) [+]
line diff
     1.1 --- a/unix-phil.ms	Thu Apr 08 23:11:28 2010 +0200
     1.2 +++ b/unix-phil.ms	Fri Apr 09 12:44:08 2010 +0200
     1.3 @@ -1,13 +1,5 @@
     1.4 -.\".if n .pl 1000i
     1.5  .nr PS 11
     1.6  .nr VS 13
     1.7 -.de XX
     1.8 -.pl 1v
     1.9 -..
    1.10 -.em XX
    1.11 -.\".nr PI 0
    1.12 -.\".if t .nr PD .5v
    1.13 -.\".if n .nr PD 1v
    1.14  .nr lu 0
    1.15  .de CW
    1.16  .nr PQ \\n(.f
    1.17 @@ -35,8 +27,6 @@
    1.18  Knowing and following the guidelines of the Unix Philosophy makes software more valuable.
    1.19  .AE
    1.20  
    1.21 -.\".if t .2C
    1.22 -
    1.23  .FS
    1.24  .ps -1
    1.25  This paper was prepared for the ``Software Analysis'' seminar at University Ulm.
    1.26 @@ -64,6 +54,7 @@
    1.27  %O .CW \s-1http://en.wikipedia.org/w/index.php?title=Unix_philosophy&oldid=351189719
    1.28  .]
    1.29  .QP
    1.30 +.ps -1
    1.31  The \fIUnix philosophy\fP is a set of cultural norms and philosophical
    1.32  approaches to developing software based on the experience of leading
    1.33  developers of the Unix operating system.
    1.34 @@ -111,21 +102,30 @@
    1.35  The Unix Philosophy tells how to design and write good software for Unix.
    1.36  Many concepts described here base on facilities of Unix.
    1.37  Other operating systems may not offer such facilities,
    1.38 -hence it may not be possible to design software is the way of the Unix Philosophy.
    1.39 -
    1.40 -FIXME
    1.41 -
    1.42 -This paper discusses the recommendations of the Unix Philosophy about software design.
    1.43 +hence it may not be possible to design software in the way of the
    1.44 +Unix Philosophy for them.
    1.45  .PP
    1.46 -The here discussed ideas can get applied by any development process.
    1.47 -The Unix Philosophy does recommend how the software development process should look like,
    1.48 -but this shall not be of matter here.
    1.49 -Similar, the question of how to write the code is out of focus.
    1.50 +The Unix Philosophy has an idea of how the process of software development
    1.51 +should look like, but large parts of the philosophy are quite independent
    1.52 +from the development process used.
    1.53 +However, one will soon recognize that some development processes work well
    1.54 +with the ideas of the Unix Philosophy and support them, while others are
    1.55 +at cross-purposes.
    1.56 +Kent Beck's books about Extreme Programming are valuable supplimental
    1.57 +resources.
    1.58  .PP
    1.59 -Before we will have a look at concrete concepts,
    1.60 -we discuss why software design is important
    1.61 -and what problems bad design introduces.
    1.62 -
    1.63 +The question of how to actually write code and how the code should looks
    1.64 +like internally, are out of focus here.
    1.65 +``The Practice of Programming'' by Kernighan and Pike,
    1.66 +.[
    1.67 +%A Brian W. Kernighan
    1.68 +%A Rob Pike
    1.69 +%T The Practice of Programming
    1.70 +%I Addison-Wesley
    1.71 +%D 1999
    1.72 +.]
    1.73 +is a good book that covers this topic.
    1.74 +Its point of view matches to the one of this paper.
    1.75  
    1.76  .NH 1
    1.77  Importance of software design in general
    1.78 @@ -255,7 +255,7 @@
    1.79  Knowledge of using the Unix shell is assumed.
    1.80  .PP
    1.81  Counting the number of files in the current directory:
    1.82 -.DS I 2n
    1.83 +.DS
    1.84  .CW
    1.85  .ps -1
    1.86  ls | wc -l
    1.87 @@ -268,7 +268,7 @@
    1.88  counts the number of lines.
    1.89  .PP
    1.90  Counting the number of files that do not contain ``foo'' in their name:
    1.91 -.DS I 2n
    1.92 +.DS
    1.93  .CW
    1.94  .ps -1
    1.95  ls | grep -v foo | wc -l
    1.96 @@ -279,7 +279,7 @@
    1.97  The rest is the same as in the previous example.
    1.98  .PP
    1.99  Finding the five largest entries in the current directory.
   1.100 -.DS I 2n
   1.101 +.DS
   1.102  .CW
   1.103  .ps -1
   1.104  du -s * | sort -nr | sed 5q
   1.105 @@ -431,7 +431,7 @@
   1.106  .PP
   1.107  A wrapper script for finding the five largest entries in the current directory
   1.108  could look like this:
   1.109 -.DS I 2n
   1.110 +.DS
   1.111  .CW
   1.112  .ps -1
   1.113  #!/bin/sh
   1.114 @@ -441,7 +441,7 @@
   1.115  a professional user would type in directly.
   1.116  Making the program flexible on the number of entries it prints,
   1.117  is easily possible:
   1.118 -.DS I 2n
   1.119 +.DS
   1.120  .CW
   1.121  .ps -1
   1.122  #!/bin/sh
   1.123 @@ -495,6 +495,7 @@
   1.124  %C Amsterdam, The Netherlands
   1.125  .]
   1.126  .QP
   1.127 +.ps -1
   1.128  The hardest single part of building a software system is deciding precisely what to build.
   1.129  No other part of the conceptual work is so difficult as establishing the detailed
   1.130  technical requirements, [...].
   1.131 @@ -644,9 +645,11 @@
   1.132  %T sendmail
   1.133  .]
   1.134  .QP
   1.135 +.ps -1
   1.136  Second, I limited myself to the routing function [...].
   1.137  This was a departure from the dominant thought of the time, [...].
   1.138  .QP
   1.139 +.ps -1
   1.140  Third, the sendmail configuration file was flexible enough to adopt
   1.141  to a rapidly changing world [...].
   1.142  .LP
   1.143 @@ -906,18 +909,19 @@
   1.144  are two design goals that are directly visible in \s-1MH\s0.
   1.145  Gancarz actually presents \s-1MH\s0 as example under the headline
   1.146  ``Making UNIX Do One Thing Well'':
   1.147 +.[
   1.148 +%A Mike Gancarz
   1.149 +%T unix-phil
   1.150 +%P 125
   1.151 +.]
   1.152  .QP
   1.153 +.ps -1
   1.154  [\s-1MH\s0] consists of a series of programs which
   1.155  when combined give the user an enormous ability
   1.156  to manipulate electronic mail messages.
   1.157  A complex application, it shows that not only is it
   1.158  possible to build large applications from smaller
   1.159  components, but also that such designs are actually preferable.
   1.160 -.[
   1.161 -%A Mike Gancarz
   1.162 -%T unix-phil
   1.163 -%P 125
   1.164 -.]
   1.165  .LP
   1.166  The various small programs of \s-1MH\s0 were relatively easy
   1.167  to write, because each of them is small, limited to one function,
   1.168 @@ -1064,7 +1068,11 @@
   1.169  Bruce Borden may have not convinced the management of \s-1RAND\s0
   1.170  to ever create \s-1MH\s0.
   1.171  In Bruce' own words:
   1.172 +.[
   1.173 +%O FIXME
   1.174 +.]
   1.175  .QP
   1.176 +.ps -1
   1.177  [...] but they [Stockton Gaines and Norm Shapiro] were not able
   1.178  to convince anyone that such a system would be fast enough to be usable.
   1.179  I proposed a very short project to prove the basic concepts,
   1.180 @@ -1077,9 +1085,6 @@
   1.181  [...]
   1.182  With these three, I was able to convince people that the structure was viable.
   1.183  This took about three weeks.
   1.184 -.[
   1.185 -%O FIXME
   1.186 -.]
   1.187  
   1.188  .NH 2
   1.189  Problems