Linked by David Adams on Sat 11th Oct 2008 16:48 UTC, submitted by IndigoJo
General Development Eric Raymond is working on an essay, putatively titled "Why C++ Is Not My Favorite Programming Language". In his announcement, he calls it "an overcomplexity generator", "bloated, obfuscated, unwieldy, rigid, and brittle", and alleges that these characteristics appear in C++ applications also. I contend that many of the complaints about C++ are petty or are aimed at specific libraries or poor documentation and that many of the features commonly regarded as unnecessary (and excluded from intended replacements) are, in fact, highly useful. C++: the Ugly Useful Programming Language
Permalink for comment 333334
To read all comments associated with this story, please click here.
Problem lies not with the language
by deathshadow on Sat 11th Oct 2008 20:55 UTC
deathshadow
Member since:
2005-07-12

... and this is true of any programming language. The problem lies with people overcomplicating and overthinking their code - and C++, like other languages that have object implementations, is ripe with opportunity to make those mistakes.

Objects are great for self contained modules where you need to pass data between functions as a set, where a simple pointer to the data being processed isn't enough. Binary Trees, relational datasets - Objects kick ass.

The problem arises when programmers start throwing objects at EVERY library they make - be it C++, Java, Javascript, PHP - Objects are generally slower for flat function operations, more complicated, and more code. Time and time again I come across libraries where no data is being shared between the functions, but all the functions are in the same object... and the object/functions would only ever be declared once in any program that uses it. The advantage to doing this is what exactly? Extra memory overhead of allocating the object, extra overhead of initializing the object, where's the benefit?

IT often seems programmers have forgotten the most basic rule of writing software - the less code you use, the less there is to BREAK.

Goes hand in hand with the attitude many programmers have about things like strict typecasting, predeclaration of variables, and semantic function/variable names (can you tell I'm a Wirth fan?) - Many seem to view the above as 'too rigid' and 'too strict' or even 'too much effort' when they prevent you from making errors in the first place. (How's the old Pascal joke go? The compiler won't let you shoot yourself in the foot...)

But this is why machine language has fallen into disuse - it's certainly no more cryptic than C, and while people might tout portability as a concern let's face it, x86 has won this round - No, it's that the strict rules are too much for most programmers to deal with given how most of them sleaze out code like they were working for IBM back in the 70's getting paid by the K-LoC...

... and again that's got NOTHING to do with the language used. You make a better language, programmers will take the same sleazeball shortcuts, use badly thought out and/or planned methodologies, and vomit up the same rubbish they do today trying to pass it off as code.

Kind of like HTML/CSS - where people who wrote pages with crap nested tables around elements for no good reason now just churn out crap nested div's resulting in two to three times the markup needed for the layout they are making, using cryptic nonsensical classnames, the wrong tags around elements, and hordes of tags that don't even do anything... You know, 70K of markup for 12k of content?

Same dance, just a different tune.

Reply Score: 8