Of course. Sooner or later you bump up against the fact that real machines are finite. That's not the issue. The issue is this: you ask two compilers to add 1 and 2.3. Compiler A says the answer is 3.3. Compiler B says it's an error. Which compiler would you rather use?
It's ultimately a matter of taste. You can push compiler cleverness too far. For example, 1+"2.3" probably should be an error (and if you don't think so, what should 1+"two point three" return?) But the rules for mixing integers, floats, rationals and complex numbers are pretty well worked out, and IMHO any language that forces the programmer to reinvent them is b0rken.
I agree that it makes mixing floats and doubles a little more work, but I'll trade that for the ability to have it automatically infer and verify whether what I'm doing makes sense when I have e.g. multiple layers of higher-order functions operating on a cyclical directed graph containing vertices indexed by a polymorphic type, and the edges are ...
Interactive testing via bottom-up design helps, but getting automatic feedback from the type system whether the code works as a whole, and which parts (if any) have been broken as I design and change it is tremendously useful. Having to write the code in a way that is decidable for the type system is a tradeoff (and the type system itself could be improved), but it's a tradeoff I'm willing to make on some projects.
> The issue is this: you ask two compilers to add 1 and 2.3. Compiler A says the answer is 3.3. Compiler B says it's an error.
In this case, Compiler B is fine with (float 1) +. 2.3 or 1 + (truncate 2.3), it just won't implicitly convert there because it goes against the core design of the language. This sort of thing is annoying at the very small level, but its utility with complicated data structures more than makes up for it.
> For example, 1+"2.3" probably should be an error (and if you don't think so, what should 1+"two point three" return?) [...]
Good example, by the way. Also, I think we're in agreement most of the way - I find Haskell's typeclasses a better solution to this specific problem (the operations +, -, etc. operate on any type with Number-like properties, and if it's not a combination that makes sense within the type system, ..., it's a compile-time error), though I prefer OCaml to Haskell overall.
It's ultimately a matter of taste. You can push compiler cleverness too far. For example, 1+"2.3" probably should be an error (and if you don't think so, what should 1+"two point three" return?) But the rules for mixing integers, floats, rationals and complex numbers are pretty well worked out, and IMHO any language that forces the programmer to reinvent them is b0rken.