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
Post a Comment
Member since:
2006-10-31
Member since:
2005-11-13
Before you get rid of C++, how about developing a language (with appropriate libraries) to do everything C++ does, including the ability to code fast, tight, native applications that can run on multiple platforms, and which will allow you to code close to the metal if you would like.
Member since:2008-08-24
And most importantly, must be 99% C-compatible.
My experience is, for a small application that doesn't do anything the base class library doesn't provide, C# is indeed much faster to code. But as the code complexity grows and you need access to some C API then C# really is a hassle.
Good C++ libraries (like boost, Qt, OpenSceneGraph, etc) does a lot to smooth out the development experience.
Edited 2008-10-11 17:26 UTC
Member since:2005-07-29
Well D comes pretty close to what he's looking for.
http://en.wikipedia.org/wiki/D_programming
Member since:2007-10-26
Personally I have high hopes for Vala:
http://live.gnome.org/Vala
That's the first project in years that has made me really excited.
Member since:2006-01-03
http://live.gnome.org/Vala
That's the first project in years that has made me really excited.
I hope Vala goes somewhere myself as well. I like the tack they are taking with it.
Member since:2005-06-29
Member since:2005-11-20
Member since:2005-06-29
Member since:2006-01-18
Objective-C just adds a bit of smalltalk syntax over C. Whereas C++ extends C syntax while keeping low-level efficiency.
BTW, note that there is Objective-C++ too
Well there are two different design principles. Objective-C followed the keep it simple principle while C++ followed the, lets take every feature there is on earth and press it into the language approach. The problem is, that the keep it simple approach always is superior. Java could have never taken off if not a huge number of projects simply failed on C++s inherent complexity! Java sort Next was able to pull of a decent component based system in time with ObjectiveC while most others had inherent delays (COM etc...) or failed entirely in their first incarnations (Project Pink from Apple and IBM) is a clear sign of the overcomplexity of the design. The funny thing is that the better C++ based systems basically follow the keep it simple principle and omit a huge load of the language to reduce themselves down to the sane core!
Member since:2008-07-01
Member since:2005-07-06
Member since:2006-02-25
Member since:2006-12-22
Member since:2007-02-17
I think you're confused, kid. Java and .NET can run with some of their code compiled to native machine code at runtime, but that's not the same thing as a language that compiles to native code. You still need the actual managed runtime environment (which is quite different than just linking a shared library) for Java/.NET to work.
Basically, with C/C++, you can write code that runs on a machine in which no existing runtime or standard library yet exists (assuming your compiler has a target for it), where-as with Java/.NET, you need to port millions of lines of code (which themselves are written in -- wait for it -- C and C++) over to the platform first.
Member since:2007-07-13
Basically, with C/C++, you can write code that runs on a machine in which no existing runtime or standard library yet exists (assuming your compiler has a target for it), where-as with Java/.NET, you need to port millions of lines of code (which themselves are written in -- wait for it -- C and C++) over to the platform first.
No, you are the incorrect "kid". You have obviously never hear of the GCJ implementation of Java, so perhaps you ought to do some more research. GCJ can be statically compiled to a single native binary with no runtime dependencies. I don't know if there is a .NET equivalent, but Java certainly has this ability. It runs as fast as GCC (which, incidentally, is slower than the Sun implementation of Java).
I spent nearly a decade working with C++ but now use Java because:
1) it is (finally) fast enough (faster than C++ in many cases)
2) it is faster to develop
3) the (free!) tools are better
4) it runs everywhere (my customers have a variety of environments, from embedded systems to enterprise servers)
5) Memory isn't that much of an issue (you can get cheap embedded platforms with 64 MB memory)
6) it has libraries that work on all platforms
and, most important of all
6) it is usually much easier to read Java code written by others than C++ (especially barely-skilled corporate programmers)
I'm guessing that most of the advocates of C++ are mostly reading code written by themselves and don't have to read a lot of code written by other people. That is one area I've found Java usually beats C++. This is what I think the earlier poster saying C++ should be written like "Java" - alluding to a code style which can easily be followed by others.
Member since:2006-01-02
Hear, hear! I have much more difficulty reading C++ code than C code (or C# code) because people define so much of their own stuff in C++ and you often have to jump around a lot to base classes, odd operator overloads, and template code (sometimes this is hard in a debugger).
Member since:2006-03-16
that language already exists, it's called Delphi...
http://www.codegear.com
Member since:2006-01-18
Objective-C... as old as C++ but way superior!
Member since:2005-07-06
Member since:
2006-01-04
Member since:
2007-12-04
Member since:2005-07-08
I think you may be a bit unfair to him. Of course he must have been doing many other things lately too than only ranting... 
I don't know about the lasting worthiness of his earlier CUPS & Fedora rants, nor about his many and sometimes maybe a bit odd or at least uncoventional opinions on many other subjects ( http://catb.org/~esr/writings/ ) - but as for understanding the pros and cons of various programming languages, he seems quite a competent person indeed to talk about that subject.
In 2003 he wrote the book The Art of Unix Programming and he has written well-known and often quoted insigthful articles where he compares the pros and cons of various programming languages, based on his knowledge of at least two dozen programming languages:
- How To Become A Hacker http://www.catb.org/~esr/faqs/hacker-howto.html
- Why Python? http://www.linuxjournal.com/article/3882
You may, of course, disagree with him, but at least he has some good arguments and knowledge to support his opinions concerning the pros and cons of various programming languages, and to discredit his opinions concerning programming one should at least have better arguments than just to blame him for ranting.
Edited 2008-10-11 19:14 UTC
Member since:2007-06-20
"The paper is developing primarily from a software-engineering perspective rather than out of formal language theory. Iâm particularly looking for empirical studies on the importance of manual memory management as a defect attractor (I have the Prechelt paper from the year 2000). Iâm also interested in any empirical studies comparing the productivity impact of nominative vs. structural vs. duck typing." --ESR
It doesn't sound like it's going to be a rant. For the record, his rant on CUPS _was_ definitely a rant, but he was also right and CUPS got improved.
Member since:
2005-07-20
The bad thing about C++ is that it's way too easy to program fugly code which no one can read now maintain. If - on the other hand - you have a bunch of good and experienced coders and software architects, you usually end up having code which looks very similar to Java (except that you can sum complex numbers with '+' operator) but is fully native and can be fine-tuned for performance where it really matters. If you don't believe this, just look at some Qt4 programs.
Member since:2006-01-06
Saying good c++ code ends up looking like java is kind of offensive...I take strong offense to that.
About the only way I can see c++ code looking like java is if the project & code base gets grossly over engineered.
The biggest valid complaints I've seen about c++ is that it allows for far too many different dialects to exist, all based on what company you work for or who you work with (of course the dialect I used is the best :-p )
Member since:2005-11-11
The biggest valid complaints I've seen about c++ is that it allows for far too many different dialects to exist, all based on what company you work for or who you work with (of course the dialect I used is the best :-p )
This is an extremely strong disadvantage in the context of what ESR is saying: open source programming. It is true that you can alleviate the over complexity of the language in a strongly controlled environment, with one coding style, the do and don't. But in open source programming, this becomes an almost fatal flaw. Only really big projects can deal with C++ (KDE, mozilla).
Also, C++ does not tend well to code reuse; this is linked to the previous point , since it id difficult to reuse the code using one subset in a project using another one. It is difficult as hell to interface to other languages because of its complicated linking model, templates can't be used either as a library without a lot of boilerplate. It is true that STL-like containers are useful, but it comes at such a high price that I am not so sure anymore a plain C library is not better in most cases.
Member since:2005-11-15
This was even more the case when OO was all the rage, and developers went on designing deep class hierarchies just because they could.
This leading to the banana/gorilla problem.
For our embedded (bare metal) development, I have considered OCaml, Ada, Oberon, Pascal, then C++. In that order.
We ended up with C++, because the others failed us with big runtimes, complex cross compiling settings, and lack of host OS support (as in Linux, macosx, Windows etc) which was important since we don't want to force an OS on the developers.
Control over memory allocation is hugely important too - our initial platform only has 32k of ram.
C++ did the job nicely, we have our own templated OS and drivers, and the result is small and efficient.
The only restriction is no RTTI and exceptions, because of the associated runtime.
If we get the opportunity, we'll add the cxa_* funtions to our libraries so we can support exceptions.
So yes, C++ is a good workhorse. We just have to have very experienced developers who know how it works under the hood.
I just wish we had the time to participate in the OCaml or Ada efforts so that cross compiling is as easy as in C++.
Member since:2006-05-02
Member since:2006-05-26
The biggest valid complaints I've seen about c++ is that it allows for far too many different dialects to exist, all based on what company you work for or who you work with (of course the dialect I used is the best :-p )
This is an extremely strong disadvantage in the context of what ESR is saying: open source programming. It is true that you can alleviate the over complexity of the language in a strongly controlled environment, with one coding style, the do and don't. But in open source programming, this becomes an almost fatal flaw. Only really big projects can deal with C++ (KDE, mozilla).
Also, C++ does not tend well to code reuse; this is linked to the previous point , since it id difficult to reuse the code using one subset in a project using another one. It is difficult as hell to interface to other languages because of its complicated linking model, templates can't be used either as a library without a lot of boilerplate. It is true that STL-like containers are useful, but it comes at such a high price that I am not so sure anymore a plain C library is not better in most cases. "
See the bolded text: this is true if you have developers that can't wrap their heads around designing things for code reuse, and false for those that can. As to the linking model, it's not so bad if you use C++ static functions and straight C interface wrappers (if needed) because C++ static functions use C style linkage, which is as close to universal as you'll find overall. But, if you don't know how to deal with that, then yes, it becomes a mess. Again, for code reuse, that's very much a function (pardon the pun) of the design method (there's another one!) of the developer and what attributes they use in their designs: if you try to use all the fancy features and make an overly complicated class hierarchy with multiple inheritance where each class in a hierarchy depends on other classes that depend on it (creating cyclic dependencies) then yes, that highly hinders code-reuse. Then again, there's absolutely nothing in straight C that prevents you from screwing things up in the same manner, and for that matter, any language that allows you to use forward declarations is not immune to this (which most do as a practical matter): this is a limit of the developers using the language, and not the language itself. Spaghetti C++ code is just more obvious to see than spaghetti straight C code, but there's more than enough snarled straight C code (as well as Java, Perl, etc.) to show it is hardly a C++ism that's unique to the language.
Member since:2005-07-06
That's not the fault of the language, it's the fault of the coder. Yes, I strongly believe that. F*cked up coders can generate unbelievably unreadable and unmaintanable code in whatever language.
Up to this day I code all my algorithm code in c++ (mostly computationally highly intensive image and video processing code, some heavily multithreaded) and if I can choose, then I choose it always before any other language, java and c# included.
Some say it's bad, because it's easy to make mistakes. Well, learn to avoid those mistakes then, fools, and believe me, those good practices will help you in the long term, and big time.
Member since:
2005-07-06
But He has a point here. C++ is the "Perl" of compiled languages... it's huge and HORRIBLE... but It's powerful and everybody uses it. It's a fact.
I think they have to take a _small_ subset of the language and create a new one from that (100% compatible at compiler and binary level). Then name it C--, Cava or C* and profit. :-)
Member since:2007-08-03
The entire language itself is certainly huge, but I'd venture that the "working set" that most developers can use to be very productive* is really not so formidable, and that even with this subset of the language, resulting code is often smaller and with less "boilerplate" than the corresponding C. Self-discipline is obviously required, though; C++ gives you yards and yards of rope with which to hang yourself
* The LLVM guys, for instance, use what they call a "tasteful subset" of C++, and I've seen people who simply can't understand why anyone would ever use C++ over C - a viewpoint very nearly diametrically opposed to mine, for the record - praise their approach and codebase.
Member since:2005-07-06
Agreed. Most of the C++ in Syllable for example doesn't use much more than basic classes, references and exceptions. You could do all of these things with nothing more than standard C, but doing it with C++ makes the code neater and more logical.
Member since:2006-02-05
Best perl description I have ever heard was the rather famous blog post by steve yegge entitled "Tour de Babel"
But Perl has many, many things going for it that, until recently, no other language had, and they compensated for its exo-intestinal qualities. You can make all sorts of useful things out of exploded whale, including perfume. It's quite useful. And so is Perl.
He describes c++ thusly
As for C: it's so easy to write a C compiler that you can build tools on top of C that act like introspection. C++, on the other hand, is essentially un-parseable, so if you want to write smart tools that can, for example, tell you the signatures of your virtual functions, or refactor your code for you, you're stuck using someone else's toolset, since you sure as heck aren't gonna parse it. And all the toolsets for parsing C++ out there just plain suck.
C++ is dumb, and you can't write smart systems in a dumb language. Languages shape the world. Dumb languages make for dumb worlds.
All of computing is based on abstractions. You build higher-level things on lower-level ones. You don't try to build a city out of molecules. Trying to use too low-level an abstraction gets you into trouble.
We are in trouble.
<snip>
With that said, it is obviously possible to write nice C++ code, by which I mean, code that's mostly C, with some C++ features mixed in tastefully and minimally. But it almost never happens. C++ is a vast playground, and makes you feel smart when you know all of it, so you're always tempted to use all of it. But that's really, really hard to do well, because it's such a crap language to begin with. In the end, you just make a mess, even if you're good.
I know, this is Heresy, with a capital-'H'. Whatever. I loved C++ in college, because it's all I knew. When I heard that my languages prof, Craig Chambers, absolutely detested C++, I thought: "Why? I like it just fine." And when I heard that the inventor of STL was on record as saying he hated OOP, I thought he was cracked. How could anyone hate OOP, especially the inventor of STL?
Familiarity breeds contempt in most cases, but not with computer languages. You have to become an expert with a better language before you can start to have contempt for the one you're most familiar with.
So if you don't like what I'm saying about about C++, go become an expert at a better language (I recommend Lisp), and then you'll be armed to disagree with me. You won't, though. I'll have tricked you. You won't like C++ anymore, and you might be irked that I tricked you into disliking your ex-favorite language. So maybe you'd better just forget about all this. C++ is great. Really. It's just ducky. Forget what I said about it. It's fine.
I agree with pretty much his entire essay http://steve.yegge.googlepages.com/tour-de-babel
Member since:2005-07-07
Member since:
2005-07-06
Member since:2006-08-29
Templates and streams (and the STL containers) are 2 of my favourite features. The fact that you don't use them is fine with me and it also highlights just what is special about C++.
In C++ you get all the _options_ and you can code the way you prefer without having a paradigm shoved down your throat.
Edited 2008-10-11 22:15 UTC
Member since:2006-01-06
Streams are horrific. Trying to handle internationalization of "grammar" concepts utterly breaks streams to hell, which is where they should go back to.
If anything STL's iterators & algorithms are extremely powerful, amazingly so. c++0x takes this power a step further with lambdas and other things.
The collections...well they are okay but definitely show how utterly obfuscated hackers can make their code. At least they aren't c macros.
Edited 2008-10-12 05:28 UTC
Member since:2005-07-06
Member since:2005-07-06
Personally, I find the << syntax for putting data into a stream really logical and intuitive. The text or data to the right looks like it's being "sent to" the object on the left. The only problem is that a lot of teachers and books don't explain properly how this works - my teacher just said, "oh, it's an overloaded operator" and didn't tell me what that meant.
Member since:2005-07-06
Well, in theory stream are nice in practice for text handling they're not so good: bnolsen is right, for internationalisation streams suck.
And I would add that they're much too verbose.
Not that printf is ideal: in C it's untyped (but this is fixed in D), and arguments are too far for the text so it's too easy to make mistakes..
Ruby puts with printf format would be ideal.
Member since:
2005-07-06
Member since:
2006-10-10
Member since:
2006-05-09
I do not like the "I-know-everything-about-everything-and-I-can-hate-it" tone in the texts ESR writes. He seems to be a software critic, and like almost all critics, he can bash on a picture with no knowledge about painting...
I love C++, it is IMHO one of the few languages that lets me program in the bare metal and provides me a higher abstraction level (OOP, template metaprogramming, etc.)...
I cannot do object programming or generic programming in C (Ã la GTK+ is not a much viable solution) and using a higher level language (Java, C#, etc.) is not doable (or is not the easiest solution) when you are developing systems or commercial applications (let's be honest, there is no a software with the same quality, functionality and performance to Microsoft Office or to Adobe Photoshop written in Java or C# or Python... and because their huge dimensions, they are not written in C neither, they are C++ code).
I agree Stroupstroup comments when he says the problem is not in C++, but in the low-skilled programmers...
Member since:2005-07-06
Member since:2005-07-06
I wish that were the case but the problem is that there are still some JNI components involved in it. I was hopeing to be able to run it on my SGI Octane the moment I saw "Java" then I realised that it had Java, but it wasn't written in 100% pure java and all of it stored nicely in a big fat *.jar file.
Member since:2005-07-07
Member since:2007-08-20
The reason that MS Office, Photoshop etc are written in C++ and not in C#, etc is because they predate C#, Java and Python by many years. These apps have been around since the early 90's.
Take any large Java app and work on it solidly for 15 years with a team of hundreds and then you will have something that you can compare to MS Office and Photoshop.
If Microsoft was starting MS Office from scratch today, I'm sure they'd go with C#/.NET from the outset.
Member since:2005-07-06
Really? Don't forget that .Net is a JIT compiled system, which means that the first time any part of the software is used, it's slow because it's being interpreted and compiled at the same time, yet it never reaches the performance levels of a native-compiled program. Why would MS put their customers through that - something which would become very public when they are selling a large program for hundreds of pounds or dollars - when they can just use something they can compile, and ship it out ready to go?
Apart from ThinkFree, can anyone name any heavyweight software, open-source or proprietary, which is based on a non-native platform?
Member since:2006-12-22
About your question:
- bloated C code: GNOME Desktop
- bloated C++ code: OpenOffice and KDE4 desktop
- slim Java code: Eclipse (the start is slow but after that is faster than Visual Studio written in C++)
- well written C code: Apache Http server, Linux kernel, a lot of other examples
- bad written, memory hungry code (C): GCC compiler tools and linker
C++ was not able to remove the legacy so the compiling of some C++ files may take hundred of megabytes, if they use multiple headers + templates on GCC (cause of including headers, expanding templates, etc.) still hard to match in a big sourcecode.
Java/.NET is useful in places where the speed matter (that is why they do benchmarks on Java) but mostly to simplify a complex business logic that C++ rarely can match. The C++ advantage remains still the huge codebase that is hard to be matched by any non C/C++/ObjectiveC language/environment.
Edited 2008-10-12 12:46 UTC
Member since:2006-01-18
- bloated C code: GNOME Desktop
- bloated C++ code: OpenOffice and KDE4 desktop
- slim Java code: Eclipse (the start is slow but after that is faster than Visual Studio written in C++)
- well written C code: Apache Http server, Linux kernel, a lot of other examples
- bad written, memory hungry code (C): GCC compiler tools and linker
C++ was not able to remove the legacy so the compiling of some C++ files may take hundred of megabytes, if they use multiple headers + templates on GCC (cause of including headers, expanding templates, etc.) still hard to match in a big sourcecode.
Java/.NET is useful in places where the speed matter (that is why they do benchmarks on Java) but mostly to simplify a complex business logic that C++ rarely can match. The C++ advantage remains still the huge codebase that is hard to be matched by any non C/C++/ObjectiveC language/environment.
Well from a library standpoint Java probably nowadays surpasses C++ by miles. I am not talking about the huge classlib which comes with every JDK. C++ people alwyays talking about the STL really makes me laugh, this feels like being stuck in the early nineties. But there is a myriad of third party libs and literally thousands of really well written opensource extensions. Add to that the probably best coding tooling in the world, and you can see that sometimes it makes sense to look what others are doing in their domain!
Member since:2006-01-02
It's possible (and done with all libraries and many commercial .NET packages) to have the code precompiled into native images and stored in the .NET image cache using the NGEN system. This has a mixed effect because some of the dynamic parts of the code become slower (the native code has to have extra checks for cases which were not known at pre-compiling time). On the other hand, the code pages become shareable and you don't pay the initial load time and runtime costs of JITting the code.
It's possible to have C# compiled all the way to native code and have no JIT at all. The Bartok compiler from the Singularity group at MSR does this.
Member since:2005-07-06
Member since:2006-01-18
Apart from ThinkFree, can anyone name any heavyweight software, open-source or proprietary, which is based on a non-native platform?
Yes, basically all java web containers, Eclipse, Netbeans, Intellij, Google Android, Limewire etc...
Member since:2005-07-07
That's nonsense that people in the Java/C#/Python camp keep on bringing up but it has no basis in reality. Nobody writes large scale applications in Python, so I'll leave that out of this discussion.
Adobe is happy to rewrite Photoshop in Objective-C to target the Mac market. Why are they unwilling to rewrite it in Java or C# if it will guarantee "easy" portability?
Managed languages will always have additional overheads compared to compiled languages. For many end-user facing applications, these overheads are just unacceptable. Managed runtimes add tremendous memory overhead that makes them unpractical for things like office suites, photo editors, browsers, and most other pieces of software.
Note, this is not to say that managed languages have no place on the desktop. They're widely used in in-house business applications as they allow for a shorter development cycle than traditional C++ applications. Also, business desktops tend to run less applications than home user ones so the increased memory usage is not so easily felt.
The move from assembler to C to C++ became practical as hardware improved. Perhaps in the near future when 64 bit machines and operating systems become ubiquitous, and everyone is running with hundreds of gigabytes of RAM, we'll start to see more applications targetting managed runtimes. Perhaps not, as some would argue that the there aren't any long term productivity benefits in moving to managed runtimes.
Member since:2006-01-02
Adobe probably has no problems linking in arbitrary C++ code into a program that contains a smaller Objective-C 'View' component. That's a lot harder to do with Java (which doesn't have great support on the Mac anyway.. so that wouldn't be an option).
Microsoft's equivalent set of tools, the Expression Suite, is actually partially written in C#. It's entrenched like Adobe's stuff, but I'm sure they would refrain from C# entirely if it were incapable. Media Center is also written in Managed Code and seems to perform quickly enough (at the very least it doesn't seem to be CPU-bound).
Member since:
2005-07-24
Member since:
2005-07-06
I think the biggest problem with C++ is whether you're writing your own program, or trying to maintain/modify someone else's. I've not seen many C programs that would give anyone trouble maintaining, but the majority of C++ programs are the worst spaghetti code imaginable. It's too easy to make a bad C++ program, and then YOU/WE get stuck trying to make it into something useful.
This is probably because technical schools were pushing C++ and JAVA for the last decade or so, so every idiot and their dog who thinks "they be progamor" writes truly dreadful C++ that somehow manages to be adopted by people/companies.
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