← Back to context

Comment by BlobberSnobber

13 hours ago

ISO defines standards for much more than bolts and plugs. A few examples include: the C++ ISO standard, IT security standards and workplace safety standards, and that’s a small subset of what they do.

They develop a well defined standard, not the technologies mentioned in the standard. So yes, they’re qualified.

But isn't RISC-V just a standard? ISO will decide what is RISC-V and what isn't. Then its complicated process will become an obstacle to innovation.

C++ "standard" sounds more like an example of why technology should avoid standards

  • 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.

      1 reply →