.\".if n .pl 1000i
.de XX
.pl 1v
..
.em XX
.\".nr PI 0
.\".if t .nr PD .5v
.\".if n .nr PD 1v
.nr lu 0
.de CW
.nr PQ \\n(.f
.if t .ft CW
.ie \\$1 .if n .ul 999
.el .if n .ul 1
.if t .if !\\$1 \&\\$1\f\\n(PQ\\$2
.if n .if \\n(.$=1 \&\\$1
.if n .if \\n(.$>1 \&\\$1\c
.if n .if \\n(.$>1 \&\\$2
..
.ds [. \ [
.ds .] ]
.\"----------------------------------------
.TL
Why the Unix Philosophy matters
.AU
markus schnalke <meillo@marmaro.de>
.AB
.ti \n(.iu
This paper discusses the importance of the Unix Philosophy in software design.
Today, few software designers are aware of these concepts,
and thus most modern software is limited and does not make use of software leverage.
Knowing and following the tenets of the Unix Philosophy makes software more valuable.
.AE

.if t .2C

.FS
.ps -1
This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
Mentor was professor Schweiggert. 2010-02-05
.br
You may get this document from my website
.CW \s-1http://marmaro.de/docs
.FE

.NH 1
Introduction
.LP
Building a software is a process from an idea of the purpose of the software
to its release.
No matter \fIhow\fP the process is run, two things are common:
the initial idea and the release.
The process inbetween can be of any shape.
The the maintainance work after the release is ignored for the moment.
.PP
The process of building splits mainly in two parts:
the planning of what and how to build, and implementing the plan by writing code.
This paper focuses on the planning part \(en the designing of the software.
.PP
Software design is the plan of how the internals and externals of the software should look like,
based on the requirements.
This paper discusses the recommendations of the Unix Philosphy about software design.
.PP
The here discussed ideas can get applied by any development process.
The Unix Philosphy does recommend how the software development process should look like,
but this shall not be of matter here.
Similar, the question of how to write the code is out of focus.
.PP
The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet.
The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed.
It is no limited set of rules, but what people see to be common to typical Unix software.
Several people stated their view on the Unix Philosophy.
Best known are:
.IP \(bu
Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
.[
%A M. D. McIlroy
%A E. N. Pinson
%A B. A. Taque
%T UNIX Time-Sharing System Forward
%J The Bell System Technical Journal
%D 1978
%V 57
%N 6
%P 1902
.]
.IP \(bu
Mike Gancarz' book ``The UNIX Philosophy''.
.[
%A Mike Gancarz
%T The UNIX Philosophy
%D 1995
%I Digital Press
.]
.IP \(bu
Eric S. Raymond's book ``The Art of UNIX Programming''.
.[
%A Eric S. Raymond
%T The Art of UNIX Programming
%D 2003
%I Addison-Wesley
%O .CW \s-1http://www.faqs.org/docs/artu/
.]
.LP
These different views on the Unix Philosophy have much in common.
Especially, the main concepts are similar for all of them.
But there are also points on which they differ.
This only underlines what the Unix Philosophy is:
A retrospective view on the main concepts of Unix software;
especially those that were sucessful and unique to Unix.
.PP
Before we will have a look at concrete concepts,
we discuss why software design is important
and what problems bad design introduces.


.NH 1
Importance of software design
.LP
Why should we design software at all?
It is general knowledge, that a bad plan is better than no plan.
As stated earlier in this document, the process of building a software
means going from an idea to a release.
The development process tells how to get from the idea to the release.
Software design is the shape of the built software.
This means, that different designs of a software would be different target points to go to.
Thus, the design of a software defines the global direction the development goes.
.PP
It is not enough that the released software offers all requested functionality.
It is a misbelief that only function matters.
Building a software the first time is only a small part of the overall work.
The larger part begins when the software is released for the first time
\(en maintainance and extending work..
This part soon covers more time than the time which was needed to build the software the first time.
.\" cf. brooks?
.PP
The extendability and maitainability of a software highly depends on its design.
Good design eases these tasks much.
Bad design, in contrast, requires much more effort for maintaining and
extending the software.
Developers should, for their own best, have maintainability and extendability in mind
when they design the software.
.PP
Users of the software, in contrast, do not care about maintainability and extendability,
at least not directly.
They care about usability and flexibility.
They want the software to directly solve their problems.
They want to be able to to use all its functions if they learned a few of them.
They want to use the software for similar tasks.
Software is successful if users enjoy using it.
Good software design can offer great flexibility and usability.
.PP
Good design matters for developers \fIand\fP for users.
Hence both groups should care about good software design.
Bad design limits the software in some way.
It may still provide all requested function, but it will have worse quality,
and thus require more work effort for developers or frustrate users.
.PP
Good software design is to the implementation like data structures are to algorithms
\(en if you get the former right, then you do not need to care about the latter,
it will simply go the right way.
.\" cf. ??? ``good data, bad algos''




.NH 1
The Unix Philosophy
.LP
The origins of the Unix Philosophy were already introduced.
This chapter explains the philosophy and shows concrete examples of its application.
.NH 2
Examples
.LP
Following are some examples to demonstrate how applied Unix Philosophy feels like.
Knowledge of using the Unix shell is assumed.
.PP
Counting the number of files in the current directory:
.DS
.CW
ls | wc -l
.DE
The
.CW ls
command lists all files in the current directory, one per line,
and
.CW "wc -l
counts how many lines they are.
.PP
Counting all files that do not contain ``foo'' in their name:
.DS
.CW
ls | grep -v foo | wc -l
.DE
Here, the list of files is filtered by
.CW grep
to remove all that contain ``foo''.
The rest is the same as in the previous example.
.PP
Finding the five largest entries in the current directory.
.DS
.CW
du -s * | sort -nr | sed 5q
.DE
.CW "du -s *
returns the recursively summed sizes of all files
-- no matter if they are regular files or directories.
.CW "sort -nr
sorts the list numerically in reverse order.
Finally,
.CW "sed 5q
quits after it has printed the fifth line.
.PP
The presented command lines are examples of what Unix people would use
to get the desired output.
There are also other ways to get the same output.
It's a user's decision which way to go.
.NH 2
Pipes
.LP
The examples show that a lot of tasks on a Unix system
are accomplished by combining several small programs.
The connection between the single programs is denoted by the pipe operator `|'.
.PP
Pipes, and their extensive and easy use, are one of the great
achievements of the Unix system.
Pipes between programs have been possible in earlier operating systems,
but it has never been a so central part of the concept.
When, in the early seventies, Doug McIlroy introduced pipes for the
Unix system,
``it was this concept and notation for linking several programs together
that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
.[
%T Unix: An Oral History
%O http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm
.] 
.PP
Being able to specify pipelines in an easy way is,
however, not enough by itself.
It is only one part.
The other is the design of the programs that are used in the pipeline.
They have to be of an external shape that allows them to be be used in a pipeline.



.NH 2
Architecture
.LP
the most important design decision.

the topic here

.NH 2
Interface architecture
.LP
standalone vs. tool chain
.LP
software leverage
.LP
possiblities

.NH 2
Results
.LP
The unix phil is an answer to the sw design question
.LP
tool chains empower the uses of sw

.NH 1
Case study: nmh

.NH 2
History
.LP
MH, nmh.
They are old.

.NH 2
Contrasts to similar sw
.LP
vs. Thunderbird, mutt, mailx, pine
.LP
flexibility, no redundancy, use the shell

.NH 2
Gains of the design
.LP

.NH 2
Problems
.LP

.NH 1
Case study: uzbl

.NH 2
History
.LP
uzbl is young

.NH 2
Contrasts to similar sw
.LP
like with nmh
.LP
addons, plugins, modules

.NH 2
Gains of the design
.LP

.NH 2
Problems
.LP
broken web

.NH 1
Final thoughts

.NH 2
Quick summary
.LP
good design
.LP
unix phil
.LP
case studies

.NH 2
Why people should choose
.LP
Make the right choice!

.nr PI .5i
.rm ]<
.de ]<
.LP
.de FP
.IP \\\\$1.
\\..
.rm FS FE
..
.SH
References
.[
$LIST$
.]
.wh -1p