Linus Torvalds and his smackdown speech

can see how C++ promotes crappy programming

Are you suggesting that C++ does this more-so than other main-stream languages such as C? One of the assumptions C++ makes is that the programmer knows what they are doing, and if that isn't true there are a lot of potential mistakes -- but a bad programmer will write bad code in any language, and while some newer languages make efforts (garage collection being a prominent example) to protect the coder from dangerous mistakes, I don't really think C is any safer than C++ in the hands of the poorly educated or inexperienced.

C absolutely still has it's place, and can sometimes be a better choice, but the same is equally true of C++; and I'd be willing to bet that although he might not say so publicly Linus would agree with that. His straightforward and honest opinions -- ranting and all -- certainly serve a purpose of getting attention and very succinctly communicating his message.

If you cut through the hyperbole he certainly does present some valid points, though the article you've linked to seems to have chosen specific quotes -- and highlighted particular sections -- based on the entertainment value of said hyperbole rather than any validity of the stated opinions.

Linus argues in such an immature way that I can't believe anyone even pays attention to him. If he didn't happen to write a good kernel and great version control system, he'd just be another irrelevant angry online interweb rage-kid. Seriously, is it possible to to read through the OP's link and come to the conclusion that "this is a well reasoned, rational human being that I can respect on an interpersonal level?". I'm pretty sure that if he was a member of this forum, he'd tell me to go fuck myself for simply pointing that out, then launch into some ad hominem for my like of (atypical) C++...

His arguments for C and against C++ can be transferred to any language. You could replace "C" with asm and "C++" with C, and it still works -- C is too full of noobs writing shit code so we've got to stick with assembly. It also works up the chain -- Java is too full of noobs writing shit code, so we've got to stick with C++.

It's simply not a valid argument against the language -- in actuality, he's attacking the culture behind the language (which many language supporters do) and the fact that "the internet is full of bad programmers"... He's trying to use a simpler language to keep out bad programmers who abuse C++'s additional tools. This works for his open-source kernel and he's free to run that project however he wants. In the real world though, we usually just interview candidates to make sure they know what they're doing, and pay supervisors to stop people being noobs.

I'm not good at C++. In fact, I'd go so far as to say that I don't even know C++. That said, from what I have used of it, I always get the impression that, in contrast to C, it's a "real" language, in the sense that the language itself has a lot of abstract concepts built into it. C is great principally because it's small, and because there's typically a pretty straightforward correspondence between a C program and the assembly that it turns into. The language itself makes it a great deal easier to generate a good assembly program, but when I use it I always feel like, if I had to, I could figure out what assembly my C code is going to turn into and then I wouldn't need C at all.

C++, on the other hand, seems to have so enough substance built into the language that to use it properly you have to actually learn something. That's why it doesn't really surprise me that people who do low-level (systems) work often don't like C++; they'd rather have a deep grasp of what their programs are doing on a low level, even if that means a bit more work when implementing something more abstract. C++, by giving you a variety of different ways of representing an abstract concept, all of which (logically at least) are reducible to the same thing, seems sort of like a waste of time in this case.

I think that's where the idea that C++ gives you "more ways to mess up" comes from, but I think it's sort of an illusion, too. It's not that there are more ways to do C++ wrong, it's just that there are more creative ways to do C++ wrong. Because the language itself has more features, there are a lot of different ways of representing the same mistake, and this also makes it harder to identify such a mistake.

I'm pretty good at C, or at least I have been once or twice, so if I read a C program and I can't immediately figure out what it does, that's probably because I just can't process the whole thing at one time. In theory, though, with enough work, I'd be able to figure it out, because no single part of it is foreign; there just isn't that much to the language. If I can't figure out a C++ program, though, it's probably because I don't know the language well enough. Most of the reason for this is that I don't know the language well enough, and that's obviously not a good reason to hate it. And because the language itself has more to it, it's not really surprising that it takes more work to learn to use it well. It's also not surprising that people who aren't that good at it can make programs that are both broken and obscure, whereas, if they used C instead, the program would probably still be broken, but it least it wouldn't be as obscure.

