Flying With Python (Strong versus Weak Typing)

Alex Martelli aleax at aleax.it
Fri Mar 14 14:16:50 CET 2003


Cameron Laird wrote:

> In article <hkiba.49303$zo2.1483266 at news2.tin.it>,
> Alex Martelli  <aleax at aleax.it> wrote:
> .
>>Static typing makes it easier for the compiler to generate fast
>>code, and (depending also on other issues) may slightly enhance
>>programmer productivity by catching a small percentage of errors
>>a bit earlier than testing would catch them -- that's all.  It has
> .
> At the cost, of course, of what are likely to be
> *larger* cuts in programmer productivity through
> the overspecification static typing so often in-
> volves.

That's part of the "depending on other issues" parenthesis I had
so glibly inserted.  I think that static typing "done RIGHT" need
not imply over-specification.  However, I can think of only two
examples of such "done RIGHT" along different routes:

-- Haskell-like typeclasses: the compiler can infer the class T
   of types to which object X belongs by seeing what functions
   are called on X -- you may also optionally specify T yourself,
   in which case you also get the option to specify some T' that
   is more restrictive than T... but presumably you'll do so
   only advisedly, for specific purposes of expressing some very
   clear design intentions, not "overspecifying";

-- Dylan-like optional specification of types, which serves
   essentially to guide the compiler to generate faster code --
   if you see type-specifications as part of _optimizing_ your
   program, then, again, you presumably won't be doing it
   _prematurely_ (as we all know, per Knuth, that premature
   optimization is the root of all evil in programming) -- so
   that choosing to express a type before the optimization
   phase can, again, be taken as an explicit expression of
   some very clear design intention.

Static-typing systems that FORCE you to specify types
needlessly (as a pure redundancy to what the compiler could
perfectly well infer on its own) are subject to the specific
criticism you express -- by MAKING you (prematurely?) specify
something, they do indeed make it more likely that you'll
over-specify it, with unfavourable productivity impact.

But it would take as little as a local coding guideline to
the extent that "thou shalt specify all types rather than
rely on the compiler's type-inferencing system" (and sadly
I _have_ seen that suggested for Haskell!) to make your
criticism extend even to languages that, per see, _should_
be exempt from it.


Alex





More information about the Python-list mailing list