[blep_]

> why all these groups of people decided to start from scratch than to put up with the C++ committee

In which the C++ committee continues to not acknowledge that its problem is being a committee, in the most ridiculously bureaucratic sense of that word.

If the only way to get my contributions accepted into a project involves writing a paper about it, sure, I can do that. If it involves writing a paper about it, and then having endless meetings about it that could have been emails, some of which I have to physically travel to, I can't be bothered. I've left actual paying jobs over that, I'm not doing it for free.

And sure, I'm an individual, and most of the people they're talking about here are representatives of companies. But the effort-to-results ratios still exist, and C++ has managed to tip them to the point that making an entire new language is less effort than proposing a C++ change.

[WalterBright]

The D programming language came out of my inability to influence C++. Amusingly, D has had a lot more influence on C++'s direction than I was able to do directly.

[bluGill]

It is and must be more difficult to make changes than start something new. When one person alone starts something new it is easy to make choices to a vision. When something is popular you cannot easily make changes that all will agree on.

C++ has painful experience on what happens when you don't carefully consider all proposed changes and so miss something. Export is an obvious example, but there are others that seemed good until painful experience later showed why not. Templates would look very different if they knew then what people would do with them.

[jcranmer]

> If the only way to get my contributions accepted into a project involves writing a paper about it, sure, I can do that. If it involves writing a paper about it, and then having endless meetings about it that could have been emails, some of which I have to physically travel to, I can't be bothered. I've left actual paying jobs over that, I'm not doing it for free.

If most people wrote papers that were so perfect in their construction that no one would ever need to ask questions about their content, as every relevant question would be answered by reading the paper, then there wouldn't need to be a need to shepherd it through meetings. But in my limited experience, most papers aren't like that. In the numerics study group, we had one paper at the most recent meeting that was so vague, we eventually decided we had no idea what the paper was actually proposing, so answering the question "would we like to move forward with this idea" was impossible. And with the author not being present... well, that's more or less the end of the road for that idea.

[blep_]

So send an email, and ignore it until you get a response. You don't need to fly to Kona for this.

[dxuh]

Not just the paper has to be perfect, but all the reviewers too. Sadly people don't just ask reasonable and already unanswered questions.

[pornel]

These replacements don't care about the committee per se, but rather reject committee's core goal of preserving backwards compatibility over everything else.

Making it easier to add more features to C++ can't fix the problem of being unable to simplify the language by removing unsafe and legacy features.

If they wanted C++, but only hated the committee process, they'd have forked the language and worked on compiler extensions (like WHATWG bypassed W3C process). But instead they all went for clean slate with some level of interoperability.

[kllrnohj]

That quote you cherry picked is literally in a section talking about how hard it is to get into the committee and how slow the committee is.

So no, they are not failing to acknowledge that. It's literally the point of the quote you're responding to.

[blep_]

I just went back and reread the section to see if I'd missed something, and... kind of, I guess? They acknowledge that it is hard to join, but they don't seem to fully get why - that the problem is their system of scheduling meetings instead of discussing things asynchronously, not the ISO in itself. Without that realization, I would be surprised if a post-ISO C++ committee didn't just keep doing the same thing as before, because face to face meetings are the only way to be productive, right?

The "look at this pretty place I got to go to" picture immediately after that section does nothing to help this impression.