Re:Kotlin Money
by hakfoo on Saturday October 12, 2024 @02:29PM
(#41821274)
There's two problems with currencies:
1. So many languages don't have a native "decimal" type to build off of, so somewhere in the data's lifecycle, a "1.75" turns into "1.7499999999997".
2. The rules around exchange rates, number of decimals, coding and symbols.
The first problem should be solved as a first-class language feature. This will discourage hacks with a "fixed point" type, where you store integer "175 cents" instead of decimal "$1.75"-- inviting huge confusion if the currency ever drops or restructures its minor unit, and supports non-money use cases where floating point inaccuracy is risky.
Item 2 makes more sense as a library. You can record that there's a 1000:1 ratio between pre-1998 and current roubles, that the symbol for the Baht will inevitably confuse Bitcoin enthusiasts, and that the Korean won no longer has any decimal places, in dynamic fields.
1. So many languages don't have a native "decimal" type to build off of, so somewhere in the data's lifecycle, a "1.75" turns into "1.7499999999997".
2. The rules around exchange rates, number of decimals, coding and symbols.
The first problem should be solved as a first-class language feature. This will discourage hacks with a "fixed point" type, where you store integer "175 cents" instead of decimal "$1.75"-- inviting huge confusion if the currency ever drops or restructures its minor unit, and supports non-money use cases where floating point inaccuracy is risky.
Item 2 makes more sense as a library. You can record that there's a 1000:1 ratio between pre-1998 and current roubles, that the symbol for the Baht will inevitably confuse Bitcoin enthusiasts, and that the Korean won no longer has any decimal places, in dynamic fields.