Mercurial > docs > unix-phil

comparison unix-phil.ms @ 3:aebbe3e76f5e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
minor rework
author meillo@marmaro.de
date Wed, 10 Feb 2010 13:19:04 +0100
parents fbd7baf6a61f
children c707b0c5c849
comparison
equal deleted inserted replaced
2:fbd7baf6a61f 3:aebbe3e76f5e
26 markus schnalke <meillo@marmaro.de> 26 markus schnalke <meillo@marmaro.de>
27 .AB 27 .AB
28 .ti \n(.iu 28 .ti \n(.iu
29 This paper discusses the importance of the Unix Philosophy in software design. 29 This paper discusses the importance of the Unix Philosophy in software design.
30 Today, few software designers are aware of these concepts, 30 Today, few software designers are aware of these concepts,
31 and thus most modern software is limited and does not use software leverage. 31 and thus most modern software is limited and does not make use of software leverage.
32 Knowing and following the tenets of the Unix Philosophy makes software more valuable. 32 Knowing and following the tenets of the Unix Philosophy makes software more valuable.
33 .AE 33 .AE
34 34
35 .if t .2C 35 .if t .2C
36 36
45 45
46 .NH 1 46 .NH 1
47 Introduction 47 Introduction
48 .LP 48 .LP
49 Building a software is a process from an idea of the purpose of the software 49 Building a software is a process from an idea of the purpose of the software
50 to the finished program. 50 to its release.
51 No matter \fIhow\fP the process is run, two things are common: 51 No matter \fIhow\fP the process is run, two things are common:
52 the initial idea and the release. 52 the initial idea and the release.
53 But the the process inbetween can be of any shape. 53 The process inbetween can be of any shape.
54 The time of release and the maintainance work after the release are ignored here, for the moment. 54 The the maintainance work after the release is ignored for the moment.
55 .PP 55 .PP
56 The process of building splits mainly in two parts: 56 The process of building splits mainly in two parts:
57 the planning of what and how to build, and implementing the plan by writing code. 57 the planning of what and how to build, and implementing the plan by writing code.
58 This paper focuses on the planning \(en the design \(en of software. 58 This paper focuses on the planning part \(en the designing of the software.
59 The here discussed ideas may be applied to any development process. 59 .PP
60 Though the Unix Philosphy does recommend how the software development process should look like, 60 Software design is the plan of how the internals and externals of the software should look like,
61 this shall not be of matter here. 61 based on the requirements.
62 This paper discusses the recommendations of the Unix Philosphy about software design.
63 .PP
64 The here discussed ideas can get applied by any development process.
65 The Unix Philosphy does recommend how the software development process should look like,
66 but this shall not be of matter here.
62 Similar, the question of how to write the code is out of focus. 67 Similar, the question of how to write the code is out of focus.
63 .PP 68 .PP
64 This paper discusses the connection between software design and the Unix Philosphy. 69 The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet.
65 Software design is the work between the requirements and the plan of how the internals and externals
66 of the software should look like.
67 However, the term ``Unix Philosophy'' was used but not explained yet.
68 .PP
69 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed. 70 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed.
70 It is no limited set of rules, but what people see what is common to typical Unix software. 71 It is no limited set of rules, but what people see to be common to typical Unix software.
71 Several people stated their view on the Unix Philosophy. 72 Several people stated their view on the Unix Philosophy.
72 Best known are: 73 Best known are:
73 .IP \(bu 74 .IP \(bu
74 Doug McIlroy's summary: ``Write programs that do one thing and do it well.'' 75 Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
75 .[ 76 .[
100 %I Addison-Wesley 101 %I Addison-Wesley
101 %O .CW \s-1http://www.faqs.org/docs/artu/ 102 %O .CW \s-1http://www.faqs.org/docs/artu/
102 .] 103 .]
103 .LP 104 .LP
104 These different views on the Unix Philosophy have much in common. 105 These different views on the Unix Philosophy have much in common.
105 Especially, the main concepts are seen by all of them. 106 Especially, the main concepts are similar for all of them.
106 But there are also points on which they differ. 107 But there are also points on which they differ.
107 This only underlines what the Unix Philosophy is: 108 This only underlines what the Unix Philosophy is:
108 A retrospective view on the main concepts of Unix software; 109 A retrospective view on the main concepts of Unix software;
109 especially those that were sucessful and unique to Unix. 110 especially those that were sucessful and unique to Unix.
110 .PP 111 .PP
115 116
116 .NH 1 117 .NH 1
117 Importance of software design 118 Importance of software design
118 .LP 119 .LP
119 Why should we design software at all? 120 Why should we design software at all?
120 It should be general knowledge, that a bad plan is better than no plan. 121 It is general knowledge, that a bad plan is better than no plan.
121 As stated earlier in this document, the process of building a software 122 As stated earlier in this document, the process of building a software
122 means going from an idea to a release. 123 means going from an idea to a release.
123 The development process tells how to get from the idea to the release. 124 The development process tells how to get from the idea to the release.
124 Software design tells how the built software should look like. 125 Software design is the shape of the built software.
126 This means, that different designs of a software would be different target points to go to.
127 Thus, the design of a software defines the global direction the development goes.
125 .PP 128 .PP
126 It is not enough that the released software offers all requested functionality. 129 It is not enough that the released software offers all requested functionality.
127 It is a misbelief that only function matters. 130 It is a misbelief that only function matters.
128 Building a software the first time is only a small part of the overall work. 131 Building a software the first time is only a small part of the overall work.
129 The larger part begins when the software is released for the first time 132 The larger part begins when the software is released for the first time
136 Bad design, in contrast, requires much more effort for maintaining and 139 Bad design, in contrast, requires much more effort for maintaining and
137 extending the software. 140 extending the software.
138 Developers should, for their own best, have maintainability and extendability in mind 141 Developers should, for their own best, have maintainability and extendability in mind
139 when they design the software. 142 when they design the software.
140 .PP 143 .PP
141 Users of the software do not care about maintainability and extendability, 144 Users of the software, in contrast, do not care about maintainability and extendability,
142 at least not directly. 145 at least not directly.
143 They care about usability and flexibility. 146 They care about usability and flexibility.
144 They want the software to directly solve their problems. 147 They want the software to directly solve their problems.
145 They want to be able to to use all its functions if they learned a few of them. 148 They want to be able to to use all its functions if they learned a few of them.
146 They want to use the software for similar tasks. 149 They want to use the software for similar tasks.