> This is like an argument against integers because integers can express so many things: age, number of arms, days of the year, and so forth. And each of those

> This is like an argument against integers because integers can express so many things: age, number of arms, days of the year, and so forth. And each of those uses should be given its own type, and the compiler should refuse to compile if you pass setPersonAge() a value of type ArmNumber even if the relevant types are both implemented as 32-bit half-words at the machine level. If you are writing systems software or encryption software and need to care about machine-level details, that should be encoded into the type system as well. The semantic meaning of a type should be decoupled from its machine representation; for example, the type PersonAge could be implemented as a string in part of the program and still be the same type, because the compiler can handle auto-conversion like that no problem but the semantics of the value haven't changed. Or, at least, that's one way to look at types.