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
|