eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Nonprogrammers underestimate the challenge of writing programs that actually work, all the time, with never a strange behavior or erroneous result. It might be useful, if perhaps insanely difficult, to attempt to convey that challenge by writing a laymans interpretive guide to a book such as “Java Puzzlers: Traps, Pitfalls, and Corner Cases,” published last year by Addison-Wesley.
Assembled from talks and articles by Google developers Joshua Bloch and Neal Gafter, “Java Puzzlers” is almost recreational reading for anyone whos ever programmed—even for someone whos never coded in Java. The basic truths are that universal.
The messages of the book are especially pointed, though, in the context of Java, a relatively modern language and one that goes to considerable lengths to eliminate many common and venerable sources and types of programmer error.
I hope that Bloch and Gafter will forgive me for spoiling Puzzle 48 of the 95 puzzles in the book. Its a perfect example of the gap between the vague ideas of software technology that one finds in the mainstream business press and the sharp-edged realities of actually trying to apply those ideas.
The puzzle shows a piece of code that defines a class “Dog,” whose members bark, with a subclass “Basenji,” whose members specifically do not bark. When that code is executed, both an instance of Dog (rightly) and an instance of Basenji (wrongly) yield a “Woof!”
Why does this happen? The answer depends on knowing the difference between things that happen when code is compiled and things that happen when code is actually run. Two different ways of writing this program will differ in this crucial respect: One program will know only that its dealing with Dogs at the time that it decides how each object will behave, ignoring the run-time knowledge that one of those Dogs is a special-case subclass.
There are plenty of books of programmer puzzles and challenges on my shelves, but “Java Puzzlers” does something I find especially useful: It doesnt merely explain why an odd behavior occurs; it also offers suggestions distinctly aimed at Java users in particular and programming language designers in general.
In this case, for example, it suggests to the Java coder, “Do not hide static methods—there is nothing to gain, and much to lose, from reusing the name of a superclasss static method in a subclass.” It suggests to the language designer, “Invocations of class and instance methods should look different from each other.”
None of this might seem to matter to anyone whos not a full-time developer—or even more recherché, a full-time designer of developers tools. In the modern era, though, I suggest that this is too narrow a view of the occupations that benefit from—if perhaps dont actually require—this insight into how complex systems actually behave, or misbehave.
Even nonprogrammers are becoming participants in the design of business processes that will be carried out by software—insight into language design is also insight into the design of more robust processes. Without that kind of insight, people expect too much common sense from technology-based systems.
The other day, for example, someone asked me why a voice mail system was demanding a setup procedure before it would play a message. “I already did set it up,” that frustrated user insisted. I made a critical error by replying, “If the system thinks you didnt, then you didnt.”
I meant the system was not in the desired state—for whatever reason—and that the user would have to humor it and go through the setup process again. The user was furious with me: He thought I was accusing him of being a liar, an idiot or otherwise incompetent. It was a painful conversation.
Understanding how programs can look right but work wrong is like understanding how a car can skid before you drive on ice or like knowing that a bulging can is a sign that you shouldnt put it in your grocery cart. Knowing how to use technology when it works correctly is good; knowing how it can fail to work, with what consequences, is also vital.
Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.