3 ms·

The problem of C++ is that its features are not just additive. In most languages, if you take two features and use them both, they add up. In C++, they may acti

The problem of C++ is that its features are not just additive. In most languages, if you take two features and use them both, they add up. In C++, they may actively interfere with one another.

pjmlp 4y ago
I gather you don't have much use of the latest versions of the languages I mentioned, in all of them I can think of examples that don't add up.
- dagmx 4y ago
  I’d be curious which Python features don’t work together?
  - pjmlp 4y ago
    One example sorted out with Python 3 would be old style classes and new style ones. Other would be tracking down if attributes get dynamically changed via __dict__, __slots__, and how __slots__ interact with each other if multiple definitions happen to exist. The way numeric division and remainder changed between Python 2 and 3.
    - dagmx 4y ago
      I think you’re talking about a different issue here. The person you replied to previously was talking about how certain new C++ features don’t work together. For example move with a lambda can cause UB. You’re talking about changes to the language or if you have a conflict of definition.
      - pjmlp 4y ago
        All of that are changes/features regardless of which form they take.
        dagmx 4y ago
        No. They’re talking about feature incompatibility within a single version. You’re talking about feature differences between different versions. Completely different things.
moloch-hai 4y ago
I doubt you can present even just a single example. All languages' features combine multiplicatively.
- masklinn 4y ago
  The rule of 0/3/5 literally exists because the default behaviours misinteract with any override of the rest.
  - moloch-hai 4y ago
    Yeah, that doesn't qualify. It is all one feature: override copy or move semantics, and there is a prescribed way to do it. Rule of zero, of course, is the norm, and is an extremely beneficial interaction. 2nd try?
    - masklinn 4y ago
      > Yeah, that doesn't qualify. It absolutely does. > It is all one feature: override copy or move semantics, and there is a prescribed way to do it. And yet rather than force you to do it the language just goes into the weed and generates complete nonsense.
nurettin 4y ago
C++ gets special treatment for some reason when it comes to backwards compatibility and modern language features. Oh no! we got threads and timers! C++ recognized the existence of file systems and regular expressions, woe I say! Polymorphic lambdas? I've got std::bind1st haha! Wait, not atomic! Anything but that!
kllrnohj 4y ago
> In most languages, if you take two features and use them both, they add up. Java nio vs. io Java Reader vs. InputStream (not necessarily the interfaces themselves, but the redundancy between them eg should I use InputStream -> BufferInputStream -> InputStreamReader? Or InputStream -> InputStreamReader -> BufferedReader?) Java float[] vs. ArrayList<Float> vs Vector<Float> vs. FloatVector vs. FloatBuffer - just how many ways can we describe "a linear allocation of numbers" in Java at this point? And they're still adding new ones! So no, other languages don't just magically handle this more gracefully than C++ does. If a language is successful, it will either suffer from this or it'll stagnate - it's the natural consequence of preserving backwards compatibility while adding new features & capabilities.
- wiseowise 4y ago
  Don't forget Date/Time classes. Absolute mess.
  - pjmlp 4y ago
    Something that .NET also missed to fix.
- ttfkam 4y ago
  Reader is for text/characters while InputStream is for bytes. An InputStream always lays at the heart of a Reader. Java's I/O may not be the most elegant of simplest, but it makes additive sense assuming you don't just have a bone to pick with the language. The float examples are artifacts of pragmatism between plain old data types versus heap allocated objects. Though I do admit Vector<Float> is absolutely obsolete and should be avoided. The others have a clear purpose and raison d'être. Now java.util.Date on the other hand…
  - kllrnohj 4y ago
    > The others have a clear purpose and raison d'être. Yes, but they don't compose cleanly together. As in, I can't just use FloatVector in all places that took a FloatBuffer previously or whatever. They aren't additive in an incremental migration sense, they are additive in the "these are just wholly unrelated APIs in their own wholly distinct silos" sense. Aka, the thing C++ is regularly slammed for doing even though it's additions aren't even this clunky.

