Titanic is not an example of why building ships has to be avoided. C++ is a great example, yes, of the damage ambitious and egotistical personas can inflict when cooperation is necessary.
It is certainly an example of why SC22 is a bad idea
The "C++ Standards Committee" is Working Group #21 of Sub Committee #22, of the Joint Technical Committee #1 between ISO and the IEC.
It is completely the wrong shape of organization for this work, a large unwieldy bureaucracy created so that sovereign entities could somehow agree things, this works pretty well for ISO 216 (the A-series paper sizes) and while it isn't very productive for something like ISO 26262 (safety) it can't do much harm. For the deeply technical work of a programming language it's hopeless.
The IETF shows a much better way to develop standards for technology.
The fact that the C++ committee is technically a subgroup of a subgroup of a subgroup is among the least of the issues of ISO for standardization.
The main problem is that ISO is a net negative value-add for standardization. At one point, the ISO editor came back and said "you need to change the standard because you used periods instead of commas for the decimal point, a violation of ISO rules." Small wonder there's muttering about taking C and C++ out of ISO.
I would argue that the structural problem is an underlying cause. So it won't be the proximate cause, but when you dig deeper, when you keep asking like a five year old, "But why?" the answer is ultimately ISO's structure and nothing to do with Bjarne's language in particular.
Hence the concern for the non-language but still deeply technical RISC-V standardization.
Titanic is not an example of why building ships has to be avoided. C++ is a great example, yes, of the damage ambitious and egotistical personas can inflict when cooperation is necessary.
It is certainly an example of why SC22 is a bad idea
The "C++ Standards Committee" is Working Group #21 of Sub Committee #22, of the Joint Technical Committee #1 between ISO and the IEC.
It is completely the wrong shape of organization for this work, a large unwieldy bureaucracy created so that sovereign entities could somehow agree things, this works pretty well for ISO 216 (the A-series paper sizes) and while it isn't very productive for something like ISO 26262 (safety) it can't do much harm. For the deeply technical work of a programming language it's hopeless.
The IETF shows a much better way to develop standards for technology.
The fact that the C++ committee is technically a subgroup of a subgroup of a subgroup is among the least of the issues of ISO for standardization.
The main problem is that ISO is a net negative value-add for standardization. At one point, the ISO editor came back and said "you need to change the standard because you used periods instead of commas for the decimal point, a violation of ISO rules." Small wonder there's muttering about taking C and C++ out of ISO.
I would argue that the structural problem is an underlying cause. So it won't be the proximate cause, but when you dig deeper, when you keep asking like a five year old, "But why?" the answer is ultimately ISO's structure and nothing to do with Bjarne's language in particular.
Hence the concern for the non-language but still deeply technical RISC-V standardization.
Say what you will about C++, but it is undoubtedly one of the most successful and influential programming languages in history.
By which metric?
C, Java, Rust, JS, C# do exist
> influential
It's certainly a cautionary tale
If we are taking cheap potshots, there's a standard for standards: https://xkcd.com/927/ or in the proposed XKCD URI form xkcd://927