.\".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

.NH 2
what it is
.LP
definitions by McIlroy, Gancarz, ESR (maybe already in the intro)
.LP
cf. unix tool chain
.LP
enabler pipe

.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