RE: dynamic vs. static typing

["Anton van Straaten" <address@hidden>]

Howard Stearns wrote:
> OK, how's this:
>
>    "1. Without early spellchecking, the proportion of typos which
> manifest during later stages rises significantly.
...etc.

There's no comparison, because it's quite rare that spelling errors result
in subtle semantic errors which require tracing program behavior in a
debugger (whatever spelling analogy you want to use); and running a
spellchecker at the end of the process ought to be as effective as running
it at the beginning.

> Actually, I don't really mean to pick on either side here. (I'm
> inclined to agree with Anton's desire to have his cake and eat it,
> too.)  But I do want to ridule a common tendency (as I perceive it)
> of people in our field. We pick a dogma we like based on personal
> style, and then we try to amass reasons for it without carefully
> articulating the value and context in a way that is measurable in
> a repeatable way. Heck, I'm doing it right now, because in my heart
> I just don't like static type checking and I dolike spell checking
> and hyphenated identifiers! I don't agree when Anton writes 1 and 2
> about type checking, and I do believe the same unscientific argument
> about spell checking.

If you disagree with my point (1), you may be reading something into it that
I didn't mean to say.  I wrote: "Without early typechecking, the proportion
of type errors which manifest during testing and at runtime rises
significantly."  Explanation/proof: if you have early type checking, zero
type errors of the kind detected by the type system make it through to unit
testing.  Without early typechecking, 100% of those type errors manifest
either during testing or at runtime.  I think it's reasonable to call that a
significant rise.

(2) is also quite solid: "Often, the nature of those type errors isn't
identified as clearly during testing or at runtime as it would be by a
type-checker, so they take longer to track down."  This one is based on
experience, but there are some underlying facts: in practice, without early
type checking, at least *some* type errors result in errors occurring either
in unit tests or at runtime, with causes that are not immediately obvious.
This then requires some kind of debugging process to identify the location
at which the original type error occurred.  The relative importance of these
events may be open to question, but you can't deny they exist.  There's
value in pre-empting them, if it's possible to do that without undue cost in
other areas.

I'm inclined to agree with Tom Lord: "What'd be interesting is a
demonstration of an evironment for either that really subsumes the other so
well people on both sides say: "well, heck, I'll just use that instead." "

But no-one's going to be building that demonstration if everyone's walking
around convinced that type systems have to be done in one of two opposing
ways, seeing the "other" way as something resembling the caricature that Joe
Marshall described earlier.

(Aside: Joe raised some good points about decidability in the sorts of
systems I've been advocating.  Matthias Felleisen has referred to the
difficulties in developing sophisticated type checking tools.  Maybe the
"LL" community is not the place where these things will arise.  Any hotshot
language designers out there are free to take that as a challenge. ;)

Anton