If my work's performance requirements were so tight as to make that an issue, I would use C. Or numpy. CPython is slow. CPython is so mind-numbingly slow, for many many reasons, that each numeric variable could be a bigfloat and it would not matter the slightest.

Now, let's talk semantics. Not converting to floating point is precisely the kind of hidden computation that should be avoided, at all costs, in a language. Haskell is efficient and rigorous, and its division operator does floating point conversion. So, no excuses.

Haskell's division operator (/) does not do floating point conversion. It may seem that way to you since evaluating 3/4 gives 0.75, for example. What actually happens is that every integer literal get the function fromInteger applied to it automatically, this function converts integers to whatever other type is necessary. So if you evaluate 3/4 at the REPL you're really computing (fromInteger 3) / (fromInteger 4), giving, by default[^1] a floating point number.

The key point in this is that only integer literals get fromInteger applied automatically, so for example

      let n=6 :: Integer in n/3

gives a type error since n is not a literal and thus not automatically coerced. (Of course, doing this without the type declaration,

      let n=6 in n/3

does give 2.0 as result, but it declares n to be a Fractional number, not an Integer.)

[^1]: only by default, if you load the rational number library, you can ask for / to compute rational numbers by simply saying the type of result you want: 3/4 :: Ratio Int evaluates to the rational number 3 % 4 (% is Haskell's odd choice of notation for rationals).

I see your Haskell and raise you OCaml, which has / and /. operators and you use float_of_int with /. if you really do want a float at the end.

    # 5/2;;
    - : int = 2
    # 5 /. 2;;
    Error: This expression has type int but an expression was expected of type float
    # 5.0 /. float_of_int 2;;
    - : float = 2.5

One could argue that writing a/float(b) just to get float result isn't free (nor nice for that matter) either. But I still think the strongest argument is that someone who isn't corrupted by other languages would expect to get a float result (when necessary).