4 ms·

C++ deserves its rep for complexity. But, it comes from a promise to avoid a version upgrade debacle in the style of Python 3. C++ promises that you will foreve

C++ deserves its rep for complexity. But, it comes from a promise to avoid a version upgrade debacle in the style of Python 3. C++ promises that you will forever be able to interleave new-style code right into the middle of ancient, battle-tested old-style code. To do that, it can only add features and never take them away. Instead, it adds features that deprecate the practice of PITA patterns that were common, necessary and difficult. Like, SFINAE was necessary all over the place to make libraries "just work" the way users would expect. But, it is a PITA to write and and PITA to read. Now, constexpr if and auto return types can usually collapse all that scattered, implicit, templated pattern matching down to a few if statements. Adding those features technically made the standard more complicated. But, it made new code moving forward much simpler to understand. Similarly: Before variadic templates, parameter packs and fold expressions, you had the hell of recursive templates. Auto lambdas make a lot of 1-off templates blend right into the middle of regular code. Deduction guides set up library writers to set you up to write std::array names{"Alice", "Bob", "Charlie}; instead of std::array<const char*, 2> names{"Alice", "Bob", "Charlie};

munificent 3y ago
> But, it comes from a promise to avoid a version upgrade debacle in the style of Python 3. There is a very wide middle ground between C++'s "Your horrific unsafe code from the 80s still compiles" and Python's "We changed the integer values common operations on strings return at runtime with absolutely no way to statically tell how to migrate the code". In Dart, we moved to a sound static type system in 2.0, moved to non-nullable types in 2.13 (sound and defaulting to non-nullable!), and removed support for the pre-null safety type system in 3.0. We brought almost the entire ecosystem with us. Granted, our userbase is much smaller than C++'s and the average age of a given Dart codebase is much younger. But you can deprecate and remove old features without causing a decade of misery like Python did. You just need good language support for knowing which version of the language a given file is targeting, good static typing support, and good automated migration tooling. None of those is rocket science.
- plonk 3y ago
  > But you can deprecate and remove old features without causing a decade of misery like Python did. You just need good language support for knowing which version of the language a given file is targeting, good static typing support, and good automated migration tooling. None of those is rocket science. That's way easier to do in a naturally statically-typed language though.
  - munificent 3y ago
    Yes, which C++ is.
- pjmlp 3y ago
  Except there is only one implementation, with language design and implementation developed together. C++, Java and .NET are now all living through "decade of misery like Python did", exactly because not everyone is jumping into the latest versions of the languages and ecosystem changes.
  - gjadi 3y ago
    Isn't this a problem only if you manage your dependencies by source rather than "compiled"? That is, in Java you may not be able to compile old code with new javac, but the class file format is still understood by the JVM. So your old .jar still works. I believe it is the same in C++ with the .so. I don't know about .NET. In Python however, I don't think the .pyc were compatible between Python2 and Python3.
    - pjmlp 3y ago
      Your jar file only works if what it expects to find it is still there, it will crash and burn otherwise. Same applies to other examples.
      - gjadi 3y ago
        I'm not sure to understand. You mean if your jar depends on other stuff?
kajaktum 3y ago
> C++ promises that you will forever be able to interleave new-style code right into the middle of ancient, battle-tested old-style code. this is a problem, btw AFAIK c++ modernizations are few and rarely successful.
- i-use-nixos-btw 3y ago
  When I learned C++, there was no auto. Range-based for loops didn't exist. The combination of those two were particularly nice because instead of writing: for(std::vector<sometype<int>>::const_iterator it = my_container.cbegin(); it != my_container.cend(); ++it){ // use *it } You could use: for(auto const& val : my_container) { // use val } Which really paved the way for less hesitation around nesting templates and other awkward things. Same goes for map with the introduction of structured bindings: for(std::map<somekey, sometype<int>>::const_iterator it = my_map.cbegin(); it != my_map.cend(); ++it){ // use it->first, it->second } became for(auto const& [key, val] : my_map) { // use key, val } The introduction of std::variant made state a lot easier to reason about. Unions meant too much room for error, and cramming polymorphism into places it shouldn't have ever been was riddled with its own performance and memory issues. std::optional was also a game changer in that regard. constexpr was huge. It killed off a bunch of awkward template metaprogramming for something faster to compile and easier to deal with. I wasn't a part of the consteval discussions but from what I HEARD people say about it and what it actually WAS, I think it was castrated at some point along the way. Concepts, also a big one. Formatting (RIP iostreams) is much nicer than the alternative. Ranges, coroutines, modules - they'll have their day too. And we have a bunch of stuff to look forward to. Senders and receivers solves a lot of component interaction problems. Reflection will rid us of so much annoying provisioning of classes. Pattern matching and expression statements will be major usability boosts. Ok, C++ doesn't move at the speed of newer languages, but for its size, complexity and all of the hurdles that it has on the way to standardisation, I think modernisations are many and often successful. I would absolutely love a major break that fixed things we can't currently fix due to ABI risks, implementer resistance, etc. I'd love to rid us of the old ways™ and focus on safety the right way™ - by removing bad bits rather than just adding good bits and telling people to use them and follow a bunch of guidelines. I'd love better defaults. There is so much work to do to make C++ great again puts on MCPPGA hat, but I can't agree that modernisation are few and rarely successful.
