Value of C++, Or Do I Live in Denial?

I chatted with a friend yesterday (who worked mostly on C#/PHP and even Ruby/Rail for web applications) about the value of C++ language, well, you can probably imagine the content of the discussion and there would be some debate.

I recalled another discussion with my colleague sb sometime at the beginning of this year, I retrieved the correspondence, re-read it again and think that my belief is still valid.

That discussion originated from two articles on technical interviews with Bjarne Stroustrup, available at the first part and the second part. Bjarne gave two interviews to Technology Review (published by the MIT) where he talks about what's good and bad with C++ and software development at large. (by the way, these two are very good articles, even some of the comments.)

== Start of Discussion

Me:
Certainly people in the industry or in the academic are all comtemplating this.

It is tempting to declare something is perfect and this is seldomly true. I prefer to compare software development to composing music or painting: there is one way of conveying things and it is bound to have some other different means. Music and paint are aesthetic outputs. Architectures, designs, maintabilities of software development are all such aesthetic goals, as if you searching for listening to "good" music, or viewing the "grasping" paint - although they all relative to the ears and the eyes.

But software development requires one more thing than the "ways" to express those aesthetic styles we all search so hard. It requires correctness - nothing comes before it, every other thing is secondary.

Also from the above interview, "The purpose of a programming language is to help build good systems, where "good" can be defined in many ways. My brief definition is, correct, maintainable, and adequately fast." I cannot agree more. "fast enough" is aesthetic goal too at first, though sometimes it is defined as part of correctness for eg real-time systems. Correctness is the one and the foremost something the software is created for either economical or scientific reasons.

Saying this does not say that correctness would overshadow the value of architectures, designs, maintabilities, responsiveness etc. Surprising, when striving to achieve the correctness which definitely requires more careful thinking, a system, by chance or as a consequence, that amount of thorough thinking naturally may lead to other good outputs in architecture, design, or maintability.

I would say "correct systems are more likely to be maitainabale, and more likely to be beautifull too when looking into the architecture or design"

So much of my mumbling...of course, there is yet another "Bjarne Stroustrup Interview"
http://www.erenkrantz.com/Humor/FakeIEEEStroustrupInterview.shtml - well, you got what I mean. *)

His reply:
Haha this is very funny.

Seriously, I think it's good to consider the software as a piece of art, as if one was looking at the bunch of equation written by Einstein and saying "waaa it's beautiful...". It is indeed.

But, personally I think we are nowhere close to that yet. I think the metaphor with the architect was perfect: he has the freedom to design masterpieces, but yet, to do that, he has to use a set of perfectly well-know and well-defined tools. He knows that to achieve task A, he needs to go through task B, using tool C and D. Or just like the physician. I would like things to be that simple in computer science. But we haven't yet reached that state.

My reply:
Yes. My thinking is along the same line. I emphasize correctness at the most important thing to consider. By itself correctness is not strictly an "aesthetic" goal (indirectly yes), and I think it comes before any other goals more related to aesthetic aspects such as architectures, designs, maintabilities, responsiveness etc. Somehow the industry leaves the impression that architecture is the foremost important - I disagree to an certain extend.

What software development differs from painting and composing music is the correctness - its mathematical spirit. Correctness is a complex task - but it is a "simple" goal to achieve, and "could" be done "simply" in more "systematic" way, with more "objective" evaluation. The striving for correctness could be thought of equivalence to countless amount of pratice effort required by a good physician, musician and painter to be fluent. The aesthetic outputs such as architecuture etc are merely the natural extension of searching for correctness, when the knowledge becomes wisdom.

His reply:
The thing is with C++, so many people have no notion of that "correctness". They attempt to write C++ without knowing how it should actually look like. They've never read the STL, never read Boost library, and think "oh it's like C", but it's so different.

The freedom given in this language allows you to define any problem in mathematical terms. There is a certain way of doing it, using a certain syntax. People should not try to write C++ when they don't know what it should look like.

The fact that it was compatible with C brought the idea widely accepted that anything can be written in C++ like C. This is doing more bad than good to C++. Anyway given the wide range of specific high level programing languages available nowaday, I think C++ will finally be found only in the area where it is really good at: complexity/performance of data processing applications. 
 
== End of Discussion

Coming back to C++ language itself, I I cannot agree more with the opinion from one author called JF, saying (titled: C++ Design Philosophy, comments to the first part of the interview)

I think it is hugely important to go back and read exactly just what the design philosophy behind C++ was (and still is). Most of the writting (especially those against C++) seems  to be demands for more features(eg garbage collection, pointer management, threading support etc). But when you carefully review the thinking behind C++ (as I have done -by the way I have developed applications in Fortran/C/C++:numerial/graphics analysis and realtime telco apps and there is no other language that could have done the job-maybe at the time.)  BS and the standard's committee are keenly aware of all these 'shortcomings'(if you want to call it that) of the language . A fundamental aspect of C++ is that it should support multi-paradigm programming -that in itself is a tall demand. But more improtantly, C++ should allow you to be as close to the machine as possible but 'no closer' while retaining 'expressivity'. In the end, there is no substitute for attention to detail and that is the programmer's job. If the machine is kind enough to give you memory when you needed it (and don't force you to give it back) then just make sure you return the favour. I believe we do and will need a language that allows you to do what you want. Incrementally though, features are being added to C++ to resolve exactly some of these issues. Practically, there is no reason to use old fashion/native arrays over vectors. It is my believe that some day threading support and memory management will be part of standard C++ once an efficient implemetation is found.

I would point anyone who is now still interested in C++ to the above two articles, read more about C++ and its philosophies. Maybe only do it only for historical interests (because I have to admit, not many current jobs require you to write C++), the efforts of stepping into un-comfort zone would pay off. When you force yourself to do something that you don’t understand and don't see immeidate pragamtic applicability, the initial results are always messy - but that experience is always original, extends your horizon and gives you a lot more visibility into the complication of the software world. For starting in C++, I would always recommend by starting directly in STL (eg some of my old posts in this forum here, here, here, here, and here, forgive sometimes my nugging).