Mercurial > docs > unix-phil
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 |