Customer Reviews

Multi-Paradigm Design for C++

5 star:		(7)
4 star:		(2)
3 star:		(1)
2 star:		(1)
1 star:		(3)

 

 

In the programming world, the word paradigm is simultaneously over and under used. It is under used in the sense that in this field, the conventional wisdom changes with the announcement of each new next big thing. Fortunes are made and lost in a matter of hours, based on a cycle of "revolutionary" new ideas. However, it is sometimes over used when referring to a specific programming language. I must confess that while it is clear that C++ is a very flexible language that allows for many different approaches, I was skeptical when I read the title of this book. I tend to define the term paradigm to mean more significant differences than others do. However, only a short while into the book, I realized the sense of the approach the author has taken.
The majority of software projects are not constructed anew, but are legacy systems that need to be updated. In almost all of those cases, this would involve multi-paradigm development, as it is a rare occasion indeed when legacy technology would be used to manage the updates. In fact, the tools and expertise may no longer exist. Even in those cases where there is a complete rewrite it is necessary to understand the old paradigm, so there is no fundamental difference from the update.
In reading this book, I was struck with many thoughts about how practical the authors approach is. He argues for C++ by emphasizing that it is a language capable of supporting many different approaches, sometimes even simultaneously. I regularly teach experienced programmers the basic concepts of object-oriented programming , and this gives me firsthand experience in seeing the difficulties in making the paradigm shift. I gleaned a few new approaches from this book that I believe will help make the transition easier.
The problem with learning new tricks is often because we know so many old ones. If we can intersperse the old and the new, transitions are easier, and this book will help you successfully perform the mixing.

Jesus, Amazon reviews are one of the best things about the internet. They have to start changing rating formulations here to discount the rise of corn pone crankery. Giving this one star and saying it is soporific (hint: that's a joke see, as the guy is complaining about use of language and the old mozartean syllable count), is LUDICROUS.

First off, where has this book been hiding? When I first read Coplien's Advanced C++ in 1992, it blew me away. I read and reread it like it was epic poetry (oh wait, that's because, well, it IS). Coplien is everything you want in an author: first, he is literate. Unlike junior who can only hold the book w/one hand (since they took away his pacifier, he has to use his thumb), he has clearly read and digested a LOT of stuff. Science people, too often have zero literary sensibility at all. Funny that the great scientists seemed to. Oppenheimer read in several languages and quoted the Baghavad Gita, Greek scholars, and was into poetry. Anyway, Coplien can also claim to have been, to borrow the Dean Acheson phrase 'Present at the Creation' (though, lucky for Cope, he was there and took part in the birthing of the most important software dev movement in the last 25 years, while Acheson helped cement the modern police state). Finally (on this front), this book is not only readable, it reads like the wind. And believe me, friends, I was almost suckered into believing the whiney tail of my hero's demise.

Now, here are a few more things I'd like to say about this book:

1. I have been reading a lot about PLE lately, and this book plugs into this so well, it's bizarre. For instance, this book takes some serious time to talk about how to do variability analysis, but also discusses things like the mapping of domain variability requirements to language features, the various codifying tools that enable substitution, but also substitution w/variation (e.g. parameterization, virtualization, etc.), but then, in a bonus turn on this vector, he talks about how this meshes with patterns, showing for instance how cases of negative variability (where the deriver wants to erase part of the base) can be refactored to Bridge, etc.

2. Don't get too thrown by the multi-paradigm angle the title implies: this book is not just a screed espousing the use of functional sideshoots, or procedural deviations.

In summary, this is a great book and I can't believe I did not know it existed until recently. If you are doing product oriented development especially, and variation at more than just the simplest level is a daily demand, this is one of the best wells to visit.

I am experienced with C++, however I found this book extremely difficult to read. The author seems to enjoy digressing and building elaborate sentences, but unfortunately this (at least to me) seriously hindered the understanding of the material.

Here and there I would see a great insight, but such insights are very hard to find among all the precious language used. There are no code samples and very little concrete stuff at all. I don't even know to this day what the book has to do with C++. I usually had to read many paragraphs a second time before I figured out their meaning. And, unfortunately, it was more often a trivial fact dressed in oh so nice words, rather than an illuminatory insight.

I just didn't gain anything from reading this book. Sorry.

The author tries to bring back together different ways of thinking (aka paradigms) and succeeds. You will never see analysis and design the same way after reading this book. He showed me what generic programming (C++ templates) and OO have in common. Even if you don't use C++ in your day to day tasks, you can benefit from reading this book. Thanks Mr Coplien.

I've been in the software development industry for over a decade, and one of the things that continues to shock and depress me is the number of developers out there that are stunningly weak on theory.

