Adding static typing to Python

[Peter Milliken]

"Jason Orendorff" <jason at jorendorff.com> wrote in message
news:mailman.1014098489.15429.python-list at python.org...
> Milliken, Peter wrote:
> > Strong typing requires that you design before you code (Extreme
> > Programmers beware! :-)) - therefore by the time a clean compile
> > is achieved 95% of the bugs *are* out :-) That is one of the
> > primary advantages to strong typing, it *forces* you to do the
> > design up front otherwise you will never get a clean compile.
>
> Hmm.  Perhaps you can explain this in more detail.
>

Statement is true when a number of conditions are satisfied :-) One of which
is that we are talking a non-trivial program!

Strongly typed languages encourage you to override the base types so that
you aren't forced one day (as an example) to go through all of the source
looking for places where floats are used and change them to double floats -
happened on one rather large project I worked :-) They changed the compiler
and it defined float as being 32-bit, the previous version defined float as
64-bit - caused no end of heartache as you can imagine :-)

So type'ing encourages things like defining data types that encompass the
range of values your variable is *expected* to have at the time you
design/write your code i.e. you might be talking the temperature of water -
0 - 100 Degrees Celsuis for instance. Languages that are strongly typed like
this then allow static checking at compile time i.e. the compiler will tell
you if you attempt to add a variable declared as Litres to a Variable
declared to hold Degrees Celsius. Similarly, the compiler will complain if
you attempt to assign a temperature of 101 Degrees to a variable declared
with the above limits. Ada allows run-time checking as well, so if you
somehow manage to write code that passes the static checking it will blow up
at run-time with a nice exception and traceback that tells you exactly what
and where it all happened :-)

So, if you follow this form of design approach i.e. taking the real world
objects and modelling them in your code - something I believe to be
encouraged in OO? :-) then if you make a mistake and attempt to add the
contents of two variables of differing types then the compiler will tell you
about it - doesn't matter wether they are both integers at the end of the
day, if you have told the compiler that variable 'A' is a temperature of a
certain range and variable 'B' is a volume of another range then you will
not be allowed to add them together - rather simplistic example, but conveys
the concept I hope.

Of course, a strongly typed checked language won't guarantee that such
features are used! This is always up to the programmer (I once saw a
programmer mangle his Forth code so badly it looked like his previous
language - Fortran! :-)). But if they are used then you are forced to make
sure that you stick with the "rules" as you define them via your type
declarations. So our argument here is presumptive of the features being
used - you could argue the same thing about any language feature i.e. I
could argue that the OO features of Python offer no advantage - based upon
never using them! :-)

> Are you arguing that compilers for strongly typed languages tend to
> reject ill-designed or thrown-together code?  I hadn't noticed.
>

Assuming the above, strongly type checked compilers/languages will indeed
reject ill-designed and thrown together code - it might take a while, but
eventually the programmer will back himself into a hole :-). You usually
have some form of "override" even so, so you could litter your code with
coercions (I have seen this too! :-)) but this is relatively easy to
discover, so the culprit is soon exposed.

> Surely you're not arguing that extra-productive programming tools
> are bad because they encourage the programmer to waste his or her
> own time by skipping the design step.

Sorry too many "negatives" here for me to work out what you are driving at -
I just came back from a "big" lunch, so the old brain isn't functioning on
all cylinders too well :-)

>
> Maybe this is true in some sense - since I enjoy coding Python so
> much, perhaps I'm overeager to get started?  But if so, then the
> solution is sane development practices and a touch of
> self-discipline.  Which will likely come in handy on any ten-year
> project.
>
>

Yes, sane development practices are essential on such large projects -
doesn't matter what language is used. Part of my argument is that language
features are designed and provided as further "encouragement" down the path
of "correct" practices. Typing is recognised as one of these features......

> In any case, it's not nice to pick on XP and then say:
>
> > [...] 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 :-)
>
> Blah.  :(

True, very wrong of me - my apologies :-) That was a cheap shot.

>
> ## Jason Orendorff    http://www.jorendorff.com/
>