[Types-sig] Static typing considered HARD

[David Ascher]

On Sat, 4 Dec 1999, Uche Ogbuji wrote:

> David Ascher wrote:
> > > No language that I know of does even a tenth of the job of configuration
> > > management, error-handling or testing for anybody.  They are not matters
> > > for a programming language to address.
> > 
> > I guess we'll have to agree to disagree.
> > 
> > I've been doing some playing with Swing using JPython.  Because it's
> > wicked slow to start, (due to Java mostly) the
> > edit-run-traceback-edit-run-traceback cycle is significantly longer than
> > with with CPython.  That's when I curse the fact that the compile-time
> > analysis didn't catch simple typos, trivial mistakes in signatures, etc. I
> > *love* Python's dynamicity.  But mostly I use its 'wicked cool' dynamic
> > features, like modifying the type of a variable in a function call or
> > changing the __class__ of an object once in a very blue moon.
> 
> I can agree to disagree as well as anyone, but I'll confess I'm still
> baffled at how you claim that any language automates configuration
> management, error-handling or testing to any significant extent.  I
> guess we'll also have to agree to not understand each other.

I'm unsure all that you mean by 'configuration management, error-handling
and testing'.  All I'm pointing out is that I, others doing large-scale
systems (e.g. eGroups) and many of my students all complain that Python
isn't doing 'as much as it could' in the area of compile-time type
checking and signature verification.

> Also, I don't think I've _ever_ done anything as off-the-wall as
> "modifying the type of a variable in a function call or changing the
> __class__ of an object".  I hope this isn't anyone's benchmark of
> Python's dynamicism.

Just in case it wasn't clear, what I meant by 'modifying the type of a
variable in a function call' is:

  def a(x):
    x = len(x)

The point is: Python is extremely dynamic, and those are extreme examples
of this dynamicity.  When you expressed quite strong reactions to Paul's
proposal to add static types, I wanted to point out that there are things
which could be done which would alleviate some of the problems that many
folks are having in doing programming-in-the-large (and in-the-small as
well), while not hindering most programmers most of the time (what was it
P.T. Barnum said? =).

Let's try a different approach.  What is your benchmark of Python's
dynamicity? What aspects do you care about keeping?  Not modifying the
__class__, that's clear. What, then?

Or is it the syntactic lemon (opposite of sugar?) which lurks behind some
static typing proposals which got you worried?

> I program in Python perhaps 40 hours a week, and have done so for a long
> time.  Most of what I work on are large-scale systems.  Very strange
> that my typos (and they are legion) are much less catastrophic than your
> own.

Ah, well, probably you're just better at it than I am.  =)

My programs are typically small and run for a long time.  They also change
ten times daily due to the changing nature of the requirements.  There is
no 'finished' program in my current line of work.  Just a different way of
doing business.  Note that developing a test suite for this sort of code
is unrealistic.  I'm paid to do science, not to do regression tests, and
the regression suite is likely to be longer and buggier than the actual
code.

Perhaps it's best if we took this off-line though -- I think we're
straying from the types-sig charter.

--david