Slashdot Mirror
Was Linus Torvalds Right About C++ Being So Wrong?
Nerval's Lobster writes: Perhaps the most famous rant against C++ came from none other than Linus Torvalds in 2007. "C++ is a horrible language," he wrote, for starters. "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." He's not alone: A lot of developers dislike how much C++ can do "behind the scenes" with STL and Boost, leading to potential instability and inefficiency. And yet there's still demand for C++ out there. Over at Dice, Jeff Cogswell argues that C++ doesn't deserve the hatred. "I've witnessed a lot of 'over-engineering' in my life, wherein people would write reusable classes with several layers of inheritance, even though the reusable class wasn't actually used more than once," he wrote. "But I would argue that's the exception, not the norm; when done right, generic programming and other high-level aspects of C++ can provide enormous benefits." Was Linus going overboard?
Maybe that's what it is. I write a lot of C code, some of it pretty good, but I just can't "get" C++. I appreciate the class stuff. Heck, I pretty much do the same thing using structs in C but past that, the rest of C++ just loses me.
You can find some really elegant C++ code out there. I am quite fond of the Qt libraries, for example. But Qt is its own C++ dialect. The company I work for codes a lot of our software in C++, and it is really nice, clean, maintainable code. But we have a style guide that everybody has to follow, and that's how we pull it off. Essentially, we are not writing in C++. We're just using a C++ compiler to compile NomLang.
In 1998 David Gelernter wrote a book that effectively argues that elegance and beauty in engineering are essential features that lead to benefits beyond the merely aesthetic.
He is still right.
The 'elegant' and 'concrete' example in TFA is ugly and hard to follow, even with plenty of understanding of lambda expressions and languages that offer them. I have other, better high level language options and other, better low level language options. C++ fails the test. C++ is not for me.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Bad programmers can produce bad code in any language, including one as well/thoroughly specified as Ada. The difference, though, is that what that code actually does is less subject to interpretation by the compiler.
I've observed that two Ada programmers will argue, "Is this program legal?" If the program is legal, they both -know- what the compiler will do (modulo the rare compiler/optimizer bug, which was usually caught through the stringent compiler validation.)
Two C++ programmers will argue, 'What will my compiler do with this code?"
Linus was right (I didn't agree with him when he wrote that but I do now). Jeff doesn't answer any of the major issues with c++: Lack of standard ABI (preventing interop with other languages), insanely complex grammar, years of paradigm shift, action at a difference, lack of abstraction away from computers, etc. Java/C# have completely displaced it in the business world and C still dominates system programming. C++ would be already obsolete except that it caught a big with the gaming industry...real-time games can't tolerate GC languages and C is considered too baroque to many developers.
Slashdot used to do full disclosure, under its previous owner. Dice lacks even basic business ethics.
Are you comparing the complexity of Java vs C++ (as a language, not as a runtime)? Are you kidding?
You can write convoluted code in any language, this is true. But C++ code can be made UNREADABLE as well as convoluted. In Java, there is only the one way of writing things. You can architect them differently if you want, but there's usually one way to write them. In C++, you have a hundred. THIS is the problem with C++. And let's not even talk about macros which is one more way to write things. You can actually write your whole program only through macros. Macros are turing-complete. They're just a language inside the language... This is pure madness.
Write boring code, not shiny code!
why not Python and ANSI C? Then you have productivity and glue code of Python and the raw speed of C without all the clutter.
The major problem with C++ is that it's popularity means there's more crap code written in it by bad programmers than any other language. But, to borrow from a quote, a bad programmer can write bad C++ in any language. I've had plenty of experience with bad programmers and bad code, and the problems rarely stemmed from the language used. They usually stem from the programmer not understanding the language or the environment and from an all-too-common mule-headed desire to design their part of the software the way they want it to work rather than in a way that fits with the rest of the software. Languages where this isn't a problem are typically new enough that there's only been one "right way" to do things taught. C++ is old enough that there's a variety of approaches built up over time, leading to the problem.
As for C++ being so popular, that's because well-written C++ can beat most other languages in performance. I've learned one thing over the decades: good engineering in software is a great priority as a developer, but from the business side it's irrelevant. Business cares that it gets the correct results and it runs fast enough. It could be the worst Rube-Goldbergesque contraption under the hood, but as long as it gave the right results and performed like a Formula 1 car they'd be ecstatic. C++ makes it easy to achieve that in the complex software common in commercial environments.
You can find some really elegant C++ code out there. I am quite fond of the Qt libraries, for example. But Qt is its own C++ dialect.
Ditto on Qt. Qt can be a beautiful thing sometimes... but then comes pre-compile, which turns it into an anus-puckering nightmare for those who don't know you're using it ;) .
The company I work for codes a lot of our software in C++, and it is really nice, clean, maintainable code. But we have a style guide that everybody has to follow, and that's how we pull it off.
That should be the norm in any competent shop, though.
Mind you, I've seen shops where styles are horribly mixed-up. That usually happens when Company A buys Company B's codebase and nobody cleans up the stuff from Company B. OTOH, I've seen instances where different teams in the same company decide to become special snowflakes and go their own way, making life into a giant shit sandwich for DevOps, QA, or SCM to eat - especially when they have to point to something and say "...fix that, because it's breaking Jenkins/Tito/unit tests/etc... and WTF man, we have artifacts for a reason!"
But then, I just came out of a Java shop where they were using Geronimo, Jetty8, Jetty9... Java 1.6 and 1.7... all in the same 'effing overall product (just that the components sit on different servers.)
Long story short, it takes discipline to keep everyone rowing in the same general direction - enforced styleguides are a part of that. Discipline also keeps things from becoming an unmanageable mess, if the head coder has the spine for it.
I usually use C++ as "C with classes". No fancy stuff like STL or Lambda expressions. That works well, and most companies where I've worked use C++ that way.,
I have discovered late in the game that Python + Fortran is almost magical. It's better than Python C++. when you are needing fast algorithms or code close the metal (SIMD or GPU) then fortran provides all the muscle that you need without all the baggage of c++. You offload complex class and memory allocation to the python.
The amazing thing I really like about the fortran is that it compiles so damn fast compared to C++ that it's easy to write a python program that generates optimized fortran and then compile it at run time rather than simply pre-compile a C++ library to include. The fortran is cleaner looking and its hard to make typos. The limits and ugly bits of fortran are pretty much not a concern since those chores can be offloaded to the python.
Some drink at the fountain of knowledge. Others just gargle.
Any language that allows the programmer to override the '=' operator is truly, verily, bad.
This is, to my mind, the most fundamental problem with C++: it is impossible to look at a page of code in isolation and know what it does, with confidence. Any of the operators could have been redefined to do anything. This is not a theoretical problem, I encountered a code base of horrors that a nerd who though he was God's gift to nerd-dom dreamed up, which had numerous standard operators reassigned to make the code he wrote "look elegant". It was impossible to analyze or maintain.
When the meaning of a simple programming construct is indeterminate, the language that supports it has failed disastrously.
Second class citizen of the New Gilded Age
This must be prefaced by mentioning that I have little experience with C++ code, the industry that I am in (Safety Critical Avionics software) absolutely refuses to use the language. In fact, the only thing I can really comment on are the reasons given to me as to why it is not used in this industry.
Compiling repeatability
Part of Safety Critical Avionics is that the binary must be perfectly re-creatable. At any time if an issue comes up someone must be able to rebuild the configuration used for compiling (versions, software packages, patches, etc.) and get a perfect match to the released binary, bit-for-bit perfect. Somehow most C++ compilers and libraries are unable to achieve this, using the same exact machine (no patches or changes) and compiling at a different time gives a different result. This has been demonstrated on several different compilers, using nothing other than standard libraries.
Code-to-binary and structural coverage analysis
For DO-178B Level-A software (paraphrase: "If this software fails, people die.") there is an analysis performed matching every line of code to a block of assembly, verifying that the compiler didn't add anything in that will cause issues. This prevents using some optimization options in C as that makes things too unreadable. However that also excludes C++ STLs and Boost libraries, as once you get into those libraries the traceability breaks down into impossibility very quickly.
Internationalization
On the side our company works on non-safety-critical software projects as companies need our help and we are looking for work. One of those side jobs is taking an application written over several years for a research facility and making it ready to be sold internationally. The project uses C++ and is converting X11 and Motif to QT, at the same time updating it to go from hard-coded English to strings that can be translated to multiple languages. The amount of cursing I hear from those engineers dealing with the internationalization of C++ far outweighs everyone else in the company on all other projects, apparently the design of the C++ language made many decisions that make such efforts very difficult.
So, mostly hear-say but from trustworthy and knowledgeable people, which is why I rarely touch the language.
DEMETRIUS: Villain, what hast thou done?
AARON: Villain, I have done thy mother.
Shakespeare invents 'your mom'
It's both. Type import this from the interpreter, and you'll get this:
While it doesn't always manage it, if you read the discussions and PEPs relating to the language's design it's clear that the idea of a "Pythonic" way of doing things is one of the top considerations.
C is quite stable compared to various other language, even factoring the C99 implementation slowness or difficulty in. Since the C11 change of standardization policy, the language will be even more stable in the future.
Honestly, I find a random program written in C to be on average FAR less maintainable than one written in C++, usually because they end up reinventing the wheel about 50 times, usually poorly. The C program that I work on at work is one gigantic mass of poor wheel reinvention over and over again. Its impersonation of objects and inheritance (for sending message) is terrible, utterly terrible, it's almost impossible to build and send a message without messing up in some way due to all of the interconnected pointers. The macros they use to try to "simplify" it only make it worse. Some parts of the code have macros nested literally dozens of levels deep.
"Are you hungry? I haven't eaten since later this afternoon." -- Primer
STL and lambda are my main reasons for using C++. They're bloody awesome.
Here's my standard challenge for C people - I've given it many times in these sort of threads and not once gotten a real response that meets the specs. Show me the code (emphasis: show me actual code, don't just say "... this is how I'd do it" and a rough description), full code (emphasis: full) for a program launching a detached (emphasis: detached) thread, such that it can happen an arbitrary number of times with no guarantee that other threads will be done (emphasis, there can be more than one thread at a time), to run the function do_something(Foo a, Bar b) (emphasis: two arguments, arbitrary size) - where the values passed for a and b are variables local to the context that launches the thread (emphasis: local), so they need to be passed by copy, not reference.
This is not at all some sort of esoteric task - launching threads with nontrivial local arguments is pretty basic, there's millions of use cases for something like this. Here it is in C++11:
std::thread([=](){ do_something(a,b); )).detach();
Little short line of code. Surely for such an obvious, non-esoteric task, C can't be much harder, right? Any takers?
(Don't bother responding if your code can't meet all of the boldface conditions... in the real world, you can't simplify the system requirements to meet the deficiencies of your coding language)
"Are you hungry? I haven't eaten since later this afternoon." -- Primer
Yet from what I've read, the Joint Strike Fighter project used large quantities of C++ in their systems.
You mean that fighter that is still over-budget, over schedule and the software systems still don't work?
Sorry, but the original Lisp got quite a few things wrong itself and by the time it got around to fixing it had missed the boat. Here's a sample
If modern Scheme had been introduced in 1965 instead of 1975 we might be today programming in some modern dialect of Lisp.
Now some fanboi will come and explain why these things aren't a bug but a feature in 3, 2, 1
I found, after decades of experimentation, that simplicity and consistency beats everything else if you want to produce reliable software. Now, I use C exclusively just so I don't have to deal with multiple different ways to do something because the C++ standards committee got a bee in its bonnet about the latest hot new concept that first came out in 1959 and was forgotten until last year.
The problem with possessing multiple ways to solve a problem is that every developer takes it as a personal challenge to find and use all the different ways. To make things easier I simply wrote a library containing those things that I usually need (sane string operations, c/line parsing, vectors, etc) and found that 90% of what you can do with X lines of fairly complex grammar in C++ can be done with around 1.5X of straightforward C grammer. I don't need the remaining 10% if it needs 300% cognitive effort to get.
The library is here: Extended C library, libxc, so help yourself (BSD license)
.
Documentation is over here: PDF link, but html available, although the documentation on the website is out of date. If you download the library source you get the full up-to-date docs.
I'm a minority race. Save your vitriol for white people.