[Types-sig] Static typing considered HARD

[David Ascher]

On Sat, 4 Dec 1999, Uche Ogbuji wrote:

> Is their problem performance or defect-management?  Again, there is an
> important difference.  I agree that typing can help the former: I am
> doubtful that it is a panacea for the latter.

The latter.  The quote (paraphrased from memory) is "When someone changes
a function interface, there's no way to know if we've caught all of the
calls to that function in the tens of thousands of line of code that we
have except to run the code'.

Note that I don't think anyone is arguing 'panacea'.  Just 'we could do
better'.

> > I see two very distinct problems, though -- one is the use of 'statically
> > typed variables', which requires fundamental changes to Python's
> > typesystem. The other is 'compile-time type/signature/interface checking',
> > which could probably be done coarsely with add-on tools without changing
> > the syntax or type system one iota (ok, maybe one or two iotas).
> > 
> > > see this "misspelling" problem.  Proper configuration-management
> > > procedures and testing, along with intelligent error-recovery, prevent
> > > such problems, which can also occur in the most strongly-typed systems.
> > 
> > Wouldn't you agree that enforcing these 'proper procedures' is much harder
> > in a language which doesn't do half the job for you?
> 
> 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.

IIRC, JimH mentioned in the early part of his talk (before it got heated)
a system which allowed one to change whether a particular symbol could be
considered 'static' or not, and suggested what seemed to me reasonable
defaults, like the names of builtins being considered 'known' at
compile-time.  With two new syntactic mechanisms called e.g. 'freeze' and
'thaw', one could maintain exactly the same dynamicity, while allowing the
user to 'tell the compiler' that some things could be trusted not to
change in the lifetime of the program (and the runtime would enforce
those, of course).  And if you really wanted to redefine 'open', then you
still could.

In other words, I'm just suggesting that given that (I'd guess) 95% of the
code out there is such that variable maintain their type throughout the
life of the program and that the builtins don't typically get overriden,
it seems a shame not to play the numbers. And we don't have to cover all
the cases.  Just the 80% which give the largest payoff.

Another trivial example: I can never remember whether it's
pickle.dump(object, file) or pickle.dump(file, object).  I tend to
remember that I don't remember after the simulation has run for two hours
(if I'm lucky) and the saving of state fails...

--david