# HG changeset patch
# User meillo@marmaro.de
# Date 1266760373 -3600
# Node ID c665b9e7bf8a5ad2b32d6f62f240e1aadfa143f9
# Parent  018d5f9a2993f82f63cf058992f3165b9f22c233
more about portability and reuse (ch03)

diff -r 018d5f9a2993 -r c665b9e7bf8a unix-phil.ms
--- a/unix-phil.ms	Sat Feb 20 23:54:43 2010 +0100
+++ b/unix-phil.ms	Sun Feb 21 14:52:53 2010 +0100
@@ -374,7 +374,7 @@
 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.
-But it is also possible, that he just can not imaging a design where
+But it is also possible, that he just can not imagine a design where
 a stream of bytes is sufficient.
 By becoming more familiar with the ``Unix style of thinking'',
 developers will more often and easier find simple designs where
@@ -534,32 +534,36 @@
 Upgrowth and survival of software
 .LP
 So far it was talked about \fIwriting\fP or \fIbuilding\fP software.
-Although it is just a verb, it does imply a specific view on the work process
-it describes.
+Although these are just verbs, they do imply a specific view on the work process
+they describe.
 The better verb, however, is to \fIgrow\fP.
 .PP
 Creating software in the sense of the Unix Philosophy is an incremental process.
 It starts with a first prototype, which evolves as requirements change.
 A quickly hacked shell script might become a large, sophisticated,
-compiles program this way.
-During its lifetime, it will get extended, rearranged, rebuilt (from scratch).
+compiled program this way.
+Its lifetime begins with the initial prototype and ends when the software is not used anymore.
+While being alive it will get extended, rearranged, rebuilt (from scratch).
 Growing software matches the view that ``software is never finished. It is only released.''
 .[
-FIXME
-gancarz p.26
+%O FIXME
+%A Mike Gancarz
+%T The UNIX Philosophy
+%P 26
 .]
-In this view, building a software is an evolutionary process;
-it begins with the initial prototype and ends when the software is not used anymore.
 .PP
-Successful software is used by many for a long time.
+Software can be seen as being controlled by evolutionary processes.
+Successful software is software that is used by many for a long time.
 This implies that the software is needed, useful, and better than alternatives.
 Darwin talks about: ``The survival of the fittest.''
 .[
-FIXME
+%O FIXME
+%A Charles Darwin
 .]
 Transferred to software: The most successful software, is the fittest,
 is the one that survives.
-The fitness is affected mainly by three properties:
+(This may be at the level of one creature, or at the level of one species.)
+The fitness of software is affected mainly by four properties:
 .IP \(bu
 portability of code
 .IP \(bu
@@ -568,21 +572,62 @@
 range of usability
 .IP \(bu
 reuseability of parts
+.PP
+Portability of code means, using high-level programming languages,
+sticking to the standard,
+and avoiding optimizations that introduce dependencies on specific hardware.
+Hardware has a much lower lifetime than software.
+By chaining software to a specific hardware,
+the software's lifetime gets shortened to that of this hardware.
+In contrast, software should be easy to port \(en
+adaption is the key to success.
+.\" cf. practice of prog: ch08
+.PP
+Portability of data is best achieved by avoiding binary representations
+to store data, because binary representations differ from machine to machine.
+Textual represenation is favored.
+Historically, ASCII was the charset of choice.
+In the future, UTF-8 might be the better choice, however.
+Important is that it is a plain text representation in a
+very common charset encoding.
+Apart from being able to transfer data between machines,
+readable data has the great advantage, that humans are able
+to directly edit it with text editors and other tools from the Unix toolchest.
+.\" gancarz tenet 5
+.PP
+A large range of usability ensures good adaption, and thus good survival.
+It is a special distinction if a software becomes used in fields of action,
+the original authors did never imagine.
+Software that solves problems in a general way will likely be used
+for all kinds of similar problems.
+Being too specific limits the range of uses.
+Requirements change through time, thus use cases change or even vanish.
+A good example in this point is Allman's sendmail.
+Allman identifies flexibility to be one major reason for sendmail's success:
+.[
+%O FIXME
+%A Allman
+%T sendmail
+.]
+.QP
+Second, I limited myself to the routing function [...].
+This was a departure from the dominant thought of the time, [...].
+.QP
+Third, the sendmail configuration file was flexible enough to adopt
+to a rapidly changing world [...].
 .LP
-foo
+Successful software adopts itself to the changing world.
+.PP
+Reuse of parts is even one step further.
+A software may completely lose its field of action,
+but parts of which the software is build may be general and independent enough
+to survive this death.
+If software is build by combining small independent programs,
+then there are parts readily available for reuse.
+Who cares if the large program is a failure,
+but parts of it become successful instead?
 
-.PP
-text files
-.PP
-reuse of independent parts
-
-
-
-
-
-
-
-.NH 2
+.SH
 Results
 .LP
 The unix phil is an answer to the sw design question