[gte910h]

Have you tried to staff a C++ project? If you don't have the ability to easily fire people, it's a horrible pain.

There are tons of people who think they know C++. There are a smaller subset that do.

If you get people who A> Refuse to follow the subset of the language your group is using on the project or B> deeply misunderstand one or two features, you're in total utter hell if you can't fire the person.

Most places don't have an easy enough ability to fire people to do C++ in my opinion, therefore C++ is not suitable for them.

[yesimahuman]

I think that indicates poor interviewing more than anything.

[gte910h]

People coding in a different subset of C++ is predictable from an interview? Howso? Not that they know it, but that they prefer it and do it to the contrary of people asking them not to.

Most other languages it doesn't matter anywhere near as much, as idiosyncrasies can be cordoned off well, but with C++, anyone doing anything strange or incompatible anywhere is a problem for most everyone. That same power and control is a curse when people are controlling things two different ways.

In a bigco which takes 6 months to fire someone, this is killer to a project. One guy can destroy a project in that timespan.

C++ has it's place, and that place is "where we can afford pretty high salaries and fire those people who don't work out quickly".

[yesimahuman]

I think that's a bit dramatic. If a coder can't assimilate into your code base and follow the patterns already in use, they would fail regardless of the language.

[gte910h]

It's more of a forefront issue with C++. Also, there are tons of ways to write C++, there are very few (relatively speaking) for Java, C, Python, Ruby or Objective-C.

If someone tends to use a different style of dot notation in Obj-C, no biggy, at worse you get a leak or two that an automated tool can find 75% of the time

If someone uses a different type of pointer/reference on a serious chunk of the codebase or a different style of template based inheritance, you're up shit creek really fast.

The language itself has tons of choices all over. The issue is getting everyone on the same page without crushing creative, high spirited people or having to fire otherwise excellent engineers.

I'm not saying the language is useless, I'm saying it is a huge ass staffing pain to get the right mix of engineers who are brilliant and willing to slavishly do what they're told which is hard to find.

[gaius]

Well, that's true of many languages, Perl for example has gotten a bad rep because everyone on the project asserts their right to "there's more than one way to do it". S'what code reviews are for.

[jpr]

The "C++ is only usable in a subset" meme must die.

[gte910h]

If you have to keep engineers around who can handle it, it is.

Writing boost heavy code vs STL code vs object oriented code vs prototype based code vs highly functionally styled code vs custom allocated code vs reference passed code vs smart pointer code, interface based code vs heavily multiple inheritance based code vs flat hierarchy mixin template based polymorphism etc.

It gets expensive to keep people who do all of that around with the level of correctness you need to not have weird bugs that take forever to find. It usually means "You have few domain experts" on the team as well (for if the project is say, for financial software, or RF controllers, or modems, etc).

[MrKurtHaeusler]

You mostly need engineers who think converting between 15 different types of strings is a useful use of developer time.

[jpr]

So your argument essentially boils down to "there should be some coding style in a project", which is true for all languages, not just C++.

[gte910h]

>which is true for all languages, not just C++

No it's not. Lots of languages have broad based understanding of good and bad based on some body, consensus, etc, that does not have mutually incompatible schools of thought that combust wildly when stuck in the same project.

I've never seen a ruby project with a code style guide.

While I've seen python ones (the language closest to C++ in getting randomly hairy different types), the mixups tend to be relatively benign comparatively speaking. Most python projects go with "Look PEP8ish/pythonic".

Objective-C is heavily driven by WWDC presentations and strong recommendations by Apple, so people tend to move to that.

C is all over the map as well, but again, individual complexity of each decision is much lower. You'll have a style guide at a C dev company. "Use lint with these flags and indent with this specifications" is what the best ones have for a majority of their work.

Perl tends to not care, same for php, whereas I think they really should care more.

C#? I've seen style guides, but they're only on about 10-30% projects.

Java: they're usually there.

>"there should be some coding style in a project",

This all comes out to: making all these decisions in a consistant style is MANDATORY for a C++ project. For most others, there are conventions which don't blow things up that make people work generally to a similar enough style. While there may be some codified choices, with C++ in particular, you have TONS of choices, choices that your staff will not all have the same opinions on, choices you'll have to get them onboard with using, onboard with understanding, and thinking in terms of those mechanisms.

That's relatively hard to do. There's so much ramming shit down people's throats in C++ projects that I think it's only worth it in a small small number of cases.

[huhtenberg]

That's not a meme, that's life.