upvote
You're arguing semantics. The committee owns the C++ standard and its future. It's not pretentious - not having such a governing body leads to either divergence or stagnation, both of which are usually fatal.
reply
No, ISO owns the standard, and they just shot down the committee's proposed draft.
reply
The committee is part if ISO. Larger ISO shot down smaller ISO. Both are under the same system. WG21 is just the C++ subgroup of ISO.
reply
> not having such a governing body leads to either divergence or stagnation

Or you do the BDFL model like Python, D, Zig, Odin, etc.

I think it works better. A language that reflects the vision of an individual deeply thinking about the interactions of language features, and being able to say "no" to anyone/everyone has many benefits.

Committees make me think of the Web, C++, Swift, etc., and they have a lot of "odd" decisions that have had a heavy cost. Swift has https://www.swift.org/swift-evolution/, but a lot of ideas with minority support were pushed through by Apple (for SwiftUI mainly), against overwhelming community feedback.

And the Web has had a lot of "duds" when you think of WebGPU, WASM (not saying it's bad, but people clearly want to stop writing TS/JS and they haven't made that a reality yet, at least in a way I'd call "successful"), etc.. Oh and DRM in the browser sucks. I forget the details but I was goofing around with FreeBSD Desktop and couldn't get various things to work due to some browser DRM bullshit. https://en.wikipedia.org/wiki/Widevine if curious.

reply
BDFL neither scales nor perseveres. People have multiple things competing for their time and attention. They get old. They probably want to retire eventually. Eventually they die. If you want something to last more than a decade or two, BDFL is a poor choice.
reply
Linus stopped scaling sometime in the late 90s - 00s. That's when lieutenants took over more authority, and a more or less informal line of succession formed. BDFLs can promote their own replacements from trusted collaborators who share the vision.
reply
For that matter, Python gave up on BDFL something like 8 years ago.
reply
> BDFL neither scales nor perseveres. People have multiple things competing for their time and attention. They get old. They probably want to retire eventually. Eventually they die. If you want something to last more than a decade or two, BDFL is a poor choice.

Well I mean you're just wrong, you can look at any of those languages (or https://en.wikipedia.org/wiki/Benevolent_dictator_for_life). Python is over 30 years old and it's going fine. You don't see people ragging on Guido everywhere. But everyone pokes fun at the C++ committee and the wacky shit they cook up.

Design by committee just sucks. Coordinating and working with people is expensive, and a drag. If you have to, you have to, but for many projects you don't and shouldn't. An individual's design is always going to be more cohesive, and we can see it clearly looking at PL history IMO.

reply
> Python is over 30 years old and it's going fine. You don't see people ragging on Guido everywhere.

Guido stepped down from that role 8 years ago. It now has a 5-member steering council along with the core developers as the primary maintainers and decision makers.

reply
Also, Guido stepping down had a lot to do with people starting to rag on him everywhere, which in turn related to him endorsing a language feature (https://peps.python.org/pep-0572/) that he'd previously rejected (https://peps.python.org/pep-3099/).

That said, I'd agree with GP that design by committee does suck and I'm not impressed with several of the decisions the SC has made since.

reply
deleted
reply
It's early days for WebGPU. Safari only enabled it in version 26, so for most of the web it's only a year old. Give it time.
reply
> Or you do the BDFL model like Python, D, Zig, Odin, etc.

Python doesn't have a BDFL[1] and the others are toys.

1: Guido stepped down in 2018 and stopped involvement entirely in 2020 after an extended conflict with the community at large over PEP 572

reply
> Python doesn't have a BDFL

Thanks, I relinquish that point and accept it as a success story for BDFL succession instead.

reply
It’s pretentious to say they own the language. They own their standard. Yet every major compiler implements something else and are all called c++ compilers.
reply
The standard is the language. Again, you're arguing semantics.
reply
The standard is a completely conceptual description of an idealized version of the language.

The implementations are the language.

One learns this when their standards-compliant code fails to compile.

reply
The major compilers are certainly behind the latest standard as far as what they implement and if you're trying to run the latest and greatest you will find things that don't work.

You will find, though, that every major compiler considers those features that don't work either. Don't work because of bugs or they're not implemented yet. But either way, it's something they plan to implement.

Your objection reads like 1995. Of course, the C++ standard didn't exist until 1998, which is my point. Compilers have generally considered it a bug to not have all features implemented - the exception that proves the rule is export, which was removed from C++11 because all compilers agreed they weren't going to implement it.

reply