Adding static typing to Python

[Steve Holden]

"Peter Milliken" <peter.milliken at gtech.com> wrote [after a "big lunch"]...
>
> "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 :-)
>
I don't see anything about strong typing that encourages you to define
artificial types in this way. I understand that many programmers use thisp,
thatp and theotherp to point to different types of value despite the fact
that all three lue types are pointers, which will thereforee have the same
storage requirements. But this won't force anyone to declare an "fpthingie"
type to protect them against such a mangling of backward compatibility.

Insane compiler vendors, unfortunately, can't be legislated against.

[don't add temeratures to volumes]
>
> 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.
>
My experience is more typically that inexperienced programmers tend to paint
themselves into a corner by over-zealous typeing, and must resort to
inappropriate coercions as a corrective.

> > 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 :-)
>
Post in haste, repent at leisure? Jason simply finds it difficult to believe
that you think high productivity is counter-productive.
> >
> > 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......
>
There are languages that make it difficult to write "bad" programs. I would
cite Algol 68 and C++ as probably the epitomes of such (language) design
style. Then there are languages that make it easy to write good programs. In
my experience Icon and Python are probably the best exemplars of this style.
The debate about which of these styles is preferable will probably go on for
ever.

or-at-least-until-the-heat-death-of-the-universe-ly y'rs  - steve
--
Consulting, training, speaking: http://www.holdenweb.com/
Author, Python Web Programming: http://pydish.holdenweb.com/pwp/

"This is Python.  We don't care much about theory, except where it
intersects with useful practice."  Aahz Maruch on c.l.py