docs/unix-phil
view unix-phil.ms @ 5:48f1f3465550
new content about interfaces and toolchests
| author | meillo@marmaro.de |
|---|---|
| date | Sat, 13 Feb 2010 11:37:50 +0100 |
| parents | c707b0c5c849 |
| children | a6b837d822b7 |
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 make use of 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 its release.
51 No matter \fIhow\fP the process is run, two things are common:
52 the initial idea and the release.
53 The process inbetween can be of any shape.
54 The the maintainance work after the release is ignored 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 part \(en the designing of the software.
59 .PP
60 Software design is the plan of how the internals and externals of the software should look like,
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.
67 Similar, the question of how to write the code is out of focus.
68 .PP
69 The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet.
70 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed.
71 It is no limited set of rules, but what people see to be common to typical Unix software.
72 Several people stated their view on the Unix Philosophy.
73 Best known are:
74 .IP \(bu
75 Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
76 .[
77 %A M. D. McIlroy
78 %A E. N. Pinson
79 %A B. A. Taque
80 %T UNIX Time-Sharing System Forward
81 %J The Bell System Technical Journal
82 %D 1978
83 %V 57
84 %N 6
85 %P 1902
86 .]
87 .IP \(bu
88 Mike Gancarz' book ``The UNIX Philosophy''.
89 .[
90 %A Mike Gancarz
91 %T The UNIX Philosophy
92 %D 1995
93 %I Digital Press
94 .]
95 .IP \(bu
96 Eric S. Raymond's book ``The Art of UNIX Programming''.
97 .[
98 %A Eric S. Raymond
99 %T The Art of UNIX Programming
100 %D 2003
101 %I Addison-Wesley
102 %O .CW \s-1http://www.faqs.org/docs/artu/
103 .]
104 .LP
105 These different views on the Unix Philosophy have much in common.
106 Especially, the main concepts are similar for all of them.
107 But there are also points on which they differ.
108 This only underlines what the Unix Philosophy is:
109 A retrospective view on the main concepts of Unix software;
110 especially those that were sucessful and unique to Unix.
111 .PP
112 Before we will have a look at concrete concepts,
113 we discuss why software design is important
114 and what problems bad design introduces.
117 .NH 1
118 Importance of software design
119 .LP
120 Why should we design software at all?
121 It is general knowledge, that a bad plan is better than no plan.
122 As stated earlier in this document, the process of building a software
123 means going from an idea to a release.
124 The development process tells how to get from the idea to the release.
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.
128 .PP
129 It is not enough that the released software offers all requested functionality.
130 It is a misbelief that only function matters.
131 Building a software the first time is only a small part of the overall work.
132 The larger part begins when the software is released for the first time
133 \(en maintainance and extending work..
134 This part soon covers more time than the time which was needed to build the software the first time.
135 .\" cf. brooks?
136 .PP
137 The extendability and maitainability of a software highly depends on its design.
138 Good design eases these tasks much.
139 Bad design, in contrast, requires much more effort for maintaining and
140 extending the software.
141 Developers should, for their own best, have maintainability and extendability in mind
142 when they design the software.
143 .PP
144 Users of the software, in contrast, do not care about maintainability and extendability,
145 at least not directly.
146 They care about usability and flexibility.
147 They want the software to directly solve their problems.
148 They want to be able to to use all its functions if they learned a few of them.
149 They want to use the software for similar tasks.
150 Software is successful if users enjoy using it.
151 Good software design can offer great flexibility and usability.
152 .PP
153 Good design matters for developers \fIand\fP for users.
154 Hence both groups should care about good software design.
155 Bad design limits the software in some way.
156 It may still provide all requested function, but it will have worse quality,
157 and thus require more work effort for developers or frustrate users.
158 .PP
159 Good software design is to the implementation like data structures are to algorithms
160 \(en if you get the former right, then you do not need to care about the latter,
161 it will simply go the right way.
162 .\" cf. ??? ``good data, bad algos''
167 .NH 1
168 The Unix Philosophy
169 .LP
170 The origins of the Unix Philosophy were already introduced.
171 This chapter explains the philosophy and shows concrete examples of its application.
173 .SH
174 Examples
175 .LP
176 Following are some examples to demonstrate how applied Unix Philosophy feels like.
177 Knowledge of using the Unix shell is assumed.
178 .PP
179 Counting the number of files in the current directory:
180 .DS
181 .CW
182 ls | wc -l
183 .DE
184 The
185 .CW ls
186 command lists all files in the current directory, one per line,
187 and
188 .CW "wc -l
189 counts how many lines they are.
190 .PP
191 Counting all files that do not contain ``foo'' in their name:
192 .DS
193 .CW
194 ls | grep -v foo | wc -l
195 .DE
196 Here, the list of files is filtered by
197 .CW grep
198 to remove all that contain ``foo''.
199 The rest is the same as in the previous example.
200 .PP
201 Finding the five largest entries in the current directory.
202 .DS
203 .CW
204 du -s * | sort -nr | sed 5q
205 .DE
206 .CW "du -s *
207 returns the recursively summed sizes of all files
208 -- no matter if they are regular files or directories.
209 .CW "sort -nr
210 sorts the list numerically in reverse order.
211 Finally,
212 .CW "sed 5q
213 quits after it has printed the fifth line.
214 .PP
215 The presented command lines are examples of what Unix people would use
216 to get the desired output.
217 There are also other ways to get the same output.
218 It's a user's decision which way to go.
220 .SH
221 Pipes
222 .LP
223 The examples show that a lot of tasks on a Unix system
224 are accomplished by combining several small programs.
225 The connection between the single programs is denoted by the pipe operator `|'.
226 .PP
227 Pipes, and their extensive and easy use, are one of the great
228 achievements of the Unix system.
229 Pipes between programs have been possible in earlier operating systems,
230 but it has never been a so central part of the concept.
231 When, in the early seventies, Doug McIlroy introduced pipes for the
232 Unix system,
233 ``it was this concept and notation for linking several programs together
234 that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
235 .[
236 %T Unix: An Oral History
237 %O .CW \s-1http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm
238 .]
239 .PP
240 Being able to specify pipelines in an easy way is,
241 however, not enough by itself.
242 It is only one half.
243 The other is the design of the programs that are used in the pipeline.
244 They have to be of an external shape that allows them to be be used in such a way.
246 .SH
247 Interface architecture
248 .LP
249 Unix is, first of all, simple: Everything is a file.
250 Files are sequences of bytes, without any special structure.
251 Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
252 and write a stream of bytes to ``standard output'' (stdout).
253 .PP
254 If our files \fIare\fP sequences of bytes,
255 and our programs \fIare\fP filters on byte streams,
256 then there is exactly one standardized interface.
257 Thus it is possible to combine them in any desired way.
258 .PP
259 Even a handful of small programs will yield a large set of combinations,
260 and thus a large set of different functions.
261 This is leverage!
262 .PP
263 If the programs are orthogonal to each other \(en the best case \(en
264 then the set of different functions is greatest.
265 .PP
266 Now, the Unix toolchest is a set of small programs that
267 are filters on byte streams.
268 They are to a large extend unrelated in their function.
269 Hence, the Unix toolchest provides a large set of functions
270 that can be accessed by combining the programs in the desired way.
272 .SH
273 Advantages of toolchests
274 .LP
275 A toolchest is a set of tools.
276 Instead of having one big tool for all tasks, one has many small tools,
277 each for one task.
278 Difficult tasks are solved by combining several of the small, simple tools.
279 .PP
280 It is easier and less error-prone to write small programs.
281 It is also easier and less error-prone to write a large set of small programs,
282 than to write one large program with all the functionality included.
283 If the small programs are combinable, then they offer even a larger set
284 of functions than the single large program.
285 Hence, one gets two advantages out of writing small, combinable programs.
286 .PP
287 There are two drawbacks of the toolchest approach.
288 First, one simple, standardized, unidirectional Interface has to be sufficient.
289 If one feels the need for more ``logic'' than a stream of bytes,
290 then a different approach might be of need, or, more likely,
291 he just did not came to a design where a stream of bytes is sufficient.
292 The other drawback of a toolchest affects the users.
293 A toolchest is often more difficult to use for novices.
294 It is neccessary to become familiar with each of the tools,
295 to be able to use the right one in a given situation.
296 Additinally, one needs to combine the tools in a senseful way on its own.
297 This is like a sharp knive \(en it is a powerful tool in the hand of a master,
298 but of no good value in the hand of an unskilled.
299 .PP
300 Luckily, the second drawback can be solved easily by adding wrappers around the single tools.
301 Novice users do not need to learn several tools if a professional wraps
302 the single commands into a single script.
303 Note that the wrapper script still calls the small tools;
304 the wrapper script is just like a skin around.
305 No complexity is added this way.
306 .PP
307 A wrapper script for finding the five largest entries in the current directory
308 could look like this:
309 .DS
310 .CW
311 #!/bin/sh
312 du -s * | sort -nr | sed 5q
313 .DE
314 The script itself is just a text file that calls the command line
315 a professional user would type in directly.
322 .NH 2
323 foo
324 .LP
325 standalone vs. tool chain
326 .LP
327 software leverage
328 .LP
329 possiblities
331 .NH 2
332 Results
333 .LP
334 The unix phil is an answer to the sw design question
335 .LP
336 tool chains empower the uses of sw
338 .NH 1
339 Case study: nmh
341 .NH 2
342 History
343 .LP
344 MH, nmh.
345 They are old.
347 .NH 2
348 Contrasts to similar sw
349 .LP
350 vs. Thunderbird, mutt, mailx, pine
351 .LP
352 flexibility, no redundancy, use the shell
354 .NH 2
355 Gains of the design
356 .LP
358 .NH 2
359 Problems
360 .LP
362 .NH 1
363 Case study: uzbl
365 .NH 2
366 History
367 .LP
368 uzbl is young
370 .NH 2
371 Contrasts to similar sw
372 .LP
373 like with nmh
374 .LP
375 addons, plugins, modules
377 .NH 2
378 Gains of the design
379 .LP
381 .NH 2
382 Problems
383 .LP
384 broken web
386 .NH 1
387 Final thoughts
389 .NH 2
390 Quick summary
391 .LP
392 good design
393 .LP
394 unix phil
395 .LP
396 case studies
398 .NH 2
399 Why people should choose
400 .LP
401 Make the right choice!
403 .nr PI .5i
404 .rm ]<
405 .de ]<
406 .LP
407 .de FP
408 .IP \\\\$1.
409 \\..
410 .rm FS FE
411 ..
412 .SH
413 References
414 .[
415 $LIST$
416 .]
417 .wh -1p