I usually lean a bit to the dynamic side (Smalltalk / Ruby / Python) on 
this subject but I can't help reacting when someone says that 
language/typesystem X is the one true language/typesystem and every 
other language/typesystem on the planet have got it all wrong.
There are things about static type checking that I miss when 
programming in dynamically typed languages, for example warnings about 
missing methods, indeed there are things that I'm glad to get rid of 
too.
In my experience it really does take longer to go from a failed unit 
test to implementing a missing method, and you're really just trading 
the compile-cycle with automatic (if limited) tests for a test-cycle 
with manually written tests or ad-hoc testing.
Putting type-checking in a separate tool could be an alternative, but 
you'd probably want  to run It when you've made a change anyway (while 
the memory is still fresh) in which case you're essentially doing the 
same checks as a compiler would, only by manually running a separate 
tool.

/Adde

On 2004-10-15, at 22.57, Colin Putney wrote:

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