barbariangrunge 3y ago
> To do that, it can only add features and never take them away. Instead, it adds features that deprecate the practice of PITA patterns that were common, necessary and difficult. The result being that programmers have to learn every single one of those ways of doing things in order to read your coworkers code. Give me python 3 breaking changes any day

munificent 3y ago

> But, it comes from a promise to avoid a version upgrade debacle in the style of Python 3. There is a very wide middle ground between C++'s "Your horrific unsafe code from the 80s still compiles" and Python's "We changed the integer values common operations on strings return at runtime with absolutely no way to statically tell how to migrate the code". In Dart, we moved to a sound static type system in 2.0, moved to non-nullable types in 2.13 (sound and defaulting to non-nullable!), and removed support for the pre-null safety type system in 3.0. We brought almost the entire ecosystem with us. Granted, our userbase is much smaller than C++'s and the average age of a given Dart codebase is much younger. But you can deprecate and remove old features without causing a decade of misery like Python did. You just need good language support for knowing which version of the language a given file is targeting, good static typing support, and good automated migration tooling. None of those is rocket science.

plonk 3y ago
> But you can deprecate and remove old features without causing a decade of misery like Python did. You just need good language support for knowing which version of the language a given file is targeting, good static typing support, and good automated migration tooling. None of those is rocket science. That's way easier to do in a naturally statically-typed language though.
- munificent 3y ago
  Yes, which C++ is.
pjmlp 3y ago
Except there is only one implementation, with language design and implementation developed together. C++, Java and .NET are now all living through "decade of misery like Python did", exactly because not everyone is jumping into the latest versions of the languages and ecosystem changes.
- gjadi 3y ago
  Isn't this a problem only if you manage your dependencies by source rather than "compiled"? That is, in Java you may not be able to compile old code with new javac, but the class file format is still understood by the JVM. So your old .jar still works. I believe it is the same in C++ with the .so. I don't know about .NET. In Python however, I don't think the .pyc were compatible between Python2 and Python3.
  - pjmlp 3y ago
    Your jar file only works if what it expects to find it is still there, it will crash and burn otherwise. Same applies to other examples.
    - gjadi 3y ago
      I'm not sure to understand. You mean if your jar depends on other stuff?

kajaktum 3y ago

> C++ promises that you will forever be able to interleave new-style code right into the middle of ancient, battle-tested old-style code. this is a problem, btw AFAIK c++ modernizations are few and rarely successful.

i-use-nixos-btw 3y ago
When I learned C++, there was no auto. Range-based for loops didn't exist. The combination of those two were particularly nice because instead of writing: for(std::vector<sometype<int>>::const_iterator it = my_container.cbegin(); it != my_container.cend(); ++it){ // use *it } You could use: for(auto const& val : my_container) { // use val } Which really paved the way for less hesitation around nesting templates and other awkward things. Same goes for map with the introduction of structured bindings: for(std::map<somekey, sometype<int>>::const_iterator it = my_map.cbegin(); it != my_map.cend(); ++it){ // use it->first, it->second } became for(auto const& [key, val] : my_map) { // use key, val } The introduction of std::variant made state a lot easier to reason about. Unions meant too much room for error, and cramming polymorphism into places it shouldn't have ever been was riddled with its own performance and memory issues. std::optional was also a game changer in that regard. constexpr was huge. It killed off a bunch of awkward template metaprogramming for something faster to compile and easier to deal with. I wasn't a part of the consteval discussions but from what I HEARD people say about it and what it actually WAS, I think it was castrated at some point along the way. Concepts, also a big one. Formatting (RIP iostreams) is much nicer than the alternative. Ranges, coroutines, modules - they'll have their day too. And we have a bunch of stuff to look forward to. Senders and receivers solves a lot of component interaction problems. Reflection will rid us of so much annoying provisioning of classes. Pattern matching and expression statements will be major usability boosts. Ok, C++ doesn't move at the speed of newer languages, but for its size, complexity and all of the hurdles that it has on the way to standardisation, I think modernisations are many and often successful. I would absolutely love a major break that fixed things we can't currently fix due to ABI risks, implementer resistance, etc. I'd love to rid us of the old ways™ and focus on safety the right way™ - by removing bad bits rather than just adding good bits and telling people to use them and follow a bunch of guidelines. I'd love better defaults. There is so much work to do to make C++ great again puts on MCPPGA hat, but I can't agree that modernisation are few and rarely successful.

barbariangrunge 3y ago

> To do that, it can only add features and never take them away. Instead, it adds features that deprecate the practice of PITA patterns that were common, necessary and difficult. The result being that programmers have to learn every single one of those ways of doing things in order to read your coworkers code. Give me python 3 breaking changes any day