The problem of C++ is that its features are not just additive. In most languages, if you take two features and use them both, they add up. In C++, they may actively interfere with one another.

pjmlp 4y ago

I gather you don't have much use of the latest versions of the languages I mentioned, in all of them I can think of examples that don't add up.

dagmx 4y ago
I’d be curious which Python features don’t work together?
- pjmlp 4y ago
  One example sorted out with Python 3 would be old style classes and new style ones. Other would be tracking down if attributes get dynamically changed via __dict__, __slots__, and how __slots__ interact with each other if multiple definitions happen to exist. The way numeric division and remainder changed between Python 2 and 3.
  - dagmx 4y ago
    I think you’re talking about a different issue here. The person you replied to previously was talking about how certain new C++ features don’t work together. For example move with a lambda can cause UB. You’re talking about changes to the language or if you have a conflict of definition.
    - pjmlp 4y ago
      All of that are changes/features regardless of which form they take.
      - dagmx 4y ago
        No. They’re talking about feature incompatibility within a single version. You’re talking about feature differences between different versions. Completely different things.

moloch-hai 4y ago

I doubt you can present even just a single example. All languages' features combine multiplicatively.

masklinn 4y ago
The rule of 0/3/5 literally exists because the default behaviours misinteract with any override of the rest.
- moloch-hai 4y ago
  Yeah, that doesn't qualify. It is all one feature: override copy or move semantics, and there is a prescribed way to do it. Rule of zero, of course, is the norm, and is an extremely beneficial interaction. 2nd try?
  - masklinn 4y ago
    > Yeah, that doesn't qualify. It absolutely does. > It is all one feature: override copy or move semantics, and there is a prescribed way to do it. And yet rather than force you to do it the language just goes into the weed and generates complete nonsense.

nurettin 4y ago

C++ gets special treatment for some reason when it comes to backwards compatibility and modern language features. Oh no! we got threads and timers! C++ recognized the existence of file systems and regular expressions, woe I say! Polymorphic lambdas? I've got std::bind1st haha! Wait, not atomic! Anything but that!

kllrnohj 4y ago

> In most languages, if you take two features and use them both, they add up. Java nio vs. io Java Reader vs. InputStream (not necessarily the interfaces themselves, but the redundancy between them eg should I use InputStream -> BufferInputStream -> InputStreamReader? Or InputStream -> InputStreamReader -> BufferedReader?) Java float[] vs. ArrayList<Float> vs Vector<Float> vs. FloatVector vs. FloatBuffer - just how many ways can we describe "a linear allocation of numbers" in Java at this point? And they're still adding new ones! So no, other languages don't just magically handle this more gracefully than C++ does. If a language is successful, it will either suffer from this or it'll stagnate - it's the natural consequence of preserving backwards compatibility while adding new features & capabilities.

wiseowise 4y ago
Don't forget Date/Time classes. Absolute mess.
- pjmlp 4y ago
  Something that .NET also missed to fix.
ttfkam 4y ago
Reader is for text/characters while InputStream is for bytes. An InputStream always lays at the heart of a Reader. Java's I/O may not be the most elegant of simplest, but it makes additive sense assuming you don't just have a bone to pick with the language. The float examples are artifacts of pragmatism between plain old data types versus heap allocated objects. Though I do admit Vector<Float> is absolutely obsolete and should be avoided. The others have a clear purpose and raison d'être. Now java.util.Date on the other hand…
- kllrnohj 4y ago
  > The others have a clear purpose and raison d'être. Yes, but they don't compose cleanly together. As in, I can't just use FloatVector in all places that took a FloatBuffer previously or whatever. They aren't additive in an incremental migration sense, they are additive in the "these are just wholly unrelated APIs in their own wholly distinct silos" sense. Aka, the thing C++ is regularly slammed for doing even though it's additions aren't even this clunky.