annotate @ 3:aebbe3e76f5e

minor rework
date Wed, 10 Feb 2010 13:19:04 +0100
parents fbd7baf6a61f
children c707b0c5c849
rev   line source
meillo@2 1 .\".if n .pl 1000i
meillo@0 2 .de XX
meillo@0 3 .pl 1v
meillo@0 4 ..
meillo@0 5 .em XX
meillo@1 6 .\".nr PI 0
meillo@1 7 .\".if t .nr PD .5v
meillo@1 8 .\".if n .nr PD 1v
meillo@0 9 .nr lu 0
meillo@0 10 .de CW
meillo@0 11 .nr PQ \\n(.f
meillo@0 12 .if t .ft CW
meillo@0 13 .ie \\$1 .if n .ul 999
meillo@0 14 .el .if n .ul 1
meillo@0 15 .if t .if !\\$1 \&\\$1\f\\n(PQ\\$2
meillo@0 16 .if n .if \\n(.$=1 \&\\$1
meillo@0 17 .if n .if \\n(.$>1 \&\\$1\c
meillo@0 18 .if n .if \\n(.$>1 \&\\$2
meillo@0 19 ..
meillo@0 20 .ds [. \ [
meillo@0 21 .ds .] ]
meillo@1 22 .\"----------------------------------------
meillo@0 23 .TL
meillo@0 24 Why the Unix Philosophy matters
meillo@0 25 .AU
meillo@0 26 markus schnalke <>
meillo@0 27 .AB
meillo@1 28 .ti \n(.iu
meillo@2 29 This paper discusses the importance of the Unix Philosophy in software design.
meillo@0 30 Today, few software designers are aware of these concepts,
meillo@3 31 and thus most modern software is limited and does not make use of software leverage.
meillo@0 32 Knowing and following the tenets of the Unix Philosophy makes software more valuable.
meillo@0 33 .AE
meillo@0 34
meillo@2 35 .if t .2C
meillo@2 36
meillo@2 37 .FS
meillo@2 38 .ps -1
meillo@2 39 This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
meillo@2 40 Mentor was professor Schweiggert. 2010-02-05
meillo@2 41 .br
meillo@2 42 You may get this document from my website
meillo@2 43 .CW \s-1
meillo@2 44 .FE
meillo@2 45
meillo@0 46 .NH 1
meillo@0 47 Introduction
meillo@0 48 .LP
meillo@0 49 Building a software is a process from an idea of the purpose of the software
meillo@3 50 to its release.
meillo@0 51 No matter \fIhow\fP the process is run, two things are common:
meillo@0 52 the initial idea and the release.
meillo@3 53 The process inbetween can be of any shape.
meillo@3 54 The the maintainance work after the release is ignored for the moment.
meillo@1 55 .PP
meillo@0 56 The process of building splits mainly in two parts:
meillo@0 57 the planning of what and how to build, and implementing the plan by writing code.
meillo@3 58 This paper focuses on the planning part \(en the designing of the software.
meillo@3 59 .PP
meillo@3 60 Software design is the plan of how the internals and externals of the software should look like,
meillo@3 61 based on the requirements.
meillo@3 62 This paper discusses the recommendations of the Unix Philosphy about software design.
meillo@3 63 .PP
meillo@3 64 The here discussed ideas can get applied by any development process.
meillo@3 65 The Unix Philosphy does recommend how the software development process should look like,
meillo@3 66 but this shall not be of matter here.
meillo@0 67 Similar, the question of how to write the code is out of focus.
meillo@1 68 .PP
meillo@3 69 The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet.
meillo@1 70 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed.
meillo@3 71 It is no limited set of rules, but what people see to be common to typical Unix software.
meillo@1 72 Several people stated their view on the Unix Philosophy.
meillo@1 73 Best known are:
meillo@1 74 .IP \(bu
meillo@1 75 Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
meillo@1 76 .[
meillo@1 77 %A M. D. McIlroy
meillo@1 78 %A E. N. Pinson
meillo@1 79 %A B. A. Taque
meillo@1 80 %T UNIX Time-Sharing System Forward
meillo@1 81 %J The Bell System Technical Journal
meillo@1 82 %D 1978
meillo@1 83 %V 57
meillo@1 84 %N 6
meillo@1 85 %P 1902
meillo@1 86 .]
meillo@1 87 .IP \(bu
meillo@1 88 Mike Gancarz' book ``The UNIX Philosophy''.
meillo@1 89 .[
meillo@1 90 %A Mike Gancarz
meillo@1 91 %T The UNIX Philosophy
meillo@1 92 %D 1995
meillo@1 93 %I Digital Press
meillo@1 94 .]
meillo@1 95 .IP \(bu
meillo@1 96 Eric S. Raymond's book ``The Art of UNIX Programming''.
meillo@1 97 .[
meillo@1 98 %A Eric S. Raymond
meillo@1 99 %T The Art of UNIX Programming
meillo@1 100 %D 2003
meillo@1 101 %I Addison-Wesley
meillo@2 102 %O .CW \s-1
meillo@1 103 .]
meillo@0 104 .LP
meillo@1 105 These different views on the Unix Philosophy have much in common.
meillo@3 106 Especially, the main concepts are similar for all of them.
meillo@1 107 But there are also points on which they differ.
meillo@1 108 This only underlines what the Unix Philosophy is:
meillo@1 109 A retrospective view on the main concepts of Unix software;
meillo@1 110 especially those that were sucessful and unique to Unix.
meillo@1 111 .PP
meillo@1 112 Before we will have a look at concrete concepts,
meillo@1 113 we discuss why software design is important
meillo@1 114 and what problems bad design introduces.
meillo@0 115
meillo@0 116
meillo@0 117 .NH 1
meillo@0 118 Importance of software design
meillo@0 119 .LP
meillo@2 120 Why should we design software at all?
meillo@3 121 It is general knowledge, that a bad plan is better than no plan.
meillo@2 122 As stated earlier in this document, the process of building a software
meillo@2 123 means going from an idea to a release.
meillo@2 124 The development process tells how to get from the idea to the release.
meillo@3 125 Software design is the shape of the built software.
meillo@3 126 This means, that different designs of a software would be different target points to go to.
meillo@3 127 Thus, the design of a software defines the global direction the development goes.
meillo@2 128 .PP
meillo@2 129 It is not enough that the released software offers all requested functionality.
meillo@2 130 It is a misbelief that only function matters.
meillo@2 131 Building a software the first time is only a small part of the overall work.
meillo@2 132 The larger part begins when the software is released for the first time
meillo@2 133 \(en maintainance and extending work..
meillo@2 134 This part soon covers more time than the time which was needed to build the software the first time.
meillo@2 135 .\" cf. brooks?
meillo@2 136 .PP
meillo@2 137 The extendability and maitainability of a software highly depends on its design.
meillo@2 138 Good design eases these tasks much.
meillo@2 139 Bad design, in contrast, requires much more effort for maintaining and
meillo@2 140 extending the software.
meillo@2 141 Developers should, for their own best, have maintainability and extendability in mind
meillo@2 142 when they design the software.
meillo@2 143 .PP
meillo@3 144 Users of the software, in contrast, do not care about maintainability and extendability,
meillo@2 145 at least not directly.
meillo@2 146 They care about usability and flexibility.
meillo@2 147 They want the software to directly solve their problems.
meillo@2 148 They want to be able to to use all its functions if they learned a few of them.
meillo@2 149 They want to use the software for similar tasks.
meillo@2 150 Software is successful if users enjoy using it.
meillo@2 151 Good software design can offer great flexibility and usability.
meillo@2 152 .PP
meillo@2 153 Good design matters for developers \fIand\fP for users.
meillo@2 154 Hence both groups should care about good software design.
meillo@2 155 Bad design limits the software in some way.
meillo@2 156 It may still provide all requested function, but it will have worse quality,
meillo@2 157 and thus require more work effort for developers or frustrate users.
meillo@2 158 .PP
meillo@2 159 Good software design is to the implementation like data structures are to algorithms
meillo@2 160 \(en if you get the former right, then you do not need to care about the latter,
meillo@2 161 it will simply go the right way.
meillo@2 162 .\" cf. ??? ``good data, bad algos''
meillo@0 163
meillo@0 164
meillo@0 165
meillo@0 166
meillo@0 167 .NH 1
meillo@0 168 The Unix Philosophy
meillo@0 169
meillo@0 170 .NH 2
meillo@0 171 what it is
meillo@0 172 .LP
meillo@0 173 definitions by McIlroy, Gancarz, ESR (maybe already in the intro)
meillo@0 174 .LP
meillo@0 175 cf. unix tool chain
meillo@0 176 .LP
meillo@0 177 enabler pipe
meillo@0 178
meillo@0 179 .NH 2
meillo@2 180 Architecture
meillo@2 181 .LP
meillo@2 182 the most important design decision.
meillo@2 183
meillo@2 184 the topic here
meillo@2 185
meillo@2 186 .NH 2
meillo@0 187 Interface architecture
meillo@0 188 .LP
meillo@0 189 standalone vs. tool chain
meillo@0 190 .LP
meillo@0 191 software leverage
meillo@0 192 .LP
meillo@0 193 possiblities
meillo@0 194
meillo@0 195 .NH 2
meillo@0 196 Results
meillo@0 197 .LP
meillo@0 198 The unix phil is an answer to the sw design question
meillo@0 199 .LP
meillo@0 200 tool chains empower the uses of sw
meillo@0 201
meillo@0 202 .NH 1
meillo@0 203 Case study: nmh
meillo@0 204
meillo@0 205 .NH 2
meillo@0 206 History
meillo@0 207 .LP
meillo@0 208 MH, nmh.
meillo@0 209 They are old.
meillo@0 210
meillo@0 211 .NH 2
meillo@0 212 Contrasts to similar sw
meillo@0 213 .LP
meillo@0 214 vs. Thunderbird, mutt, mailx, pine
meillo@0 215 .LP
meillo@0 216 flexibility, no redundancy, use the shell
meillo@0 217
meillo@0 218 .NH 2
meillo@0 219 Gains of the design
meillo@0 220 .LP
meillo@0 221
meillo@0 222 .NH 2
meillo@0 223 Problems
meillo@0 224 .LP
meillo@0 225
meillo@0 226 .NH 1
meillo@0 227 Case study: uzbl
meillo@0 228
meillo@0 229 .NH 2
meillo@0 230 History
meillo@0 231 .LP
meillo@0 232 uzbl is young
meillo@0 233
meillo@0 234 .NH 2
meillo@0 235 Contrasts to similar sw
meillo@0 236 .LP
meillo@0 237 like with nmh
meillo@0 238 .LP
meillo@0 239 addons, plugins, modules
meillo@0 240
meillo@0 241 .NH 2
meillo@0 242 Gains of the design
meillo@0 243 .LP
meillo@0 244
meillo@0 245 .NH 2
meillo@0 246 Problems
meillo@0 247 .LP
meillo@0 248 broken web
meillo@0 249
meillo@0 250 .NH 1
meillo@0 251 Final thoughts
meillo@0 252
meillo@0 253 .NH 2
meillo@0 254 Quick summary
meillo@0 255 .LP
meillo@0 256 good design
meillo@0 257 .LP
meillo@0 258 unix phil
meillo@0 259 .LP
meillo@0 260 case studies
meillo@0 261
meillo@0 262 .NH 2
meillo@0 263 Why people should choose
meillo@0 264 .LP
meillo@0 265 Make the right choice!
meillo@0 266
meillo@0 267 .nr PI .5i
meillo@0 268 .rm ]<
meillo@0 269 .de ]<
meillo@0 270 .LP
meillo@0 271 .de FP
meillo@0 272 .IP \\\\$1.
meillo@0 273 \\..
meillo@0 274 .rm FS FE
meillo@0 275 ..
meillo@0 276 .SH
meillo@0 277 References
meillo@0 278 .[
meillo@0 279 $LIST$
meillo@0 280 .]
meillo@0 281 .wh -1p