Search in Book Reviews

In any normal year this would have received the accolade I gave to Generic Programming and the STL. When the book arrived on my desk my face lit up with anticipated pleasure. Jim is one of the fathers of the Pattern movement, his earlier book,Advanced C++ Programming Styles and Idiomsis still a book worth reading despite being written almost eight years ago. A lot has happened since, not least that Jim has added a fluency to his writing that makes his work a pleasure to read (I think I will long remember his report of Alexander's presentation to OOPSLA (96, I think) which would qualify for an award for pure descriptive writing).

Many programmers have a habit of considering C++ an OOPL. They also use OOP as if it is some form of complement and non-OOP as a derogatory description of code. This is a kind of bias that should be unacceptable. Unfortunately the result is that they come to think that any good programming idiom or method must per se be OOP.

What this book sets out to demonstrate is that there is a wealth of programming mechanisms and OOP is only one of them. For example, generic programming as exemplified by the STL in C++ is specifically and intentionally not object-oriented. Indeed you would have to distort a pure OO approach to achieve smooth generic programming. Such a paradigm does not ride happily with languages such as Java or Smalltalk.

What Jim sets out to achieve in this book is to paint a far wider canvas, unconstrained by a single paradigm or methodology. C++ is a particularly good vehicle for this because from its inception it was designed to support the way programmers work rather than attempting to force programmers to work the way some 'expert' thought they should.

If you want to broaden your perspective and are willing to risk facing a world in which OOP is not always the best then you should take the time to read this book. I suspect that having done so you will want to hang on to your copy so as to read it again in a leisurely fashion. It is true that C++ has a number of pitfalls, and languages like Java and Eiffel have fewer but when you have finished reading this book you may understand the price that is paid for that extra safety. Then you will be better able to make an informed choice of which tools and methods are appropriate to a task.

Finally, if you ever get a chance to listen to James Coplien speak grab it with both hands, he is one of those exceptional speakers that set standards that most of us can only aspire to.