Dr. Dobb's Journal June 2002
In computing as elsewhere, good ideas often finish last. This often happens because their technically inferior competitors were backed up by a better marketing team. Equally often, though, it happens because there simply isn't enough room for all the good ideas at once. As a result, many things that people really ought to know and use are left by the wayside.
Take computer security, for example. It may be a hot topic today in the media, but it is virtually ignored in university curricula. Everyone agrees that it's important and really ought to be covered, but no one can agree on what to drop to make room for it. Most programmers, therefore, have to pick it up piecemeal on the job.
Richard Smith's Authentication: From Passwords to Public Keys is a good place to start. Instead of trying to cover the whole topic of security, Smith looks in detail at one specific problem: How do I prove to a computer that I'm who I claim to be? Smith starts by analyzing the problem, and the ways in which someone might attack authentication systems. He then looks at the evolution of password-based authentication and the social aspects of security. Each subsequent chapter examines a different authentication technique including smartcards, biometrics, Kerberos, and digital certificates.
The discussion is technical but code free as Smith's main aim is to explain each system's capabilities and limitations, rather than how to program to a particular vendor's API. His explanations are easy to follow, even when the subject matter is complex, and the diagrams are equally clear. All in all, Authentication is an excellent survey and I recommend it whole-heartedly.
The subject of Richard Mitchell and Jim McKim's Design by Contract, by Example is another example of a good idea that somehow got squeezed out of the mainstream. Design by contract is a technique for managing the complexity in object- oriented systems that first appeared in Bertrand Meyer's language Eiffel. A "contract" is a set of preconditions that must be true before a method can safely be called, plus another set of postconditions that the method guarantees will be true when the call completes. Together, these constraints allow programmers (and compilers) to reason about chains of method calls more effectively.
Preconditions and postconditions can be implemented in most modern languages by putting assertions at the start and end of methods. However, Meyer realized that if a class B is derived from a class A, then B's methods must have the same or weaker preconditions as A's, and the same or stronger postconditions. What's more, if a class changes over time, then each new version must satisfy these same constraints. These extra constraints are what make design by contract such a powerful technique, but they are almost impossible to implement without language and compiler support — which has, unfortunately, not been forthcoming. As a result, most Java and C++ programs are littered with classes that don't quite work the same way as their parents.
Mitchell and McKim's book is a well written, well-organized introduction to design by contract. Six basic principles are laid out early on and then applied to a series of increasingly complex examples. Most of these examples are written in Eiffel, but anyone who has any experience with object-oriented programming should be able to follow them easily. And even if the language you're using doesn't support contracts directly, this is a powerful analysis and design technique, and well worth adding to your bag of tricks.
The last book in this month's trio covers basic data processing in Perl, but is aimed at a crowd who normally aren't taught much about programming at all. Computers are now as important to scientists as test tubes and telescopes, but most universities don't teach science students any more about programming than they did 25 years ago. Most physical scientists, therefore, have to pick up stream processing and regular expressions on their own.
A new series of books from O'Reilly & Associates is trying to meet this need. The first book in the series (Gibas and Jambeck's Developing Bioinformatics Computer Skills) tried to cover too much, and as a result didn't give enough time to any one topic to really be useful. James Tisdall's Beginning Perl for Bioinformatics, on the other hand, is exactly what the average over-worked geneticist needs. Tisdall assumes that his readers have never seen Perl, and have forgotten most of what they might once have known about programming in some other language. Over the course of a dozen chapters, he introduces Perl's basic operations and shows how they can be used to parse and manipulate common biological data formats. Experienced programmers will probably find the pace much too slow, but Tisdall's careful dissection of each example in turn is just right for his intended audience.
DDJ