[dfox]

Because not caring how FP values are stored and what the implications are (or even not realising that you favorite programming language uses FP by default) is a particularly fast way to become the "minus 10 times programmer".

Storing monetary values as FP is one thing, but I've seen phone numbers and other numeric identifiers (long time ago before PCI-DSS even credit card numbers) stored as FP values, with predictable results.

[hugatest]

As long as you know the implications, you don't need to know how the values are stored.

You may say it's easier to know how they are stored, then you can derive the implications anytime you need them. Maybe that works for you, but most people who I know that got this wrong do actually know how FP values are stored, they are just drawing the wrong conclusions. So better focus on the implications, cause it's those that matter.

I already expressed this in the GP comment, and it's a little shocking to see all the replies that didn't actually pick up on that.

[ryandrake]

Knowing how the values are stored provides you the "why" behind the practical implications. Another example: Half of the range of all values that "float" can store lie between -1.0 and 1.0. Knowing how those values are encoded in memory tells you why.

[digging]

> Because not caring how FP values are stored and what the implications are (or even not realising that you favorite programming language uses FP by default) is a particularly fast way to become the "minus 10 times programmer".

I don't think that's true at all. You're merely looking at a symptom of someone who is intrinsically a negative performer. But that's rather like assuming that someone with a cough has tuberculosis.