docs/unix-phil
view unix-phil.ms @ 3:aebbe3e76f5e
minor rework
| author | meillo@marmaro.de |
|---|---|
| date | Wed, 10 Feb 2010 13:19:04 +0100 |
| parents | fbd7baf6a61f |
| children | c707b0c5c849 |
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
170 .NH 2
171 what it is
172 .LP
173 definitions by McIlroy, Gancarz, ESR (maybe already in the intro)
174 .LP
175 cf. unix tool chain
176 .LP
177 enabler pipe
179 .NH 2
180 Architecture
181 .LP
182 the most important design decision.
184 the topic here
186 .NH 2
187 Interface architecture
188 .LP
189 standalone vs. tool chain
190 .LP
191 software leverage
192 .LP
193 possiblities
195 .NH 2
196 Results
197 .LP
198 The unix phil is an answer to the sw design question
199 .LP
200 tool chains empower the uses of sw
202 .NH 1
203 Case study: nmh
205 .NH 2
206 History
207 .LP
208 MH, nmh.
209 They are old.
211 .NH 2
212 Contrasts to similar sw
213 .LP
214 vs. Thunderbird, mutt, mailx, pine
215 .LP
216 flexibility, no redundancy, use the shell
218 .NH 2
219 Gains of the design
220 .LP
222 .NH 2
223 Problems
224 .LP
226 .NH 1
227 Case study: uzbl
229 .NH 2
230 History
231 .LP
232 uzbl is young
234 .NH 2
235 Contrasts to similar sw
236 .LP
237 like with nmh
238 .LP
239 addons, plugins, modules
241 .NH 2
242 Gains of the design
243 .LP
245 .NH 2
246 Problems
247 .LP
248 broken web
250 .NH 1
251 Final thoughts
253 .NH 2
254 Quick summary
255 .LP
256 good design
257 .LP
258 unix phil
259 .LP
260 case studies
262 .NH 2
263 Why people should choose
264 .LP
265 Make the right choice!
267 .nr PI .5i
268 .rm ]<
269 .de ]<
270 .LP
271 .de FP
272 .IP \\\\$1.
273 \\..
274 .rm FS FE
275 ..
276 .SH
277 References
278 .[
279 $LIST$
280 .]
281 .wh -1p