Oddly enough, I was just reading a response to his famous C vs. C++ rant no more than two browser-tabs ago.

While I was reading I think I've come up with a pair of analogies that illustrate what Linus was trying to express in his usual, ham-fisted way:

Badly-written C++ tends to paint you into a corner; Badly-written C++ tend to paint outside the lines.


In other words, less-experienced C++ programmers tend to come down with a serious case of object-orientitus -- where they strive to force everything into class hierarchies and carpet-bomb the project with design patterns. This is exacerbated by the fact that most less-experienced C++ programmers tend to only have an idea of what "OOP" is supposed to be, rather than *why* it's supposed to be, so they often lack the perspective to challenge the C++ 101 way of thinking of things. Thus, they often arrive at an over-engineered solution that is paralyzed in the face of change.

Less-experienced C programmers, on the other hand, tend to not do a great deal of formal "design" at all. Thus, C is often seen as a more "fluid" language. However, it's so fluid to change because poorly-written C programs often have little high-level design to speak of, hence, no high-level design to maintain, hence an easier time to refactor. There's no reason to start coloring inside the lines after they've been so wantonly violated to begin with.

Now, the above is not a problem or virtue with either language, but problems with *programmers* -- inexperienced programmers who don't yet know better.

One reason I posted this was to see what more experienced coders think... I can't say for sure as I am not a full time coder, but when I read stuff like this and I read Carmack say stick with C or less OOP, I just have to consider these people's opinions some what as they do it for a living and know a hell of a lot more than I do....

Remember also that what is good for a massive software project by a very experienced programmer is not necessarily -- or often not even remotely -- also good for a small-to-medium sized software project by a less experienced programmer, and that subjective criteria such as personal preference, prior experience and existing code bases can play a huge part in making an intelligent choice of tools or languages.

It can be interesting to hear the opinions of these sort of people and there are often some valuable points that are worthy of consideration, but it is rare for their experiences to be directly applicable to your situation. If you happen to find yourself in the exact same (or a very similar) position to John Carmack or Linus Torvalds then by all means give their opinions a weighty consideration -- if (as is far more likely) not, consider their opinion, but be sure to note differences between the situations and form your own opinion accordingly.

when I read stuff like this and I read Carmack say stick with C or less OOP, I just have to consider these people's opinions

N.B. Carmack put off learning C++ for a long time and stuck with C, but his position in 2012 is:[quote name='John Carmack']I had C and Objective-C background, and I sort of "slid into C++" by just looking at the code that the C++ guys were writing. In hindsight, I wish I had budgeted the time to thoroughly research and explore the language before just starting to use it.
Today, I do firmly believe that C++ is the right language for large, multi-developer projects with critical performance requirements, and Tech 5 is a lot better off for the Doom 3 experience [of transitioning to C++][/quote]But yes, he also writes advice on how to use non-OOP styles in C++, such as this: http://www.altdevblo...ogramming-in-c/

C++ is a "pay for what you use" language. This means you can write slow, bloated code, or lean and mean speedy code. Linus' argument is that he can't trust his contributors to not overuse the heavyweight features, and to over-abstract things. Carmack was simply happy with C's features, and hadn't yet been swayed by the productivity gains that C++ had to offer him, but has since come around. Mike Acton rants about typical C++ code, but doesn't overreact by shunning the language; he just educates his staff on how not to fall into the typical pitfalls.

