Sponsored Link •
Bill Venners: Another thing I don't remember hearing about when I was programming in C++ is multi-paradigm programming�programming using multiple styles. You seem to be talking about this a lot recently. What programming styles does C++ support, and what is the benefit of combining multiple styles in the same program?
Bjarne Stroustrup: Multi-paradigm programming is not a new thing. However, it is a relatively new way of talking about things. Just as I was basically unsuccessful teaching people about classes used as interfaces as opposed to stateful objects, I had some trouble explaining how to use different paradigms. But if you look in my first book on C++, it says: we support traditional C style programming, and we do it better than C; we support data abstraction; and we support object-oriented programming. Data abstraction was basically the way you wrote code in Ada and a whole slurry of other languages. Data abstraction is very good for dealing with high performance numerical problems where you have lots of rellatively standard concepts, such as complex number, vector, and upper-diagonal matrix, that must be efficiently implemented to be useful and that can be represented as relatively independent classes.
Bill Venners: Data abstraction is free-standing classes without inheritance?
Bjarne Stroustrup: Basically, yes. Object-oriented programming is where you use class hierarchies, as first done by Simula. When you look at my earlier writings, there was usually a section under data abstraction that said, "and we need to parameterize our containers with the element type and do operations on parameterized containers." This is what later grew to be generic programming. Then object-oriented programming came along, and most people's emphasis and attention shifted to class hierarchies. In the C++ world, generic programming slowly emerged from data abstraction over the late '80s and '90s. Generic programming is now so prominent, and we know so much more about it, that I describe it separately.
Bill Venners: And generic programming is when I write code to a generic type T that gets plugged in later?
Bjarne Stroustrup: Yes. When you say, "template type T," that is really the old mathematical, "for all T." That's the way it's considered. My very first paper on "C with Classes" (that evolved into C++) from 1981 mentioned parameterized types. There, I got the problem right, but I got the solution totally wrong. I explained how you can parameterize types with macros, and boy that was lousy code. Fortunately, it's more important to have the right problem than to have the right solution, because at least when you have the right problem you can eventually solve it. We understand how to use parameterization so much better now than I did then. I mean, I could only glimpse part of the solution and part of the importance of the problem. Fortunately, I glimpsed enough. Today, we casually do things that would have been almost impossible in C++ in the eighties or nineties, before the generic style was first directly supported in C++ by templates.
So the notion of multi-paradigm programming was there from the beginning. This is why I say, "C++ supports object-oriented programming," usually adding "and it supports it better than some languages." I don't say, "C++ is an object-oriented programming language." I never had the idea that there was just one right way of writing code. From the very beginning, the notion of using different styles or paradigms was there. I usually list, C-style programming, data abstraction, object-oriented programming, and generic programming as styles directly supported by C++. And from the very beginning, there were examples that used combinations of the styles. I'm just emphasizing multi-paradigm programming more strongly now. I think I'm better at teaching it. I'm better at getting the ideas across or maybe the community has simply matured to the point where it's easier to explain the need for multiple styles. However, there is still much to get across to the C++ community, especially in the area of how the different styles can be used in combination to create the best, most efficient, most maintainable code.
Apropos to this, I had a nice experience reading a review of the third edition my book, The C++ Programming Language, a few years ago. A reviewer, I think it was Al Stevens, said the third edition read much better than the original edition. However, to check, he went back and read the original to see if it really was as bad as he remembered it to be. His conclusion was that the first edition wasn't that bad. He thought now that it was very clear. But when the first edition came out, he had written a review that said it was almost incomprehensible. Ideas mature. And the community matures partly through reasonably pioneering works that are hard to understand at the time. If you go back to the roots of C++, you will find things considered very hard that are now considered obvious, and you have trouble understanding why people had problems with them. I don't quite understand why I couldn't teach those ideas, but I too have learned a lot since then.