Python, C++, and Other Religions

However, as time went by, the initial simplicity of a lot of these utilities was obscured by creeping "featuritis." Make, for example, started off as a simple semideclarative way to describe dependencies between files, but the addition of conditionals, loops, macro transformations, and other facilities over the last quarter of a century have turned it into an exceptionally clumsy programming language. Similarly, vi (the simple UNIX editor) now has more features than early versions of the operating system upon which it was developed. The result is that mastering these basic tools is now much harder than it needs to be.

This isn't just a personal opinion. Most of the scientists and engineers in the software engineering classes I teach at Los Alamos National Laboratory (LANL) have graduate degrees in theoretical physics, mechanical engineering, or similar disciplines. They're smart, and they're used to working hard. They would like to move their programs off specialized supercomputers and onto Linux-based clusters, but their efforts are being frustrated by the unnecessary complexity of configuring Bugzilla, deleting directories in CVS, quoting shell variables in make, and so on.

LANL has therefore set up a project called "Software Carpentry" (see http:// www.software-carpentry.com/), the aim of which is to produce a new generation of tools that will be easier to use than those we have today. To make it easy to install these tools, write scripts for them, and make them talk to each other, the decision was made to use Python for all implementation work. (If there had been a simple, lightweight component system that ran on both Linux and Windows, it would probably have been chosen instead, but Linux implementations of COM have been hampered by patent issues, and CORBA is neither simple nor lightweight.)

That's when the flames started. It was easy to discount people who thought that Software Carpentry was some kind of pro-Python conspiracy: That's simply not what had happened. I also had a clear conscience about deleting flames that said that [pick a random language] should have been chosen instead. Feedback from 140 students over a year and a half convinced me that Python was much easier to learn than the alternatives, and none of the flamers had anything other than personal anecdotes to back up their preferences.

The comments that really bothered me were those from people who felt that programmers ought to be allowed to use whatever language they wanted. I agree that it would be easier for someone who already knows Tcl, Perl, or Ruby to write tools in those languages than in Python, but what about the poor, often-forgotten user? If you want to use all the programming tools that come with a full Linux installation these days, or use a metatool like autoconf, you have to master Perl, Python, Tcl, Emacs Lisp, two major flavors of shell, and several slightly different flavors of regular expressions. That is simply too high a price for someone who is already running as fast as she can to stay on the leading edge of fluid mechanics research. Advocating it is about as sensible as suggesting that online help should be written in whatever mix of English, Esperanto, and Klingon appeals to individual developers, and betrays a self- centeredness that may go a long way toward explaining why so much of today's software is so hard to use.

So Python it is. If you haven't looked at the language already, it is to Perl or Visual Basic what Java is to C++ (but without any marketing hype). I expect the previous paragraphs will engender even more flames on the subject; I promise to read and reply to all those that are (a) polite, and (b) based on something other than personal anecdotes, or the kind of "but it's obvious" arguments that led Aristotle to believe that heavy objects fall faster than light ones.

Which brings us, finally, to this month's books. The first, The Quick Python Book, by Daryl Harms and Kenneth McDonald, is an introduction to the language for people who already know how to program. The first part of the book covers the language's major features, from simple I/O to object-oriented programming. The middle of the book describes packages, overloading operators, and regular expressions, while the last part explores COM programming, interfacing to C/C++, JPython (an implementation of the language that runs on the Java Virtual Machine), and other specialized topics. The writing is clear and, except for Chapter 4 (a soup-to-nuts overview of the language that will probably just leave most readers confused), well organized.

Except for its weight, Martin Brown's Python Annotated Archives is a good second book on the language. Each chapter is a detailed dissection of a single useful script, such as a quick web log reporter or a utility that creates a tree of symbolic links to mirror an existing directory structure. It's not something you'd want to read all at once, but if, like many programmers, you learn best from examples, this might actually be the best way to pick up Python.

Despite starting with an excellent summary of the language, David Beazley's Python Essential Reference really is just that -- a reference. Most of the book is devoted to the libraries in the standard Python distribution; while I would have liked more examples, my main criticism is that much of the ground it covers is already adequately covered by the online documentation at http://www.python.org/. I would have found the book more useful if it had explained more of the things that have a "to be written" flag online, and hope that the second edition will fill in the missing pieces.

Mark Hammond and Andy Robinson's Python Programming on Win32 is another O'Reilly entry in the crowded field of Windows programming books. This one manages to summarize Python in just six pages, before moving on to talk about advanced features, particularly support for COM. That support makes it possible for Python to script Excel or Outlook, talk to ODBC databases, create Windows NT services, and do everything else that Visual Basic is currently used for. Like Perl, I think that Python is a good bridge for developers moving from UNIX to Windows, and this book will help make the transition even easier.

Despite my growing fondness for Python, I'm still writing a fair bit of C++ and Java these days. I had thought that every nook and cranny of the C++ book market was already filled, but Dov Bulka and David Mayhew's Efficient C++: Performance Programming Techniques and Herb Sutter's Exceptional C++ have both proved me wrong. The first book is about the things that can make C++ programs run slowly, and what programmers can do to work around them. It is not only a worthy successor to Jon Bentley's landmark Writing Efficient Programs (which is still one of my favorite programming books), but also one of the best descriptions I've ever read of what's going on under the hood in a C++ program. Even if you don't care about speeding up your programs, this makes the book well worth reading.

Sutter's Exceptional C++ is subtitled "47 Engineering Puzzles, Programming Problems, and Solutions," which is exactly what the book delivers. Want to know how to create case-insensitive strings using the classes in the Standard Template Library? See pages 4-7 for the easy bits, and the three pages that follow for a critical look at the first solution's usability. Confused about when and how to use exceptions? See items 8 through 19. Pointers that will manage the memory they point to? That's item 37 (which has a well-deserved difficulty rating of 8). Like Scott Meyers' Effective C++ books, Exceptional C++ shouldn't be anyone's first book on the language, but ought to be read by anyone who expects to spend a year or two working with C++.

Of course, if you ask people what language they expect to be working in a year or two from now, many will say Java. While it hasn't lived up to its original "write once, run anywhere" promise, it is a solid systems programming language that is now supported by a bewildering variety of libraries. One of the most important of these is likely to be Jini, which is designed to support transient, heterogeneous networks -- in simple terms, to let tomorrow's smart refrigerator talk to tomorrow's smart watch.

If Jini takes off, Keith Edwards' Core Jini is likely to become the standard reference. If that happens, I hope that Addison- Wesley will split this book in two -- there's certainly enough material. After some early gush (the first chapter actually is called "A New Computing Paradigm"), Edwards explains what's wrong with today's networks, and the five key concepts in the Jini model: discovery, lookup, leasing (a sophisticated derivative of time-outs), remote events, and database-style transactions. The next 15 chapters then go through every aspect of the Jini API, as well as the simplified JavaSpaces layer that sits on top of it. There's lots of code (with more white space and fewer comments than I'd like), and enough examples to show how and where different parts of that API can be used. The explanations are clear, but occasionally assume knowledge of other parts of the Java world (such as JavaBeans) that some readers may not have.

