|
Home > Archive > Unix Programming > January 2004 > Book Review - The Art of UNIX Programming
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Book Review - The Art of UNIX Programming
|
|
| Danny Yee 2004-01-23, 5:35 pm |
| The Art of UNIX Programming
Eric S. Raymond
Addison-Wesley 2004
525 pages, index
A book review by Danny Yee
http://dannyreviews.com/h/Art_Unix.html
In _The Art of UNIX Programming_ Eric Raymond covers programming in the
broadest sense: not just engineering aspects of design and implementation,
but also Unix philosophy, history and culture, and the social aspects of
development in an Open Source world. Covering so much, it is necessarily
shallow, but that also makes it easy reading -- and entry points are
provided for those wanting more. There are plenty of case studies and
examples, and the emphasis is on practice rather than abstract theory.
--
Raymond begins with Unix philosophy, with what Unix gets right and some of
its "rules". He gives a brief history of Unix, covering its origins and
its fusion with early Internet culture and the free software movement,
culminating in "open source". And he contrasts the Unix approach with
alternatives, considering alternative approaches to multitasking,
boundaries, file formats, interfaces, etc. and then specific other
operating systems such as MacOS, VMS, OS/2, and Windows NT.
Turning to design, he starts with modularity and the concepts of
compactness, orthogonality, and "single point of truth". The Unix
emphasis on textuality is illustrated with examples ranging from
/etc/passwd to data-file metaformats (RFC 822, XML), application protocols
(SMTP, POP3, IMAP), and metaformats (HTTP, SOAP). This is followed by
a more general look at Unix approaches to designing for transparency
and discoverability.
A chapter on multiprogramming offers a taxonomy of Unix IPC methods:
"shelling out", pipes and filters, wrappers, Bernstein chaining, and
slave processes and peer-to-peer communication using tempfiles, signals,
sockets, or shared memory. Problematic methods include Sys V IPC,
RPC and threads.
Raymond considers twelve examples of "minilanguages", ranging from regular
expressions and the simple declarative languages used in data files to
Javascript and Emacs Lisp, and offers tips on designing new ones. And a
brief chapter covers data-driven programming and ad-hoc code generation.
Raymond explains the various ways Unix does program configuration -- run
control files, environment variables, command line options -- again with
case studies. On interfaces he runs through some common Unix designs:
filters, return value only "cantrips", sources, sinks, compilers, ed-like
(line), roguelike (curses), various kinds of engine/interface pairs,
and network servers. The Rule of Least Surprise and the "Silence is
Golden" principle (no unnecessary output) also get a mention.
A chapter on optimization -- "a very short chapter, because the main
thing Unix experience teaches us about optimizing for performance is
how to know when not to do it" -- is followed by one on complexity.
Here Raymond considers ed, vi, sam, Emacs, and wily as examples, and asks
"Is Emacs an argument against the Unix tradition?" -- he suggests that
Emacs is best considered a framework rather than a tool.
Moving on to "Implementation", Raymond begins with the special place of
C under Unix; he then offers evaluations of 8 languages and advice on
choosing an X toolkit. A quick tour of major Unix programming tools
covers vi or emacs, yacc and lex, make, version-control and profiling
tools, and emacs as an IDE. And a chapter on reuse focuses on the
advantages Open Source offers; it is here Raymond discusses open source
licensing issues from the point of the user.
The final section covers "Community". Here Raymond looks at the
evolution of C and Unix standards, the IETF and the RFC standards process,
programming for portability, and internationalization. He surveys the
messy "zoo" of Unix documentation formats -- troff, TeX, Texinfo, PD,
HTML, ... -- with a detailed look at DocBook and associated tools as
"a possible way out". And he outlines "best practice" in open source
collaboration with other developers, and explains the logic of open
sources licenses and how to pick one for your own project.
A final chapter considers opportunities and risks -- problems in the
design of Unix, and possibly in its environment and culture -- and looks
at Plan 9 as "The Way the Future Was".
--
Raymond writes clearly and effectively, and is prepared to make strong
statements using informal language, sometimes humorously.
"The combination of threads, remote-procedure-call interfaces,
and heavyweight object-oriented design is especially dangerous.
Used sparingly and tastefully, any of these techniques can be
valuable -- but if you are ever invited onto a project that is
supposed to feature all three, fleeing in terror might well be an
appropriate reaction."
The text is sprinkled with Zen references and an appendix offers some
Unix koans -- it seems the originally intended title was "The Tao of
Unix Programing"; there are some set piece stories, such as the "Tale
of J. Random Newbie". The result is just plain fun.
A notable feature of _The Art of UNIX Programming_ is its use of many
small case studies, some of which I found informative in their own right
-- I didn't know about SNG, the textualised PNG format, for example.
Raymond draws on his own experience for many of his examples, with
fetchmail featuring several times (though CML doesn't get a mention).
A nice inclusion is the occasional brief comment on the text by Unix
pioneers such as Brian Kernighan and Doug McIlroy, chipping in with a
personal perspective.
Raymond's politics hardly intrude at all -- gun rights sayings as
fortune file examples is about it. The only thing that jarred for
me was a triumphalist declaration of victory for "open source" over
"free software".
For most hackers and almost all nonhackers, "Free software
because it works better" easily trumped "Free software because
all software should be free".
Most hackers may not support the explicitly political agenda of the
Free Software Foundation, but it is still freedom which is central to
their attraction to free software -- freedom from dependency on vendors,
freedom to innovate and share innovations -- with purely engineering
advantages concomitant on that. And most nonhackers don't understand
or care about the "works better" arguments at all -- here "free as in
beer" is possibly the biggest selling point, though the political angle
seems increasingly important in some countries.
Anyone doing Unix programming should find plenty to chew on in _The Art
of UNIX Programming_: even experienced Unix hackers may learn a few new
things from it, or perhaps have fun finding things to disagree with.
Programmers from outside the tradition wanting an introduction should
also find it rewarding. The only real requirement is some interest in
programming, even if it's only (as in my case) the occasional programming
ventures of a system administrator. The full text is available online,
but _The Art of UNIX Programming_ is designed for reading rather than
as a reference, so a print copy is in my opinion well worth having.
--
This review is dedicated to the memory of David Hogan, Unix and Plan 9
hacker.
--
%T The Art of UNIX Programming
%A Raymond, Eric S.
%I Addison-Wesley
%C Reading, Massachusetts
%D 2004
%O paperback, index
%G ISBN 0-13-142901-9
%P 525pp
%K computing
%W http://catb.org/~esr/writings/taoup/
%Z thirty years of development wisdom
1 December 2003
------------------------------------------------------
Copyright (c) 2003 Danny Yee http://danny.oz.au/
Danny Yee's Book Reviews http://dannyreviews.com/
------------------------------------------------------
| |
|
|
| Randy Howard 2004-01-23, 5:35 pm |
| In article <bu0v15$hpi$1@thrud.anatomy.usyd.edu.au>, editor@dannyreviews.com
says...quote:
> The Art of UNIX Programming
> Eric S. Raymond
> Addison-Wesley 2004
> 525 pages, index
>
> Raymond begins with Unix philosophy, with what Unix gets right and some of
If you're going to write a review of a UNIX book, you should at least
know how it is capitalized.
--
Randy Howard
2reply remove FOOBAR
| |
| Carlos J. G. Duarte 2004-01-23, 5:36 pm |
| Randy Howard wrote:quote:
> In article <bu0v15$hpi$1@thrud.anatomy.usyd.edu.au>, editor@dannyreviews.com
> says...
>
>
>
> If you're going to write a review of a UNIX book, you should at least
> know how it is capitalized.
Now, cam'on, you are not being fair. Deenis Ritchie himself has spoken
about this in the past: the original intended capitalization of that
fine operating system was Unix, it seems the folks at AT&T received a
new printer that produced nice big letters and started writting UNIX all
the place.
[Can't seem to find that inverview, although ...]
--
carlos ** http://cgd.sdf-eu.org
| |
| joe@invalid.address 2004-01-23, 5:36 pm |
| "Carlos J. G. Duarte" <cjgd@clix.pt> writes:
quote:
> Randy Howard wrote:
>
> Now, cam'on, you are not being fair. Deenis Ritchie himself has spoken
> about this in the past: the original intended capitalization of that
> fine operating system was Unix, it seems the folks at AT&T received a
> new printer that produced nice big letters and started writting UNIX
> all the place.
> [Can't seem to find that inverview, although ...]
Well, he calls it "Unix" pretty consistently here
http://cm.bell-labs.com/cm/cs/who/dmr/hist.html
mostly uses "UNIX" here
http://cm.bell-labs.com/cm/cs/who/dmr/notes.html
And uses both here
http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html
This seems to point to the original name being "Unix", as a derivative
of "Multics"
"Although Bell Labs had dropped out of the Multics project in April
1969, those of us in Cambridge kept in touch with individual folks
at BTL, and so we knew that Ken and Dennis were working on a
project of their own. We even knew that it had a joke name, Unix,
coined by Brian Kernighan, that was a reference to Multics. ("One
of whatever Multics was many of" or "Multics without balls.")"
http://www.multicians.org/unix.html
Joe
| |
| Thomas Dickey 2004-01-23, 5:36 pm |
| Carlos J. G. Duarte <cjgd@clix.pt> wrote:quote:
> Randy Howard wrote:
[QUOTE][color=darkred]
> Now, cam'on, you are not being fair. Deenis Ritchie himself has spoken
> about this in the past: the original intended capitalization of that
Actually the earliest publications that I saw used "UNIX" consistently in
a smaller fontsize, making it appear at first glance as if it were "unix".
(Intent is a different matter altogether, but the appearance was lowercase).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
| |
| John L 2004-01-23, 5:36 pm |
|
"Thomas Dickey" <dickey@saltmine.radix.net> wrote in message news:100l95414m8evc7@corp.supernews.com...quote:
> Carlos J. G. Duarte <cjgd@clix.pt> wrote:
>
>
> Actually the earliest publications that I saw used "UNIX" consistently in
> a smaller fontsize, making it appear at first glance as if it were "unix".
>
> (Intent is a different matter altogether, but the appearance was lowercase).
>
That is "small caps" -- used because otherwise all-uppercase words seem
too large in comparison to the surrounding lowercase text.
John.
| |
| Thomas Dickey 2004-01-23, 5:36 pm |
| John L <jl@lammtarra.fslife.co.uk> wrote:
quote:
> That is "small caps" -- used because otherwise all-uppercase words seem
> too large in comparison to the surrounding lowercase text.
Yes.
And at the same time I had noticed that lowercase "unix" was common in the
online documentation for UNIX (whether it was consistent or not, I don't recall
- this was ~25 years ago).
It is possible that the developers preferred using the informal "unix",
adapted it (as in many manpages to a leading capital at the beginning of
a sentence), but that the lawyers made it capitalized (to help guarantee
that the name could be trademarked).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
| |
| John L 2004-01-23, 5:36 pm |
|
"Thomas Dickey" <dickey@saltmine.radix.net> wrote in message news:100lm4mlfif9a4e@corp.supernews.com...quote:
> John L <jl@lammtarra.fslife.co.uk> wrote:
>
>
> Yes.
>
> And at the same time I had noticed that lowercase "unix" was common in the
> online documentation for UNIX (whether it was consistent or not, I don't recall
> - this was ~25 years ago).
>
> It is possible that the developers preferred using the informal "unix",
> adapted it (as in many manpages to a leading capital at the beginning of
> a sentence), but that the lawyers made it capitalized (to help guarantee
> that the name could be trademarked).
>
Quite possibly. You should ask in news:alt.folklore.computers whose
denizens would likely know.
John.
| |
| Wayne C. Morris 2004-01-23, 5:36 pm |
| In article <100l95414m8evc7@corp.supernews.com>,
Thomas Dickey <dickey@saltmine.radix.net> wrote:
quote:
> Actually the earliest publications that I saw used "UNIX" consistently in
> a smaller fontsize, making it appear at first glance as if it were "unix".
That's called small-caps. Traditionally, any time a word or abbreviation
in the middle of a sentence is printed in all-caps, small capitals should
be used so that it doesn't look too big relative to the surrounding
letters. This includes abbreviations and acronyms like AM, PM, CD, NASA,
USA, etc.
Unfortunately the advent of desktop publishing has allowed a great many
books to be published by people who know nothing of traditional typesetting
& typography. Some of those old rules may seem arbitrary or pointless, but
they existed for reasons which are still good today.
| |
| Thomas Dickey 2004-01-23, 5:36 pm |
| John L <jl@lammtarra.fslife.co.uk> wrote:
quote:
> Quite possibly. You should ask in news:alt.folklore.computers whose
> denizens would likely know.
perhaps (their memory may be equally poor).
my point was that there's more than one possible explanation.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
| |
| unglued 2004-01-23, 7:34 pm |
| Thomas Dickey <dickey@saltmine.radix.net> wrote in message news:<100mciv9190lb8d@corp.supernews.com>...quote:
> John L <jl@lammtarra.fslife.co.uk> wrote:
>
>
> perhaps (their memory may be equally poor).
> my point was that there's more than one possible explanation.
LOL ! Computer theology, when can we look forward to the first Unix/UNIX jihad ?
| |
| Thomas Dickey 2004-01-24, 6:35 am |
| unglued <dragonseed@spray.se> wrote:quote:
> Thomas Dickey <dickey@saltmine.radix.net> wrote in message news:<100mciv9190lb8d@corp.supernews.com>...
[QUOTE][color=darkred]
> LOL ! Computer theology, when can we look forward to the first Unix/UNIX jihad ?
Too late - the lawyers already won.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
|
|
|
|
|