Inefficiency of __getattr__

[Alex Martelli]

"Kragen Sitaker" <kragen at dnaco.net> wrote in message
news:NpzC5.1605$l52.81889 at news-west.usenetserver.com...
    [snip]
> So what's the advantage of static typing over dynamic typing?  Does it
> help you catch bugs, and if so, which ones?

It helps catch some type-related bugs -- particularly in areas
of the code that it's hard to ensure are wholly tested because
they deal with rare/exceptional/abstruse conditions.  Even for
bugs one would catch anyway in testing, it does help by letting
you do the "catching" earlier -- costs are lower the earlier
you catch the bugs.

It also helps your compiler generate better code.  And, your
source can be more expressive, as it states certain things that
you know about your code, in a precise and unambiguous way.

Whether these undeniable gains are worth the various components
of bother that static typing just-as-undeniably adds, is of
course The Question.  I come from a background of mostly static
typing, but over the years I've never entirely lost track of
the dynamic-typing world, and from a LOT of relevant experience
in both camps I have come to be pretty convinced of two things:
    -- the whole song-and-dance of mandatory strict static typing
        where the programmer has to specify everything statically
        is far too much to pay for the benefits; this means Eiffel,
        C, C++, Java, Pascal, &c;
    -- having NO way to specify static typing in the language,
        even where one would DEARLY LOVE to do so for any of
        the possible benefits, is going too far in the other
        direction; this covers Python, Scheme, &c.

I think the optimal solution will have to include:
    -- type INFERENCE: the compiler is able to INFER types when
        feasible
    -- OPTIONAL static type annotation: the programmer MAY, IF
        AND WHEN HE OR SHE WISHES, specifically denote the type
        (or rather 'typeclass', in the Haskell sense...) that a
        give object reference must have at some point (just as
        he or she may, if and when desired, specifically denote
        other semantic constraints); this extra, optional info
        will be usable in various ways depending on development
        mode/stage:
        -- when the explicit denotation is contradicted by the
            inference, a compile-time error result
        -- in debugmode, runtime checks are added to verify the
            explicit denotations (possibly giving exceptions)
        -- in optimizemode, the compiler can rely on the explicit
            denotations (as well as its inferences) and deduce
            any possible optimization from them
        -- warnings and advice can optionally be given by the
            compiler to prompt the programmer to add denotations
            where this would be of greatest help if possible

Haskell is already pretty good at this -- it does have fully
static typing, but this is only a moderate hassle thanks to
its wide use of inference, polymorphism, and typeclasses. Dylan
points the way to get there from the fully dynamic side of
things, with explicit denotations being really optional (and
fully-dynamic typing available when wanted) and mostly used
for optimization or clarity.  I know of no language where
"belonging to a type" (or class/typeclass/etc), "satisfying
a certain contract" (in the Meyer sense), and other kinds of
"assertions" (explicit denotations), are handled as seamlessly
and smoothly as I would love them to be; e.g. where, when
writing or editing a function, I can just as easily and
productively assert of an argument "...and this meets the
OrderedNumeric typeclass constraints" as I can assert "...and
this is positive, odd, and not exactly 1 more than a power
of two" (should I happen to know this specific and peculiar
bag of facts about the characteristics of the argument I
expect:-).  Eiffel and Sather perhaps come closest on this, but
these "contract clauses" only really apply "at the interface"
of modules (objects) in those languages, while their (static)
typing applies more pervasively, so they're not equivalent
and "seamless"...


Alex