Cee Plus Plus Sux

A common argument in favor of CeePlusPlus is its performance advantage over other languages. But are the language's disadvantages a worthwhile compromise for performance?

DanGreen comments on a Q&A with Brian Hook [http://www.voodooextreme.com/ask/askgrand.html]:

: Like most language discussion, it comes down to the writer's perspective and personal weighting in the flexibility, performance, understandability triangle. Depending on your use for a language, understandability may be the most important aspect. In my work, UnderstandabilityRulesSupreme?. Choosing the right algorithm, purchasing a bigger "PizzaBox?" or scaling outwards (like a WebFarm?) will settle nearly all performance issues. But when writing a game on today's hardware, understandability has to take a BackSeat? to FramesPerSecond?. However, I suspect MooresLaw may put an end to the argument within the next decade and understandability will be the only factor. Maybe the SoftwareCrisis will intervene before then, anyway, and force everyone's hand. (See RichardGabriel's PatternsOfSoftware for an excellent discussion of understandability amongst other things.) -- DanGreen

BadCodeCanBeWrittenInAnyLanguage, but big languages, or LittleLanguages with big libraries, make bad code much easier. If CeePlusPlusSux, so do JavaLanguage, VisualBasic, and PerlLanguage. All of these languages are bad for newbies, all are easier to write than to read unless you use discipline and standards, and all are indispensable within certain domains. The best way is to pick the appropriate language for the job: HorsesForCourses. Or pick more than one language to enhance "understandability", say, use the SimplifiedWrapperAndInterfaceGenerator to bolt small, self-contained C++ primitives into a PythonLanguage framework ... -- PeterMerel

MooresLaw is a RedHerring if you are in competition. It is not enough for your solution on today's hardware to be as fast as the competitor's solution 3 years ago, even though 3 years ago everyone thought this level of performance was good enough. MooresLaw applies to the competition too. They will still be twice as fast as you.

...If processing power reaches a level that supports instantaneous usage for all applications bar those that contain NpComplete algorithms, twice as fast is a non-event. And I guess that's the key. Will there be some point in the future when language-level optimizations aren't important? If so, then by definition the triangle of performance, flexibility, understandability is reduced to flexibility and understandability. (I'm not sure I even understand what I mean by flexibility... perhaps reusability would be a better term. ...actually, after re-reading PatternsOfSoftware, Gabriel's term Habitability covers it nicely.) Anyway, algorithm choice may always be important, but what percentage of applications are algorithmically intensive? Will the applications of tomorrow be more algorithmically intensive than those of today? Are the bottlenecks of tomorrow going to be network bandwidth and video bandwidth anyway? Is squeezing the performance of the software going to be unnecessary because the time taken to go send the info down the pipe or display and relay the latest 3D, surround sound, feedback wizardry to the user will far exceed it? I don't have the answers to these questions but I have suspicions and that's why I used the word suspect above. -- DanGreen

The real issue is whether we believe in the 80:20 rule of performance, and whether we are applying it right. -- DaveHarris

What gets me about the above statement, "MooresLaw applies to the competition too. They will still be twice as fast as you" is that MooresLaw is the reason I wish more programmers could spend less of their time fixated on performance issues. But there seems to be a vicious cycle: programmers getting drawn into excessive optimization because of the importance given to benchmark testing as the determining factor whereby which application or operating system is "more viable in the e-commerce marketplace" (or whatever.) I've experienced aspects of this in console game development, and observed similar on the linux-kernel mailing list. But every time my operating system crashes (yes, it happens to be dual-boot NT/linux) what really affects me - emotionally, anyway - is the sheer dedication of programmer time on the linux-kernel list to making aspect X of the operating system Y cycles faster. And the fact they're obligated to pursue this path because of the benchmark-following 'drones' purchasing systems IN IGNORANCE of MooresLaw... is really irritating. I want a reliable system. I can buy faster hardware every three months. -- BillKelly

I code faster in some languages than others, despite equivalent experience levels. -- PhlIp

Competition is a RedHerring. Most software is developed in-house, so there is no competitor as such.

In the small minority of cases where there really is competition, and the software needs to be brought to market, who do you think will win, the company which finishes 6 months early, or the company whose software is twice as fast? Besides, decisions about buying large software products are almost never reduced to technical issues, always market and social ones.

And to what do we owe the blanket assumption that one language will let you finish 6 months early? could it be ... SATAN?? -- PCP

Sure CeePlusPlus is hard to use. But somebody has got to do it to create all those ScriptingLanguages and UserInterfaces that allow the majority to avoid C++ programming. Heart surgery is tough as well, but you'd never say it sucked if you needed a triple-bypass done right and fast. You'd just find one of the practitioners who knew how, and gladly admit you weren't one of them.

Most scripting languages are written in CeeLanguage, and often sizeable parts are written in themselves (i.e., just the ByteCode interpreter in C). Tk, Gtk and Motif are examples of GUI toolkits written in C. SqueakSmalltalk's MorphicInterface is written in SmalltalkLanguage, JavaSwing is written in JavaLanguage. Garnet is written in CommonLisp.

Now ... WhyAreMostScriptingLanguagesWrittenInCee??

Because C is a PortableAssemblyLanguage?.

That would be fine, but at least there aren't thousands of people who think they are skilled heart surgeons practicing heart surgery :)

MooresLaw is the reason I wish more programmers could spend less of their time fixated on performance issues

Keep in mind that not everyone writes software (or OSes) for the latest and greatest PC. Do you want to pay for a 1.5 GHz Pentium IV for your TiVo box (which I've been told runs Linux)? Do you think grocery stores would pay for them in their cash registers? Not every programmer sees the immediate benefits of MooresLaw. -- EddieDeyo

It's a matter of marketability. If speed distinguishes your software from your competitors, performance is killer. If not, go program in PrologLanguage.

To me writing command line programs in CeePlusPlus is not bad, but MicrosoftFoundationClasses, ATL, etc. are what is so bad. This is where Java has it all over VisualStudio 6 C++. However, DotNet and CeeSharp level the playing field now.

Competition is not a RedHerring, it is the reason why C++ will be abandoned. That is because TimeToMarket will overwhelm performance, given MooresLaw, making C++ a losing proposition.

I work with HandHelds. I use C++ and C (and PerlLanguage to generate C++). Java programmers look at my code and freak out. They tell me that my perfectly compiling and working code is illegal just because I use struct instead of class. They create virtuals when an if statement would do, and don't use virtual when polymorphically overloading. They delete stack objects, but they don't delete[] when new[]ing. They construct temporaries on the heap and then leak them when they terminate scope. When you ask them why they didn't use the stack, they complain that there's no Stack class from the standard library. I want to hit them with their keyboards. JavaLanguage is CobolLanguage. Java programmers aren't. -- SunirShah

Do you have some observation to make other than that programmers who know only Java idioms aren't good at C++?

We interview a lot of self-described C++ programmers. Even self-described "expert" C++ programmers. Damn few of them can spot a non-virtual destructor, or explain why such a thing might be problematic.

There are some atrocious C++ programmers making a perfectly good living, and there are some star programmers who choose to use Java. -- anon.

Well, obviously. The assertion was that on average Java programmers aren't very good programmers compared to C++ programmers on average. But consider the environment in 1994 before Java was released. Now all the bad programmers have moved onto Java. Bad programmers will always exist, and always herd to whatever is the hot new do-it-all language of the day. Mooooo. -- SunirShah

See: AllPanaceasBecomePoison, ComplexityMatters, AlternateHardAndSoftLayers, CppBashing

CategoryCpp CategorySucks