4 ms·

Yes. I believe that doesn't affect my argument. Instead of the ~4 programing languages found within C++20 you would be adding one more to the codebase. Does tha

Yes. I believe that doesn't affect my argument. Instead of the ~4 programing languages found within C++20 you would be adding one more to the codebase. Does that sound like a good idea? Maybe my comment was too harsh. It's great someone's trying to make the C++ situation better. I hope they succeed. I just think they won't and C++ should go the way of C and stop "evolving", while this thing is very similar in spirit to blowing it up even further. (I've actually liked working with C++ for the past 15 years, but not because it's productive but for the stockholmy "challenge" of it)

pjmlp 4y ago
I bet that are plenty of dialects in Python 3.11, Java 20, C# 12, C23.... That is what happens when languages stick around for decades
- staunton 4y ago
  Thing is, C++ really is special in that way. I would say C is at most 2 languages (maybe not even that, or most legacy code is already the "newer" of those), Python is at most 2.5 languages (subtract one because Python 2 is no longer supported in 3). C# and Java have a better shot in this sad competition but still, it's not like you're not supposed to be using 50% of those languages original features anymore.
  - pjmlp 4y ago
    There are lots of features we are not supposed to use, yet we keep bouncing into them.
usrusr 4y ago
Being no expert at c++ (far from it..) and knowing nothing about carbon I'd expect that you'd usually need to do at least some cleanup amongst those "~4 languages" (nice way to put it!) on the c++ side before enjoying interop. But I'd also assume that much (all?) of that cleanup would be stuff that would be worth doing anyways, even if you sticked to c++, but that you keep postponing...
- staunton 4y ago
  The issue is that it's very hard to "clean C++ up" because backwards compatibility must be upheld (there are obviously good reasons for that). C and C++ have terrible defaults that mostly cannot be changed anymore. You can try to add warnings for everything (people dislike and disable them), static analysis, valgrind, (not trivial to set up and use correctly) etc. etc. You can add new stuff (e.g. smart pointers) and mandate (e.g. C++ core guidelines) that the old ways (new/delete) should not be used. I could continue forever describing measures aimed at making C++ safer. In my opinion all these things have failed. The language is old, has insane amounts of legacy beurocracy and process tied to it, has terrible unchangeable defaults, unchangeable ABI, and is insanely complicated to "get right" (write a function that adds two signed integers and returns the result, that has no undefined behavior) to the point where there is an established tradition not to try to get it right. Yes, smart pointers are nice, concepts are also nice, but this patchwork does not work well with other features, and what this "improvement" process does is make it more complicated. Almost noone really understands it anymore. It's time to retire it and start over completely, as well as reconsider if all the things that C++ has been traditionally used for warrant such a language. Things like GC languages or Rust/Zig should fill that space. They have decent interop where needed. Meanwhile C++ is not going away for a very long time. I see this project as building another language into C++ that makes it even more complicated.
  - usrusr 4y ago
    Yes, c++ (the language) can't be properly cleaned up because support for not just some but all legacy codebases isn't optional at all. But I wasn't talking about cleaning up c++, the language, I was talking about cleaning up c++ codebases to align them with whatever subset of c++ that will play nice with carbon. Surely won't be everything, whatever obscure leftover from 1984 you dig up, but will likely aling well with good somewhat modern (or modernized) codebases. That would mean ending up with code that cleanup process will likely end up restricting itself to a certain subset of c++ that might in fact be a good candidate for a "somewhat cleaned up c++ language", but I agree, that wouldn't be worth it: a properly different thing designed for interoperability with a large subset of c++ will be much easier to learn than a literal subset.

pjmlp 4y ago

I bet that are plenty of dialects in Python 3.11, Java 20, C# 12, C23.... That is what happens when languages stick around for decades

staunton 4y ago
Thing is, C++ really is special in that way. I would say C is at most 2 languages (maybe not even that, or most legacy code is already the "newer" of those), Python is at most 2.5 languages (subtract one because Python 2 is no longer supported in 3). C# and Java have a better shot in this sad competition but still, it's not like you're not supposed to be using 50% of those languages original features anymore.
- pjmlp 4y ago
  There are lots of features we are not supposed to use, yet we keep bouncing into them.

usrusr 4y ago

Being no expert at c++ (far from it..) and knowing nothing about carbon I'd expect that you'd usually need to do at least some cleanup amongst those "~4 languages" (nice way to put it!) on the c++ side before enjoying interop. But I'd also assume that much (all?) of that cleanup would be stuff that would be worth doing anyways, even if you sticked to c++, but that you keep postponing...

staunton 4y ago
The issue is that it's very hard to "clean C++ up" because backwards compatibility must be upheld (there are obviously good reasons for that). C and C++ have terrible defaults that mostly cannot be changed anymore. You can try to add warnings for everything (people dislike and disable them), static analysis, valgrind, (not trivial to set up and use correctly) etc. etc. You can add new stuff (e.g. smart pointers) and mandate (e.g. C++ core guidelines) that the old ways (new/delete) should not be used. I could continue forever describing measures aimed at making C++ safer. In my opinion all these things have failed. The language is old, has insane amounts of legacy beurocracy and process tied to it, has terrible unchangeable defaults, unchangeable ABI, and is insanely complicated to "get right" (write a function that adds two signed integers and returns the result, that has no undefined behavior) to the point where there is an established tradition not to try to get it right. Yes, smart pointers are nice, concepts are also nice, but this patchwork does not work well with other features, and what this "improvement" process does is make it more complicated. Almost noone really understands it anymore. It's time to retire it and start over completely, as well as reconsider if all the things that C++ has been traditionally used for warrant such a language. Things like GC languages or Rust/Zig should fill that space. They have decent interop where needed. Meanwhile C++ is not going away for a very long time. I see this project as building another language into C++ that makes it even more complicated.
- usrusr 4y ago
  Yes, c++ (the language) can't be properly cleaned up because support for not just some but all legacy codebases isn't optional at all. But I wasn't talking about cleaning up c++, the language, I was talking about cleaning up c++ codebases to align them with whatever subset of c++ that will play nice with carbon. Surely won't be everything, whatever obscure leftover from 1984 you dig up, but will likely aling well with good somewhat modern (or modernized) codebases. That would mean ending up with code that cleanup process will likely end up restricting itself to a certain subset of c++ that might in fact be a good candidate for a "somewhat cleaned up c++ language", but I agree, that wouldn't be worth it: a properly different thing designed for interoperability with a large subset of c++ will be much easier to learn than a literal subset.