Re: dynamic vs. static typing

[Joe Marshall <address@hidden>]

"Anton van Straaten" <anton@appsolutions.com> writes:

> Matt Hellige wrote:
>> This brings up the question of what the difference really is between
>> "type errors" and other run-time errors (like pattern matching failure
>> in particular), but we've been over that...
>
> Can I go over it again?  ;o)

Only if I can put in my $0.02 worth.

There is another dimension to the static vs. dynamic debate and that
is one of decidability.  In general, you cannot determine what a
program does without actually running it.  Information gleaned from
abstract interpretation is therefore an approximation of `really'
interpreting the program.  So interesting questions asked at compile
time give one of three answers:  "It is decidedly so." "My sources say
no." and "Reply hazy, try again."

It is that third category that is a problem.  Most static type
aficionado's *appear* to take the stance that one goal is to provide
compile-time guarantees about types.  Thus the `reply hazy' category
is equated with the `no'.  Most dynamic type apologists argue that it
is too annoying to add the necessary information to allow the type
system to answer `yes'.  (My own viewpoint is that there are *many*
interesting and useful programs in the `hazy' category, so I'd rather
forego the guarantees, but any tool that points out a provable bug
early on is welcome.)

This tends to lead each side to see a bizarre caricature of the other:
  dynamic type advocates seem to be saying they wouldn't even want
provably buggy programs to be flagged, static type advocates appearing
to say that run-time errors are guaranteed impossible.

> Also, in an evolving system, providing static information that turns
> out to be incorrect may be more costly than if we didn't bother to
> encode that information explicitly (an arguable point).

Any time you ask someone to provide redundant information, you strictly
increase the error rate.