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?
The problem with C++ is that it's way too easy to write write-only code, because the language has so many features that nobody but language experts understand all of them. So we all program in different dialects, and then scratch our heads when we read other peoples' code.
I always get halfway through a Nerval's Lobster summary before my anger/indignation/smug validation gives way to the sad realization that Dice has trolled me yet again.
Oh no, on the contrary. There are plenty of idiots who can write code in C++.
C++ deserves all the hate it gets. Life is too short and mental health too precious to become an expert in C++.
Linus was not going overboard. In this rare instance, I'd argue he hasn't gone far enough.
Although the language itself isn't truly, truly bad, the only thing that made it tolerable was a library like Qt. STL and Boost are so shocking it isn't even funny, as well as the attitude amongst many that they are some kind of 'standard'. That's where C++ really did go off the rails.
I have read maybe 1 billion articles about language X being better than language Y and in many cases it is pure religious fanaticism; someone has committed to a language and now justifies that commitment with zealotry. A very common refrain about any given language is how many people write poor code in that language. This argument is often reserved to support the more "sophisticated" languages. For instance it is pretty much a gold medal sport to crap on PHP; and yes there is lots of terrible PHP which probably stems from the fact that it is often someone's first language and that someone is self teaching.
Then other languages are looked at as toy languages by those who resent them, Python would often be a victim here.
Then there are the wonderful charts of speed which in theory would justify everyone using ASM optimized to their CPU.
But for me it is not one language but a pairing that has caught my heart. Python and C++ do just about everything I want. Python is just so damn productive. Then I use C++ for where Python falls down on speed or the environment itself is not conducive to C++ (embedded and multi-platform Mobile).
But to answer his cry about people over-engineering things with silly STL uber inheritance type crap. That is where oddly enough the zealots of C++ are their own worst enemies. They love C++ so much they are giving it a bad name. Many people use STL in some purist way that completely blows Keep It Simple Stupid out of the water.
But I really do hold a special revulsion for anyone who claims that their language "Enterprise" which translates to me as so shitty that nobody will notice that most of your drone developers are also shitty.
If you care about performance, the ability of C++ to "run on the iron" is a valuable tool to have in your arsenal. Add in inline assembler, and IF YOU KNOW WHAT YOU'RE DOING you can write blazing fast code in C++ and still provide a sensible code architecture.
There's no sense in blaming the language for the abuses developers have written -- you might as well indict English for the horrible spelling and grammar of many Americans...
If you know what you're doing, C++ is a terrific, powerful language suitable for a plethora of projects. On the other hand, if you don't know what you're doing, well, I guess there's Visual Basic or C#.
Linus is doing systems level work. At systems level work, there are a lot of mediocre and bad programmers who use the common language of C++. Those who know c well are unlikely to be the mediocre and bad programmers.
That is really a truism across all fields and languages.
In the business world with business logic, there are a lot of mediocre and bad programmers who use the common language of Java. You can filter out many of them by adding a skill requirement of some other less-used languages inside that realm of business software development.
In a field where everyone is doing Ruby development and you don't want mediocre/bad Ruby programmers? Require them to also demonstrate proficiency in another language.
In a field where everyone is using C#? Require them to also demonstrate proficiency in C++ or some other language.
If you only require a single thing you can get unskilled individuals with only a single skill. If you require multiple skills you are more likely to get more talented individuals, since the talented, higher producers tend to pick up a wide range of skills.
//TODO: Think of witty sig statement
I wouldn't use it for most firmware either. Firmware often has size constraints that C++ is less than friendly about. It also often runs in a limited environment that may not be friendly to C++.
This is all true, but I'm not sure how it's any different to almost any other popular language.
Java and C# have also evolved a lot of new language features in recent years. For many types of software, the way the code looks will also be heavily influenced by which libraries and frameworks are used in that project's stack.
It's the same story for web development. We have different flavours of JavaScript (ES5 in most browsers today, but ES6 just around the corner and supporting a wider range of programming styles), Python (2 vs 3), and so on. And with these more dynamic languages, the style is often even more guided by a framework if you're using one.
Even if you're not using pervasive third party frameworks or libraries, any project of non-trivial size is going to adopt its own conventions and build its own abstractions to suit its particular needs, and then the rest of its code will again become its own dialect written in terms of those conventions and abstractions.
In fact, I can't think of any mainstream language except for C that doesn't suffer from the "dialect" problem to some extent. And that's because C is a 20th century language in a 21st century world, so lacking in expressive power that it can't support any of these modern, high-productivity development styles and abstraction tools. Its ubiquity, portability and simplicity are assets, but they are effectively its only redeeming features in 2015, and as time goes by it will be necessary for fewer and fewer projects to choose C for those reasons.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." -- Bjarne Stroustrup
"If you attack a tool based primarily on not liking the people who use it, you're still just a bigot, no matter how famous you are." -- Anonymous Slashdot poster
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I can't think of any mainstream language except for C that doesn't suffer from the "dialect" problem to some extent
What about GObject?
As you say, C is a very bare-bones language, so it's not uncommon to see the object-oriented wheel reinvented as a C library, incompatible with the other such reinventions.
Casting is telling the compiler to do what you want. It's like saying "Shut up! I know what I'm doing, this thing is a XY pointer, even if you can't figure it out yourself."
In every language (which supports casting) you can make an error while casting by claiming something that isn't correct. Surprise!
Compared to C, sure. C was conceived in a spirit of pragmatic minimalism that's easy to love. I remember learning C from the K&R book back around 1980. That book was so thin it was practically a pamphlet next to books that taught you other languages. Everything about C was so neat, and trim, and cogent -- even the book everyone learned it from. That plus The Unix Programming Environment and perhaps Software Tools and you were cooking with gas.
It's natural to compare C++ to C; the very name encourages you to do so. It was to conceived to dovetail and build upon C. But it was conceived with an almost diametrically opposite kind of philosophy. C chucked out all the precious features that designers were putting into languages in the late 60s and early 70s and went with a tiny set of proven useful features. C++ implemented every bell and whistle anyone had ever dreamed up for object oriented programming, which was largely an academic topic that was full of clever but impractical notions. Well, it turned out that a lot of those things like operator overloading and multiple inheritance weren't all that useful in the judgment of later language designers, but you can hardly blame Bjarne Stroustrup from knowing that in advance.
It's practically impossible to overstate the practical success of C++. It took what was for most practicioners a theoretical idea (object oriented programming) and made it the way everyone programs by default. But you can't expect someone who loves C to love C++, which has almost none of the virtues that people admire in C.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
So basically, you don't understand C, so its bad? Is that what you're saying? I'm asking because none of your examples are even mildly difficult concepts.
You seem to have difficulty accepting the syntax for function pointers for one obvious one.
You also don't seem to understand that a pointer and a reference are the same thing, and the array thing your referring to, is also your misunderstanding, its also passing a pointer ... because you don't pass an array ON THE STACK, you pass a reference/pointer to the array.
Your comment about argument mismatches being a problem is easy to solve, don't use a retarded compiler, done. Now the compiler doesn't let you fuck it up. If you make a Java, C++, pascal, or .NET compiler retarded and let it ignore obviously bad code, it'll fuck up too.
Everything in your post is just shear ignorance of the language and its syntax. You didn't even post anything about the actual difficult parts of C. You just made yourself look ... simple and uneducated, not C look bad.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager