"Strong typing vs. strong testing"
salil
rohshall at gmail.com
Tue Oct 5 05:36:11 CEST 2010
On Sep 30, 1:38 pm, Lie Ryan <lie.1... at gmail.com> wrote:
> The /most/ correct version of maximum() function is probably one written
> in Haskell as:
>
> maximum :: Integer -> Integer -> Integer
> maximum a b = if a > b then a else b
>
> Integer in Haskell has infinite precision (like python's int, only
> bounded by memory), but Haskell also have static type checking, so you
> can't pass just any arbitrary objects.
>
> But even then, it's still not 100% correct. If you pass a really large
> values that exhaust the memory, the maximum() could still produce
> unwanted result.
>
> Second problem is that Haskell has Int, the bounded integer, and if you
> have a calculation in Int that overflowed in some previous calculation,
> then you can still get an incorrect result. In practice, the
> type-agnostic language with *mandatory* infinite precision arithmetic
> wins in terms of correctness. Any language which only has optional
> infinite precision arithmetic can always produce erroneous result.
I have not programmed in Haskell that much, but I think Haskell
inferences type "Integer" (the infinite precision) by default and not
"Int" (finite precision) type for the integers. So, the programmer who
specifically mentions "Int" in the signature of the function, is
basically overriding this default behavior for specific reasons
relevant to the application, for example, for performance. I think
Haskell's way is the right. It is providing "safe behavior" as
default and at the same time treating programmer as adults, at least
in this case.
I think dynamic languages are attractive because they make programs
less verbose. But, statically typed languages with type inference
(Haskell, OCaML, Scala, F#) is a very good compromise because they
offer both type safety and succinctness. And when we need algorithms
that should work the same independent of types, Haskell has
typeclasses which are pretty intuitive, unlike the horrible C++
templates.
More information about the Python-list
mailing list