Dr. Dobb's Journal April 2003
Most people know Parkinson's First Law, which states that work expands to fill the time available. Fewer people have heard his Second Law: "Perfection is achieved only at the point of collapse." Based on my own experience, this is a fundamental rule of software. By the time a language or application does everything that its users want it to do, it has become so complicated that it is starting to fall apart.
I was reminded of the Second Law while reading Creating Applications with Mozilla, by David Boswell, Brian King, Ian Oeschger, Pete Colins, and Eric Murphy. As the blurb on the back cover says, Mozilla is more than just a browser. It is a complete application framework built on JavaScript, Cascading Style Sheets (CSS), an XML format for specifying GUIs called XUL, another XML format for binding actions to components, and a new component model called XPCOM. This is all very cool, and I'm sure each element's existence can be justified, but the result is significantly more complex than other systems that achieve the same ends.
Creating Applications with Mozilla does its best to make Mozilla comprehensible, but it is certainly an uphill struggle. After a quick introduction, the book tackles each of Mozilla's components in successive chapters: XUL, CSS, scripting, packaging and installing, XBL, XPCOM, and so on. There are plenty of examples and screenshots along the way, and a good index, but I really did get the feeling that I was reading about the world's biggest, most complicated steam engine, when the internal combustion era had already arrived.
Java's New I/O (NIO) package is not nearly as complex as Mozilla, although that doesn't mean it is simple. Like many programmers, I have always felt that Java I/O was more painful than it needed to be. The NIO package doesn't make simple things any simpler, but it does (finally) add regular expressions, nonblocking multiplexed streams, and (my favorite) scattered reads and writes.
Ron Hitchens's Java NIO explains these new facilities clearly and succinctly. Most of the content is available in the API documentation, but Hitchens organizes and illustrates it to make it more accessible. I found Chapter 4, on Selectors, particularly helpful, while Chapter 5 (regular expressions) did a good job of clarifying the differences between regular expressions in Java and in Python.
One of the reasons the NIO package exists is that low performance is still a major headache for Java programmers. You often hear claims that Java's performance is approaching that of C++, but the difference in reality is still often a factor of two or three. Performance Analysis for Java Web Sites, by Stacy Joines, Ruth Willenborg, and Ken Hygh, looks at the various factors that determine the speed of a Java-based web site, from garbage collection and multithreading inside the JVM to the performance of JSPs and EJBs and the impact of routers and firewalls. The authors' focus is on how to figure out where the bottlenecks are, rather than on tricks for fixing particular problems. Measurement and testing are major parts of their methodology, using both off-the-shelf tools and custom harnesses. The book is practical, down-to-earth, and well written; the only thing that is missing are exercises at the end of each chapter, so that it can be used as a textbook.
Last, and definitely least, is Hank Rainwater's Herding Cats: A Primer for Programmers Who Lead Programmers. This is, quite simply, a bad book. Its references to Star Wars are tiresome, while the author's attempt to bring Hitler and 9/11 into the discussion are both pretentious and offensive. Equally offensive is his advice to put bad programmers in testing (now doesn't that show a lot of respect for QA?), and comments like, "If you were a woman..." Perhaps his editors should have reminded the author that many programmers are women, or better still, perhaps they should have found a different book to publish.
DDJ