Hacker News Reader

Comment by dralley | Hacker News Reader

>[Modern] programming languages have decimal/rational data types

This caveat is kind of funny, in light of COBOL having support for decimal / fixed precision data types baked directly into the language.

It's not a problem with "non-modern" languages, it's a problem with C and many of its successors. That's precisely why many "non-modern" languages have stuck around so long.

https://medium.com/the-technical-archaeologist/is-cobol-hold...

Additionally, mainframes are so strongly optimized for hardware-accelerated fixed point decimal computing that for a lot of financial calculations it can be legitimately difficult to match their performance with standard commercial hardware.

View on HN

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

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.

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

Rust I agree, Python not really as the language doesn't provide any way to keep invariants.

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

It is surely relevant.

Rust provides the mechanisms to enforce them, while in Python, like all dynamic languages, everything is up for grabs.

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)

It is quite simple to do the same in Julia

Reply on news.ycombinator.com