The bigger the team the more restrictions you want in a language.

C++ is lovely when you are working alone, but as the team grows people start having very conflicting opinions on what parts of the language should be used. The only way to handle this is to restrict everyone to a subset of C++ and forbid everything else, otherwise it will be impossible to navigate the codebase.

Innocent looking things like try/catch becomes a nightmare when not everyone has taken that into consideration when they clean up resources. Either you have to enforce proper cleanup around every function call or you have to forbid everyone from throwing exceptions, there is no middle ground here.

Does anyone know everything about Python 3.5, language and libraries, including evolution issues when having to handle old code?

What about style guides to forbid people to use generators, metaclasses or other advanced features?

Just to pick a language most people think it is easier than C++.

Are generators really an advanced feature? I've used them pretty often (instead of returning a list) and they're pretty simple.

For many types of programmers that would be happy with something like C or Go, most likely yes, given that they already allow for some interesting patterns. Also because they changed a bit, in the early days you could not pass arguments back to them.

However, when I wrote generators I was actually thinking about comprehensions.

I think comprehensions are less advanced (they're a specialized case of iterators) and very commonly used.

> Also because they changed a bit, in the early days you could not pass arguments back to them.

Sending arguments is certainly advanced.

I agree that the problematic of big teams of heterogeneous skills is not the same as the small teams of skilled people (some fields simply won't tolerate anything else), but the rest of your message stills sounds the same to me -- somehow the __language__ needs to be "restricted" because some (few?) __people__ on the team abused it?

There is nothing specifically wrong with C++ en toto. What's happened is that historically, it was perceived as a leverage tool to make larger, more ambitious projects attainable. What I saw of that was that the failure rate went up.

So my memory is that C++ is mildly "worse is better" than was C.

I think the failure rate went up because:

   - more people got drawn into programming. Some of them 
     got dumped there; many people with whom I worked were 
     actually, say aeronautical engineers who were told 
     that they had to pivot to software to keep their job. 

   - people think of the radius of software when thinking
     of size, when the real measure is the surface area 
     of a sphere implied by that radius.

   - Us old guys got to learn C on smaller projects which 
     were actually deployed, so we had the benefit of 
     going through the full cycle, playing all the roles.

   - You can easily run into ctors/dtors problems when
     decomposing C++ projects into modules. 

   - Preventing integration problems between modules just
     requires a lot of good interpersonal communications 
     and sometimes, C++ gets in the way. 

   and most insidious of all

   - New language systems are devilishly hard to embrace in
     environments which are intended to be competitive. 

One thing I've learned is - expressive power is 100% about what the expectations of the reader are. I find differential equations more expressive than English for those things where they are appropriate, but that's because I trod a different path. With C++, the expressive power is because the reader unpacks more information per symbol-suite. Just realize that that is not the same for everyone.

> With C++, the expressive power is because the reader unpacks more information per symbol-suite. Just realize that that is not the same for everyone.

Then reducing the expressive power of a language will only make this worse, not better. To make code to speak to a random reader, one needs to carefully select idioms (from the professional domain, not the language's ones) he/she wants to implements, and if new/unfamiliar ones need to be introduced, make sure they are clean and easy to grasp. Removing features from the language makes this harder.

Funnily enough, people frequently illustrate their point with exceptions, whereas in my league of a single feature contributing the most to code readability, exceptions compete for #1 position! They are easy to grasp __conceptually__ for a C programmer, and when properly used, make code much easier to read. They also create a feeling of confidence when dealing with code (as they cannot be missed, contrary to error signalling via return values). Etc.

Agreed. I've always shaken my head at people who essentially say "______ is terrible because it makes it easy to shoot yourself in the foot."

The proper answer is to not shoot yourself in the foot.

Most of my programming is done in Python, where people cry about the inability to create private class members. IMO, use the convention of prefixing the name with an underscore, and if a user of your module messes with something marked as private, then it's on them when their program explodes. Don't blame Python for not supporting private members.

> The proper answer is to not shoot yourself in the foot.

That's a bit like shrugging your shoulders when an infant walks off a precipice and saying the proper solution is for the infant not to walk off the precipice. The proper solution is actually either to put up a rail, making the precipice safer, or keep the infant away from the precipice in the first place (or rather, to hold the infant by the hand whilst showing them the safe way to approach the edge so that they can go solo when ready).

Or to stick with the poor analogy, the reason people used to shoot themselves in the foot is because old guns could easily go off in the holster. The answer was the safety catch.

Back on topic, the only reason this is not done with C++ is because people have come to rely on the ability to shoot from the holster (often avoiding their foot) and the back compatibility dictates that the ability must therefore remain. There are plenty of features that would not have been designed that way if C++14 had come into the world fully formed without evolving via its ancestors. It's also one reason people keep inventing new languages - it's an opportunity to learn from past mistakes with a clean slate, not just to bring in concepts that simply don't fit.

I would argue that there is scope for picking a 'major version' of C++ and consciously breaking back-compatibility in some areas. It's controversial, because it would require a lot of work in some existing C++ projects if they wish to benefit from any new language features beyond that point. Just look at the hooha made around Python 3.