If you think that C will automatically give you better performance, then here's a helpful exercise -- when writing any C++ code, imagine in your head what the equivalent C code would be, and then reflect on whether your code is the best solution. e.g. this codestruct A { virtual void DoStuff() = 0; int a; };
struct B : public A { void DoStuff() { b = a; } int b; };
B obj;
obj.DoStuff();...would be equivalent in C to:struct A_VTable { void (*DoStuff)(A* self); };
struct A { A_VTable* vtable; int a; };
void A_DoStuff( A* obj ) { (*obj->vtable->DoStuff)(obj); }
struct B { A base; int b; };
void B_DoStuff( A* base ) { B* obj = (B*)base; obj->b = obj->base.a; }
A_VTable g_B_VTable = { &B_DoStuff };
void B_Construct( B* obj ) { obj->vtable = &g_B_VTable; }
B obj;
B_Construct( &obj );
A_DoStuff( (A*)&obj );A good C++ programmer should always be aware of what the equivalent C code is (or better -- what the equivalent asm code is). As you can see, the C++ code has made it extremely easy to generate a LOT of (equivalent) C code -- this is what Linus is afraid of. An inexperienced coder will default to using solutions that look fine in C++, but look crazy when actually written out manually in C. His thought is that if he forces people to type this code out manually, then they'll think twice about it (assuming you've written in C before, have you ever written anything like the above C code? I bet not, even though it's so tempting to do so from C++). He thinks that being able to easily write this code in C++, means that all his contributors will automatically default to bloated, under-thought, over-engineered solutions... and he might be right. However, when working at a company, like Carmack's, you have the luxury of hiring and educating your staff very selectively, instead of having to rely on unpaid open-source contributors.


Regarding OO, there's two issues that I think are important --
1) Most people don't really understand OOD. They understand the OOP tools: classes/objects, inheritance, composition, etc, and can use these tools.... but don't actually understand the rules behind them. Any framework that makes excessive use of inheritance and polymorphism probably has OO-itis. IMHO, inheritance should actually be very rare in good OO code.
So when complaining about OO code, a lot of the time, people are actually complaining about code that has been written using OOP tools, but which has not followed OOD design rules.
2) Yes, it is fair to say that typical OO doesn't fit with highest performance code. The big failing of (and also the core idea of) OO is that it's a good idea to bind together data-layouts and data-transformations together into a single entity: the class. This was fine in the 70's when it was invented, but since then, CPU performance has doubled yearly, while memory performance only goes up 10% per year. This means that in 2012, the biggest bottleneck is memory access speeds, which makes data-layouts very important when optimising code. The fact of the matter is that different transformations are better suited to different layouts, so binding every transform to a single layout is a very bad idea. You're forced into trying to find the "one true layout", which usually doesn't exist.

Because of this, you'll find that a lot of the 'rock star' engine programmers are now championing what they call DOD - data oriented design, instead of OOD - object oriented design.

Bad programmers will be bad programmers.

One thing I am trying to adopt now is: "If it works and is reliable, it is ok!"
Don't try to make the most beautiful, optmized and perfect code. Just solve your problem in a way that you can code it in a short period of time and that it will not break or have breaches.

About Linus... He is one of the old programming religions' priest. He will have followers and you have to respect his achievements (for example the Linux kernel).
Aside this fact, I recommend an agnostic and nommad programming life that adapts your skills to the hottest platforms and technologies.
Do not stick to one single paradigm for the rest of your life... that is sad

All OSS guys fight and bicker like this. You can see the end result of it by booting into Linux.

The C++/C is almost ten years old now, and it's been argued to death. They don't like it because a lot of this type of crowd likes to live like it's still the 1980s, and they hate anything that has come afterwards. It's all pure C, and text mode interfaces, compiling programs with gibberish names to be run on shell terminals.

Honestly I do not give a shit what Linus or Carmack or Tim Sweeney thinks about any language.

Why? Because I'm not in the same league as them and more importantly, I don't need to be. For 99% of programmers productivity > performance. If you are writing the core of unreal 4 or idTech 6, the code had better be damn fast. For the rest of us, it's more important that it works, it's easy to read and we didn't spend 6 months on 2 weeks work.

On 8/13/2012 at 4:18 PM, ChaosEngine said:

For 99% of programmers productivity > performance.

