4 ms·

Context: https://github.com/seanbaxter/circle/blob/master/new-circle/README.md https://github.com/seanbaxter/circle/blob/master/new-circle/... Note that Circle

Context: https://github.com/seanbaxter/circle/blob/master/new-circle/README.md https://github.com/seanbaxter/circle/blob/master/new-circle/... 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?

FpUser 3y ago
>"Context: https://github.com/seanbaxter/circle/blob/master/new-circle/README.md https://github.com/seanbaxter/circle/blob/master/new-circle/..." "simpler by disabling features ..." "By construction, the resulting edition is fully compatible with existing C++ code." I do not understand how "disabling features" can be "compatible with existing C++ code".
- gavinray 3y ago
  You use pragmas to disable/enable features on a file-by-file basis. Since existing code contains no Circle pragmas, it's compiled by the Circle compiler as "standard" C++. I urge you to try it -- there's binaries and Docker containers available. Takes two seconds.
  - rewmie 3y ago
    > You use pragmas to disable/enable features on a file-by-file basis. No, I don't. Some compilers support that, though, namely MSVC, but those practices are a huge code smell that are heavily discouraged for decades.
    - LoganDark 3y ago
      > No, I don't. Wrong "you". They were describing how Circle implements C++ compatibility, not how you personally use non-Circle compilers.
pjmlp 3y ago
Because politics, mostly. 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.
- rewmie 3y ago
  > 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?
  - pjmlp 3y ago
    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.
    - tialaramex 3y ago
      > he only has one vote 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.
suby 3y ago
> 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.
- vanderZwan 3y ago
  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.
rewmie 3y ago
> 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?
- celrod 3y ago
  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.

FpUser 3y ago

>"Context: https://github.com/seanbaxter/circle/blob/master/new-circle/README.md https://github.com/seanbaxter/circle/blob/master/new-circle/..." "simpler by disabling features ..." "By construction, the resulting edition is fully compatible with existing C++ code." I do not understand how "disabling features" can be "compatible with existing C++ code".

gavinray 3y ago
You use pragmas to disable/enable features on a file-by-file basis. Since existing code contains no Circle pragmas, it's compiled by the Circle compiler as "standard" C++. I urge you to try it -- there's binaries and Docker containers available. Takes two seconds.
- rewmie 3y ago
  > You use pragmas to disable/enable features on a file-by-file basis. No, I don't. Some compilers support that, though, namely MSVC, but those practices are a huge code smell that are heavily discouraged for decades.
  - LoganDark 3y ago
    > No, I don't. Wrong "you". They were describing how Circle implements C++ compatibility, not how you personally use non-Circle compilers.

pjmlp 3y ago

Because politics, mostly. 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.

rewmie 3y ago
> 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?
- pjmlp 3y ago
  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.
  - tialaramex 3y ago
    > he only has one vote 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.

suby 3y ago

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

vanderZwan 3y ago
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.

rewmie 3y ago

> 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?

celrod 3y ago
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.