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

From: Chris Uppal (chris.uppal_at_metagnostic.REMOVE-THIS.org)
Date: 07/15/04 

Date: Thu, 15 Jul 2004 10:36:45 +0100

Mark S. Hathaway wrote:

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

You mean you haven't seen enough already in this thread ?!

Anyway, seizing the opportunity to answer a slightly different question...

[BTW, a bit of background. I did years of C, then years of C++, then years of
Java. I was as much of a static typing enthusiast as any. To the point of
pondering and designing type systems that seemed to me more powerful --
expressing tighter restrictions in wider semantic domains -- than the ones I
was using in those various languages. Then I started Smalltalk and have
essentially lost all interest in static typing as a way forward in language
design. Just to be clear, I'm talking here about /declarative/ static type,
type inference is a different beast altogether]

Starting with a digression. I once read someone describe the advantage of
garbage collection as that it allowed you to reason locally about object
lifetimes, whereas in systems without GC you have to reason globally. Hence
reasoning about lifetimes is harder in the absence of GC (which restricts the
space of workable designs, as well as increasing the chances of error).

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.

A small example: consider a Queue datatype. What formal type would that have ?
A first cut, expressed as a Java interface, might be:

    interface Queue
    {
        void put(Object it);
        Object get(); // assume this never fails
        int occupancy();
    }

I don't want to get into generics, so lets make it more concrete:

    interface JobQueue
    {
        void put(Job it);
        Job get();
        int occupancy();
    }

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

    interface Puttable { void put(Job it); }

    interface Getabble { void get(); }

    interface JobQueue
    extends Puttable, Gettable
    {
        int occupancy();
    }

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:

    interface Puttable { void put(Job it); }

    interface Getabble { void get(); }

    interface Moniterable { int occupancy(); }

    interface JobQueue
    extends Puttable, Gettable, Moniterable
    {
    }

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

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

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

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.

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.

    -- chris

Relevant Pages