The Bookshelf

of a well-read Web Nerd by Philip Greenspun for the Web Tools Review

These are mostly books that I personally own and have found useful. If you buy them by following links from this page (very carefully, as I explain in Chapter 2 of my book), the bookstore kickback (15 percent of the price of the book) is donated to charity (see the gift shop of Travels with Samantha for more explanation).

If you don't want to buy them, then you're best off participating in the database-backed Web site Q&A forum. Every month I give away my favorite selection from the titles below to someone who is contributing to the Web community's knowledge.

Learn to Program

Or learn to talk about programming if you already know how to program. I've only ever seen one great book on the subject of computer programming: Structure and Interpretation of Computer Programs (Abelson and Sussman; MIT Press). If you're already a great programmer, it will take you an evening to read the first few chapters and you'll discover a precision vocabulary for discussing what you've spent 10 years learning the hard way. If you're not already a great programmer, I would have thought that these few chapters would save you from having to spend years flailing around in the dark. Unfortunately, there doesn't seem to be a substitute for practical experience.

Sidenote: the authors used to have a review wall outside their offices at MIT. University professors from around the world writing in scientific journals said "finally I understand what all this computer science stuff is about; this is the most brilliant book ever. I'm glad that we're using it to teach freshmen now." In the center was a review from Byte magazine: "I didn't understand any of this book."

SICP is tougher to read than Teach Yourself to be a Dummy in 21 Days but it is the real thing, well organized and written.


If you measure a book's success by how well it delights the intelligent and tasteful, then Edward Tufte is one of the most successful authors of our age, with Given that these books have been so popular and that the world is still cluttered with so much ugliness (notably the Web itself), one is tempted to ask whether or not the standard should be instead "how well do these books educate the stupid and tasteless?"

I don't think that Tufte holds himself to either of the preceding standards, however. I look at these books as the physical artifacts of two decades spent showing people how graphic design affects thinking, decision-making, and emotions. Letting Envisioning Information fall open randomly, one finds a discussion of whether Maya Ying Lin's Vietnam Memorial should have had the names ordered by date of death or alphabetically. As there were over 600 Smiths who died in Vietnam and 16 James Joneses, an alphabetical listing would have given the memorial the flavor of a telephone directory. The MIT Library copy of Visual Explanations tends to fall open to the section showing how 13 charts prepared by engineers failed to persuade NASA officials and Morton Thiokol management to scrub the launch of the space shuttle Challenger. Tufte's simple redrawing of the same data would have persuaded almost anyone of the dangers of launching on a day 35 degrees colder than any previous launch.

Get these books for the inspiration, notably the inspiration that design matters. All of my graphic designer friends have the complete set on their desks. Most of my friends who are really good programmers also own the set. These are about the only books on which both groups agree.

User Interface Design

"No matter how cool your interface, it would be better if there were less of it."
-- Alan Cooper
Sometimes a well-implemented system still isn't what users wanted. In About Face, Alan Cooper starts off by saying that programmers shouldn't be allowed to design user interfaces because programmers will build systems that are easy to program, not systems that are easy for users. He points out that if carpenters designed houses, they would be easy to nail together but not so great for living, e.g., there would be no bathrooms because plumbing is difficult to install. We insist on having an architect advocate for the user. Cooper has a good point, though it is informed by his experience working in the Windows world where programmers tend to be young mediocrities writing C code en masse in a maze of cubicles.

Cooper's best point is that users don't understand the difference between RAM and disk and that they shouldn't have to. Disks are just a way of saving money. We'd have all RAM if we could afford it. Cooper rails against the entire File menu and programs that ask you whether or not you want to save when you're closing a document. He proposes that the program use the file system to offer you a chance to make milestones and save off versions of your document, then sometimes revert to those milestones but notes correctly that users should never see the files.

Obviously that last point isn't very relevant for Web site developers (though it does point up the idiocy of the typical shopping basket system where you have to explicitly check out or your order gets lost) but much of the book will be thought-provoking if you are setting out to build a new site.

It is a shame that the economics of geek book publishing force everyone into writing books with huge shelf-dominating spines. This might have been a great 250-page book. Instead, it is a good 580-page book. If you know that you won't have the patience for it, let me suggest reading Jakob Nielsen's "The Death of File Systems".

