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.

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.