4 ms·

«computers only use decimal points, not decimal commas» That's what localization is all about: eliminating these false assumptions. It's only confusing when y

by athenot 11y ago

«computers only use decimal points, not decimal commas» That's what localization is all about: eliminating these false assumptions. It's only confusing when you're not used to it. On a similar note, 12-hour time notation (eg. 3pm) is confusing as heck when you're used to 24 hour notation.

ars 11y ago
> That's what localization is all about: eliminating these false assumptions. I've never seen a production compiler use anything except decimal points. So writing code that outputs code must be extra confusing: Turn off localization for the parts meant for the computer, and turn it on for the parts meant for humans.
- athenot 11y ago
  Well here's the thing: decimal points are for humans in the first place. Computers use fixed, floats or whatever binary representation that suits the needs of the environment.
- wyldfire 11y ago
  > I've never seen a production compiler use anything except decimal points. There's a distinction between literals used in programming languages and how various input/output routines emit different numerals. Most programming languages follow the convention: a '.' for a radix symbol and no thousands separator. Many programming languages also include: explicit '.' implies a floating-point numeral, scientific notation support. Most modern programming languages (and even some older ones) have standard library or extremely popular library support for localization. That localization will customize things like the radix and thousands separator. Some languages support custom literals, so you probably could adapt it to match your locale if the grammar doesn't somehow become ambiguous. Other interesting stuff literals sometimes include: different numeral bases, signedness, precision. It doesn't seem confusing to me, but I'll admit that there have probably been many times that I could take advantage of the programming languages' support for parsing literal numerals whose format happens to match my locale's (en_US.*).

by athenot 11y ago

ars 11y ago

> That's what localization is all about: eliminating these false assumptions. I've never seen a production compiler use anything except decimal points. So writing code that outputs code must be extra confusing: Turn off localization for the parts meant for the computer, and turn it on for the parts meant for humans.

athenot 11y ago
Well here's the thing: decimal points are for humans in the first place. Computers use fixed, floats or whatever binary representation that suits the needs of the environment.
wyldfire 11y ago
> I've never seen a production compiler use anything except decimal points. There's a distinction between literals used in programming languages and how various input/output routines emit different numerals. Most programming languages follow the convention: a '.' for a radix symbol and no thousands separator. Many programming languages also include: explicit '.' implies a floating-point numeral, scientific notation support. Most modern programming languages (and even some older ones) have standard library or extremely popular library support for localization. That localization will customize things like the radix and thousands separator. Some languages support custom literals, so you probably could adapt it to match your locale if the grammar doesn't somehow become ambiguous. Other interesting stuff literals sometimes include: different numeral bases, signedness, precision. It doesn't seem confusing to me, but I'll admit that there have probably been many times that I could take advantage of the programming languages' support for parsing literal numerals whose format happens to match my locale's (en_US.*).