[In the same vein, I also like the old standby... Macintosh Human Interface Guidelines (available at or from Amazon.]

Database and SQL

Web (HTML and HTTP)

It used to be an article of faith among Web people that the Web be self-documenting. Unfortunately, it has transpired that people who design Web standards are better at sitting in standards committee meetings than they are at writing or Web publishing (for example, as of September 1997, the Web Consortium folks hadn't installed a search engine at their site).

Nobody at O'Reilly is crying too hard over the inability of the Web standards folks to put together a coherent sentence. They're happy to sell you HTML: The Definitive Guide (Musciano and Kennedy). This is territory that is well worn by 200 other "for dummies" type books but with the O'Reilly version you get a little clearer exposition of the standard and not too many annoying user interface widgets in the text (see the book behind the book behind the book). A broader but shallower view is presented by the useful Web Design in a Nutshell (covers HTML, style sheets, random multimedia formats, browser compatibility).

As badly as HTML was documented on the Web, the state of affairs for HTTP was much worse. O'Reilly has rectified the situation with Web Client Programming (Clinton Wong; 1997). This book clearly explains the HTTP protocol and then shows you how to build your own little Perl programs that go out onto the Web and grab pages, check links, etc. (Note: you might not give Wong's three-line Perl scripts too much thought, but any one of them could be the subject of a 14-week class in "Agents" at the MIT Media Lab). Wong introduces a very powerful Perl library (LWP) for making tiny Web robots. My only complaint with the book is that he doesn't give an example of using HTTP PUT, really about the most useful thing that I can imagine doing right now with a Perl script.

It would be nice if modesty prevented me from recommending my own book Philip and Alex's Guide to Web Publishing, which contains high-level stuff for decision-makers and low-level stuff for grunts.


Most Tcl books spend most of their time covering Tk, the user interface toolkit. Tk is useless for server-side Web stuff. What you want is something that covers the core language thoroughly. Unfortunately, I don't think that such a book exists. Most people buy Ousterhout's book. He wrote the Tcl language to begin with, but I don't think his book is very good.


As nasty and tasteless as Tcl is, it is a positive dream compared to Perl. The only conceivable way to write a correct Perl program IMHO is cutting and pasting from someone else's code.


Speaking of nasty and tasteless... Unix Power Tools a good place to start learning how to be an effective user. If you want to actually run the joint, you need to learn about system administration. You probably want the following books on Unix sysadmin in general: The most popular flavor of commercial Unix is Sun Microsystem's Solaris. Sun authorizes an official series of books on how to run their systems, but most of these only try to cover the most basic stuff and fail miserably to achieve even this limited ambition. If you see anything with the name "Janice Winsor" on it, don't bother to pick it up. On the other hand, Adrian Cockcroft and Richard Petit also write for this series and their Sun Performance and Tuning is excellent; Configuration and Capacity Planning for Solaris Servers (Wong 1997) isn't so bad either. To learn how to actually set up a Solaris machine, try Solaris 2.X for Managers and Administrators.

This page was delivered to your browser by a Hewlett-Packard Unix server. The best book that I've found so far on running this operating system is Jay Shah's HP-UX System and Administration Guide. The advice ranges from general background to idiot things like how to boot single user if you've forgotten the root password. There are conceptual aids for things like LVM and even shell-command level instructions on how to establish, break, back-up, and re-establish mirrored disks.

If you want to get with the 90s and run Linux, you can read "Linux Installation and Getting Started" at I'm sure the next edition of Running Linux will be good but the current one is out of date. Linux in a Nutshell is current but is a reference rather than a tutorial.

Whatever brand of Unix poison you choose to swallow, if you're not already a monster Emacs user, you'll want to read Learning Gnu Emacs and Writing Gnu Emacs Extensions.


If you want to practice the version control methodology outlined in "Using CVS for Web development", you'll probably want to get Open Source Development With CVS (Fogel 1999; Coriolis).

I asked Andrew Grumet to review this book. Andrew's qualifications include a PhD from MIT, a software development job at, and 100% total ignorance of CVS. Here's his experience:

This is really two books. One is a CVS reference, and the other is about starting and running an open source development project. I have only read about half the book at this point, with a primary interest in the CVS material. So far I find it to be well written, informative, and comprehensive (see the sometimes helpful table of contents below). Chapter 2 covers the day to day mechanics, showing you how import a project into an existing repository, make working copies of the project, commit changes made on working copy files to the repository, perform updates to merge changes from the repository into the working copy, add and remove files and directories, create static snapshots of the code, and so on. Chapter 4 covers what you need to know to install CVS (if it's not already on your system) and administer a repository. Chapter 6 promises to cover "advanced" topics (haven't gotten there yet).

I have no real complaints at this point. One nice thing is that they kept a reasonable damper on distracting typography (only the occasional "Note" or "Tip" icon). The material on open source development seems a little bit more touchy feely and less technical, but makes for enjoyable reading anyway. The bottom line: a good, readable reference for your CVS needs.



Chapter 1 Why Open Source Development And CVS Go Together
  What Is Free Software (And Why Should You Care)?
  What Does CVS Have To Do With It?
  Principles of Open Source Development And How CVS Helps
  What Makes It All Tick?

Chapter 2 An Overview Of CVS
  CVS Basics
  A Day With CVS
  Other Useful CVS Commands

Chapter 3 The Open Source Process
  Failure And Success
  Starting A Project
  Running A Project
  Knowing What We Don't Know

Chapter 4 CVS Repository Administration
  The Administrator's Role
  Getting And Installing CVS
  Anatomy Of A CVS Distribution
  Starting A Repository
  Finding Out More

Chapter 5 Designing For Decentralized Development
  The Importance Of Software Design
  Proprietary Software Design Vs. Free Software Design
  Design Invariants
  Code Design
  Evolution-Centered Design
  Principles of Free Software Design
  When In Doubt, Abstain

Chapter 6 Advanced CVS
  Beyond The Basics
  CVS As Telephone
  A Bird's Eye View Of Project History
  Using Keyword Expansion
  Going Out On A Limb: How To Work With Branches and Survive
  That's All, Folks!  Welcome To Guru-Hood

Chapter 7 Building, Testing, And Releasing
  Why Release?
  Starting The Release Process
  Building, Installing, And Packaging
  Finding Out More

Chapter 8 Tips And Troubleshooting
  When Things Go Wrong
  The Usual Suspects
  Common Problems And How To Solve Them

Chapter 9 Complete CVS Reference
  Organization And Conventions
  Keyword Substitution (RCS Keywords)
  Repository Administrative Files
  Run Control Files
  Working Copy Files
  Environment Variables

Chapter 10 Third Party Tools That Work With CVS
  What Are Third Party Tools?
  pcl-cvs: An Emacs Interface To CVS
  cvsutils: General Utilities For Use With CVS Generate GNU-Style ChangeLogs From CVS Logs
  cvslock: Lock Repositories For Atomicity
  Other Packages
  Writing Your Own Tools

Appendix A CVS Maintenance And Development Today

Appendix B GNU General Public License


Windows NT

If you've accepted Bill Gates as your personal savior, but have despaired of finding a concise book on NT, rejoice in the 210 pages of The No B.S. Guide to Windows NT 4.0 (Jim Forkner; No Starch). Sadly, in September 1997 when I picked it up, it didn't answer any of the questions with which I was struggling, e.g., how to make an NT box drive multiple monitors, how to restrict IIS to listening on only one of a machine's virtual IP addresses, how to manage an NT box that is in a machine room and on a different subnet.

If you come from a Unix background and want to play some of the same tricks to which you became accustomed, it is probably best to learn about NT from the O'Reilly series:

Real Books

I sometimes get around to reading real books. If I like them, I add a review to my collection.
Text and pictures (inevitably to follow) copyright 1989-1997 Philip Greenspun.

Reader's Comments

The ultimate Unix sysadmin book is "Unix System Administration Handbook" by Nemeth, Snyder, Seebass and Hein aka "The Red book"

-- John Lowry, January 9, 1998
It wasn't available yet when philg wrote that he couldn't find a good, short book on NT, but one worth considering is Aeleen Frisch's "Windows NT System Administration" from O'Reilly. Not as relevant for someone just running a workstation, but see the appendix with a "quick start for Unix sysadmins."

It's ISBN is 1-56592-274-3.

Don't believe the cover hype about "Effective and Painless NT Management," of course. What was Tim O'Reilly smoking the day that slipped by? ;)

