Programmer's Bookshelf

Bots: The Origin of New Species

by Andrew Leonard
HardWired, 1997
218 pp., $21.95
ISBN 1-888869-05-4

Pattern Languages of Program Design 3

Robert Martin, Dirk Riehle, and Frank Buschmann (Editors)
Addison-Wesley Longman, 1998
632 pp., $41.95
ISBN 0-201-31011-2

Information Warfare and Security

Dorothy E. Denning
ACM Press (Addison-Wesley), 1999
522 pp., $34.95
ISBN 0-201-43303-6

C++ Programming Language, Third Edition

Bjarne Stroustrup
Addison-Wesley, 1997
910 pp., $44.95
ISBN 0-201-88954-4

Cyber Rights: Defending Free Speech in the Digital Age
Mike Godwin
Times Books/Random House, 1998
352 p.p., $27.50
ISBN 0-8129-2834-2

Java Gems: Jewels from Java Report


Dwight Duego (Editor)
SIGS Books & Multimedia
Cambridge University Press, 1998
230 pp., $29.99
ISBN 1-56884-322-4
Programming Perl, Second Edition


Larry Wall, Tom Christiansen, and Randal L. Schwartz, with Stephen Potter
O'Reilly and Associates, 1996
645 pp., $39.95
ISBN 1-56592-149-6

Abot, says Andrew Leonard in his book Bots: The Origin of New Species, is "a supposedly intelligent software program that is autonomous, is endowed with personality, and usually, but not always, performs a service." Like their mechanical equivalents, bots (short for "robots") are everywhere on the Internet, performing searches, attending to e-mail, playing games, and otherwise making your Web experience heaven or hell, depending on how you look at it.

In an entertaining and interesting yet curious book, Leonard chronicles the evolution of bots, identifies some of the more famous (and infamous) ones, and talks with their creators. Bots is entertaining primarily because Leonard is a very good writer. Bots is interesting because the subject matter is timely and fascinating. Still, Bots is curious because it is hard to figure out just who this book was written for. Leonard straddles a dangerous fence by providing enough technical details to stymie nontechnical readers, but not enough for programmers to get elbow deep into the critters.

None of this is surprising, considering that Leonard is a contributing writer for Wired magazine and that Bots was published by HardWired, the magazine's book-publishing arm. If you like Wired, you'll probably like Bots, although the book does read like a far-too-long magazine article at times. Add to this the Wired look-and-feel (green ink, horizontal drop-caps in weird fonts, unreadable page numbers), and...well, you get the idea.

Nonetheless, Leonard talks to all the right people in the bot world and provides an excellent bibliography for further study. And, as evidenced by conversations with the likes of user-interface guru Ben Schneiderman and others, Bots provides plenty of food for thought.

-- Jonathan Erickson

Asoftware design pattern is a solution to a particular computing problem. Each pattern has, in general, four parts: the pattern name, the problem to be solved, the solution provided by the pattern, and the trade-offs. Familiarity with patterns makes software design easier, because large concepts can be dealt with using the patterns, rather than reinventing the wheel in each program.

A recent presentation on patterns comes via Addison-Wesley's Corporate & Professional imprint. The production quality of Pattern Languages of Program Design 3, edited by Robert Martin, Dirk Riehle, and Frank Buschmann, is excellent, and the binding easily endured the two months I spent reviewing the text. Most importantly, because you'll find yourself reading the text with pen in hand, the pages are of sufficient thickness to take marginalia and highlighting without bleed-through. This is a nice book.

The editors have selected 29 papers presented at the Pattern Languages Of Programming (PLoP) '96 and EuroPLoP '96 conferences. The papers are grouped such that the book has 10 parts, which range from the introductory "General Purpose Design Patterns" to the more ethereal "Patterns On Patterns." Each part is briefly introduced by one of the editors. The book is brought to completion with a brief bio-graphy of each contributor and an index.

