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