I got turned on to this book by a presentation at TechEd. According to the speaker, C# is capable of at least five different coding paradigms, only one of which is Object Oriented. In the enterprise development world, OO is viewed as the "right" way to do things, with no understanding of the tradeoffs being made by following the OO approach. Worse, object models are getting created by people that have no idea how to validate the design. What is "right" and "wrong" is decided mostly by gut feel. If you ever hear the phrase, "well, I had to do some refactoring in the classes that were inheriting from mine because the change I made broke some stuff," you know the design was bad.

When I review code, I see developers drifting in and out of the OO style, mixing in bits and pieces of Functional programming, a bit of event-driven/message-based programming, and absolutely no idea of why or how to decide which paradigm to follow in a given situation. Worse, if they know any theory at all, it's only for the OO approach. Not good when trying to use the Functional programming features in C#.

If you just thought to yourself that C# is only an OO language, then you REALLY need to read this book.

I found this book to be an excellent starting point for anyone trying to educate themselves on the appropriate use and selection of a programming paradigm. It has enough theory to get you started, and will build enough of a vocabulary to let you find more focused books.

The computer book market is flooded with how-to guides. This isn't one of them. As developers, we are pretty good at getting things done. However, that still leaves us a far cry from treating our profession as a craft, worthy of deep understanding. I suspect this may be part of the reason why 80% of software development costs occur after a product has gone to production, even in the corporate world.

Yes, this book can be hard. In fact, it can be very hard, especially for an experienced developer that is reading quickly while looking for the "how-to" bits. The book challenges you to go back to first princples, which is hardest for folks that have made a career of getting the job done and slinging code as needed. Read the book like a college text book, and it might help. Read each chapter twice. If you can get your head around it, it's worth the effort.

I was so excited when I found this book. Large scale application design is HARD! Although I hadn't read any of Mr. Coplien's previous books, his name is prominent in the C++ community.

This book has some interesting ideas but most engineers won't get to them because of the author's fascination with the language. Time and again I found myself re-reading a passage only to discover that he was making a simple point.

Please Mr. Coplien, consult a writer before you write any more. Your text is obtuse, dense, when stating the obvious. S/he would certainly warn you of the dangers of passive voice, a trap in which you're completely mired!

I hope this doesn't violate any copyrights but here are the last two sentences in section 1.8.

[after a discussion of late binding] "Multi-paradigm design doesn't aspire to such reflective solutions; this is largely an issue of practicality and scope. The pattern tie-ins in Chapter 9 are limited to structural commonalities and variabilites that are simple extensions to C++ constructs."

I'm sorry but I, and most of the engineers I've worked with, just don't talk that way. I'd be tempted write something like that if I wanted to be sure that no one would read my paper.

IMHO, Mr. Coplien, if you want a model of how to write something which is readable to those outside of the C++ design community, pattern your prose after any of the following books (which I've found very readable):

- The C++ Programming Language - Stroustrup (Part IV)

- Design Patterns - Gamma, et.al.

- Advanced CORBA programming - Henning, Vinoski

This book explores the foundations of software design paradigms. It explaines an approach that enables designers and programmers to grasp the modern design paradigms in their naked form. Don't let the name of the book fool you: The book is not only for C++ programmers... many software designer and programmer will benefit from it.

I have kept this volume on my bookshelf for a couple of years and from time to time I would pick it up and re-read it. This is apparently not a book that, in my opinion, you will learn anything out of it if you do not know what it is already.

This book is not about C++ per se. It is about the design process for C++ programmer. The language choice of C++ is simply because C++ supports all the paradigms in question.

I would further comment that this book is quite hard to read. A quick browse possibly won't get you anywhere. There doesn't seem to be any logic behind the flow of the book. This is why I said that you have to know the material already to feel entertained by it.

However, the concept that the book talks about is very important that I think every good programmer should be aware of.

The main complaint I have with this book is that it's basically unintelligible unless you've already read several thousand pages of other books about design patterns and advanced C++.

The other complaint I have is that if you've already read that much about C++, then you have to wade through a lot of stuff that you've already figured out just to dig up the dozen or so nuggets of new insight. (Admittedly, I'm prejudiced against dissecting methodology, so you might take this view with a grain of salt.)

This book isn't bad, but for the average C++ programmer there's probably a lot of fruit out there that hangs lower than this one. "Design Patterns" (Gamma), "The C++ Programming Language" (Stroustrup), "Exceptional C++" (Sutter) and "The C++ Standard Library" (Josuttis) come to mind.

Years ago many of us "over fourty" were influenced by Thomas Kuhn's book "Structure of Scientific Revolutions". I did not realize until I opened James Coplien's "Multi-Paradigm Design for C++" that I indirectly needed to thank Thomas Kuhn for the MAJOR impact Coplien has had on the C++ and now Pattern community. I know when I pick up anything written by James Coplien that I will grow intellectually (if I focus and pay close attention to his wealth of references). This book is no exception. I loved it and realized its impact as I read it. It is what I needed at this point. Maybe you will feel the same.