janc@uofm-cv.UUCP (Jan Wolter) (01/16/84)
What are your favorite books on computer science? The sort of books that you feel any computer scientist should own? I can name three, but would like to hear the opinions of others. (1) Knuth. The Art of Computer Programming. Addison Wesley. Multitudinous fundamental algorithms thoroughly analized. A book any hacker can curl up with and enjoy. Too well known to discuss in detail. (2) Brooks. The Mythical Man-Month. Addison Wesley. The man who was project manager on OS/360 discusses software engineering. Brooks Law (adding manpower to a late soft- ware project makes it later) is a cornerstone of this book. A thought provoking examination of the realitys of the programming "art". Hackers will be less comfortable with this one. (3) Dijkstra. Selected Writings on Computing: A Personal Perspective. Spring-Verlag. This is a large collection of short monographs by the man best known for igniting the goto-less programming debate. This is a mixed bag of techical texts and informal commentaries. A few typical quotations to wet the taste: Programming is one of the most difficult branches of applied mathematics. Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer. By claiming that they can contribute to software engineering, the soft scientist make themselves even more ridiculous. The informal commentaries are delightful, but the reader should take the time to study the techical pieces too. They are beautiful in themselves, and do much to back up Dijkstra's criticisms of the work of others. No hacker could survive reading this book. Comments on these and other computer science books are invited. Jan Wolter -- University of Michigan
rpw3@fortune.UUCP (01/19/84)
#R:uofm-cv:-46100:fortune:22600004:000:8166
fortune!rpw3 Jan 18 19:56:00 1984
Let's see, given Knuth, Brooks, and Dijkstra,... I would rave about
the following seven:
William A. Wulf, Roy Levin, and Samuel P. Harbison, "HYDRA/C.mmp"
This is an essential reference for operating systems and network
architects in the 80's, even if the systems they build do not
closely reflect the principles presented here. HYDRA/C.mmp was
an experimental (but fully functional) multi-processor timesharing
computer system built at Carnegie-Mellon (CMU) between 1971 and 1977.
C.mmp was the computer (16 PDP-11's plus 32 Mbytes of shared memory);
HYDRA was the operating system. The basic protection mechanism was the
"typed object" and the "capability" (a kernel protected handle) to
apply a operation (procedure) to an object. (The "root" of the system
was the object whose type is "Type".) Such UNIX concepts as "read",
"write", "execute", "send", "receive", "create", "lookup", "rename",
and "delete" are easily mapped into this framework. But HYDRA did not
supply these operations; they were supplied by user-level procedures.
The file systems, debuggers, scheduler policies, and network interfaces
were all (unpriviledged) user level programs. The principle of
policy/mechanism separation guided most of the major design decisions.
The most valuable feature of the book (besides the introduction of
clear models and definitions) is the "Retrospective" section at the
end of each chapter and a whole chapter of "Reflections" at the end.
Here the authors ruthlessly examine the material just presented from
the viewpoint of what they learned, what they would do differently,
which assumptions proved out and which did not, and thorny problems
that are still not solved. As always, it is helpful to know where
others have stumbled (and succeeded).
Butler W. Lampson, M. Paul, and H. J. Siegert (editors), "Distributed Systems"
This is one of the Springer-Verlag Lecture Notes in Computer Science
series, publishing notes from courses (generally given in Europe). The
full title is "Distributed Systems: Architecture and Implementation, an
Advanced Course". Unlike most of the others in the series, in this one
the readability has benefited greatly from Lampson's access to Xerox
PARC's Alto/Star fonts and graphics. Even with 20 chapters (500 pages)
and over eight contributers the content is well integrated, and nicely
surveys what was known (and not known) about distributed systems and
networks in the state-of-the-art in 1980. It is still quite up-to-date.
After presenting a "distributed system architecture model", the book
covers IPC, hardware, link protocols, hierarchy issues, end-to-end IPC,
naming, protection, atomic transactions, synchronization, the multi-copy
update problem, and applications and their protocols. A view of the
layering of a complete application is given in the chapter "Ethernet,
Pup, and Violet", which describes a distributed, replicated calendar
system. But my favorite chapter is the last, by Ken Thurber, which
has section titles:
- What we have defined
- What we think we know
- What we conjecture
- What we think we don't know
- What we advise
- What you should know
- What we don't agree upon.
This final chapter alone is worth the price of the book, which is
cheaper if you get it in the "Springer Study Edition".
Dan Siewiorek, Gordon Bell, and Allen Newell, "Computer Structures"
Second edition: "Principles and Examples". 926 pages. This is
THE classic encyclopedia of computer architecture; it presents
a taxonomy of computer structures and examples of machines which
fit one or more catagories. Mandatory reading and re-reading
for practicing and would-be architects. "All of the machines
discussed in this book have actually been constructed and
evaluated. The papers, wherever possible, are written by the
specific machine architects or people closely associated with
the architectures. Several of the machines are presented in
elaborate detail, enabling the reader to appreciate the design
complexities encountered and design methodologies employed by
the architects." Articles include the IBM 360/91, Illiac IV,
B5500, Manchester Mark I, PDP-8, Tandem 16, Aloha packet radio,
Xerox Alto, PDP-11, CDC 6600, VAX, HP 9845A, IBM System 38,
Cray-1, TI ASC, Ethernet, the SYMBOL machine, ARPAnet IMP,
Intel 8008 through 8086, and many many more.
C. Gordon Bell, J. Craig Mudge, and John E. McNamara, "Computer Engineering"
Subtitled "A DEC view of hardware systems design", it is exactly that.
From "In the Beginning" (1957) through "The PDP-8 and Other 12-bit
Computers" and "The Evolution of the PDP-11" to "VAX-11/780" this
book lays out the DEC engineering methodology and style. In the
chapter "Impact of Implementation Design Tradeoffs on Performance:
The PDP-11, A Case Study" the register/ALU/data-path diagrams are
given for every machine from the LSI-11 (PDP-11/03) to the PDP-11/60
with discussion of technology, microcode, tradeoffs, and performance.
Papers on caches, buses, threaded code, Register Transfer Modules
(later called PDP-14), C.mmp and Cm* (CMU's multi-processors), the
PDP-10 (PDP-6, KA-, KI-, and KL-10), and packaging and manufacturing
flesh out a feast for historians. Hardware architects would do well
to consider the lessons here, especially the "Wheel of Reincarnation"
discussed in the section on the DEC 338 display computer.
R. C. Holt, "Concurrent Euclid, The UNIX System, and Tunis"
Good intro to concurrency. The EUCLID simulation kernel is a good model
for simulation systems in general (we have used a "C" adaptation for
doing I/O system simulations). The description of the UNIX file system
has helped several beginners unscramble the ideas of directories,
i-nodes, and files. The model of interrupt handlers as processes is
impeccable (Down with interrupts! Bring back the 6600!) and even
efficient. The two pages of PDP-11 assembler which is called a "kernel"
(EUCLID's use of the word) would be called "save/resume" in UNIX. The
idea (and in the case of Tunis, practice) of building systems that can
have additional processors added to them without changing anything is
much needed in this world of fast micros.
David Gries, "The Science of Programming"
The ideas and methods of Dijkstra's "Discipline of Programming"
made accessible to mere mortals. I must confess I didn't really
believe/understand the proof of the loop invariant theorem until
I read the version presented here. Full of goodies like
a "checklist for understanding a loop" and "ways of weakening
a [loop invariant] predicate". The "balloon theory" of loops
is great! (You start with a loop predicate [balloon] which includes
both the pre-condition and the post-condition, then "deflate the
balloon" as you iterate the loop until it just encloses the
post-condition.)
Tom DeMarco, "Controlling Software Projects"
A solid book about software development, and its pitfalls.
Subtitled "Management, Measurement, & Estimation", the book
opens with "You can't control what you can't measure. In most
disciplines the strong linkage between measurement and control
is taken for granted. But I fear the idea may be news to many
software managers, otherwise rational men and women who harbor
an illusion of control, even though they never measure anything."
He goes on to discuss WHY we are so poor at measurement and
estimating (chiefly the political problem of estimates being
used to create incentives). Rather than an estimate being "the
most optimistic prediction with non-zero probability of coming
true", he proposes "a prediction that is equally likely to be
above or below the actual result". My only reservation is that
it may be hard to find (upper) management willing to face the
truth about their software disasters. (Dijkstra has asked,
"How do you tell truths that might hurt?") After all, years
after Brooks's Law, we still pour more people on late projects.
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065stewart@ihldt.UUCP (01/20/84)
Here's another book everyone should have on their shelf, no matter what
kind of programming they do:
The Art of Software Testing
by G.J. Myers
John Wiley & Sons, 1979
This is one of those rare, refreshing books that makes you look at a
subject in a completely different way. It's short and easy to read,
without oversimplifying or leaving things out. I've talked to others
who have read it, and they have all agreed that it's a book of
exceptional value.