-- Rob Szarka, July 15, 1998

If you write perl programms by cutting and pasting other peoples code, you should probably not comment on books about perl. You say you prefer FortranII -- that's ok just use it, but don't keep your readers from trying to learn a language that a lot of people use succesfully and efficently.

-- Martin Mueller, August 7, 1998
...perl really has come quite a long way especially with Apache's 'mod_perl', you can have a perl interpreter rolled up inside more huge CGI overhead. The docs with Apache and mod_perl/mod_cgi are all you really need to get going. Any chance of a review of this? I note that 'Guide to Web Publishing,' gives pretty much the same review.....(awwww...come'on..)

loved the book, btw....

-- Ken Wills, November 16, 1998

This is a fairly minor comment, but perhaps Mr Mueller is not the only one confused by philg's reference to FORTRAN II---apparently its infamy has faded enough that non-scientists these days don't appreciate the gut horror it's supposed to inspire. FORTRAN 77 is wretched enough: silent errors if you happen to type more than 72 characters on a line, function calls that don't even check if they've been handed the right *number* of arguments, never mind of the right types, etc, etc. And while I've been spared the experience myself, I have watched an officemate try to decipher 1965-vintage FORTRAN IV, where the principal control structure was the computed GOTO (and the program was written by a guy who thought things like llo10, note *very* carefully, made good variable names).

