3 ms·
Is this getting downvoted? bummer. You have provided a real example, which I was looking for, of why one might need to express a square dollar; thanks. I won
by an1sotropy 4y ago
Is this getting downvoted? bummer.
You have provided a real example, which I was looking for, of why one might need to express a square dollar; thanks.
I wonder if the people who want to argue "types save you from bugs" see your example as very unwelcome, since they'd want to use "squared dollars" as an example of something nonsensical that should be flagged as a type error. I hope those people can reflect rationally on the limits of type systems in the real world.
- usea 4y agoI also enjoyed the square dollars example. A type system is merely a tool to encode information to help better model things. If you want to prevent multiplying dollars together, types can help you do that. If you want to enable multiplying dollars together, types can help you do that, too.
- Spivak 4y agoBut it shouldn’t be an error in any unit system. # oops my scaler has a unit x unit * x unit = x unit^2 The value isn’t catching this line of code since it’s potentially valid. It’s catching the line of code where you pass the result to a function that expects unit.
- an1sotropy 4y agoI agree, but the original article at dusted.codes hopes types will "prevent silly mistakes like multiplying $100 with £20". I don't know what that author would think of multiplying $100 with $20, but my point is that this embrace of type systems is apparently not just about function interfaces; it also includes the operands of things like multiplication, and preventing that operation if the types are fishy.
- Izkata 4y agoFor better or worse hopefully they think the two examples the same. Using the example above, "multiplying $100 with £20" can be achieved just by making the better engineer a remote employee paid in pounds. It adds the exchange rate into the mix, so the math will change over time, but conceptually the math is the same as the "dollar * dollar" example.