Adding static typing to Python

[Milliken, Peter]

-----Original Message-----
From: brueckd at tbye.com [mailto:brueckd at tbye.com]
Sent: Tuesday, February 19, 2002 11:54 AM
To: Peter Milliken
Cc: python-list at python.org
Subject: Re: Adding static typing to Python


On Tue, 19 Feb 2002, Peter Milliken wrote:

> The loose typing of Python is perceived as one of its big features :-).
> There are regular discussions on the usefulness of Python for "larger"
> projects. Many claim that they use it without any problems

I'm one of those people who like to make those sorts of claims. :)

> - I suspect that
> it is from a background of ignorance and lack of metrics

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 :-)

There is no dispute from me that Python is the best environment for certain
situations - the library support alone is worth a very great deal! :-) A lot
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 :-).
"Contractual" type interfaces between modules helps a lot - something else
that Python lacks (IMO) that is useful for "large" projects. 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 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 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". In which case such opinions become
almost meaningless in the argument.

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!

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
Extreme Programming advocates! :-) (please, no argument here, I have
probably got the idea of Extreme Programming wrong - I really don't care,
from what I have seen described the style doesn't suite me :-)). Because you
are "forced" to design up front and the compiler won't let you do sloppy
coding then you tend to write it and get it right the first time - then you
move on :-)

> The only way in Python to find these is through (exhaustive) testing -
> such rigorous testing *requires* you to develop an exhaustive test
> suite that is capable of running periodically i.e. nightly etc to
> catch such errors.

The current state of software development is that large programs need
exhaustive and rigorous testing anyway. The reason that the loose typing
doesn't kill you is that good testing finds misnamed variable bugs like
you cited above as well as bazillions of other bugs.

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! You also have to find it through (often)
painstaking use of the debugger or print statements. With a strongly typed
language, you can (often :-) I know there are exceptions :-)) do it in a
single pass with a compiler - definitely the debugger and print statements
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 :-). 

> Whether the people who support Python for larger projects have the
> discipline within their project team to maintain such an effort is
> unclear - there has been no mention of it at all.

Really? Good testing comes up every single time this topic comes up, and
invariably people talk about how they *do* write tests for their code, and
how good testing helps them find all sorts of bugs.

You also never see anyone talking about testing the test code :-) -
something that is constant with any language :-) But the same scale of
efficiencies apply to the test code as the production code.

> So I doubt that the proponents of Python in these instances have any
> idea of the true cost of this language "feature" - they appear to be
> wound up in how quickly they can produce a working prototype (or
> whatever) so I suspect their day to day work involves very small,
> manageable projects where the lost efficiency due to loose typing
> isn't really that noticable for them i.e. they "live with it" :-).

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. Doesn't matter what language is used, test suites are still required
to ensure that accidental changes aren't introduced.

> When I compile a Ada program cleanly I know that 95% of the bugs are out
of
> it - before I even start testing! :-) Of course, it takes me longer to
write
> up front but overall development effort (in my subjective opinion - since
I
> have no metrics :-)) is that it is much lower.

Whatever floats your boat, I guess. Very few of my bugs (in any language)
are things caught by a compiler and if anything, the warm fuzzies because
the code compiles is often a false sense of security. The 95% seems very
high, even considering Ada's strictness - to that I'd say that with Python
95% of the bugs never make it into the code in the first place. :)

Then you haven't tried a strongly typed language :-) I have tried both,
which allows me to speak from some knowledge :-) I haven't tried any other
strongly typed language than Ada, so my statements are necessarily limited
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. 

Have fun,
Dave

You too mate :-)
Peter