docs/unix-phil

changeset 13:c665b9e7bf8a

more about portability and reuse (ch03)
author meillo@marmaro.de
date Sun, 21 Feb 2010 14:52:53 +0100
parents 018d5f9a2993
children 59305c854751
files unix-phil.ms
diffstat 1 files changed, 70 insertions(+), 25 deletions(-) [+]
line diff
     1.1 --- a/unix-phil.ms	Sat Feb 20 23:54:43 2010 +0100
     1.2 +++ b/unix-phil.ms	Sun Feb 21 14:52:53 2010 +0100
     1.3 @@ -374,7 +374,7 @@
     1.4  First, one simple, standardized, unidirectional interface has to be sufficient.
     1.5  If one feels the need for more ``logic'' than a stream of bytes,
     1.6  then a different approach might be of need.
     1.7 -But it is also possible, that he just can not imaging a design where
     1.8 +But it is also possible, that he just can not imagine a design where
     1.9  a stream of bytes is sufficient.
    1.10  By becoming more familiar with the ``Unix style of thinking'',
    1.11  developers will more often and easier find simple designs where
    1.12 @@ -534,32 +534,36 @@
    1.13  Upgrowth and survival of software
    1.14  .LP
    1.15  So far it was talked about \fIwriting\fP or \fIbuilding\fP software.
    1.16 -Although it is just a verb, it does imply a specific view on the work process
    1.17 -it describes.
    1.18 +Although these are just verbs, they do imply a specific view on the work process
    1.19 +they describe.
    1.20  The better verb, however, is to \fIgrow\fP.
    1.21  .PP
    1.22  Creating software in the sense of the Unix Philosophy is an incremental process.
    1.23  It starts with a first prototype, which evolves as requirements change.
    1.24  A quickly hacked shell script might become a large, sophisticated,
    1.25 -compiles program this way.
    1.26 -During its lifetime, it will get extended, rearranged, rebuilt (from scratch).
    1.27 +compiled program this way.
    1.28 +Its lifetime begins with the initial prototype and ends when the software is not used anymore.
    1.29 +While being alive it will get extended, rearranged, rebuilt (from scratch).
    1.30  Growing software matches the view that ``software is never finished. It is only released.''
    1.31  .[
    1.32 -FIXME
    1.33 -gancarz p.26
    1.34 +%O FIXME
    1.35 +%A Mike Gancarz
    1.36 +%T The UNIX Philosophy
    1.37 +%P 26
    1.38  .]
    1.39 -In this view, building a software is an evolutionary process;
    1.40 -it begins with the initial prototype and ends when the software is not used anymore.
    1.41  .PP
    1.42 -Successful software is used by many for a long time.
    1.43 +Software can be seen as being controlled by evolutionary processes.
    1.44 +Successful software is software that is used by many for a long time.
    1.45  This implies that the software is needed, useful, and better than alternatives.
    1.46  Darwin talks about: ``The survival of the fittest.''
    1.47  .[
    1.48 -FIXME
    1.49 +%O FIXME
    1.50 +%A Charles Darwin
    1.51  .]
    1.52  Transferred to software: The most successful software, is the fittest,
    1.53  is the one that survives.
    1.54 -The fitness is affected mainly by three properties:
    1.55 +(This may be at the level of one creature, or at the level of one species.)
    1.56 +The fitness of software is affected mainly by four properties:
    1.57  .IP \(bu
    1.58  portability of code
    1.59  .IP \(bu
    1.60 @@ -568,21 +572,62 @@
    1.61  range of usability
    1.62  .IP \(bu
    1.63  reuseability of parts
    1.64 +.PP
    1.65 +Portability of code means, using high-level programming languages,
    1.66 +sticking to the standard,
    1.67 +and avoiding optimizations that introduce dependencies on specific hardware.
    1.68 +Hardware has a much lower lifetime than software.
    1.69 +By chaining software to a specific hardware,
    1.70 +the software's lifetime gets shortened to that of this hardware.
    1.71 +In contrast, software should be easy to port \(en
    1.72 +adaption is the key to success.
    1.73 +.\" cf. practice of prog: ch08
    1.74 +.PP
    1.75 +Portability of data is best achieved by avoiding binary representations
    1.76 +to store data, because binary representations differ from machine to machine.
    1.77 +Textual represenation is favored.
    1.78 +Historically, ASCII was the charset of choice.
    1.79 +In the future, UTF-8 might be the better choice, however.
    1.80 +Important is that it is a plain text representation in a
    1.81 +very common charset encoding.
    1.82 +Apart from being able to transfer data between machines,
    1.83 +readable data has the great advantage, that humans are able
    1.84 +to directly edit it with text editors and other tools from the Unix toolchest.
    1.85 +.\" gancarz tenet 5
    1.86 +.PP
    1.87 +A large range of usability ensures good adaption, and thus good survival.
    1.88 +It is a special distinction if a software becomes used in fields of action,
    1.89 +the original authors did never imagine.
    1.90 +Software that solves problems in a general way will likely be used
    1.91 +for all kinds of similar problems.
    1.92 +Being too specific limits the range of uses.
    1.93 +Requirements change through time, thus use cases change or even vanish.
    1.94 +A good example in this point is Allman's sendmail.
    1.95 +Allman identifies flexibility to be one major reason for sendmail's success:
    1.96 +.[
    1.97 +%O FIXME
    1.98 +%A Allman
    1.99 +%T sendmail
   1.100 +.]
   1.101 +.QP
   1.102 +Second, I limited myself to the routing function [...].
   1.103 +This was a departure from the dominant thought of the time, [...].
   1.104 +.QP
   1.105 +Third, the sendmail configuration file was flexible enough to adopt
   1.106 +to a rapidly changing world [...].
   1.107  .LP
   1.108 -foo
   1.109 +Successful software adopts itself to the changing world.
   1.110 +.PP
   1.111 +Reuse of parts is even one step further.
   1.112 +A software may completely lose its field of action,
   1.113 +but parts of which the software is build may be general and independent enough
   1.114 +to survive this death.
   1.115 +If software is build by combining small independent programs,
   1.116 +then there are parts readily available for reuse.
   1.117 +Who cares if the large program is a failure,
   1.118 +but parts of it become successful instead?
   1.119  
   1.120 -.PP
   1.121 -text files
   1.122 -.PP
   1.123 -reuse of independent parts
   1.124 -
   1.125 -
   1.126 -
   1.127 -
   1.128 -
   1.129 -
   1.130 -
   1.131 -.NH 2
   1.132 +.SH
   1.133  Results
   1.134  .LP
   1.135  The unix phil is an answer to the sw design question