I heard about this note from Linus Torvalds from David Wolever yesterday. Here’s Torvald’s opinion of C++.
C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much, much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
Well, I’m nowhere near as talented a programmer as Linus Torvalds, but I totally disagree with him. If it’s easy to generate crap in a relatively high-level and type-safe language like C++, then it must be child’s play to generate crap in C. It’s not fair to compare world-class C programmers like Torvalds and his peers to average C++ programmers. Either compare the best with the best or compare the average with the average. Comparing the best with the best isn’t very interesting. I imagine gurus like Bjarne Stroustrup and Herb Sutter can write C++ as skillfully as Linus Torvalds writes C, though that is an almost pointless comparison. Comparing average programmers in each language is more important, and I don’t believe C would come out on top in such a comparison.
Torvalds talks about “STL and Boost and other total and utter crap.” A great deal of thought has gone into the STL and to Boost by some very smart people over the course of several years. Their work has been reviewed by countless peers. A typical C or C++ programmer simply will not write anything more efficient or more robust than the methods in these libraries if they decide to roll their own.
Torvalds goes on to say
In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C.
I’ve had the opposite experience. I’d say that anyone wanting to write a large C program ends up reinventing large parts of C++ and doing it poorly. The features added to C to form C++ were added for good reasons. For example, once you’ve allocated and de-allocated C structs a few times, you realize it would be good to have functions to do this allocation and de-allocation. You basically end up re-inventing C++ constructors and destructors. But you end up with something totally sui generis. There’s no compiler support for the conventions you’ve created. No one can read about your home-grown constructors and destructors in a book. And you probably have not thought about as many contingencies as the members of the C++ standards committee have thought of.
I disagree that writing projects in C keeps out inferior C++ programmers who are too lazy to write C. One could as easily argue the opposite, that C is for programmers too lazy to learn C++. Neither argument is fair, but I think there is at least as much validity to the latter as there is to the former. I think there may be a sort of bimodal distribution of C programmer talent: some of the best and some of the worst programmers use C but for different reasons.
I do not claim that C++ is perfect, but I’ve never had any desire to go back to C after I moved to C++ many years ago. I’ll grant that I’m not writing my own operating system, but neither are the vast majority of programmers. For my work, C++ is as low-level as I care to go.
I’m not defending Torvald’s assertions, which are pretty strong, particularly with respect to programmers and kinds of programmers. Nonetheless, a C programmer having a mastery of C declarations, of storage allocation and reclamation, and of the standard C library (augmented perhaps with one or two special ones, like Gnu) plus a lot of self-discipline can IMO do fine with just plain C. C++ is important to know because there are large and valuable packages and systems written in it, and even if C is the primary linking to C++ code is straightforward, as is calling C from C++.
I’m far more interested in productivity … number of non-syntactic bugs per module of C written, and time to produce. There’s little reason why people should be any more error prone in C than in any other language, although surely you won’t get as much done per unit time in C as in R for the set of quantitative things that interest me. There are other options, too, like Ch.
Some of the C vs C++ argument may be resurrecting the OO versus non issue. It is true that once having embraced OO, I’ve been regularly disappointed by its support in many programming languages other than Smalltalk, and the uses made of it by programmers. I find some of the uses of it in R remarkably good, but I do not see the pressure to use it as great as I thought years ago. This may be purely a stylistic issue on my part.
… As may be my opinion of C++. I think that if a design is functional in C, passing function parameters, and using vectors or lists of structs, some of the benefits of OO are had automatically.
Finally, my notion of self-discipline includes the absolute insistence that no messages be produced by the compiler, including warning ones, and that liberal use of the assert facility be made, both for self-checks and as semantic documentation.
C++ is a horrible language. Sorry to be blunt, but as someone with over ten years of experience in it… and I made a living selling C++ software for a time… C++ is an absolute piece of garbage.
Complex code becomes insanely unreadable. Have you ever browsed the Boost library? Just building the thing requires a Ph.D. in compiler technology. The source code is totally unreadable to me, despite my 10 years of experience with the language. Every line is using another quirky template trick. Insane.
Yet, I repeatedly choose C++ over the alternatives. There are several reasons:
1) STL is a damn good data structure library, irrespective of C++. It is ten times better than the alternatives in C.
2) C++ is widely available, widely supported, and GCC C++ is a nice de facto standard. I can build my C++ on any Linux or Mac machine I come across without much of a glitch. Yes, C is far more portable, but C++ is good enough.
3) C++ is insanely fast. Yes, C is even faster, but compared to Python, all these languages are crazily fast.
4) C++ is a respected and well-known language. When I post my software for everyone to use, I don’t want it to be in some esoteric language that will deter people.
5) C++ still allows me a tight low-level control. Less so than C, but enough for my needs. Java, in comparison, is a bit of a pain in this respect… for example, I often need unsigned integers in my work… Java does not support them… working around this is a major headache.
6) No pointer! Once you have learned to program in C++ without pointer, you can produce far more reliable code with less effort. There are some corner cases where you still need pointers, but I’m not even sure. In comparison, you cannot work without pointers in C.
A lot of really smart people have thought for a really long time about postmodernism; a lot of smart people + a lot of effort + a bad left turn somewhere still equals an unusable mess. (/flamewar on!)
To be honest, I don’t have quite as big a problem with C++ as Torvalds seems to, but I still wouldn’t go out of my way to use it for any project I actually cared about.
Isn’t this the same argument made against FORTRAN, PHP and VB, etc.? A good programmer writes good regardless of the language. It’s like Steve McConnell wrote in Code Complete, you should write INTO a language NOT IN a language.
It’s like saying hammers are bad, because you can bash in skulls with them and only skull bashers use hammers. That’s why I only use screwdrivers…
I agree with the previous comments. I think that Torvalds meant to say that C++ is a poorly designed language, and I believe this statement is uncontroversial. I think that John focused on programmers’ productivity, but I have to disagree with him. C++ is a sprawling, complex language that allows many programming styles. It’s difficult to read other people’s code. It is easy to make subtle mistakes. In other words, it’s a language that gets in the way, whereas C is not.
We can dissect why it came to prominence (good timing, the backing of Bell Labs, backward C compatibility) and why it’s still relevant today (large code base, a powerful STL, sunk costs for scores of programmers), but this is also beside the point. A more interesting question is: why use C++ on a new project today? I can’t see any reason. Fast numerical code? Use C or Fortran, since all stable and maintained numerical libraries are in C and Fortran, and APIs are in ANSI C (e.g., CUDA). Embedded and operating systems? Everyone uses C, for a reason. End-user applications? Java and/or Python. Server-level application programming? Python/Ruby/PHP etc. Data analysis? R or Java libraries (e.g., Weka), maybe functional languages.
Sure, you can use C++, or assembler for that sake, in all these domains. Not recommended though. The advantages of C++, C compatibility and OOP, have been eroded by the emergence of new OOP languages that allow for greater productivity.
The two areas were C++ has an intrinsic competitive advantage are videogames, although the AI and glue programming is increasingly performed by scripting languages like Lua and Python; and some performance-critical applications, e.g. DBMS engines, indexing etc., although even in these areas Java has made great strides (e.g., here and here).
I’m with you, John. C++ doesn’t force you to write readable, maintainable, correct code, but it does give you the tools to do so. Now, I think C++ out-of-the-box is pretty useless, but with STL and Boost, you have an incredible toolset.
@Daniel, I have less experience with Boost than you, I think, so I can’t directly address your comments, but from just using Boost I have saved tons of time. For example, the command line argument library is genius! I have no idea how they implemented it, but they’ve basically created a declarative, domain-specific language for command line arguments inside of C++. I have no idea why it compiles, and as long as it just works I have no interest in learning. I accept that my command line declaration will look nothing like “normal” C++, but I accept it on its own terms and it is just what I need.
Now, if you have to use MFC or even ATL, you’re likely to have a terrible opinion of C++. All of those macros might be okay if the abstraction never leaked….
They leak all the time.
I have to go the command line and run the pre-processor just to see what is happening when debugging some of the more complex stuff. MFC is especially bad. It combines gratuitous macros, simply _bad_, outdated OO design, and a complete failure to integrate OO with the Win32 windows object model and messaging architecture in a way that abstracts either. Don’t get me started on how their default serialization strategy locks in bad design and prevents refactoring.
The point I’m trying to make is that there are many old, terrible C++ libraries. That’s not the same thing as saying C++ is terrible.
When I write C++ using tenets of refactoring, RAII, single responsibility, composition over inheritance, and generally the SOLID principles, I can go back six months later and look at the code and smile. That’s a great feeling, and one I can’t imagine I’d ever have in straight C. It’s not to say that I don’t hope to transition to more C# in the future, but with the right techniques I find that I can be a happy camper in C++ too.
Dave
@Winawer: Good point: A lot of smart people have put a lot of effort into a lot of bad ideas. Still, this is something of a sibling rivalry. The C and C++ communities are trying to solve the same problems with essentially the same tools. So I think the STL is comparable to home-grown C or C++ algorithms and containers.
I think you hit the nail right on the head, David. I’m a fan of C++ because I’ve used it for some time and I know how to get the most out of it for my purposes. I think that Torvalds continues to be an ass about this issue because it’s just not his style, but he falsely attributes Everything Bad About Software to C++. He can do amazing things with C, and that’s great. He should continue to use it.
Despite that, though, I think that I agree with gappy that C++ isn’t necessary most of the time. I like it for “guts” work or bridge work (I should say that I have liked it), but for the most part, apps can be written in Java or some other language, and web apps these days never ever use C++.
I find that the benefit of C++ mostly lies in the STL. As far as Boost goes, everyone should learn to use shared_ptr, but that’s going in the standard now. The nice thing about other Boost libraries is that they “just work” almost all of the time, and I have rarely had a problem with them when I apply them to their intended purpose.
I genuinely believe that C++ is the best language in the world.
The reason I say this is that has the best support for (compile-time) generic programming.
You can actually write a huge library with minimal redundancy. C++0X is even going to improve on this.
Also when the compiler is done with templates, only the bear necessities remain. I guess it would not differ much from compiled C code.
And anyone can understand what is happening from looking at the code, which is nearly impossible in a language like Ruby – which I consider the second best language in the world because it gives you so much freedom AND expressiveness.
So to me, even more than OO, generic programming is what sets C++ apart.
I have deep experience with Java and C++. Writing C++ programs using Boost and a good IDE is almos as easy (sometimes easier) than writing Java programs. The IDE I use is SunStudio IDE. Boost makes writing C++ programs very easy. C++ without Boost is hell.
You know what, the best way to convince Linus and the gang is to show some real results. If a group of C++ coders rewrite git core and call it gitxx (a la jgit, which is a pure java implementation of git) or something and show that you can implement the same code shorter, more portable and faster (possible given STL sort is much faster than qsort), I’m sure he’ll shut up on the subject for good :)
I believe that C++ is the language that you make it. If you use Boost, STL, and Qt4, then C++ is about as safe as Java. Using shared_ptr objects, RAII, and actual exception handling makes C++ pretty rock solid. However, contrary to what Daniel says:
C++ is a superset of C, so therefore using C++ you can get as close to hardware as you desire. Again, though, C++ is what you make and want from it. If you want insane speed, turn off RAII, exception handling and the other tweaks you can do to make it more C-like but with a standard dialect. If you want a type-safe, object-oriented, thread-safe language…C++ can do that too. I agree with John when he says that you end up reinventing the aspects of C++ in C. I’ve got so far as implementing function calls in structs with manually managed constructors and destructors. This bastardized C++-like language wasn’t my design, but I had to code using it. A C++ compiler wasn’t available for the platform (a DSP chip) and the project dictated certain structure.
I find it sad that more didn’t make it into C++0x. I would have really liked to have seen concepts worked into the standard. It’s really amazing what the guys at Boost have done already with templates and type requirements, but it would have been really nice to extend the functionality into the language itself.
The bottom line is that C++ has the flexibility to be the language that you want. Use it as a functional language if you want. Use it as a pure, multiple-inheritance, object-oriented language if that’s your thing. The beauty of C++ is in its flexibility…yet it doesn’t lose its raw bit-smashing strength of C.
I have largely negative experience of C++, frankly. So far I’ve always come into C++-based projects from the outside, as it were, getting a piece of software and needing to adapt or extend it. With, usually, none of the original authors or any internal design documents (what classes, what are they doing, how do they interact?) available. The software is usually part of a research project, so it’s not written by software professionals, and it has usually (always, really) already been repurposed and extended by other people who have grafted on their changes to the existing code base with the same lack of documentation and other information I face myself. And in such a situation, many of the nifty features of C++ – operator overloading, templates, multiple inheritance – conspire to make the whole thing absolutely, hair-pullingly unreadable.
“So what?” you say, “of course it’s a mess when all the tenets of good programming and design are violated.” Sure. But it’s also the reality for most software, especially the kind of semi one-off stuff you get in lab settings, written by people whose primary area of expertise is not software design. And reality is not going to change for the benefit of a programming language.
The language is a tool and should adapt to its intended use, not the other way around. For this kind of software development – non-professionals, one-off or limited number of users, where adapting and repurposing the code itself by strangers is one of the legitimate use cases – the full C++ language is a rather poor choice. Similarly largish systems written in tools like Python, C# or Java are noticeably easier to get up to speed with and get running. They do suffer from a lack of the low-level interfaces you frequently need, though.
What is a _good_ choice, in my experience, is “C++ Lite”. Treat the language more or less as C with objects. No operator overloading, no multiple inheritance (use pure virtual classes to create “mixins” or interfaces), no templates. Yes, you end up with more code, and more duplicate code, but when it’s supposed to be grasped relatively easily by other people that is overall a good thing, not a bad one. Keep things local, keep things explicit and keep things grounded and it’s suddenly a lot easier to understand and adapt.
In my opinion only of course, and in this particular kind of situation. It’s a kind of situation that I suspect is a lot more common than the disciplined team of professionals where nobody else ever sees the source, though.
I don’t think he will, actually. His objections are irrational enough that he’d find something to object to, no matter how perfect the code was. He objects to it simply because it’s C++ and he doesn’t like it. It’s a canard.
I don’t think that any C++ detractor believes you can’t get real results with this language. Speed is on par with C, the language is incredibly vaster, and STL + Boost are unfathomable (esp the latter is incredible). I think that Torvalds means that the language is poorly designed. It doesn’t encourage a good and consistent programming style) and allows for error so subtle that even Stroustroup couldn’t easily spot. But his criticism is not so important for those who have invested time and codebase in the language. I wonder if going forward new CS graduates will do heavy C++. My guess is not. I foresee a lot of lightweight C++, close to Java, but not much code leveraging the power of C++, because for a newbie the investment is not justified. I am not emotionally invested in this issue. I am just curious to see the face of programming in 10 years.
I think this is a case of Torvalds being unable to understand or write in C++. Now what I’ve said is controversial, but at it’s core, when intelligent people like Torvalds make douche like commentary it’d due to psychological reasons, not their ability to make objective comparisons. And Torvalds has become so specialised in C writing that I truly think the guy is baffled by the language and the abstract concepts. Add to that he’s a control freak who needs to pore over every gram of code due to being an OS coder, and he would be tearing his hair out trying to understand some of the addon libraries for C++ like the STL. To be honest, though he has a point: things like the STL have tons of extra fluff you rarely -if ever- use. But when he dismisses the language he’s basically whining that he has become so specialised in C that he feels like an idiot again trying to relearn some in C++. I bet assembly coders would feel that C is stupid for the similar reasons that Torvalds is bashing C++. I also think the point about comparing great C programmers to great C++ programmers, and average to average was the crux of this issue.
The problem with C++ is that it wasn’t designed, it was accreted. Stroustrup, being a researcher, had no issue with adding any and all features to the language on a “sure, let’s give that a try” basis. The result of course is hopeless complexity.
If he had stopped around 1987 or so, C++ would have remained a decent language.
After having programmed in C++ for many years professionally, I absolutely detest that language. It’s not that I don’t understand the language – I understand it very well – but the problems I always seem to get into are figuring out the inane complexities that C++ brews up in short order. There are so many ways to needlessly complicate your code to the point even you can’t work with it. There are so many non-standardized conventions that one just gets into a huge mess in short order. Trying to get multiple libraries to work together is like pulling teeth. Then, just to add insult to injury, at every spot where the design of C++ could of made it easier and more productive, the designers made sure to take the route that did the exact opposite. There are hundreds of little things that can go wrong, and this makes for a large amount of time spent fixing shit.
I’ve been using a lot of C and Objective-C lately, and just love it.
The context of the original discussion seems to be ignored in this post. It devalues it a fair deal, not to mention it’s 2 years late.
I like C++, and have programmed in it for many big projects although I don’t use it much nowadays, but STL and Boost and other total and utter crap is absolutely correct from my experience, at least the STL part. In a particular cenario where I had lots of complex and dynamic trees and lists, the STL memory managent was so bad that after half an hour of number crunching the program always ground to an halt because of memory fragmentation. I ended up dumping STL and implementing all the data structures and memory management myself. So sometimes you don’t realize the crappiness of something until you use it to its limits.
John, don’t feed the troll.
Linus is smart but too arrogant.
It would be nice to have a C++ kernel that replaces Linux. Take a look at:
http://l4ka.org/projects/pistachio
“L4Ka::Linux, a modi ed Linux 2.4 kernel running on top of L4Ka::Pistachio,
enables unmodi ed commodity applications to coexist with customized system components,
which allows a smooth migration path towards customized services, and
supports secure extensions to monolithic operating systems.”
Well… C fits in your head. C++ doesn’t. At least not easily. It’s easier to understand the whole language of C. With C++, it seems like an endless adventure of learning new ways to do the same thing. With C you can concentrate how to write the most beautiful code with the limited set of functionality that C provides (without reverting to ugly hacks… the limits of the language are easy to understand and cope with). With C++, you end with the same questions every time: “should I write the code this way, or would it work the better the other way”. Of course, if you can fit C++ in your head completely (not easy task to achieve), then you probably won’t agree with that I said.
Yes, not only are you not writing your own extremely high-profile operating system and distributed version control system, you’re not writing high-profile open source software either. But Linus is, and he’s defending why HE chose C for those.
One important detail that everyone forgets when entering this debate (and also the debugger debate) is that Linus’s public arguments concern his public open source projects, and the values of open source projects are going to be much different from the values professional programmers working in proprietary (shrinkwrap and custom systems) software care about.
In proprietary software projects managers try to maximize the value they receive from programmer time. Linus simply doesn’t care about your time. He routinely shuts down what would’ve been tens of thousands of dollars of work (in the form of rejected patches) on a whim.
You’re basically arguing apples vs. bicycles.
Linus Torvalds is right! Some people are f*cking idiots at C++ coding, actually some people are extremely poor programmers. The weird side-effects of C++ are almost impossible to see when reading the code. Some crappy C++ code you almost have to single step with a debugger just to understand what the hell it is doing, unlike C. C++ is one of the biggest cluster-f*cks that I’ve ever seen.
For embedded development, C++ causes you some pain when you want to pass data between tasks and interrupts.
I would like C to borrow some of the good aspects of C++, like the concept of classes for encapsulation purposes.
Writing good C++ code requires good dicipline, and good tools (IDE + libraries). There’s a lot of awful C++ code out there, but it’s the potential to write good code is what makes a difference. I’ve made very good C programs using good techniques and they end up very well, but I end up with many limitations that C++ does not have so I’ll always preffer C++. C++ (with STL+boost) allows me to do much more than C with very little/zero overhead so for me writting C code for what I do it’s pointless.
@dcode
C++ is a superset of C
No. Not true. That’s a myth.
There are supersets of C, such as Objective C. But C++ is not one of them.
Technically C++ is not a superset of C, but it nearly is. The set of C features not in C++ is small and mostly deprecated.
You are debating Torvald’s view only because he is a celebrity and he is a celebrity not because he is talented or knowledgeable but because he is the leader of a cult and, in fact, a cult with a tiny share of the OS kernel market. I suggest you forget about Torvalds and his crazy fringe beliefs.
“I imagine gurus like Bjarne Stroustrup and Herb Sutter can write C++ as skillfully as Linus Torvalds writes C, though that is an almost pointless comparison.”
I’m afraid that might not be as obvious as you think it is. Torvald’s main goal is a high performance and portable git. Whether Stroustrup or Sutter can write C++ “skillfully” matters less than whether they can write high performance C++, and whether that code will actually build on a variety of architectures. It’s already “established” that idiomatic C++ is slower than idiomatic C via the Compiler Shootout benchmarks. Now have a look at theMozilla C++ Portability Guide and ask yourself how many rules people would follow, versus argue against. Then throw in some more rules for efficiency.
With C, Torvalds already knows the language perfectly well. And he has a community of developers on tap who know the language and his performance goals perfectly well. As you state, the lowest level you want to bother with is C++ itself, which is insufficient for anyone demanding performance. You need to occasionally look at the ASM compiler output and compare that to how fast you’d write it. So really, it sounds like his selection is working as intended: keeping people who refuse to understand low level implications away.
In my experience maintaining and extending enterprise apps for finance industry with large codebase (mio of lines of code) the last thing you want to see is C++. Like an earlier poster mentioned C++ allows too many styles of coding and too much complexity. And we almost always find that C++ coders have thrown themselves into reinventing the wheel because their APIs are so limited. Productivity in maintaining and extending someone elses C++ is just too low. C++ is probably nice when you can start a project from scratch and apply your own ideas on how to use the language but for many programmers doing projects from scratch is very rare.
C++ remains the first choice for lot of developers. I have used C++ to write a Kernel from scratch. Taj OS is first operating system developed in India which is totally based on object oriented concept.
C++ programmers can code C as well, so you can’t really say C++ programmers are horrible. A bad C++ programmer would also be a bad C programmer. There’s nothing really wrong with C++ as a language, but if you are attracting the newbies, that’s just the ability to generate hype around a language – and that is a positive thing.
If you look at how many ‘programmers’ are drag-and-drop .NET programmers who can assign values to properties and make a method call to classes developed by programmers developing an underlying tier of code, and compare that to Java programmers, would you really say .NET is a bad platform using the same analogy as C++ and C? After all, the development tools, the community support, and the number of programmers out there who can code in .NET make using .NET so much cheaper for developing simple applications.
why either bothering with languages ? use whatever suits your needs
Adding functions to do allocation and deallocation need not be the same as reinventing the mess that is C++ constructors and destructors. Copy constructors, virtual destructors, non-intuitive results if someone on your team misses one, unexpected breakage because of “smart pointers” (a misnomer if ever there was one), unpredictable execution orders, static constructors depending on extensive loader/library support (making them untrustworthy in anything but a standard user-level environment on a commodity general-purpose OS), massive abuse of the stack (see previous) . . . the list of problems with the C++ interpretation of this fundamentally simple idea just goes on and on. That is, in fact, one of the defining characteristics of C++: a simple and worthwhile idea extended and made more complex and overused until the problems are greater than the benefits. The same applies to operator overloading, for example, or templates (compiler-copied code is a poor substitute for a type system that allows one to create type-agnostic collection classes *once*), or a dozen other misfeatures.
A lot of the most readable, maintainable system-level code I’ve seen is “object oriented C” – C with a set of macros/libraries/conventions that implement a much simpler kind of OOP than C++ without encouraging the bad habits that C++ practically makes inevitable. In either language, one line of code can translate into many thousands of instructions, nearly as many cache misses and pipeline stalls, maybe even a page fault or two as all the required code has to be brought in. That’s good if those thousands of instructions are doing something useful in terms of the application at hand. That’s bad if it’s just running around in circles creating and destroying ephemeral objects because the person who wrote that one line had no idea that the ten programmers before her had added so many layers of abstraction and indirection – yet that’s exactly what C++ and the books on C++ encourage. I’ve seen *very good* programmers fall prey to that. C++ makes it way too easy for programmers to work at cross purposes and create mutually incomprehensible code, whereas fully comprehending each others’ code – including its resource and performance implications – is essential to serious programming.
C++ used *very carefully* is fine, but using it that carefully is more work than building the needed constructs in C. The necessary C++ coding standards to mandate use of certain constructs and forbid others, along with the enforcement that would be required to make that standard useful, would be far more burdensome than writing the bits of C code that are needed when they’re needed. One could say that the problem is not the language but the idioms and habits that have grown up around it. There’s some truth to that, but I believe the language itself must bear some of the blame for encouraging those idioms and habits. I think Linus is wrong about a great many things – typedefs, debuggers, and specs are three software-engineering examples I’ve written about myself. I don’t agree with him out of habit, but he nailed this one. C++ is broken at such a fundamental level that it might as well be by design.
I agree with Linus C++ sucks.
I believe Bjarne Strousstrup said inside c++ there is a much cleaner simpler language struggling to get out. I agree it is called c.
C++ tries to be all things to all people and in doing so becomes overly complex and fails to be good at anything. C++ tries to be a low level system programming language and a high level language to develop apps in. These are two tasks are very disimilar task. Your working on a app trying to work at a high level of abstraction then some noob developer decides to compromise your abstraction and safety with low level programming. I have seen the converse too your working on a system programming task and some noob decides to use high level programming constructs.
You want to do low level system programming use C
Your building high level apps use Java, Python, Ruby or some other high level garbage collected language
Use the right tool for the right job, C++ is never the right tool unless constrained by legacy.
C++ is a language with a schizophrenic identity crisis and way to complex.
Although I must confess when I have to use C++ at work and school I do use STL and BOOST for convienance BOOST has a lot of incomprehensable MACRO and template TRICKS in it.
It is really hard to figure out what the hell BOOST is doing under the hood.
Troy
Why not use `D’ instead of either `C’ or `C++’?
Jack of all trades, master of none. Several have made the point, if not in those worlds, and I think it’s the real problem many have with C++. Personally, I write a lot of code in C, mostly because it’s kernel stuff but also sometimes because it’s just the right tool for the job. I also write a lot of code in Python, because it’s the right tool for a different job. If I were learning to do some of those same jobs today and didn’t already have tools I’m used to, I might learn Ruby or Groovy. I might still learn Scala or Erlang for still different jobs. What I won’t do, and what I don’t believe any language designer should expect people to do, is use one language for all things. C succeeded because it was relatively easy to learn and to generate efficient code for. Python succeeded because it was even easier to learn. Groovy is rumored to be great for developing little domain-specific languages, while Scala and Erlang are specifically designed for complex distributed systems. None of them intended to be or do all things for all people.
John Ousterhout got it exactly right when he encouraged moving to a multi-language paradigm using the right tool for each task (http://home.pacbell.net/ouster/scripting.html) even though I don’t think Tcl is the right tool for much of anything. Even more important than the fact that C++ sucks is the fact that any one language sucks. Anybody who’s not at least thinking about which language to use for each project, or about how the functionality they’re implementing might be used from multiple languages, is a bit behind the state of the art.
“C++ tries to be all things to all people and in doing so becomes overly complex and fails to be good at anything”.
I think GOOGLE is good.
@Jeff: I agree with your point that no language can do everything well. And much of the disagreement in these comments results from people having different applications implicitly in mind.
I’ve swung back and forth between trying to find the best tool for every task and wanting to learn a small number of tools well and use that small set for everything.
At one point I was very much in the “best tool for the job” camp, but that got out of hand, both for me personally and for the people I managed. There’s a mental/organizational tax for every tool in play, and sometimes it’s better to use a sub-optimal tool than to introduce yet another tool into the mix. (Here’s a post I wrote along those lines.) I’ve also gone too far to the other extreme and thought I could use one language for everything, but that’s not workable. Maybe the best you can do is try to master one language in each category: one scripting language, one system programming language, etc.
Totally agree about language fatigue, John. At Revivio we had significant parts of the system implemented in C, C++, and Java. Impedance mismatches between them constantly created bugs and generally slowed down development. At SiCortex, important things were implemented in C, Python, perl, and bash, with other languages – Haskell and Lisp at least – in some niches. As with many things, it’s a balancing act. A toolbox that’s too big can be too heavy to carry, but one that’s too small might not contain a suitable tool. The trick is to minimize the product of “cost to carry” times “wrongness for the job at hand” for the problems at hand, and the answers are different for each programmer.
That’s why I haven’t actually learned most of those languages I mentioned, BTW. Either C or Python is generally “close enough” for the stuff I care about, though I definitely feel it’s time to at least play seriously with a JVM-based language and one designed for distributed applications. Fortunately, Scala fits both bills, though Groovy might be more fun and Erlang might be more instructive. Now all I need to do is find the time…
Chila,
“I think GOOGLE is good.”
Your logic if flawed
The fact that good C++ programs / software exist doesn’t imply that C++ is a good tool
I myself have written C++ code that I am proud of,
I have also written some good perl code too both those languages still suck though
Smart people can build good things with bad tools.
You can write good code in any language some languages just make it harder C++ and Perl being ones I am familar with.
There is no language that it is hard to write bad code in
Besides my impression from listening to google tech talks is that they are moving away from C++ towards Java and Python if you have better info please enlighten me.
Troy
Troy:
You said: “C++ fails to be good at anything”
…but…
1. Google’s core is made in C++
2. Google is good (in my opinion)
….therefore….
Your statement is false (asuming Google is good) & my logic is correct.
Let me explain: You said that there are no elements (programs) in the universe that had at the same time two characteristics (being written in C++ and be “good”), but I found one element that does (in my opinion). This element is called “counterexample”. This is basic logic learned in high school and it’s also intuitive.
Google Chrome & Firefox are also very “good”.
What browser do you use?
Adobe Photoshop is also very “good”.
The software inside the Large Hadron Collider is made in C++. This is a multibillion € proyect, I don’t think they’ll risk so much money by using the “wrong tool”.
If that’s the logic you learned in high school Chila, you need to go back. The only conclusion one can reach from your two axioms is that something good can be made with C++, not that C++ itself is good. To connect that conclusion with the one you stated, one must employ a second syllogism:
A1: Good things can only be made with good languages.
A2: A good thing has been made with C++ (previous conclusion).
C: C++ is a good language.
Unfortunately, as Troy already pointed out, good software can be made with bad languages. Happens all the time. It requires much more discipline and work than using good languages, but it’s quite possible. Without proof of A1, your counterexample is irrelevant. Good luck.
Yes I realized that after I posted it. I need A1. You’re right. I just got a little altered after reading “Your logic if flawed” from Troy and begain writing inmediatelly.
But I also think that if there are many examples of good significative programs made with the language, the language itself should be good. Why are these people then choosing C++? Because it’s a bad tool?.
I guess the snarky answer would be because they don’t know any better. A little more seriously, though, it might not be the wrong tool for them. There’s value in using a language that your developers already know, that’s well supported in the tools you’re already using, that the libraries you need were written in, etc. With the proper coding standards, and proper enforcement of those standards, just about any language can be used safely and productively. Many organizations can apply that kind of discipline to their C++ coding efforts, and get good results. On the other hand, there are good reasons why even some of your examples are considering or moving toward alternatives. They believe, and not without reason, that even if their programmers have created decent software using C++ in the past and can continue to do, those same programmers can be even more productive in other languages.
Can you pass me the links where I could confirm that some of my examples are moving?