Squeak-dev Digest, Vol 22, Issue 20

Andreas Nilsson wahboh at mac.com
Fri Oct 15 17:56:15 UTC 2004


Regardless of wether or not there is a clean separation between the 
processes, I'd say there's a difference.
I'd much rather be notified of an error, say a missing function, at 
compile-time than at run-time.
The fact that a compiler can't check for all errors doesn't mean that 
it shouldn't check for any errors, does it?
And don't give me the unit-tests saves the day speech, finding a 
missing function via a failed unit test takes ten times as long as when 
the compiler warns you, period.
Things usually aren't black or white but somewhere in between, and I 
don't see why the issue regarding static/dynamic should be any 
different.

/Adde

On 2004-10-15, at 01.24, Rick McGeer wrote:

> > 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.
>
>
>
>
>




More information about the Squeak-dev mailing list