I have never had to deal with FORTRAN II, and I hope never to face the experience, except maybe in some twisted CS carnival House of Horrors.

-- Colin Roald, March 27, 1999

I thought Phillips comments about PERL especially were interesting.. as I have just cobbled together a web robot based on other perl scripts. I then wrote some scripts in Python which I found much cleaner and shorter, although I must admit for straight text processing I still use Perl.

-- Jamie Ross, March 27, 1999
Just looking at the number of books whose description includes the word "dated" makes me wonder why -- aside from the relative convenience and comfort of "unplugged" reading -- anyone bothers with paper books about computing anymore. Writing a book about a "current" topic seems to be a losing battle. By the time the book is published, the pace development and progress on Internet Time has already reduced the value of the paper and the enclosed CDROM. As far as I can see, the only reason that paper books still appear in such prodigious quanities is that the book trade is trying to squeeze whatever revenue they can from the physical publishing model before it becomes so much history. That, and the problem that no one has figured out how to make money publishing a book exclusively on the web -- yet.

Just to clarify the last sentence: I'm not saying that it can't be done, just that it hasn't (for whatever reason) been done. I'm reasonably confident that once the Powers-That-Be get over the idea that the Internet can be packaged as an inconvenient version of a cable TV channel running mostly commercials 24 hours a day, success and enlightenment will eventually come and benefit us all -- and my wife will finally get me to throw out all those books, magazines, and papers I've been accumulating for the past 20 years.

-- Frank Wortner, April 30, 1999

Here are a few reasons I tremendously like Perl:

(1) Its close to C in structure. Which means that even lesser programmers from universities across the river Charles from east Cambridge can learn and master it :-)

(2) There are an ample number of pre-written modules that are available on most every single topic. All open source.

