Flying With Python (Strong versus Weak Typing)

[Chermside, Michael]

Hasoob ahs writes:
> I would like to hear from other Python programmers [whether they'd fly in
> a python-controlled airplane].
> Would you be comfortable?. Your answer may help me decide between
> strong and weak typing. I prefer an answer of yes or no followed by an
> explanation.

Hasoob, I hope the following helps answer your question.

I prefer (I think) strong (ie, explicit) typing.

I'm a BIG Python fan.

The reason that I prefer strong typing is that I tend to think about
the type of the object that I pass around. I like to have the compiler
know what types I'm using because it's something that _I_ as the
programmer knows. In a way, it's kind of like python's use of
indentation... since the programmer uses indentation (even in Java or
C), the compiler should also!

HOWEVER, after working with Python for a time, I have learned that
there are a few major DRAWBACKS to strong typing (as usually
implemented), and that the ADVANTAGES are far less than most believe.

(1) The first drawback is FAR too much typing, particularly of redundant
information! I don't mind the typing itself, but the huge amount of
text needed to declare every type every place can obscure the actual
code (and easier-to-read code is better code!). Consider these:

     // Java example
     public int countBlueWidgets(List widgets, int min, int max) {
         Iterator iter = widgets.iterator();
         int i = 0;
         while (iter.hasNext() && i < min) {
             i++;
             iter.next();
         }
         int count = 0;
         while (iter.hasNext() && i < max) {
             i++;
             Widget w = (Widget) iter.next();
             if (w.isBlue()) {
                 count++;
             }
         }
         return count;
     }


     # Example in Python
     #  assumes java-style iterator for consistency (perhaps it's in jython?)
     def countBlueWidgets(widgets, min, max):
         iter = widgets.iterator()
         i = 0
         while iter.hasNext() and i < min:
             i += 1
         count = 0
         while iter.hasNext() and i < min:
             i += 1
             w = iter.next()
             if w.isBlue():
                 count += 1
         return count

If you read the java code, it's pretty clear what types "i" and "count" are.
In fact, the only types I have the least bit of uncertainty over are those in
the function signature -- what is "widgets" supposed to be? Knowing that,
the types of "iter" and "w" are pretty obvious too. It's not helpful for
the programmer to be constantly having to state the obvious. The following
example illustrates what _I_ think is actually _useful_ from the java
type declarations -- the rest can be deduced by the compiler, and the reader
(see Haskell for a language which works pretty much like this):

     // Example in imaginary "typed" python/java mix
     def <int> countBlueWidgets(<List[Widget]> widgets, <int> min, <int> max):
         iter = widgets.iterator()
         i = 0
         while iter.hasNext() and i < min:
             i += 1;
         count = 0
         while iter.hasNext() and i < min:
             i += 1
             w = iter.next()
             if w.isBlue():
                 count += 1
         return count


(2) Earlier I claimed that the ADVANTAGES of strong typing were far less
that most people believe. Of all the kinds of bugs in the world, it only
helps you with one sort... the bugs where you use one type when you should
have used a different one ("does that method take an Account object, or a 
String containing the account id?"). While this kind of bug is pretty easy
to make, it's also REALLY easy to find and fix... because if you get it
wrong things will simply NOT WORK. If I were doing lots of refactoring,
then having typechecking might help out (but a refactoring tool would help
LOTS MORE), and if my testing were so poor that there were paths of execution
that I never bothered to execute, then typechecking might help out, but
if that's the case, then what I REALLY need is better testing!

And besides which, lots of popular languages hardly ever use strong typing,
and we never seem to have this kind of bug in those languages. Take Java
for example. If you'll examine my java example above, you'll see that the
list is declared as a "List", not (as in my imaginary example) a 
"List[Widget]". Now, they keep promising that someday they may fix this
flaw in Java, but in the meantime there are hundreds of programs out there
using the collections library, which is declared to simply contain
objects. Not only does this require stupid casts like this one:

       Widget w = (Widget) iter.next();

but it means that the compiler really isn't checking the types of all those
objects in the list (and in any serious program, nearly ALL objects live
in data structures rather than in local variables -- Java uses strong typing
only in the trivial cases!). The list could have contained SpamEater objects 
instead of Widget objects, and the code would have blown up. Of course, you 
hardly EVER have that problem in java... but that's because using the wrong
kind of variable isn't a very common sort of mistake.

(3) Finally, there are other disadvantages to strong typing that go further
than mere syntax annoyances (like extra typing). The most important of these
is that you lose the ability to "fake out" the code by passing in an object
which behaves "mostly like" the expected object, but isn't one. There are
a surprising number of places where this is handy: mock objects for unit
testing, working around bugs in libraries, extending the abilities of
existing code, and so forth. Using my example above, suppose you want to
go all the way to the end of the list instead of stopping at "max". One way
to achieve this (which is overkill in this simple example, but it illustrates
the point) would be to create an object called "infinity". I would be like
an integer EXCEPT that it compared larger than any actual integer. With weak
typing, you can do this, but strong typing would insist on an actual integer
object.


So my conclusion? There are some reasons why I prefer strong typing, but
these reasons are fairly trivial and unimportant -- in my estimation they
add LESS to program integrity than having a clear, readable syntax (which
contributes LOTS by allowing more effective code reviews, and fewer
opportunities for subtle syntax bugs). So YES, I would fly in a python-
controlled airplane.

-- Michael Chermside