A large number of people were involved with the production of this volume. Many papers are the product of a team of authors. The papers were worked into the conferences by "shepherds," whose clarifications and assistance were thankfully received by several authors. The editors invoked a large number of reviewers (a half page list). As one would expect with this many eyes reading and commenting on the text, it is in good English, with complete, declarative sentences. My personal bugbear -- typos -- are almost nonexistent.

The majority of the authors use graphics to present alternative views of their pattern. These include the Booch cloud, class structure, object sequence, collaboration, and interaction diagrams. Unfortunately, the symbols used on the diagrams are not explicit in the text; the reader is assumed to be familiar with them. There is also a smattering of jargon, so I recommend that you not start your pattern education with this text. Rather, begin with Design Patterns by Gamma, Helm, Johnson, and Vlissides (Addison-Wesley, 1995), which is referenced in 33 of the 39 sections of the book. (By the way, you'll also need to know that those authors are known in the patterns community as the "Gang of Four," abbreviated "GoF.") A familiarity with James Coplien's writings also would be helpful, and you should have a reading knowledge of C++ and Smalltalk.

There is no disk or CD provided with the book. This deficiency is more than overcome by the inclusion of the authors's web-page URLs, their e-mail addresses, and several Internet list servers and news groups.

So what's new? In the introduction, Brian Foote writes,

"What's new here is that there's nothing new here."

This is to be taken in the sense that the patterns presented in the book are not being exposed to the light of day for the first time, but rather, have been used in actual working programs. Because the patterns document things that work, it is reasonable to conclude that they may work in other situations, perhaps yours. The advantage of studying published patterns is, of course, the benefit of having a few more minds applied to your problem at a minimal cost.

I found the Asynchronous Visitor pattern to be the most interesting. It corrects a problem inherent in the GoF Visitor pattern, the purpose of which is to allow one to indirectly modify a class hierarchy. After further study and argument, it has been found that the Visitor pattern introduces a dependency cycle of the base class on all its derivatives, so any additions to the Visitor class require a recompilation of the entire hierarchy. The Asynchronous Visitor pattern separates the visitor class from the hierarchy, and hence minimizes the need for recompilation, which can be quite dear in C++ programs.

I draw two lessons from the chapter on the Asynchronous Visitor pattern: It is a "better" pattern than Visitor. Patterns can't be applied blindly -- some experience with them is necessary. Second, a pattern that "works" (Visitor) may not work all that well after all.

These lessons belie the stated purpose of The Software Pattern Series, inscribed on the back of the frontispiece: "Books in the series distill experience...into a form that software professionals can apply immediately." This is too hasty by at least two measures:

• It takes time to assimilate and evaluate patterns merely to ascertain if they are suitable for use.

• It would be rare for a professional program designer to accept anything into a program immediately, since one must live with the side effects of both good and hasty decisions. A reader therefore does well to evaluate both the patterns and the claims thereof.

Although written somewhat tongue-in-cheek, the last paper in the book, "A Pattern Language for Pattern Writing" by Meszaros and Doble, might be the easiest place to start studying the book. It shows how to put a pattern article together, and hence makes it easier to take the other papers apart.

The least useful patterns were those devoted to the process of software development; that is, how people interact to produce the stuff. These patterns are devoted to evolving frameworks, designing in teams, and testing. These papers are mostly good advice that has been presented at far greater length, and with greater clarity in other venues: Peopleware by DeMarco and Lister jumps to mind.

PLoPD3 is no novel. It is a difficult book to read, for you are reading the documentation and code of other programs. It is not a book to skim once and shelve. Rather, I suggest you read a paper, try to imagine how you would use the pattern, and try some of the sample code. Try to imagine some of the problems that will occur if you use the pattern. With this admittedly conservative approach, the book will take a few months to read.

-- Peter N. Roth

Dorothy Denning is one of the world's most respected computer-security experts. She's also the author of the now-classic Cryptography and Data Security (Addison-Wesley, 1982) and a professor of computer science at Georgetown University. But if Denning ever wants to chuck it all and opt for an honest living of, say, writing horror stories, her most recent book, Information Warfare and Security, has all the source material she will ever need. Before finishing half the book, I was ready to cancel my e-mail accounts, jettison my modems, cancel my credit cards, move what little money I have from the bank to my mattress, and head out for the Flint Hills.

You see, part of what Denning has done in Information Warfare and Security is chronicle what seems to be just about every breach in computer security over the past few years. Page after page of hacks, cracks, phreaks, and psyops by everyone from teenagers and thrill seekers to spies and nuts. Credit card numbers, passwords, bank accounts -- they're all fair game for anyone who is bright, persistent, online, and so inclined.

Not that it was Denning's intent simply to titillate us with one interesting or exciting story after another. Instead, her goal is to provide us with a comprehensive overview of what's become known as "information warfare." In defining this term, Denning relies on a definition supplied by Winn Schwartau in his book Information Warfare (Thunder's Mouth Press, 1996) whereby:

Information warfare consists of those actions intended to protect, exploit, corrupt, deny, or destroy information or information resources in order to achieve a significant advantage, objective, or victory of a specific adversary or adversaries.

However, Denning doesn't stop there. She goes on to explain that she attempts to take the definition deeper, to

...provide a theory of information warfare based on the value of information resources to an offense or defense...Information warfare is a 'win-lose' activity. It is about 'warfare' in the most general sense of conflict, encompassing certain types of crime as well as military operations.

To that end, Denning opens Information Warfare and Security with a description of the role of information warfare in the Gulf War. The brief history she presents is both interesting and exciting and immediately pulls you into the book. This chapter kicks off "Part I: Introduction" of the book, which covers other topics such as the author's theory of information warfare, issues such as motivation, and types of computer crime. From there, Denning moves to "Part II: Offensive Information Warfare," which addresses topics such as open source (no, not source code, but the information about all of us that is open and easily accessible), psyops ("psychological operations"), traitors and moles, corporate espionage, dumpster diving, shoulder surfing, phone phreaking, packet sniffers, e-mail forgeries, and much more. Finally, in "Part III: Defensive Information Warfare," Denning surveys the tools and techniques that enable individuals and organizations to protect themselves from attacks: cryptography, RSA, biometrics, digital signatures, trash disposal, firewalls, and the like.

Although Denning does explain the basics of topics such as public-key encryption in Part III, Information Warfare and Security isn't a technical book. Instead, it is perhaps the best single overview of the real-world security issues that you'll find. And what makes the book particularly interesting is that Denning puts the various types of computer cracking into the broader context of topics such as phone phreaking (hey, I always like to read about the exploits of Cap'n Crunch) and other forms of information warfare. In fact, it is hard to imagine how she was able to gather all of the incidents described and present them in a coherent manner that keeps you reading.

In all likelihood, Information Warfare and Security won't realize over time the "classic" status of Cryptography and Data Security (they're not the same kinds of books), but it is important as a comprehensive introductory survey of the challenges we face in the coming century.

--Jonathan Erickson

Bjarne Stroustrup's The C++ Programming Language, Third Edition has been available for a while. This work, by the creator of C++, is the definitive treatment of the subject and has been since its first edition in 1987. I must confess that I did not care for the first edition. I had expected a tutorial approach as elegant as the classic K&R white book. But then, K&R was about C, a programming language that supported a familiar programming model. The C++ programming model was new to most of us 10 years ago, and Stroustrup's first edition was daunting, to say the least. Looking at it now, I find it far less so and much easier to read.

Comparing the first and third editions of The C++ Programming Language provides insight into how the C++ language has grown and changed in the past decade. The third edition has almost three times the number of pages and a slightly different organization. Whereas the first edition included a 67-page language reference manual at the end, the third edition includes only a language grammar section to represent formal language definition. This is appropriate. The ANSI/ISO Standard document, which is now the formal language and library definition, is itself about 750 pages long. Stroustrup plans to publish The Annotated C++ Language Standard (coauthored by Andrew Koenig, the ANSI C++ committee's Project Editor) sometime this year.

The third edition takes a tutorial approach with many of Stroustrup's personal programming philosophies. The author's explanations of how he uses language features provide examples for learning the behavior of those features. He also explains code idioms that some programmers routinely use but that he finds inappropriate.

As much as possible, the third edition reflects Standard C++. When small language features are found to be missing, particularly new ones, Stroustrup pledges to add them to a future printing.

The book includes many code examples. There is no diskette or CD-ROM, because Stroustrup avoids a teaching approach wherein readers compile and run examples. His examples are mostly code fragments that demonstrate the points he makes and the issues he addresses. The code fragments are readable, meaningful, and neither frivolous nor cute, and since you do not compile them, you need not worry that your compiler does not fully support Standard C++. There are four parts to the body of the book: "Part I: Basic Facilities;" "Part II: Abstract Mechanisms;" "Part III: The Standard Library;" and "Part IV: Design Using C++." Even if you are already a seasoned C++ programmer, Part IV, which is a rewrite of several chapters from the second edition, is worth the price of the book. It describes Stroustrup's philosophies on the design and development cycle of a software project involving C++. In his words, Part IV aims "to bridge the gap between would-be language-independent design and programming that is myopically focused on details."

The three appendixes are: "A: The C++ Grammar;" "B: Compatibility;" and "C: Technicalities." Appendix B discusses the differences between C and C++ and explains how the languages have become more compatible over time. Some of this convergence results from changes being made to the C specification (double-slash comments and no implicit int, for example). The appendix also discusses the issues related to porting C++ code from older C++ implementations, advising that, where possible, you should use the latest implementation of a compiler so that newer features are available to you.

Appendix C is about technical details that a programmer faces that are not necessarily language issues. I particularly like the discussion on the problems associated with traditional multidimensioned arrays as compared to using STL containers to achieve the same result without the headaches.

This book is an essential addition to a C++ programmer's library. It is not for dummies, and it wouldn't be my first choice for an entry-level, self-help tutorial on C++ for beginning programmers. It is, however, an excellent textbook for programmers who are self-motivated and students who study under the watchful care of a skilled instructor. As an experienced C++ programmer, I find the book useful as a reference to language usage and behavior. The author invented the language and then stayed close to the standardization and innovation process for the duration, always maintaining a careful vigilance over the evolution of his brainchild. Consequently, this book serves, for those who do not care to pore over the ANSI/ISO document (or the promised annotated version), as the authority on the Standard C++ language, how it works, and how you should use it.

-- Al Stevens

Cyber Rights, by Mike Godwin, is a book for any champion of the rights of the little guy. Godwin, counsel to the Electronic Frontier Foundation, set out in this book to explain cyberspace and why it matters; to show how the law and the U.S. Constitution apply to cyberspace, or how they should; to answer widespread fears about cyberspace; and to defend the Internet. I think he does a good job on all counts.

Godwin is not a dispassionate observer. If I read his biases correctly, he believes that it's better for children to live in an adult world than for adults to live in a child's world; better for the guilty to go free than for the innocent to be punished; that freedom is not a means to an end but a human need.

Godwin has been involved in some landmark cases involving the Internet, sometimes only peripherally. The book is organized around those cases, and although it does justice to the cases and to the law, it is hardly dry legalese. Godwin is a surprisingly readable writer. In part it's because he is passionate about what he's writing; in part, because the issues are so important. But it's also because he's a good writer.

Cyber Rights addresses the whole range of speech issues on the Net: libel, what it means, and whether the concept even applies to the Net; hate speech; privacy; copyright and other intellectual property issues; censorship, obscenity, and whether there's any sense in applying community standards to a global medium. The capstone of the book and of Godwin's career to date is the defeat of the Communications Decency Act of 1996, a triumph of common sense over FUD.

-- Michael Swaine

Iimagine that I'm the last programmer who hasn't written a line of Java code. I hear there is a large demand for Java programmers, but I haven't gone looking for a Java job, and don't plan to. I fail to see how I can make use of an interpreted language for my primary deliverables -- engineering number-crunching applications. So why am I reviewing a Java book? For the same reasons you should read it.

The first is readability. The first article I turned to in Java Gems: Jewels from Java Report was a comparison of C++ and Java by Robert Martin, whose writing I have admired for a few years now. Martin is the current editor of the C++ Report, and sets out to compare the languages sans the usual language flame wars one encounters on Usenet newsgroups. Martin likes both Java and C++, and points out the weaknesses and strengths of each language from his view as one who enjoys programming in any language.

The second reason to read this book is that it can show you how to improve your web site. I confess that most of the goings-on on the web are still a mystery to me, but I do have a web site whence to market software. Anything that will help my customers is therefore "A Good Thing." The gem by Lowell Kaplan demonstrates a way to get Java to talk to CGI scripts, albeit in code presented in what looks like 4-point type.

A third reason is that I like to know what's going on. The text is current; articles considered for republication appeared between March 1996 and June 1997. Okay, to an engineer this is current; to someone on wherever the bleeding edge is, this is paleontology. But it was interesting to note that there are a few articles dealing with the notion of persistent Java objects. I would hope persistence is a "solved problem" by now.

Finally, Java Gems: Jewels from Java Report is a convenient book. I found that I could jump in anywhere, read an article, and then leave the book until I had some spare time. Every article is supplemented with e-mail addresses and URLs for follow-up, and most of them have a fair amount of Java code to read.

Two cautions: First, because these articles are gems, they are short; the coverage of a topic is brief and to the point. Second, most of the authors are Java True Believers, so set your hype filter to stun before diving in.

-- Peter N. Roth

How do you write the canon for a programming language that you created? Some writers will spend much of the reader's time trying to prove that their language is naturally superior because it was conceived by their superior mind. They are the ones that sprinkle their books with phrases like "as you can clearly see" as a preamble for ideas only understood by green-blooded science officers that say goodbye with "live long and prosper." Even among the humble, most write a reference book with the warmth of a logarithmic chart and the pathos of a decision table. But, in keeping with the Perl philosophy of TMTOWTDI, Wall shows us a more excellent way.

Programming Perl has warmth, personality, and, at unexpected times, brilliant wit. It feels like a explanation from a close friend. It even has a short section on Perl poetry.

How warm is it? Perl is the only language with an officially sanctioned "thingy." A thingy, as defined by the authors, is "a value that is sort of like an object, that you may or may not know the name of, but that you can refer to via references from which the thingy dangles, metaphorically speaking." I don't feel quite so guilty now for checking the do-lollies in my C code by setting the warning level to puke-on-all.

Programming Perl is not an easy introduction to the language. This is especially true for the UNIX-challenged. The authors casually assume you know about things (or should I say thingies) like character block devices, UNIX-file permissions, and utmp files. If you expect a C> prompt when you sit down in front of a SUN -- start with a different book. Also, Programming Perl, like the language, is very dense. Complex ideas are compressed into the shortest space possible. What else would you expect from the folks that brought you the elusive and oft unseen $_ variable? If you are new to Perl and inherited a web site with Perl CGI scripts that must be changed by next Monday, try Learning Perl by Randal Schwartz instead.

While Programming Perl is not a good introduction, it is the definitive reference of the language. It is the one required book for all Perl programmers. It is the original source for syntax, semantics, and core functionality. It is the Perl version of The C Programming Language by Kernighan and Ritchie. It's the same thing, only funnier.

-- Donald Bryson

DDJ