And for the other 1% productivity is still more important 99% of the time.

But of course C vs. C++ is not really about productivity or performance. C++ noobs can be just as unproductive as anyone else. The issue is almost always relative proficiency and expertise with the languages/tools in question throughout your (potential) development staff.

Any engineer (or small group) can get their head buried in their particular product for long enough periods of time to not gain or maintain expertise with the latest languages or language evolutions they haven't been using. And that will inevitably affect the best choices for them at any given point in time.

And when languages/tools are new to an industry, it's a lot less practical to try to hire expertise, and there can be significant costs in terms of growing pains and mistakes in trying to transition.

In certain situations growing pains lead to the codification of programing idioms and paradigms, and ultimately language evolution. In other situations it leads to backing away from the new language/tool for as long as possible - "'Till they get their crap worked out".

Every one of those high profile programmers who at some point had misgivings about C++ probably had to struggle through that language transition and deal with engineering groups doing the same. And, in fact C++ really did have some crap to work out, above and beyond lack of proficiency or expertise in the programming populace. But it has, in fact, worked most of it out. And as for those (unnamed) dark corners that don't want to go away, C++ is still "pay as you go". You can, for the most part, choose not to go there, for free.

[quote name=John Carmack]
I had C and Objective-C background, and I sort of "slid into C++" by just looking at the code that the C++ guys were writing. In hindsight, I wish I had budgeted the time to thoroughly research and explore the language before just starting to use it.
Today, I do firmly believe that C++ is the right language for large, multi-developer projects with critical performance requirements, and Tech 5 is a lot better off for the Doom 3 experience [of transitioning to C++]

[/quote]
I find it interesting that Carmack has Objective-C experience and still thought that C++ was the better solution. Aren't they pretty much the same?

[quote name='Hodgman' timestamp='1344857019' post='4969013']
[quote name=John Carmack]
I had C and Objective-C background, and I sort of "slid into C++" by just looking at the code that the C++ guys were writing. In hindsight, I wish I had budgeted the time to thoroughly research and explore the language before just starting to use it.
Today, I do firmly believe that C++ is the right language for large, multi-developer projects with critical performance requirements, and Tech 5 is a lot better off for the Doom 3 experience [of transitioning to C++]

[/quote]
I find it interesting that Carmack has Objective-C experience and still thought that C++ was the better solution. Aren't they pretty much the same?
[/quote]

No, not really. C++ is a multi-paradigm language which happens to support generic programming and Simula-style OOP. Objective-C is a strict superset of C with some dynamic programming features and OOP syntax inspired by Smalltalk. You can certainly write equivalent OO code in both languages, but then again, you can do the same with various other languages pairs - C/C++, Java/C#, Python/Lua, etc. That doesn't mean that the two languages are identical in idiom, however; look at how different C# and Java code can be, and they're so similar that with some contortions you can get a C# compiler to compile Java - that's not really possible with Objective-C and C++ unless you stick to the language both are based upon - C.

I find it interesting that Carmack has Objective-C experience and still thought that C++ was the better solution. Aren't they pretty much the same?

Not at all. ObjC basically just adds 'Messages' as a native concept to C, which are basically duck-typed interfaces, instead of static-typed interfaces. Messages are called by performing a runtime string lookup to fetch the function pointer (as opposed to a vtable lookup in c++) - the c++ equivalent would be something like std::map. C++ also added a lot of other features to C besides OOP helpers.

Also, I'm sure the choice of language has a lot to do with the compilers/debuggers/IDEs available for the target platforms...

All OSS guys fight and bicker like this. You can see the end result of it by booting into Linux.

Mmmmm, infighting definitely seems to be far more prevalent in those communities for sure. Without wanting to derail too much, my personal theory is that this comes more from Unix culture than from OSS culture, however. Might be an interesting topic for a separate discussion?

