Sam on C++

Sam Gentile put up a great comment yesterday on Multi-paradigm design and generic programming, which I found spot on in several ways. My current work is all pure C#, which, I admit, I like as a language. However, I still miss working with C++ and the power it gave me, particularly being able to work with templates (here's hoping for generics!).

I do feel, however, that I find myself in disagreement with some of Sams's assertions. My main concern is saying that C++ was designed to support Multi-Paradigms. Well, I'm not privy to the events that lead to C++ standarization, but I don't swallow this; not completely, at least. I do agree C++ was never designed to be fully OO; in fact, I thing C++ goes quite a bit beyond OO by giving you more possibilities; but I disgress. My real point is that it is the other way around: It happens that C++ can be in such a low-level fashion (abstraction-wise) that you can tack these other programming paradigms on top of it by building abstractions, but I don't think that was the main intention. Then again, that's just my opinion.

One of my pet peeves with C++, even though I love working on it, is that, even with all its power and flexibility, some things that should be trivial are still way too complicated, unnessarily. Despite what one may think, C++ still carries the heavy burden of its C-legacy, and that hurts the language usability. Case in point: Manipulating strings... such a fundamental task in most modern applications, can be a real pita in C++, even with the help of the std:string and friends.

Now, Sam (and Coplien) do have several other assertions I agree with. The OO-Purity of C++ is one that comes to mind. Purity? Who cares about purity? Let's be brutally honest: Purity doesn't make products any better; purity doesn't help you sell more copies of your products (at least in most markets :)), and purity sure as hell doesn't automatically give you maintainability and flexibility. Design and abstraction give you those. I think OO is, in essence, just a low-level abstraction you can build other abstractions on, but designing (and even less, making requirements definitions) at the pure OO level is just counter-productive. So here's my take: At the end of the day, there's no pure and unpure, there's just it feels right or it feels wrong. Gut feeling seems to be these days the best you can hope for.

As for abstraction building, I'm not even completely sure C++ is necessarily the way to go. The way I see it, it very much depends on the problem domain. I'm not going to argue one way or another right now, so just let me tell you three things I've read this year that resonated deeply within me regarding abstractions:

• Story number 12 of The Pragmatic Programmer.
• Paul Graham's Succinctness is Power and specially his Taste for Makers article.
• Graydon Hoare's "One Day Compilers" presentation. Well worth a read if Domain-Specifil languages are in your mind these days.