Re: measuring dynamic vs. static typing effectiveness

[Tom Lord <address@hidden>]

It's pretty messed up that people try to debate issues like
type-checking in the abstract and in absolute terms.   

Programs are always written and programming languages are always used
in some design context whose characteristics shouldn't be ignored.

Debating (or trying to design experiments about) "static vs. dynamic
type checking" with no further qualification is a bit like trying to
decide:

	Which is better as a construction material: granite, lumber,
	brick, mud-and-straw, reinforced concrete, steel, aluminium,
	or popsicle-sticks?

The answer is, of course, "yes".

In that light, and in my opinion, the most interesting lines of
thinking about type checking _from_the_language_design_perspective_,
are the ones that try to synthesize the options into a coherent goal:

Can I have a programming environment that gives me complete freedom to
choose between dynamic and static type checking in a fine-grained,
seemless way?  Will it provide the best forms of both that we know of?
Does it generalize static type checking so that it's able to check
other staticly provable characteristics of my program?  What does this
cost in terms of language definition and implementation?

It's not very surprising that I can write a "soft checker" for lisp or
a lisp-like union-type for ML.  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."

-t