Linus does not come across as a pleasant person much of the time. It's certainly true that C++ is a great tool for those who like to waste time by writing endless boilerplate, but to slam the entire language in that way with apparently no rational analysis whatsoever? Great if you want to be a populist cheerleader, not so great if you care much about your reputation and credibility.

[quote name='Daaark' timestamp='1344898254' post='4969229']
All OSS guys fight and bicker like this. You can see the end result of it by booting into Linux.

Mmmmm, infighting definitely seems to be far more prevalent in those communities for sure. Without wanting to derail too much, my personal theory is that this comes more from Unix culture than from OSS culture, however. Might be an interesting topic for a separate discussion?[/quote]Not much to say, because there isn't much room for debate on the topic.

Linus does not come across as a pleasant person much of the time. It's certainly true that C++ is a great tool for those who like to waste time by writing endless boilerplate, but to slam the entire language in that way with apparently no rational analysis whatsoever? Great if you want to be a populist cheerleader, not so great if you care much about your reputation and credibility.[/quote]He seems like a good guy on G+.
When you're in his position and you have tons of questions, suggestions, and debates coming your way, you have to put your foot down and end them. Especially with the idiots who argue just to argue. Sometimes that means strong language. And a lot of times, the internet filter makes everything come out negative.

I gotta be honest and I am not sure why but when I read his C++ a while back I strangely (with no good reason) began not only to hate C++ but also rage childishly like him too, I never did find out why, I guess I needed an excuse to hate on C++. Anyway looking at all his other rants, I find them somewhat amusing and entertaining but no different than from a troll who is angry at the world.

The worst part about his rantings are they're a lot like all the crap you see everywhere anyway, I think theres only a few decent forums that dont attract or allow crap like that, for the rest of the internet however, well lets just put it this way, people like Linus only attract people like Linus even unintentionally.

Language wars have existed since the internet was conceived (and, probably before that too, just over telephone or in the uni's corridor).
The only surprising thing about this is how many people actually care when Your God Torvalds, may you all bow before him, says that "everything ABC is shit" and "all XYZ are idiots". It's not like this guy has written anything that's decisive for what Linux is today. Without Peter Anvin, Linux would never have as much as booted, without a thousand GNU people it would not have as much as a shell or a compiler or a file system, and without people like Ingo Molnar (he definitively gave the biggest bangs, but there's at least half a dozen others with many important contributions) it would not be nearly competitive in any way.
My first Linux install was Slackware 1.1.1, which was much closer to "made by Linus Torvalds" than what you get today when you install e.g. SuSE or Debian (*shudders* at the thought of manually unpacking several dozen .tar files from floppy and editing /etc/fstab and /etc/passwd...). Oh boy, it really sucked. It was just lucky for Linux that Windows 3.1 sucked even more when you wanted to run a webserver, and Windows 95 (at the time of Slackware 3.0) and Windows 98 weren't truly an improvement for that kind of thing (though Win98SE totally anihilated Linux in every other respect).

So really, I don't get it why so many people deem Linus Torvalds a religious leader when really most of what's good in Linux nowadays was written by other people.

That said -- back on track with the language war -- there are lots of rubbish C++ programmers. OK. Who cares. There are a lot of rubbish programmers. One might reply that the entire suite of autoconf-based programs is a single monolithic proof-of-concept of rubbish C programmers.

For example, trying to build GMP [size=1](which ironically has a C++ binding too) yesterday gave me an error because [font=courier new,courier,monospace]configure [/font]failed to determine the size of [font=courier new,courier,monospace]mp_limb_t[/font] (which is a typedef for [font=courier new,courier,monospace]int[/font]). Now tell me why any sane person would want to run an extra "platform configuration" program for that kind of thing (which is the sole reason for the failure!) when the language readily supplies a [font=courier new,courier,monospace]sizeof [/font]operator.

Anyway, whether or not one likes what some particular person has written in some particular language, this hardly gives a leverage to judge on the language itself. If you're honest, you have to admit that most "rubbish C++ programmers" are in fact C programmers (and likely not even good C programmers).