Re: dynamic vs. static typing

[Pascal Costanza <address@hidden>]

On 9 Dec 2003, at 5:41, Anton van Straaten wrote:

> Responding belatedly - been busy:
>
> On 30 Nov 2003, at 4:46 PM, Pascal Costanza wrote:
>> On 26 Nov 2003, at 20:08, Anton van Straaten wrote:
>>
>>>> One of the things I don't like about Smalltalk is that there
>>>> is quite some information that I know when I'm coding, but
>>>> don't (can't) tell the program about.
>>>
>>> This is one of my big objections to "pure" dynamic typing.  If
>>> there's information that I want to be able to express in my program,
>>> that I can't reasonably express, that's a limitation that I don't
>>> like.
>>
>> ...but you can always add assertions to express your intentions, can't
>> you?
>
> You're right that assertions will express intentions, but there are a 
> number
> of problems with them.  First, in some languages - particularly in 
> dynamic
> languages - they can't be disabled, so you may take a runtime 
> performance
> hit for using them.  This can inhibit their use.  Certainly, DT 
> programs
> tend not to make nearly as many assertions about types as they could.

I'd say that these things are orthogonal to the ST vs. DT issue.

> Secondly, in languages where you can disable assertions at runtime, or 
> if
> you decide to use a global flag to determine at runtime whether an 
> assertion
> should be checked, you run into a potentially worse problem: deciding 
> which
> assertions to disable, and which to leave active.  It's quite possible 
> to
> have an assertion for some condition, decide to disable it because it
> doesn't trigger during testing, and then experience subtle bugs that 
> would
> have been detected and reported by an assertion, had it not been 
> turned off.
> Leaving all assertions on, all the time, may not be an option, for
> performance reasons.

I wouldn't expect this to be a big problem. It seems to me that most 
performance problems come from localizable bottlenecks, and that it is 
sufficient to only tweak the involved code to get good performance 
after you have identified with the help of a profiler. At least that's 
what's reported very often in different places.

> Finally, of course, assertions in a DT language don't give you any 
> choice
> about when they can be run.  I'd be quite happy with a DT language 
> which
> could analyze at least some of my assertions statically and tell me 
> things
> about them.  In fact, that's what I've been advocating.

Then we're in strong agreement. A static type checker as an optional 
tool would be great, but only if it's possible to override its 
"decisions".

Phew! ;)


Pascal

--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."