> I see the evolution of languages and environments needing to move 
toward  respect for the distinctions between design-time and 
compile-time and  interface interaction. I'm not sure the Smalltalk 
approach of "it's all  design time--or run-time, whatever"<s> is optimal.

This gets to the heart of the strong- vs weak-typing issue, and so let's 
address it.  The notion that there is a clean separation between 
design-, compile-, and execution time is a myth; and an expensive and 
destructive one at that.   Software isn't a concrete artifact like a 
boat or a car or an airplane.  It's an instantiation of a dynamic 
interaction with an environment.  This means paper designs aren't worth 
the disk space they're written on -- because nobody understands a 
dynamic interaction until they see it in action.  In other words, coding 
is design and design is coding.  This also means that coding never 
stops, because the environment the code executes in is constantly 
changing.   A talented programmer understands this, writes for a  bald 
environment (in other words, makes very few assumptions about what the 
environment looks like), documents his code extensively (because that's 
where dynamic assumptions are captured), and writes his code in the 
debugger -- because he's testing as he writes.  That's the principal 
insight of the late-bound programmer.

Strong typing is one of many artifacts of the early-bound programming 
universe that dominated the sixties, seventies and (through a number of 
genuinely unfortunate accidents)  persists today despite its 
obsolescence.  It's an attempt to capture dynamic information in a 
static context.  Of course it never really works -- the information just 
isn't present.  To take an example, one can I suppose declare that a 
variable is always a Stack -- but one cannot capture whether the Stack 
is empty or full, or (without hideous contortions) even what type of 
object is in the Stack.  Better to throw out the notion that one can 
statically check for any of this, and instead use dynamic checks.  After 
all, since

Stack foo

is just shorthand for

(foo isStack) ifFalse:["Throw an error"]

one might as well have

Stack <nonEmpty> <ofString> foo

as shorthand for

(foo isStack) ifFalse:[E1].
(foo isEmtpy) ifFalse:[E2]
(foo isString) ifFalse:[E3]

etc.