Note that Circle is not an F/OSS compiler as someone pointed out before. This however doesn't make Circle less relevant, because it is actually a testament to show that C++ could have been much better without the claimed breakage. If Circle does provide a number of desirable features and its compiler can be built by a single person, then why shouldn't the committee do the same?
> If Circle does provide a number of desirable features and its compiler can be built by a single person, then why shouldn't the committee do the same?
Well, there are downsides to taking Circle's approach which I think are worthwhile to mention. Languages are preferable to everyone creating their own custom DSL. They provide a single target that everyone is able to learn, it allows one to work in a much larger body of work without friction.
When I pull down a library or codebase, I want to be able to immediately hit the ground running instead of having to understand every aspect of how the developers have tweaked the language to suit their preferences, and how each of these tweaks interact with each other. You probably shouldn't rely on people making these choices themselves, because you don't want everyone being a language designer -- it invites a combinatorial explosion with conflicting features that don't play nicely with each other. But mostly, it's about maximizing one's ability to pull down and work in foreign codebases without having to learn a new dialect of a language.
This isn't quite a DSL approach though: the features are turned on and off locally, and don't "escape" from that local source. So provided that one knows the features that can be turned on or off they can just read the source code top to bottom without having to trace which feature was accidentally set in a different file.
Also, re:
> You probably shouldn't rely on people making these choices themselves, because you don't want everyone being a language designer
This would be true for any other language, but with C++ one already has to figure out which subset of features to use, which is basically the same type of choice as turning Circle features on or off.
ISO processes are a complex beast, you will notice that C++ is the exception of having the language author still around, all other programming languages under ISO, the authors kind of moved on after the first revision.
Note even Plan 9 and Inferno's C, isn't quite ISO C89, with Dennis Ritchie hardly taking part in meetings afterwards.
> ISO processes are a complex beast, you will notice that C++ is the exception of having the language author still around, all other programming languages under ISO, the authors kind of moved on after the first revision.
I don't see your point. What leads you to believe that Stroudtrup being involved in C++'s standardization effort is any relevant with regards to where the language is going?
Also, if a standardization process is driven by consensus, what would be the point of trying to force your personal ideas over everyone else's?
On the contrary, many people like to blame him for the direction some decisions have been made, while completely lacking the understanding that he only has one vote among about 300 something.
He has been a kind of C++ consciousness with his books and papers, but C++ isn't a language with BDFL.
HP, IBM and Dec made the point the language had to be part of ISO for industrial adoption. As most languages back then.
Maybe had the language evolved as a foundation with BDFL, many of its warts had been sorted out already.
I don't think that's a very helpful understanding of the situation. Bjarne's influence isn't limited to one of 300 votes. Some random guy from Microsoft with voting rights isn't the same in practice. As an example it seemed pretty clear to me from evidence viewed now, that ~15 years ago Bjarne undermined C++ 0x Concepts in favour of his own simpler less capable design, which C++ eventually got in C++ 20.
Circle has this feature, since Bjarne's C++ 20 feature is called concepts, Sean calls this "interfaces" instead, but it's the C++ 0x Concepts functionality.
I also don't buy the story that poor Bjarne was strong armed into his leading role on WG21 (the C++ language committee). Does Brain Kernighan play a similar role at WG14 (the C language committee)? No. He's moved on, Bjarne has not.
Are people suggesting that a BDFL would be better? I see a lot of dissatisfaction with ISO but that's not the same thing. Rust doesn't have a BDFL, and these days neither does Python. Maybe neither BDFLs nor ISO committees (well, specifically JTC1 sub-sub-committees, these are all under JTC1's SC22, a sub-committee for programming languages) are a good way to develop programming languages.
WG21's "Direction Group" is a handful of "experienced" people, by-invitation only, which has "been decided" (by itself of course, with a little help from Herb) to choose the future direction of C++. It further decided that to shape their work they should consult what was written in a book and in several papers about C++, all of them written by one of its members, Bjarne Stroustrup.
It reserves the right to chime in on absolutely everything, and has an "expectation" that everybody else (e.g. chairs of sub-committees) will take the Direction Group's advice.
> Concepts Lite is a consequence of ISO politics, it was either that or nothing all.
On the contrary, WG21 had voted in C++ 0x Concepts for the standard which would eventually become C++ 11 but after that Bjarne wrote a paper claiming that you don't need all these fancy features other people designed. You do, which is why C++ 20 Concepts achieves so little - but his paper was influential.
Over the next several months, the argument was made that C++ 0x shouldn't have this complicated C++ 0x Concepts feature which they had voted in because it wasn't implemented yet, and anyway Bjarne says it's not necessary. As JeanHeyd Meneide has observed it's weird, sometimes WG21 feels like it's absolutely crucial to have a working implementation, but then other times (cough modules) they don't see this as important at all and ship the standard with basically a TBD sticker. See if you can guess which WG21 member wanted Modules and also which WG21 member didn't want C++ 0x Concepts.
WG21 went back and ripped C++ 0x Concepts back out of the standard and then spent years more working on what would eventually become C++ 11.
> He has been a kind of C++ consciousness with his books and papers, but C++ isn't a language with BDFL.
Yeah, for a Dane he's surprisingly "Swedish" in his approach (this joke only makes sense if you've lived in Sweden and/or Denmark, but in short: Swedish decision making is extremely consensus based, whereas Denmark is more hierarchical by comparison).
> This however doesn't make Circle less relevant, because it is actually a testament to show that C++ could have been much better without the claimed breakage.
But it does break backwards compatibility, doesn't it? Meaning, if you pass Circle code to a C++ compiler, that's a no-go from the start, isn't it?
What aspect are you focusing on to argue that Circle introducss no breakage?
Every new C++ standard introduces new things that will not work under an old standard.
Not breaking backwards compatibility means that code for old standards should generally still work if recompiled.
Not breaking ABI means it should still work if not recompiled.
Note that Circle is not an F/OSS compiler as someone pointed out before. This however doesn't make Circle less relevant, because it is actually a testament to show that C++ could have been much better without the claimed breakage. If Circle does provide a number of desirable features and its compiler can be built by a single person, then why shouldn't the committee do the same?