Dumping stuff trimmed from other pages here.
Any language could be considered bad. The most common ones that seem to be referred to as bad are MainstreamLanguages such as CobolLanguage, FortranLanguage, CeeLanguage, CeePlusPlus, and BasicLanguage. Sometimes people also call PerlLanguage and PythonLanguage pretty bad.
I suspect that the main reasons people use bad languages are either situation pressure, or it is the best of what they know and they don't want to learn better (or they disagree that better exists).
Don't discount that the "bad language" may simply be what they were taught and what they see everyone else using. To illustrate: you could also ask why do so many people speak EnglishLanguage?
Why does anyone use CeePlusPlus if it's so bad?
People use CeePlusPlus for a number of reasons:
- They're working within the MicroSoft toolset, which is set up to encourage work in either C++ or <shudder> VisualBasic. Apart from the maintenance horrors of the language itself, VB presents a number of serious architectural limitations that prevent it scaling - no object pooling & only single apartment threading (SingleThreadedApartment) - so in MS-land C++ is almost universally accepted as the basis for building larger apps.
- They're working with RealTime / embedded systems. Manufacturers of these systems usually offer ApplicationProgrammingInterfaces in CeeLanguage or CeePlusPlus, and the maintenance and performance costs of shoe-horning a JavaVirtualMachine into the picture aren't acceptable.
- Their team's experience base is mainly CeePlusPlus. It's easy (and fun!) for C++ folk to make the transition to the JavaLanguage, but a conservative manager may see this as an unacceptable risk.
- They've never tried serious development in any other language, so they succumb to the BlubParadox.
- (Or they've never heard of ObjectiveCee.)
Or is it not bad, in some way I don't understand?
Although I've rubbished CeePlusPlus here a couple of times (especially on AllPanaceasBecomePoison), I maintain a grudging affection for the language. Given the right team, I can build big systems fast in C++, applying all the ExtremeProgramming techniques without getting tripped in any particular way. Nothing about the language is a development showstopper; it just requires higher development discipline to do things right in C++ than to do things wrong.
- If a team is doing some IS kind of project in CeePlusPlus, they are tagged with one of the two danger signs in Alistair's book. What alternative implementation language[s] could/should they consider?
- They should consider AlternateHardAndSoftLayers with the most appropriate of PythonLanguage, HaskellLanguage, PerlLanguage or <shudder> VisualBasic for the soft layer. Better to write most of your system in a soft language that's easier to maintain, then profile and rewrite the hard bits in C++. But you may find strong management resistance to this notion - management sees extra languages as extra risks, not risk reducers.
- ObjectiveCee. It's a direct superset of C, unlike C++ (you can assign void pointers to non-void pointers, for example), with a message-oriented Smalltalk-like object system. It's not really an obscure language either. Most MacOs development is done in the CocoaFramework, Apple's ObjectiveCee class library. I'm really surprised people keep forcing themselves to choose between C++ and Java, meanwhile a beautiful, very simple OO superset of C is right there waiting to be used. ObjectiveCee isn't perfect, but it's unbelievably better than C++. And C++ keeps getting farther and farther from the metal; templates, RunTimeTypeInformation, and so much more have slowed this beast down, and the ISO committee just keeps adding more and more to it. C++ gets slower and slower and uglier and uglier. I'm really shocked people keep forcing themselves to use it even when they really don't have to. (GnuCee, by the way, comes with an ObjectiveCee compiler too, since the language is just a small, simple wrapper around C. GnuCee is the compiler Apple uses in their ExCode IDE.)
- You got to love the irony of a paragraph that in the same breath, a) praises ObjectiveCee for it's "Smalltalk-like" object system, and b) condemns C++ for RTTI for "slowing this beast down". For one thing, RTTI doesn't cost you any CPU cycles unless you explicitly use it (with DynamicCast, etc.) - and even then RTTI is comparatively cheap. For another, ObjectiveCee (and all languages with DynamicTyping) perform the equivalent of RTTI on every single message send!. The cost of a selector lookup in ObjectiveCee is (depending on how closely it mirrors Smalltalk semantics) quite a bit more than a VeeTable lookup in C++. Which isn't itself a bad thing; greater LateBinding gives the programmer more flexibility, which is the selling point of higher-level languages. But when such arguments are used to promote the MythOfCppBloat, that's another story altogether.
- Indeed. I wonder if many of the C++ criticizers have actually done much development in C++, or if they just buy into the "C++ = big bloated code" stereotype. Also many people confuse nice clean portable C++ with the horrible COM/MFC ridden monstrosities that some Windows programmers created
- I wasn't saying C++ is slower than Objective C, but the fact is, C++ has gotten slower, and continues to get slower. What about the .NET runtime? (Or Mono?) What about the managed code that comes with it? I know, those things - like dynamic casting, exceptions, templates, etc. - are all optional. If a C++ programmer wants to, they can just use C++ as a "better" C. Well, for better or for worse, many developers are going to take advantage of all of those features, and at that point the efficiency arguments start to go out the window, and in my opinion, Objective C starts to look like a really, really nice alternative.
- Uh, DotNet really has almost nothing to do with CeePlusPlus. Or any particular language. A dialect of C++, called ManagedCeePlusPlus, is supported by DotNet - but Managed C++ is sufficiently different under the hood that observations about it don't apply to C++. When you speak of "many" developers, an important question to ask is "developing what?" Much custom business software isn't being written in C, C++, or ObjectiveCee; instead, it's being written in VB, C#, Java, etc. All of which are probably more appropriate for that sort of software than either C++ or Obj-C is. C++ and Obj-C both are more suited to shrinkwrap and/or widely-distributed OpenSource software, where the additional testing/development required to support a more low-level language can be amortized across many more installations/sales/downloads, and users are more likely to have greater demands on performance. In that domain, ObjC is nice, but C++ has long surpassed it. The one thing that ObjC has that C++ doesn't is DynamicTyping (of objects), and numerous dynamic object models have been greenspunned on top of C++. I shudder at the amount of work that would be required to add many of the C++ semantics to ObjC.
- Remember that C++ programmers can choose which features to use (we don't use templates, RTTI is a checkbox in the project settings). Just because the feature exists and is arguably bloated doesn't mean it has to be used
- How can a team or company wean themselves from CeePlusPlus?
- If they don't actually have a good reason for C++, then as Kyle says above they ought to go to JavaLanguage. It has some warts, but it's really such a much better choice for most applications.
- Using CeePlusPlus, how can maximum flexibility be maintained?
- Why does CeePlusPlus exist?
- So that we can have an OO language that's close to the metal.
--
PeterMerel
See WhyFunctionalProgrammingLanguagesArentMainstream
Why People Use Bad Languages