Adding static typing to Python

[Chris Gonnerman]

----- Original Message -----
From: <brueckd at tbye.com>


> On Mon, 18 Feb 2002, Milliken, Peter wrote:
>
> > Python also lacks features of "data hiding", it attempts to provide
> > some support for it but only in a desultory "procedural" way - try
> > this with 40 programmers and you won't get far! :-)
>
> This is silly - let me guess, your same 40 programmers also can't remember
> to document their code, they follow no naming conventions, they use global
> variables everywhere, etc, right? :) Surely, if you can somehow convince
> them to follow basic coding standards then Python's support for data
> hiding won't cause you any problems. It keeps the honest people honest,
> that's all. OTOH, if you have to babysit your developers then you're
> right, Python is not for your project. Also, you should probably fire most
> of your development staff.

The harder you try to hide the data, the more likely the programmer will
find it "necessary" to work his/her butt off to reach it.  Python's data
hiding, which might be called "by suggestion," is IMHO better because the
programmer *knows* when he/she has crossed the line, and can be prepared
to take responsiblity for it.

(If your programmers don't take responsibility, get new programmers.)

> > and the compiler won't let you do sloppy coding
>
> That's one mighty intelligent compiler! <good-natured snicker>

No kidding.  I've yet to see an automated tool to correct code; I think
I remember reading it is impossible to prove correctness in that sense.

> > Finding such bugs (misnamed variables) requires multiple runs through
your
> > test suite i.e. find a bug, fix it and re-run the tests. You *can't*
find
> > all such bugs in a single pass!
>
> Yes and, all told, that process took a whopping 2 seconds. Meanwhile, the
> compiler for those other languages has finally moved on to the link stage
> and is busy printing out 100 lines of "errors" because of your one
> misnamed variable.

Been there, done that, and the T-shirt is only available in XXXXXL (to allow
space for the error messages).  Give me Python tracebacks any day; my errors
are usually obvious.

> > True, you obviously have a large investment in your test suite. My point
is
> > that up front development time is reduced through the features of strong
> > typing.
>
> Can you give a concrete example showing this?

I'd like to see your metrics also.  Strong typing (as in "contract" oriented
design) has never been effective for me.  I learned Ada years ago (when it
was still new) and I remember fondly/have nightmares about the verbose,
detailed error dumps from the compiler.  Sure, it was nice to know exactly
where in the manual I could find an explanation of my stupidity, but doing
common activities in Ada was just too much work... I saw way too many of
those compiler dumps, and since learning Python I have found that a logical,
simple language design is the best for me.

I can put out working code on the first try many times with Python; with C,
Ada, and other more antique languages, I have always produced working code
on about the fourth or later compile.  I am pretty experienced with C, and
before Python it was my most productive language; those error-removal
iterations are pretty short for me in C.  Given a job done equally well in
either language I am probably about as efficient in either, but that is the
result of many years of C experience stacked against about a year of light-
duty Python experience... and many jobs are much simpler in Python than C.
Few if any buffer-overruns to deal with, for example.

Strong typing (in function prototypes) is for control freaks IMHO.  I used
to be one, but it's just too much work.