comparison unix-phil.ms @ 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
comparison
equal deleted inserted replaced
12:018d5f9a2993 13:c665b9e7bf8a
372 .PP 372 .PP
373 There are two drawbacks of the toolchest approach. 373 There are two drawbacks of the toolchest approach.
374 First, one simple, standardized, unidirectional interface has to be sufficient. 374 First, one simple, standardized, unidirectional interface has to be sufficient.
375 If one feels the need for more ``logic'' than a stream of bytes, 375 If one feels the need for more ``logic'' than a stream of bytes,
376 then a different approach might be of need. 376 then a different approach might be of need.
377 But it is also possible, that he just can not imaging a design where 377 But it is also possible, that he just can not imagine a design where
378 a stream of bytes is sufficient. 378 a stream of bytes is sufficient.
379 By becoming more familiar with the ``Unix style of thinking'', 379 By becoming more familiar with the ``Unix style of thinking'',
380 developers will more often and easier find simple designs where 380 developers will more often and easier find simple designs where
381 a stream of bytes is a sufficient interface. 381 a stream of bytes is a sufficient interface.
382 .PP 382 .PP
532 532
533 .SH 533 .SH
534 Upgrowth and survival of software 534 Upgrowth and survival of software
535 .LP 535 .LP
536 So far it was talked about \fIwriting\fP or \fIbuilding\fP software. 536 So far it was talked about \fIwriting\fP or \fIbuilding\fP software.
537 Although it is just a verb, it does imply a specific view on the work process 537 Although these are just verbs, they do imply a specific view on the work process
538 it describes. 538 they describe.
539 The better verb, however, is to \fIgrow\fP. 539 The better verb, however, is to \fIgrow\fP.
540 .PP 540 .PP
541 Creating software in the sense of the Unix Philosophy is an incremental process. 541 Creating software in the sense of the Unix Philosophy is an incremental process.
542 It starts with a first prototype, which evolves as requirements change. 542 It starts with a first prototype, which evolves as requirements change.
543 A quickly hacked shell script might become a large, sophisticated, 543 A quickly hacked shell script might become a large, sophisticated,
544 compiles program this way. 544 compiled program this way.
545 During its lifetime, it will get extended, rearranged, rebuilt (from scratch). 545 Its lifetime begins with the initial prototype and ends when the software is not used anymore.
546 While being alive it will get extended, rearranged, rebuilt (from scratch).
546 Growing software matches the view that ``software is never finished. It is only released.'' 547 Growing software matches the view that ``software is never finished. It is only released.''
547 .[ 548 .[
548 FIXME 549 %O FIXME
549 gancarz p.26 550 %A Mike Gancarz
550 .] 551 %T The UNIX Philosophy
551 In this view, building a software is an evolutionary process; 552 %P 26
552 it begins with the initial prototype and ends when the software is not used anymore. 553 .]
553 .PP 554 .PP
554 Successful software is used by many for a long time. 555 Software can be seen as being controlled by evolutionary processes.
556 Successful software is software that is used by many for a long time.
555 This implies that the software is needed, useful, and better than alternatives. 557 This implies that the software is needed, useful, and better than alternatives.
556 Darwin talks about: ``The survival of the fittest.'' 558 Darwin talks about: ``The survival of the fittest.''
557 .[ 559 .[
558 FIXME 560 %O FIXME
561 %A Charles Darwin
559 .] 562 .]
560 Transferred to software: The most successful software, is the fittest, 563 Transferred to software: The most successful software, is the fittest,
561 is the one that survives. 564 is the one that survives.
562 The fitness is affected mainly by three properties: 565 (This may be at the level of one creature, or at the level of one species.)
566 The fitness of software is affected mainly by four properties:
563 .IP \(bu 567 .IP \(bu
564 portability of code 568 portability of code
565 .IP \(bu 569 .IP \(bu
566 portability of data 570 portability of data
567 .IP \(bu 571 .IP \(bu
568 range of usability 572 range of usability
569 .IP \(bu 573 .IP \(bu
570 reuseability of parts 574 reuseability of parts
571 .LP 575 .PP
572 foo 576 Portability of code means, using high-level programming languages,
573 577 sticking to the standard,
574 .PP 578 and avoiding optimizations that introduce dependencies on specific hardware.
575 text files 579 Hardware has a much lower lifetime than software.
576 .PP 580 By chaining software to a specific hardware,
577 reuse of independent parts 581 the software's lifetime gets shortened to that of this hardware.
578 582 In contrast, software should be easy to port \(en
579 583 adaption is the key to success.
580 584 .\" cf. practice of prog: ch08
581 585 .PP
582 586 Portability of data is best achieved by avoiding binary representations
583 587 to store data, because binary representations differ from machine to machine.
584 588 Textual represenation is favored.
585 .NH 2 589 Historically, ASCII was the charset of choice.
590 In the future, UTF-8 might be the better choice, however.
591 Important is that it is a plain text representation in a
592 very common charset encoding.
593 Apart from being able to transfer data between machines,
594 readable data has the great advantage, that humans are able
595 to directly edit it with text editors and other tools from the Unix toolchest.
596 .\" gancarz tenet 5
597 .PP
598 A large range of usability ensures good adaption, and thus good survival.
599 It is a special distinction if a software becomes used in fields of action,
600 the original authors did never imagine.
601 Software that solves problems in a general way will likely be used
602 for all kinds of similar problems.
603 Being too specific limits the range of uses.
604 Requirements change through time, thus use cases change or even vanish.
605 A good example in this point is Allman's sendmail.
606 Allman identifies flexibility to be one major reason for sendmail's success:
607 .[
608 %O FIXME
609 %A Allman
610 %T sendmail
611 .]
612 .QP
613 Second, I limited myself to the routing function [...].
614 This was a departure from the dominant thought of the time, [...].
615 .QP
616 Third, the sendmail configuration file was flexible enough to adopt
617 to a rapidly changing world [...].
618 .LP
619 Successful software adopts itself to the changing world.
620 .PP
621 Reuse of parts is even one step further.
622 A software may completely lose its field of action,
623 but parts of which the software is build may be general and independent enough
624 to survive this death.
625 If software is build by combining small independent programs,
626 then there are parts readily available for reuse.
627 Who cares if the large program is a failure,
628 but parts of it become successful instead?
629
630 .SH
586 Results 631 Results
587 .LP 632 .LP
588 The unix phil is an answer to the sw design question 633 The unix phil is an answer to the sw design question
589 .LP 634 .LP
590 tool chains empower the uses of sw 635 tool chains empower the uses of sw