Squeak-dev Digest, Vol 22, Issue 20
Colin Putney
cputney at wiresong.ca
Fri Oct 15 20:57:54 UTC 2004
On Oct 15, 2004, at 1:56 PM, Andreas Nilsson wrote:
> 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.
In many languages, there is a difference between compile-time and
run-time. In Smalltalk there is not. I'll say that again, because it's
really important to be clear about it: in Smalltalk, run-time is all
the time.
Advocates of static typing always seem to talk about being notified of
errors earlier, and how this is desirable because of the cost of change
curve, etc. In Smalltalk, that simply doesn't apply. The fact that
executing a method necessarily occurs after it is compiled is
irrelevant because compilation time is negligible. In Smalltalk, you're
running the method before a static language has even finished
compiling.
> The fact that a compiler can't check for all errors doesn't mean that
> it shouldn't check for any errors, does it?
A compiler should only check for errors that would prevent correct
compilation. Other tools might check for other errors, though.
> 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.
Not in Smalltalk.
> 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.
Nor do I. Let me head back towards middle ground by making this
distinction: I don't think static type analysis is useless, I just
don't think it should be built into the language or done by the
compiler. It's a tool that can help us write, understand and debug our
code - as is unit testing. The more tools we have for that, the better.
The problem with building typing into the language means that you're
stuck with it for ever afterwards. If you come up with a better type
system, you have to write a whole new language to take advantage of it.
When the analysis tool is optional - and hence cleanly separated from
the core language semantics - it can be replaced by a more advanced or
more appropriate system without breaking the existing code or tools.
Andreas, is this explanation helpful? II assume you joined this list
and this discussion because you're interested in Squeak, Smalltalk, or
dynamic languages in general. I'm replying to your post in the hopes of
helping you understand why otherwise rational programmers would discard
the safety of type-checking. If that's not something you find
interesting, say so.
Colin
More information about the Squeak-dev
mailing list
|