4 ms·

Why do you want these compilation errors? Both are measures of length. I can add an inch and a centimeter, and the result is a well defined length that we can

by clarry 7y ago

Why do you want these compilation errors? Both are measures of length. I can add an inch and a centimeter, and the result is a well defined length that we can express in inches, centimeters, light years, or any other measure of length. Likewise for areas or ratios of lengths. I would generally prefer it if the language just gave me the correct result, which I can then print out in the user's preferred unit.

GnarfGnarf 7y ago
Adding inches and raw centimetres is like adding apples and oranges, which they taught us not to do in grade school. What you are thinking of is: in1 = cm1.toInches(); If someone passes cm to a function that expects inches, much error and grief will result.
- clarry 7y ago
  No, I'm not thinking of dec1 = hex1.toDecimal(); because num1 = 0xff00 + 64; works just as well and so does functionThatExpectsNumber(0b1101); as does p1 = mat1 * vec1; Lengths are just as absolute as integers, but we have different ways to input and represent them. A sufficiently advanced language understands the equivalences and does just the right thing. Adding apples and oranges does not happen. Generally your function should not expect inches, it should expect some length and I can input it in any unit of length I want. Sure there are cases where you're constrained and need to account for the limited range and precision of your underlying storage format, but that should not be the default for any modern high level general purpose programming language. We don't need to concern ourselves with grade school stuff, the computer can do it for us. Adding apples to oranges is concern at a lower level than the abstraction we should be working with by default. Doing arithmetic by hand on pen and paper is pretty low level. Adding apples to oranges is also a concern when you don't have proper types by which the system can deduce that orange is actually just 2.54*apple.
  - GnarfGnarf 7y ago
    You're missing the point. I make an app that prints charts. It includes a function that subtracts user-specified margins from the paper width, to calculate available space. Some of my customers are in the U.S (inches), others are not (cm). If I call printPage(0.75, 0.75); you really think it's going to be all the same whether "0.75" represents inches or centimetres?

by clarry 7y ago

GnarfGnarf 7y ago

Adding inches and raw centimetres is like adding apples and oranges, which they taught us not to do in grade school. What you are thinking of is: in1 = cm1.toInches(); If someone passes cm to a function that expects inches, much error and grief will result.

clarry 7y ago
No, I'm not thinking of dec1 = hex1.toDecimal(); because num1 = 0xff00 + 64; works just as well and so does functionThatExpectsNumber(0b1101); as does p1 = mat1 * vec1; Lengths are just as absolute as integers, but we have different ways to input and represent them. A sufficiently advanced language understands the equivalences and does just the right thing. Adding apples and oranges does not happen. Generally your function should not expect inches, it should expect some length and I can input it in any unit of length I want. Sure there are cases where you're constrained and need to account for the limited range and precision of your underlying storage format, but that should not be the default for any modern high level general purpose programming language. We don't need to concern ourselves with grade school stuff, the computer can do it for us. Adding apples to oranges is concern at a lower level than the abstraction we should be working with by default. Doing arithmetic by hand on pen and paper is pretty low level. Adding apples to oranges is also a concern when you don't have proper types by which the system can deduce that orange is actually just 2.54*apple.
- GnarfGnarf 7y ago
  You're missing the point. I make an app that prints charts. It includes a function that subtracts user-specified margins from the paper width, to calculate available space. Some of my customers are in the U.S (inches), others are not (cm). If I call printPage(0.75, 0.75); you really think it's going to be all the same whether "0.75" represents inches or centimetres?