3 ms·

I think there's a good reason for it to be part of a library. The problem with currencies is much like dates: they're a social construct, and change more than m

I think there's a good reason for it to be part of a library. The problem with currencies is much like dates: they're a social construct, and change more than most of the social constructs we embed in programming languages. I don't want to update my interpreter or compiler because Turkey changed their rules of daylight savings time, or Ethereum becomes popular.

coreload 2y ago
Yes, and sometimes the context is not just social but legal or contractual, e.g. rounding currency.
- ebiester 2y ago
  Yes, and rounding currency is just something that is always handled, as is the number of places that you take a currency out to - for example, gas is often priced at thousandths of a dollar rather than hundreds but presented to the customer in hundredths at the end. Or Yen in most cases does not have a decimal point, except that the places where you round or don't round can be consequential in large enough quantities. These are largely things that can be handled by a library, but if it's in the language you best not get it wrong because it's so much harder to change!
  - benatkin 2y ago
    From my perspective those are tenths of a cent. Stripe has integer values for cents. Am I wrong here? https://stackoverflow.com/questions/35326710/stripe-currency-are-all-amounts-in-cents-100ths-or-does-it-depend-on-curren https://stackoverflow.com/questions/35326710/stripe-currency...
carapace 2y ago
This. But more than being changeable they (time and money) are supra-logical or trans-rational. In other words, computers are limited to what can be modeled or calculated with the one logical operation (it has lots of names, I like "Quine dagger") but these phenomenon are not.
skybrian 2y ago
You could say the same of Unicode, though. Some cultural abstractions become increasingly rigid because they’re embedded in computer systems everywhere.
JumpCrisscross 2y ago
Oh, this reminds me of my first job out of college at a Swiss bank. Apparently every time a currency conversion was done in a particular model, there was a routine that translated back and forth between the pre-Euro currency and Euro at the conversion rate. So a USD-EUR transaction with a party in France would be run as USD-FRF --> FRF-EUR. All in COBOL. As a result, every so often, you'd get a slightly different result running a USD-EUR trade with a party in France versus e.g. Germany or the U.K.
- tomcam 2y ago
  So what happened when those discrepancies arose?
  - JumpCrisscross 2y ago
    > what happened when those discrepancies arose? They were just passed along.
  - tvaughan 2y ago
    They became the basis for the plot of Superman III
hakfoo 2y ago
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.

coreload 2y ago

Yes, and sometimes the context is not just social but legal or contractual, e.g. rounding currency.

ebiester 2y ago
Yes, and rounding currency is just something that is always handled, as is the number of places that you take a currency out to - for example, gas is often priced at thousandths of a dollar rather than hundreds but presented to the customer in hundredths at the end. Or Yen in most cases does not have a decimal point, except that the places where you round or don't round can be consequential in large enough quantities. These are largely things that can be handled by a library, but if it's in the language you best not get it wrong because it's so much harder to change!
- benatkin 2y ago
  From my perspective those are tenths of a cent. Stripe has integer values for cents. Am I wrong here? https://stackoverflow.com/questions/35326710/stripe-currency-are-all-amounts-in-cents-100ths-or-does-it-depend-on-curren https://stackoverflow.com/questions/35326710/stripe-currency...

carapace 2y ago

This. But more than being changeable they (time and money) are supra-logical or trans-rational. In other words, computers are limited to what can be modeled or calculated with the one logical operation (it has lots of names, I like "Quine dagger") but these phenomenon are not.

skybrian 2y ago

You could say the same of Unicode, though. Some cultural abstractions become increasingly rigid because they’re embedded in computer systems everywhere.

JumpCrisscross 2y ago

Oh, this reminds me of my first job out of college at a Swiss bank. Apparently every time a currency conversion was done in a particular model, there was a routine that translated back and forth between the pre-Euro currency and Euro at the conversion rate. So a USD-EUR transaction with a party in France would be run as USD-FRF --> FRF-EUR. All in COBOL. As a result, every so often, you'd get a slightly different result running a USD-EUR trade with a party in France versus e.g. Germany or the U.K.

tomcam 2y ago
So what happened when those discrepancies arose?
- JumpCrisscross 2y ago
  > what happened when those discrepancies arose? They were just passed along.
- tvaughan 2y ago
  They became the basis for the plot of Superman III

hakfoo 2y ago

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.