I like this one: "By definition, a program is an entity that is run by the computer. It talks directly to the CPU and the OS. Code that does not talk directly to the CPU and the OS, but is instead run by some other program that does talk directly to the CPU and the OS, is not a program; it's a script." Here's the other eleven.

Problem with C++ is that it's so wide that finding a group of people that think the same way about C++ is virtually impossible.

I fail to see why this is a problem. The multi-style nature of C++ is better than trying to cram every problem into an OO or functional or message passing style.

Conversely, I think you highlighted the best thing about C++ and is certainly one of the design goals Stroustrup had in mind. It allows the programmers to choose the style that fits a problem best.

I would hope that a person using C++ to write a webserver would have a completely different idea of how to use it to a person who uses C++ to write a game, or a realtime controller, or a stock exchange, or a highly parallel physics simulator, or a compiler.

That way you have clear definitions of what features to expect. If you have two devs who say "I know X", it means you can be reasonably sure that they can check each other's work.

Additionally, say we have a section of code that should be pure (functional.) We can do that in C++, but there's no guarantee that someone won't come by and make it impure. If we instead require a pure language, then this issue never comes up. The restrictions of each language give you guarantees about the characteristics of the code, making it easier to reason about.

If you have every feature available all the time, then the code quickly and easily becomes more complicated than it has any right to be. You have to manually restrain yourself with C++; you simply don't have to do that with simpler languages.

Now, I'll admit that cross-talk between languages is currently kind of a pain. Most languages really only interface well with C... and even then not necessarily well. So maybe it makes sense to use C++, for now, but that doesn't mean that C++ isn't an issue.

I fail to see why this is a problem. The multi-style nature of C++ is better than trying to cram every problem into an OO or functional or message passing style.

I think I already expressed this from a perspective of a person that has to hire developers to develop and maintain a codebase.
When you are a lone star programmer - C++ is great.
When you have to work with a large group of people - then it becomes a problem.

And no, there are not two ways of doing things in C++, there are thousands. In short - too many to be good for assembling and maintaining a team.

"I fail to see why this is a problem. The multi-style nature of C++ is better than trying to cram every problem into an OO or functional or message passing style.

I think I already expressed this from a perspective of a person that has to hire developers to develop and maintain a codebase.
When you are a lone star programmer - C++ is great.
When you have to work with a large group of people - then it becomes a problem. "

And that's the fault of the language is it?

And no, there are not two ways of doing things in C++, there are thousands. In short - too many to be good for assembling and maintaining a team.

As another person pointed out, there is a large overlap between C++ and C. So in practice, most people actually do have similar ideas about C++.

You're confusing design with code. Programmers will always have different ideas about what DESIGN to use, whatever language it's implemented in.

Compared to languages like Python and Lisp and Java, C++ is no worse off in the different language facilities that people think of using.