If Jini is about how to build networks, then Jakob Nielsen's Designing Web Usability: The Practice of Simplicity is about what's wrong with the biggest network application in general use today. There's a lot of color in the book, and a lot of good advice about how to make web sites that people can, and will, use. A lot of expensive corporate sites would be much friendlier if their creators paid attention to what Nielsen says about the evils of frames and splash screens, or to his simple explanations of why cool ideas such as 3D navigation don't work in practice. Over and over, I found myself saying, "Well, of course," and then realizing that I had actually made the mistake he was describing. Following the advice in this book isn't guaranteed to make your web site a good one, but not following it is almost certainly going to make it bad.

Michael Berry and Murray Browne's slim volume Understanding Search Engines: Mathematical Modeling and Text Retrieval, looks like it was typeset some time in the early 1980s, but the technologies it describes are key to dealing with the biggest challenge facing the Web in the 21st century. As more and more content and pseudocontent becomes available through the Internet, we need increasingly more powerful tools for searching and indexing it if we are not to find ourselves in the same situation as the hapless denizens of Borges' Library of Babel. This book examines both the mathematics behind modern information retrieval systems, and the nuts and bolts of preparing documents, managing queries, and responding to feedback from users. At 116 pages, it is one sixth the size of Core Jini, but in the long run, it's likely to prove at least as useful.

The last two books on this month's lengthy list are both concerned with making programs better. In Toward Zero-Defect Programming, Allan Stavely describes how the Cleanroom practices developed at IBM can lead to dramatic reductions in defect rates, and long-term maintenance costs. The lengthy semiformal invariants and proofs that the Cleanroom method requires programmers to write will seem like overkill to many, but only because society keeps letting us sell software that isn't guaranteed to work. Sooner or later, we're going to have to meet the same standards as housing contractors and toaster manufacturers; when that happens, I for one will be grateful for the simple, straightforward explanations in Stavely's book.

Finally, there is Game Architecture and Design, by Andrew Rollings and Dave Morris. When I first saw the blurb for this book, I hoped that the authors had finally given me a chance to cross off one of my "Reviews of Unwritten Books" (http://www .ercb.com/feature/feature.0012.html). Alas, while this book has some worthy points, it tries to do too much. There is definitely a market for a book on how to design modern computer games. There is also a need for a book on how to manage development of game software (although I don't believe that games are as unique in this respect as the authors claim in their introduction), and on how to implement games using C++, COM, and other technologies. But in trying to cram all of this into one book, the authors have too often sacrificed continuity. Poor editing doesn't help here -- there are not only some obvious cut-and-paste typos, but different chapters use different diagrammatic notations and occasionally contradict one another. I think game developers are better off reading this book than nothing at all, but they'd be better off still to pick up Steve McConnell's Rapid Development.

DDJ