As the saying goes, there's good news and bad news. The good news is that if I switch on the radio, I have a reasonable chance of hearing the Doobie Brothers singing "Black Water." The bad news is that kids are wearing flares and platform shoes again.
Luckily, there's more good news as well -- Brian Kernighan and Rob Pike have a new book out. Their initial joint effort, 1984's The Unix Programming Environment, was the first comprehensive introduction to the standard UNIX toolset, and in many ways remains the best. It, and three other books with Kernighan's name on the spine -- The C Programming Language, Software Tools, and The Elements of Programming Style -- had a lot to do with UNIX becoming the world's most popular operating system. (Yes, I know Windows is more widely used: I said "popular" on purpose.)
The Practice of Programming recapitulates and updates the best parts of those four books. Coding style, interface design, testing and debugging techniques, and ways of improving program performance are discussed lucidly and authoritatively. As a bonus, some of the examples are implemented in two or more of C, C++, Java, Awk, and Perl, so that Kernighan and Pike can compare and contrast those languages's strengths and weaknesses.
Upon reflection, however, two things about this book left me feeling slightly depressed. The first is how little software development practices have changed in 20 years. Most programs are still written without ever having really been designed, and tested haphazardly if at all. In a lot of ways, we have changed less since the 1970s than the big car manufacturers or grocery chains. The second thing that depressed me is that I'll probably be able to say the first thing again 20 years from now, when the Doobie Brothers are back on the radio for the third time...
The way we program might not change in the next two decades, but the hardware our programs run on is bound to. How to Build a Beowulf, by Thomas L. Sterling, John Salmon, Donald J. Becker, and Daniel F. Savarese, provides a glimpse of what that hardware might be like. A "Beowulf" is a supercomputer constructed from mass-produced PC components, and running freely available software. The term comes from NASA's Beowulf project, which built the first such machine in 1994. Today, for a couple of hundred thousand dollars, you can build a machine that has 200 state-of-the-art microprocessors, several gigabytes of RAM, and a fast interconnection network based on any of several switching technologies. Such a machine is not only more powerful than anything that existed in the world a decade ago, it is probably also more reliable, since its hardware and software are both mass-market products.
How to Build a Beowulf discusses everything from the choice of processors for such a machine (x86 compatible is the favorite choice, with the DEC Alpha a close second), through installing and configuring Linux, to network protocols, security, and application programming. Mass-produced components like PC motherboards and memory chips are part of what makes Beowulf-class machines possible, but free software like Linux, the GNU compilers, and the Message-Passing Interface (MPI) are just as important. As web server stats show, Linux is already more stable than many commercial operating systems; that stability is crucial if you are trying to keep 200 or more instances of the OS up and running simultaneously. Similarly, the openness of MPI has freed programmers from dependence on the proprietary (and usually short lived) programming systems foisted on them by vendors in the bad old days of the 1980s and early 1990s.
Programming a massively parallel machine is still no easy task, as the failure of the parallel computing start-ups of the last two decades shows. Now that machines of this kind are within the reach of medium-sized companies and academic departments, however, and given the speed with which enterprise applications like Oracle are being ported to Linux, I expect that parallel computing is finally going to go through the "phase change" that hit desktop computing in the early 1980s. Of course, I said the same thing in 1989...
This month's third book -- Developing Visual Basic Add-ins, by Steven Roman -- is narrower than How to Build a Beowulf, but will probably be of more immediate use to a lot of programmers as a result. All major Windows tools expose large parts of their functionality through a COM interface. This allows developers to call on such things as Microsoft Word's spelling checker, or Excel's calculation engine, from applications written in C++, Visual Basic, or even Perl. It also allows you to add functionality to those tools, and in particular to extend Microsoft Developer Studio by adding your own buttons, toolbars, and windows to it.
Microsoft's own descriptions of how to do this are contradictory and incomplete, but that's where Roman's book comes in. After a short introduction, Roman dives into the specifics: what a basic add-in has to provide, how it can register itself, how to add menus, how to handle events, and so on. Marginal flags show which pieces of information are VB5 or VB6 specific, and this information on its own almost justifies the cost of the book. Finally, at 171 pages (not counting a few pages of advertising at the back), the book has the almost unique property among Visual Basic books of being small enough to hold comfortably in one hand...
The final book this month is Graph Drawing: Algorithms for the Visualization of Graphs, by Guiseppe di Battista, Peter Eades, Roberto Tamassia, and Ioannis G. Tollis. The title is an accurate summary of the book's contents, but doesn't do justice to its breadth. Section 5.1, for example, is devoted to angles in orthogonal drawings, while Chapter 7 covers incremental construction techniques. The style is academic -- there are a lot of references, and a lot of proofs and lemmas -- but the book will be a rich mine of ideas for anyone who is trying to persuade a computer to turn data into dots, boxes, lines, and arrows.
DDJ