docs/unix-phil
view unix-phil-slides.ms @ 26:b368ff5cdb5f
added literature; some minor rework
| author | meillo@marmaro.de |
|---|---|
| date | Sun, 07 Mar 2010 22:40:05 +0100 |
| parents | e6ac51dc18bf |
| children | e8adc3571e8c |
line source
1 .TL
2 \fR\s-6Why\s0\fP
3 .br
4 the Unix Philosophy
5 .br
6 .vs -4
7 \fR\s-6still matters\s0\fP
8 .AU
9 .ft R
10 .sp 1.2i
11 .ps 11
12 markus schnalke <meillo@marmaro.de>
15 .S "goals of this talk
16 .I
17 introduce the Unix Phil
18 .I
19 show that most modern software is crap
20 .I
21 explain why the Unix Phil leads to better software
22 .I
23 convince you that good software is of matter
24 .sp 2
25 .I
26 make you think
29 .S "roadmap
30 .I
31 Historical background
32 .I
33 What is the Unix Philosophy?
34 .I
35 The Unix Phil after Gancarz
36 .I
37 Discussion on real world examples
38 .I
39 The Unix Phil is more than software dev guidelines
43 .S "me and the UP
44 .LP
45 first contact: through the suckless project
46 .LP
47 ``cat -v Considered Harmful''
48 .LP
49 ``The Unix and the Echo''
50 .LP
51 ``The Unix Programming Environment''
52 .sp 1
53 .LP
54 better understanding through digging in the past
60 .P "historical background
65 .S "historical background
66 .I
67 the late 60s and early 70s
68 .I
69 operating systems are complex
70 .I
71 MULTICS just failed
72 .I
73 Brooks' ``The Mythical Man-Month''
74 .I
75 a lot of different hardware
76 .I
77 limited computing power
78 .I
79 textual input and output (line printers)
82 .S "everything is a file
83 .LP
84 is the(?) basic concept in Unix (and even more in Plan9)
85 .LP
86 made simple operating systems possible
87 .LP
88 it is not covered by the Unix Phil; the Unix Phil is on a different level
89 .sp 2
90 .LP
91 Unix is mainly two things:
92 .I
93 an operating system (system calls)
94 .I
95 a toolchest (coreutils)
99 .P "What is the Unix Phil
103 .S "What is the Unix Phil *itself*?
104 .LP
105 ``The Unix philosophy is a set of cultural norms and philosophical
106 approaches to developing software based on the experience of
107 leading developers of the Unix operating system.''
108 (wikipedia)
109 .sp 2
110 .LP
111 How the inventors of Unix write software.
112 .LP
113 Common things of classic Unix tools.
114 .sp 2
115 .LP
116 difficult to define
119 .S "Unix Phil vs. SW dev processes
120 .LP
121 the Unix Phil
122 .I
123 much: *what* to program
124 .I
125 few: *how* to program
127 .LP
128 Software developments processes:
129 .I
130 few: *what* to program
131 .I
132 much: *how* to program
134 .sp 2
135 .LP
136 Extreme Programming is like the Unix Phil
137 but with more *how* than *what*,
138 and with formalisms
144 .S "What is the Unix Phil?
145 .I
146 Doug McIlroy (1978)
147 .I
148 Mike Gancarz: ``The Unix Philosophy'' (1994)
149 .I
150 Eric S. Raymond: ``The Art of Unix Programming'' (2003)
151 .sp 2
152 .I
153 Richard Gabriel: ``Worse is Better'' (1989)
156 .S "Doug McIlroy
157 .LP
158 This is the Unix philosophy:
159 .I
160 Write programs that do one thing and do it well.
161 .I
162 Write programs to work together.
163 .I
164 Write programs to handle text streams, because that is a universal interface.
167 .S "Mike Gancarz: ``The Unix Philosophy''
168 .I
169 Small is beautiful.
170 .I
171 Make each program do one thing well.
172 .I
173 Build a prototype as soon as possible.
174 .I
175 Choose portability over efficiency.
176 .I
177 Store data in flat text files.
178 .I
179 Use software leverage to your advantage.
180 .I
181 Use shell scripts to increase leverage and portability.
182 .I
183 Avoid captive user interfaces.
184 .I
185 Make every program a filter.
186 .sp 1
187 .LP
188 plus ten lesser tenets
193 .P "The Unix Phil after Gancarz
197 .S "Small is beautiful
198 .I
199 small software is easier to understand, write, maintain
200 .I
201 less lines of code contain less bugs
202 .I
203 monsters are large
206 .S "Make each program do one thing well
207 .I
208 programs with many functions are large
209 .I
210 one thing is easier to understand
211 .I
212 often straight forward to implement
213 .I
214 reusable
217 .S "Build a prototype as soon as possible
218 .I
219 shows the quality of the design
220 .I
221 shows the problems of the software
222 .I
223 the best way to shape a software
224 .I
225 users find bugs
228 .S "Choose portability over efficiency
229 .I
230 (comes from incompatible hardware in history)
231 .I
232 use is most important
233 .I
234 availability
235 .I
236 only needs to be fast enough
239 .S "Store data in flat text files
240 .LP
241 binary data is machine dependent
242 .LP
243 human readable data is:
244 .I
245 is very likely supported
246 .I
247 good to port
248 .I
249 many tools work on it (Unix toolchest)
250 .I
251 as generic as possible
252 .LP
253 processing needs only to be fast enough
256 .S "Use software leverage to your advantage
257 .LP
258 what do we have computers for?
259 .LP
260 make best use of computing power
261 .LP
262 reduce development effort
265 .S "Use shell scripts to increase leverage and portability
266 .LP
267 was very important in history
268 .LP
269 high level languages
270 .LP
271 prototyping
272 .LP
273 quick hacks
276 .S "Avoid captive user interfaces
277 .LP
278 don't assume the user to be human
279 .LP
280 exclude the user whenever possible
281 .LP
282 automate
285 .S "Make every program a filter
286 .LP
287 programs transform data
288 .LP
289 combine programs
290 .LP
291 have one common interface
295 .S "a different POV
296 .I
297 pipes
298 .I
299 interface design
300 .I
301 the toolchest approach
302 .I
303 a powerful shell
304 .I
305 worse is better
306 .I
307 upgrowth and survival
311 .P "real world examples
314 .S "various
315 .LP
316 who uses
317 .CW "grep -R
318 ?
320 .sp 1
321 .LP
322 .CW "cat -v
324 .sp 1
325 .LP
326 pagers are taken for granted
328 .sp 1
329 .LP
330 what about the readline?
334 .S "find -printf
335 .LP
336 How to reformat the output of find(1) to have ``FILENAME PATH''
337 instead of ``PATH/FILENAME''?
339 .LP
340 the ``easy'' way:
341 \f(CWfind /dir -printf "%P %h\en"\fP
343 .LP
344 the ``good'' way:
345 .br
346 .CW "\s-1find /dir | sed 's,\e(.*\e)/\e(.*\e),\e2 \e1,'
348 .LP
349 The difference shows off when one wants, for instance,
350 the path to be manipulated further.
353 .S "MH / nmh
354 .LP
355 a Mail User Agent (MUA)
356 .LP
357 is a toolchest
358 .LP
359 work with mails like with generic files
360 .LP
361 the only(?) MUA that follows the Unix Phil
362 .LP
363 has a very special feeling
366 .S "uzbl
367 .LP
368 a web browser that adheres to the Unix Phil
369 .LP
370 a young project (about 1 year)
371 .LP
372 central question: what is the one task a web browser covers?
373 .LP
374 makes very visible use of software leverage
375 .LP
376 suffers hard from our broken web
382 .P "more than software dev guidelines
385 .S "say no
386 .LP
387 in today's computer world, the Unix Phil is much of asceticism
388 .LP
389 one needs to abjure a lot of ``nice'' features
390 .LP
391 IMO that leads to a valuable attitude
394 .S "avoid complexity
395 .LP
396 avoid complexity first and foremost
397 .LP
398 complexity is the ``boss enemy'', software developers fight against
399 .LP
400 strive for simplicity, clarity, generality
403 .S "good solutions
404 .LP
405 we don't need just solutions, we need good ones
406 .LP
407 today, we can make almost everything possible,
408 but we still cannot make it good
411 .S "live it
412 .LP
413 the Unix Phil is not just a few guidelines
414 .LP
415 you cannot follow just some of the tenets
416 .LP
417 you will not understand the Unix Phil when you don't engage with it
418 .sp 3
419 .LP
420 .ce
421 it's a philosophy \(en live it!
425 .P "literature
428 .S literature
429 .I
430 ``\fBThe Unix Philosophy\fP''
431 by Mike Gancarz
432 .br
433 Go and get it!
434 .I
435 ``\fBThe Unix Programming Environment\fP''
436 by Kernighan and Pike
437 .br
438 A Bible for Unix-lovers.
439 .I
440 ``\fBThe Mythical Man-Month\fP''
441 by Fred Brooks
442 .br
443 The case about complexity.
444 .I
445 ``\fBThe Practice of Programming\fP''
446 by Kernighan and Pike
447 .br
448 How good code should look like.
449 .I
450 ``\fBcat -v Considered Harmful\fP''
451 by Pike and Kernighan
452 .CW \s-2http://harmful.cat-v.org/cat-v/\s+2
453 .br
454 A must-read.
457 .S
458 .LP
459 this talk was prepared using tools of the Heirloom project:
460 .CW \s-2http://heirloom.sf.net\s+2
461 .LP
462 the slides macros are based on
463 .br
464 .CW \s-2http://repo.cat-v.org/troff-slider/\s+2
465 .sp
467 .LP
468 the slides are available on my website
469 .CW \s-2http://marmaro.de/docs\s+2
470 and on
471 .CW \s-2http://ulm.ccc.de/ChaosSeminar/\s+2
472 .sp
474 2010-03-08