4 ms·

> It's not a problem with "non-modern" languages, it's a problem with C and many of its successors. Not really. Any semi-decent modern language allows the crea

by adwn 5y ago

> It's not a problem with "non-modern" languages, it's a problem with C and many of its successors. Not really. Any semi-decent modern language allows the creation of custom types which support the desired behavior and often some syntactic sugar (like operator overloading) to make their usage more natural. Take C++, for example, the archetypal "C successor": It's almost trivial to define a class which stores a fixed-precision number and overload the +, -, *, etc. operators to make it as convenient as a built-in type, and put it in library. In my book, this is vastly superior to making such a type a built-in, because you can never satisfy everyone's requirements.

pjmlp 5y ago
It is also trivial to keep doing C mistakes with a C++ compiler, hence no matter how many ISO revisions it will still have, lack of safety due to C copy-paste compatibility will never be fixed.
- adwn 5y ago
  > [...] no matter how many ISO revisions it will still have, lack of safety due to C copy-paste compatibility will never be fixed. Okay, no idea how that's relevant to "built-in decimal types" vs "library-defined decimal types", but if it makes you feel better, you can do the same in Rust or Python, two languages which are "modern" compared to COBOL, don't inherit C's flaws, and which enable defining custom number types/classes/whatever together with convenient operator overloading.
  - deleted 5y ago
    [deleted]
  - pjmlp 5y ago
    Rust I agree, Python not really as the language doesn't provide any way to keep invariants.
    - adwn 5y ago
      > Python not really as the language doesn't provide any way to keep invariants Again, how is that relevant? If there's no way to enforce an invariant in custom data types, then there's also no way to enforce invariants in code using built-in data types.
      - pjmlp 5y ago
        It is surely relevant. Rust provides the mechanisms to enforce them, while in Python, like all dynamic languages, everything is up for grabs.
        adwn 5y ago
        What I meant [1] was: In Python, invariants are enforced by conventions, not by the compiler. If that's not suitable for a given use case, then Python is entirely unsuited for that use case, regardless whether it provides built-in decimal types or user-defined decimal types. That's why I said that your objection regarding invariant enforcement is irrelevant to this discussion. [1] (but was to lazy to write out)

by adwn 5y ago

pjmlp 5y ago

It is also trivial to keep doing C mistakes with a C++ compiler, hence no matter how many ISO revisions it will still have, lack of safety due to C copy-paste compatibility will never be fixed.

adwn 5y ago
> [...] no matter how many ISO revisions it will still have, lack of safety due to C copy-paste compatibility will never be fixed. Okay, no idea how that's relevant to "built-in decimal types" vs "library-defined decimal types", but if it makes you feel better, you can do the same in Rust or Python, two languages which are "modern" compared to COBOL, don't inherit C's flaws, and which enable defining custom number types/classes/whatever together with convenient operator overloading.
- deleted 5y ago
  [deleted]
- pjmlp 5y ago
  Rust I agree, Python not really as the language doesn't provide any way to keep invariants.
  - adwn 5y ago
    > Python not really as the language doesn't provide any way to keep invariants Again, how is that relevant? If there's no way to enforce an invariant in custom data types, then there's also no way to enforce invariants in code using built-in data types.
    - pjmlp 5y ago
      It is surely relevant. Rust provides the mechanisms to enforce them, while in Python, like all dynamic languages, everything is up for grabs.
      - adwn 5y ago
        What I meant [1] was: In Python, invariants are enforced by conventions, not by the compiler. If that's not suitable for a given use case, then Python is entirely unsuited for that use case, regardless whether it provides built-in decimal types or user-defined decimal types. That's why I said that your objection regarding invariant enforcement is irrelevant to this discussion. [1] (but was to lazy to write out)