[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dynamic vs. static typing
"Anton van Straaten" <firstname.lastname@example.org> 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.