Dr. Dobb's Journal July 1997
Most authors write because they hope to strike it rich, or because it's part of their job, or because they have something they're itching to tell you about. Jonathan Rosenberg's How Debuggers Work falls into the third of these categories. After helping to develop the tools that made MasPar's MP machines easier to program than most parallel supercomputers, Rosenberg moved to Borland, where he worked on debugging tools. Having read the blurb on the back of this book, I hoped it would be for debuggers what Tanenbaum's Operating Systems: Design and Implementation was for its subject: a practitioner's guide to what matters when you actually have to get something built.
Unfortunately, How Debuggers Work falls short. Rosenberg covers all the right topics -- hardware and OS support, breakpoints, context and data inspection, multithreading, GUIs, and how to handle optimized code -- but each time I thought he was about to get into the nuts and bolts, the section or chapter ended.
For example, after pointing out that the PowerPC can normally execute instructions out of order, but always executes them in order when debugging, he says, "This is something for debugger developers and users of the PowerPC to watch closely." I'm grateful for the warning, but I would have been more grateful if he'd told me what I could do about it. Similarly, after pointing out that it can be difficult to set breakpoints on single-line for loops and outlining a simple-minded solution, Rosenberg says, "This solution is not foolproof...," and then he stops.
How Debuggers Work could also have benefited from more careful editing. The list of Java debugging classes, for instance, contains the meaningless "public class extends RemoteValue" seven times, a mistake that is repeated in the tables later. Someone should also tell the author that the Heisenberg principle doesn't actually say that "[a] debugger must intrude on the debuggee in a minimal way."
Having been so critical, I should now say that I think this book has a lot of potential. None of the undergraduate computer-science programs I'm familiar with teach students how to build tools for debugging, profiling, dependency management, or version control. As a result, most undergraduates enter the workforce either not knowing how to use such tools, or believing that they aren't really important. (After all, if they were as important as parsers, we'd have done four homework assignments on them as well, wouldn't we?) If Rosenberg were to turn this book into a practical guide of the sort that exists for operating systems and compiler construction, he would do computing a great service.
The second book on my list, Programming Language Choice, was an even greater disappointment. Sooner or later, everyone in computing gets embroiled in a debate over the relative merits of different languages. A few years ago, after sitting through yet another presentation in which yet another parallel programming language was called "intuitive, powerful, and flexible," I decided to look through the literature for experimental comparisons of the usability of different programming languages.
I was surprised to discover that few have ever done such experiments. Think about that for a second: Almost everyone believes that some languages (Smalltalk, C++, Perl, Scheme) are "better" than others (Fortran and Cobol being the usual targets for scorn), but I was only able to find one group that had ever tried to quantify the differences ("An Experiment to Measure the Usability of Parallel Programming Systems," by Duane Szafron and Jonathan Schaeffer in Concurrency: Practice and Experience, 8(2), 1996). So much for the "science" in computer science.
When I mentioned this to colleagues, they were less surprised than I had been. "There's so much variability among programmers that no study could be meaningful," was a common reaction, while another was, "The needs of different domains are so different..." However, pharmacologists manage to study the effectiveness of drugs, despite variations in sensitivity of up to 10 million to 1, and they don't seem bothered by having to specify an application area before starting a study. Even in computer science, we measure the usability of GUIs. Surely, I thought, something similar could be done for the one tool that every programmer uses?
When I came across this book, I hoped that it might be a step toward that goal. No such luck. With a few exceptions, this book might as well be titled Programming Language Advocacy. Most contributors simply describe their favorite language, then claim that it is well suited to undergraduate teaching, without offering any evidence stronger than their personal preferences. At its worst, this advocacy degenerates into hype. Do you believe, for example, that "Almost all Smalltalk projects succeed," or, "While other languages were being deliberately shaped to encourage particular design approaches, Lisp...could mold itself around any approaches that seemed appropriate"?
Matters aren't helped by the fact that the conference that gave rise to this book was held in September 1993. As a result, there is no mention of Java, whose ubiquity, safety, and object orientation make it a very strong candidate for undergraduate education, while Ada 95 is spoken of in the future tense, and defunct research languages like CooL and Omega are given as much space as Smalltalk and C++.
Programming Language Choice does have two redeeming features. The first is Marian Petre's discussion of programming paradigms and cultures, which is worth reading carefully. She points out that most programmers unconsciously shift the paradigms of the language they happen to be working in. Similarly, in the absence of a clearly defined model of what the computer is doing, both expert and novice programmers will borrow from whatever models they have and construct a "just-so" story to explain the behavior they observe. I also enjoyed the chapter by Lee and Stroud on C++, primarily because it laid out, in detail, the criteria to use in choosing a teaching language. These discussions make the book worth borrowing, but you'll probably want to spend your money elsewhere.
The same is true of The Media Equation, even though it is a much better book. Reeves and Nass both work at Stanford University, where they study how people react to and interact with computers, television, and other media. They have discovered that even when people know they're dealing with a machine, they treat it as if it were a social being -- a person. Similarly, people who've been flattered by a computer program will think that they've done better work with it, even if they know that it's just a program and that its flattery is preprogrammed.
This may sound a bit trite, but the authors' initial detailed description of their experiments and results is fascinating. However, I was less fascinated by their third and fourth detailed descriptions, and by Chapter 6, I was really hoping to see a sentence starting, "We can summarize our other work as follows..." Topics discussed in the book's later chapters aren't any less interesting, but after 200 pages, I'm more interested in conclusions than experimental design.
DDJ