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