Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management

From: Mark S. Hathaway (hathawa2_at_marshall.edu)
Date: 07/15/04 

Date: Thu, 15 Jul 2004 12:44:21 -0400

>>>Also from "dynamic people" I *do* expect examples of useful type
>>>operations with proofs that having them would lead to loss of static
>>>checkability here and there. So far their argumentation is like we need
>>>no 2, because we do not like it. Further, I saw no advances in 1 made
>>>by dynamic languages, which in the end were not adopted by statically
>>>typed languages.

>> Mark S. Hathaway wrote:
>>
>>"because they don't like it"? or because they don't feel it's
>>necessary, given their other language features?
>>
>>C'mon SmallTalk foks, chime in here! We want to know how you
>>feel about this debate over the necessity of static type-checking.

> Chris Uppal wrote:
>
> You mean you haven't seen enough already in this thread ?!

I just want a crystal clear conversation, narrowed down to
one crucial issue. And, besides, my tiny little brain doesn't
always grasp these things without great effort. :-(

> Anyway, seizing the opportunity to answer a slightly different question...
>
> In a similar way, declarative typing (at least in the languages I'm ever like
> to be paid to work in) has a notion of /the/ type of an object. And, unless
> you put in quite a bit of extra work, the places that use an object ("send
> messages" to it) will tend to refer to /the/ type. In the end the type of an
> object is, in some way, the sum all the interactions it can participate in -- a
> global concept.
>
... example snipped

BTW, do you realize you now have me saying "the" as though
it's some foreign word, in every sentence. It's *the* thing.
*The* thing is that *the* blah blah blah. :-)

> we've arrived at a type expressing a coherent "package" of functionality by
> considering all the uses that client code will wish to make of these objects.
> We've been reasoning globally.
>
> Now, in Smalltalk or any other dynamically typed language (or indeed in some
> non-declarative static type systems using type inference) we wouldn't ever have
> to do that. Most applications that make use of a queue can be decomposed into
> producers and consumers. The producer only uses put(), the consumer only uses
> get(), so -- reasoning locally -- we only need to know that the object in
> question has the relevant method. Now we can translate the result of that
> local reasoning into Java (that's always possible, provided we allow arbitrary
> retro-fitting of interfaces to existing classes and interfaces):
...example snipped
> The consumer would declare itself to use a Gettable, the producer would use a
> Puttable. We've managed to split down the initial global type into a
> finer-grained group of types, which allows us to reason about (and declare) our
> types at a more local level. This I see as an improvement -- we have less to
> reason /about/ (always good) /and/ we have greater flexibility.
>
> But now suppose that we want to add some load monitoring to our system. One of
> the things we want to track is the occupancy of the queue. So we add a new
> module which -- reasoning locally -- only needs to know that the object in
> question will respond sensibly to occupancy(). We can, of course, express the
> resulting type in Java:
...example snipped
> But notice that the producer or consumer might need to pass the queue object to
> the monitoring module, in which case either:
> they must be declared to take a Puttable + Moniterable (resp. Gettable +
> Moniterable);
> or:
> they must cast their Puttable to a Moniterable (!).
>
> In Smalltalk we want to reason locally, not globally, about types (what Thomas
> Gagne, upthread, called decoupling).

> But, to my mind, our quest to minimise global reasoning has forced us
> to a point where it is infeasible to express the resultant types in
> mainstream type systems.

Interesting.

> It's certainly /possible/ to do
> that kind of thing in Java, but in practise people largely don't. There
> quickly comes a point beyond which the extra effort of devising ever
> finer-grained interfaces, with ever more intricate interrelations, becomes
> counter-productive.

"counter-productive" or seriously breaking the actual code
by preventing genericity?

> In Smalltalk we can reason locally (informally) and it all just works (and it
> /does/ work, despite the informality -- that's the important thing to keep in
> mind).

I think Kazakov might argue with you there. He doesn't believe
it 'works' unless it's shown before-hand with static type-checking.

All those Smalltalk program; how do you avoid type-check problems?

> This is, I believe, what Smalltalkers mean when they say that Smalltalk
> "doesn't get in the way". All programmers (whatever the language) have to do
> the informal local reasoning about types (that's just part of programming), and
> in Smalltalk that's /all/ you have to do. In a language with declarative
> typing you then have to go on and deal with the mess and compromise that I've
> illustrated above

Compromise?

That's a strong word to use. But, isn't it just the price one
has to pay to have a provably correct program?

> The choice is, of course, pragmatic -- you have to balance the increased risk
> of errors and impaired expression of intent on one hand, against the
> straight-jacket of global reasoning (or awkwardness of local reasoning) on the
> other. Just to complicate matters, the weighting given to these factors will
> change depending on the application.

I think this paragraph puts the question rather well.
But, key to the answer is how much impairment is caused
by the necessity of flagging types.

> Returning to the topic of this thread, I believe that there is a growing number
> of programmers who have tried both static (declarative) and dynamic type
> systems, and who find that dynamic matches their needs better. I don't /know/
> that for sure, but it should be a lot easier to measure that than doing
> comparative productivity studies. If it is true, then we can deduce that
> either:
> there is a growing number of programmers who are /really/ stupid;
> or:
> dynamic typing is a win in many situations, and it would probably
> be a win in more situations if it were more widely applied.

But, we're not going to allow 'appeal of the masses' to settle
such an elitist intellectual question, are we?

Relevant Pages