(3) Dynamite regular expressions, as a core language feature (and not added on as an afterthought by compiling in Henry Spencer's regex library).

(4) A wonderfully written set of books. I love Programming Perl (2nd edition -- every time I have a question I find the answer somewhere within its pages). O'Reilly has an excellent set of Perl books that target developers from novice to expert.

(5) Well supported by and any number of people who are happy to charge you for support that can be found free with some searching

(6) Copious amounts of good quality documentation that come with Perl. A language is only as good as its documentation. Perl shines in this department.

Quite a few programmers seem to have no problem using Perl to solve problems -- given that it has become so popular in Web development, it must be useful to many people, wouldn't you think?

And while we are on the topic, here's a retort from the creator of Perl. hope it provides some amusement:

Lispers are among the best grads of the Sweep-It-Under-Someone-Else's-Carpet School of Simulated Simplicity. [Was that sufficiently incendiary? :-)] --Larry Wall

-- Jagadeesh Venugopal, July 10, 1999

Learning Tcl

I guess that if someone were to write a book about just the core tcl language, they'd run out of useful things to say at about page 80. So most books are about layers on top of tcl. If you must kill a tree, the first few chapters of Exploring Expect, by Don Libes, have a good tcl intro. You can skip the rest.

For those in tune with 90's, there's an online book Tcl for Web Nerds, by Lydia Sandon, which is all you really need.

-- Ken Mayer, July 23, 1999

I would like to add a suggestion.. Python is another excellent scripting language that leans more to the simplicity of TCL but has a lot more power to develop applications, especially for the net. There are a couple of good references (Programming Python for the World Wide Web comes to mind) for doing HTTP clients and spiders and there are very good modules available.. Its free of course and available from There are also modules for interfacing to many dbs

-- Jamie Ross, July 29, 1999
The MacOS Human Interface Guidelines are available online at:

-- Michael Edwards, August 20, 1999

Perl is a very expressive language. Programming Perl, you have the choice to trade readability for programmer efficiency. That is not necessarily a bad thing.

-- Christian Lemburg, September 2, 1999
After the passage of days, weeks, years, etc., when you find yourself staring uncomprehendingly at code written by someone who traded readability for "programmer efficiency," you might begin to wonder if all that trade was such a good idea.

I'm not knocking Perl -- cryptic code is possible in any language. Whether cryptic code ever provides a reward without some accompanying "punishment" is debatable.

-- Frank Wortner, October 7, 1999

Can't believe nobody mentioned PHP here. I learned Perl, I looked at Tcl (thanks to Philip), but nothing comes close in ease-of-use for writing web applications. There's just so much already there, that you would need to "re-invent" for other languages and by combining ideas from C, Perl and Java, PHP gives you the flexibility to implement the way you need. Highly structured and organised or just quick and dirty. The PHP community is growing fast and very supportive. See:

-- Marc Burgauer, October 18, 1999

Hola! from the most wired dormatory in America,

In case you were in a cave for the last 5 years, and just now discover a copy of Programming Perl at the entrance--why not read this tip on how to digest it easily.

I thought my CS friends were crazy. Fell asleep to Chapter 2. I dare not even look at the alphabetical Ch. 3 and 7. How can this be the famous tutorial? The problem is simple: it's a bible. Quite literally. No nonsense details, and lots of it. Don't give up. The authors thought of you. There's hope.

Heed Ch. 2's subtle suggestion as to how you might want to use the book as a tutorial:

A. The >contexts< in which Perl language features, basic Perl functions, and core Perl libraries will be used in are not in Ch. 2, 3, or 7--Ch. 4-6 reveals all. Look there instead. Code examples and real world use are simply saved for later. This is a great way to preserve the succinct nature of a deskside reference.

B. Read it backwards! Skim past Ch. 2, 3, and 7 if you have some programming background. Refer back to them as you stumble across strange terrain during your careful study of Ch 4-6. Read this way the reference becomes a tender tutorial. Your fingers will also become very familiar with the whereabouts of each toy in this treasure chest.

This book is a pearl. So is the community.

-- Li-fan Chen, November 4, 1999

Ken Mayer advised in June that, "For those in tune with 90s, there's an online book, Tcl for Web Nerds, by Lydia Sandon, which is all you probably need." I've recommended ... Web Nerds myself. However,

-- Cameron Laird, November 27, 1999
As a reasonably clueful person with some SQL and DB experience who went looking for a book on Oracle8 and bought one, I can say that (1) the Oracle8 Complete Reference is an adequate reference, (2) it's probably better than many of the other big thick books on Oracle8, and (3) nevermind those two qualified recommendations, but the author(s) must have been lifelong crack users whose previous programming and DB experience was gained by reading comic books. Well, maybe that's a little harsh, but there is some VERY silly and misguided stuff in this book, occurring mostly when the author strays into attempting to explain something other than Oracle features. Caveat emptor.

-- Joseph N. Hall, March 6, 2000
A shorter (& new / fun) book by Alan Cooper - The Inmates Are Running the Asylum ISBN: 0672316498 or (UK)
Also The Humane Interface by Jef Raskin ISBN: 0201379376 or (UK) looks interesting

-- Daniel Bodart, March 23, 2000
It's nice to see the language debate(s) is/are alive and well!

I've been a Perl hacker for many years, and I'm thankful [on a near-daily basis] that it exists. I can't say the same for TCL. Although I've grown to accept its existence, and have learned to deal with its idiosyncracies (simply because I can't use anything else inside the mighty AOLserver (yet?)), I do so begrudgingly. Syntactically, I find TCL to be a pain-in-the-tush, and far less intuitive than my beloved Perl. Additionally, its math model is primitive and rather brain-dead.

The bottom line is that I find myself wishing Perl was embedded in AOLserver rather than TCL.

-- Gary Chambers, May 8, 2000

It might be interesting to know that SICP is available online, from MIT Press:

-- Patrick Hudepohl, December 3, 2001

I have bought Mastering Regular Expressions because I found the review here, but I just would say two thinks:If anybody still thinks of buying the book, he is adviced.

-- Albert Walnut, December 10, 2001
In response to Alberto's comment about Mastering Regular Expressions, It should be noted that the book is not titled Regular Expression Cookbook for the Web.

It is however one of the clearer and more complete reference to Regular Expressions and it has proven very useful to me with Perl, PHP, vi, sed, grep, Visual Studio and so on. The book tries to explain the concept of Regular Expression, not their use. To limit regular expressions solely to the web sites and HTML is like limiting the use of electricity solely to lighting, an aberration.

-- Alexandre CV, November 9, 2002

Add a comment

Related Links

Add a link