Adding static typing to Python

[brueckd at tbye.com]

On Mon, 18 Feb 2002, Milliken, Peter wrote:

> Rather than from ignorance, maybe it's from actual experience using it.
> Have you considered the possibility that the claims might be true? In this
> job as well as the past few our Python code has always had less time
> devoted to developing, testing, maintaining, and refactoring it. It's not
> that there's hidden costs involved - we tend to write it and move on to
> something else because it just works.
>
> Depends, "ignorance" was used in the context of "have you tried an
> alternative?". You don't provide any examples of where you have found Python
> superior over any other language development environment. So it becomes
> impossible to verify the veracity of your statement :-) I provided an
> alternative language in my statements to back up my claims :-). Since we are
> talking loose typing versus strong typing, I would expect you to respond
> with experience in a strongly typed language. The original poster used Java
> as his comparision and is wishing for the feature in Python. Necessarily he
> feels it is a deficiency in the Python language that I concur with :-)

Sorry, I didn't realize you would be so picky. :) I am speaking from
experience using C, C++, and Java. So, in my above paragraph, when I say
stuff like "our Python code always took less time to develop, debug, blah,
blah" it is obviously in relation to another language, otherwise it
couldn't be less now could it? Also, to be picky, we are talking about
static versus dynamic typing, actually. :) Python is strongly but
dynamically typed.

> also depends on your definition of "large", my definition of this is several
> million lines of code - co-ordinating enough programmers to produce this
> level of effort in a reasonable time can be quite a challenge :-).

Very true, but several million lines of C++ might very well be several
hundred thousand of Python, so be careful in the comparison. A Python
program several million lines long may very well be the largest and most
complex program in the history of the world.

> "Contractual" type interfaces between modules helps a lot - something else
> that Python lacks (IMO) that is useful for "large" projects.

It might be useful, sure, but you can certainly have contractual
interfaces without having the language force your obedience. On any large
project there need to be published interfaces between the various
components, and someone not adhering to the interface is both an easy and
quick find, in most cases.

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

> This level of discussion has occured in the past and
> people have disputed every one of these points - again, relevant experience
> is important, the argument generally tends to the dismissive without
> offering any supportive experience

Excellent point! When, exactly, did Python's "weaknesses" that you
describe cause your big project to fail? Was it when the team grew from
one dozen to two dozen developers, or was it when the LOC exceeded 100k?
Please be specific. :)

> i.e. "I used data hiding features of
> language X for Y+ years on projects that were over Z programmers large and I
> never missed it once I moved to Python".

I used the data hiding features of C++ for about 8 years on projects that
were over 40 developers large and I never missed it once I moved to
Python. Before that I was mainly a C and assembly programmer and (getting
back to the point), I found C's type system to be more of a hinderance
than a help.

> The meer fact that you are referring to "this job"  and the "past few" means
> that (to me :-)) you haven't worked on a "large" project (by my definition).
> This many of my "large" projects cover a span of 10 or more years!

Congratulations. Please re-read my post: "this job" and the "past few"
refer to the ones in which I have used Python for production code. I
should also point out that a huge percentage of "large" projects that
cover a span of so many years is because they take so long to get into
production that they are no longer relevant. :) I've been on those, and
while you are in many cases guaranteed a permanent job because of it, it
doesn't make it fun.

> Strong typing forces design up front i.e. it forces you to think through the
> problem rather than just start coding - so it would be an anathema for

Ahhh... so as far as software goes, the best and most bugfree code would
therefore be in assembly language as it would require the most
forethought! The amount of design you do, before and during, is
proportional to the size and complexity of the project, regardless of
language. This really has nothing at all to do with static typing at all.

> and the compiler won't let you do sloppy coding

That's one mighty intelligent compiler! <good-natured snicker>

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

> You also have to find it through (often) painstaking use of the
> debugger or print statements.

No: most of the time you'll see it in the traceback, which is
automatically printed for you.

> are *never* involved! Running the same test over and over again to get these
> levels of bugs out is clearly more inefficent than using a compiler. So
> where your process may take possibly hours, I'm talking about minutes to fix
> and recompile :-).

Well, since you earlier thought I had no experience, I'll risk doing the
same thing here: I have never, ever had this process take more than a few
minutes, and I'd wager that 99% of the time it would be more easily
measured in seconds. It really sounds like you are letting your mind get
worked up over a theoretical problem that you have never actually
encountered. I apologize for being blunt, but it just ain't so. :)

> Might be true for lots of people, but nearly every single Python module in
> our company's code has either built-in or accompanying tests that run
> every night. The same is true for our non-Python code. The dynamic or
> static typing of the language makes little real difference - if you don't
> test, you overlook bugs, pure and simple.
>
> 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?

> by that background. The original post states that the typing of Java was
> perceived as a distinct advantage, so presumably the level of type checking
> there is enough to request the feature in Python.

Ugh! Probably the worst change that could happen to Python would be to add
a static type system similar to that in Java. Yes, I have used it, and yes
it really does hurt that much. It adds complexity and confusion and longer
compile time, and yet runtime type errors can still occur.

Have fun Pete,
Dave