[nemaar]

>It's been a great strategy for 30 years and I hope they keep at it.

I wouldn't say that it's been great. The evolution of C++ is insanely slow.

[eej71]

Perhaps. It's like that old joke about perspective. The length of a minute depends on which side of the bathroom door you're on. :-)

From my standpoint, I'm _still_ trying to get my head around all the ramifications of what has arrived in C++-11 (and it's a lot!). And I still have '14 and '17 to plow through too. '20 will be here before I know it. So for me, there is so much to absorb.

To my eyes the C++ leadership has done a great job at setting up standards processes for regularly delivering new versions and the compiler community has done an amazing job at keeping up too.

I expect to see more movement in the world of standard libraries which is where C++ still feels like a desert compared to other languages.

But yes it definitely is not fast when compared to other newer language communities.

[dom0]

> The evolution of C++ is insanely slow.

The only language today with more independent implementations than C++ is C. Compared to C, C++ evolution is not slow — processes involving so many implementers are inherently not in fast-forward mode.

Most major languages only have a handful of active implementations, if it's not just one implementation. Most don't have specs.

[ThatGeoGuy]

I would argue that you're eschewing Lisp and Scheme in terms of independent, active implementations, however in a more general sense I agree.

Moving fast (and breaking things) is just not what the standardization committee does, and that's fine. They can move faster since C++11/14, but sometimes you really don't want a giant moving target with new features all the time. I think their approach works for the kind of environment you find C++ used in.