[Types-sig] Static typing considered HARD

[Uche Ogbuji]

Paul Prescod wrote:

> Here's the problem: in Visual Basic, Java, ML  and other languages I am
> most familiar with, compilation is conceptually three pass:
> 
> * parse
> * "resolve names to type/code/variable references"
> * execute

This seems all out of whack to me.  First of all, symbol-table
management may or may not belong to the "parse" step, depending on your
preferences.  The Dragon book ducusses this matter in good detail.  I
don't know about VB, but Java and C/C++ certainly merge your steps 1 &
2.  C/C++ also does not have "execute" as any recognizable part of
compilation, unless you mean cpp and template instantiation.  I don't
think Java has "execute" as part of compilation either.  ML, at least
the version I used a few years ago, is something of its own breed of
fish.

> But in Python, type objects only come about *through* the execution of
> code. This makes Python incredibly dynamic but it also means that the
> question of what exactly static type checking means is confused. Simple
> example:
> 
> import sys
> 
> if sys.argv[0]=="weirdness":
>         from foo_mod import foo_class
> else:
>         from foo_mod2 import foo_class

This is the sort of thing that gives Python its power, and it is the
sort of thing without which I'm not sure I wouldn't be considering
another language.

> One could imagine that in some Python 2, import statements and class
> definitions could be limited to being at the top, before "code". There
> might be some special syntax (e.g. __import__, __define_class__ ) for
> doing module-loading and type definition at runtime. Still, I don't
> consider that something for the types-sig to work out. My personal
> opinion is that it would be a Good Thing for Python to become a tad less
> dynamic in the "core syntax" in exchange for compile-time checking of
> names.

This is exactly the sort of idea that terrifies me about Python 2, as
I've done a poor job of expressing before.  My hope is that Python 2
remains Python, and such artificial constraints as "imports only at the
top" and all that in order to satisfy IMHO mis-placed notions of type
safety are dropped in the nearest dustbin.

> Note that in a lot of ways, Java is "as dynamic" as Python. You can
> introduce new functions and classes "at runtime." The difference is that
> Java's syntax for doing so is brutally complex and verbose so you are
> disinclined to do it.

No! No! No!  If you are talking about Java reflections and
introspection, I have no inkling how these features lend it even a
modicum of Python's dynamicism.  Note that Python's true introspection
and dynamic typing is one of my most powerful tools in converting Java
programmers to the language.  I have heard Java described as
"programming in a straight jacket".  That is a very accurate
observation, and the precise reason I don't want Python to even start in
that direction.

> I think that there must be a middle ground where
> our "default semantics" are static but it is easy enough to do dynamic
> things (e.g. foo_mod = __import__( "foo.py")) that we don't feel
> burdened.

I'll look out warily for the sort of middle ground in question.  If it's
something such as "imports only at the top", I guess I'll just have to
scream blood and bile.

> Even if we ignore static type checking Python 2 really has to do
> something about the "misspelling problem." One extra character on a
> method name can crash a server that has been running for weeks. Once
> this problem is fixed, the term "static type checking" will become
> meaningful. In the current environment, it is probably not and thus
> should not be the first focus of a new types-sig.

I keep hearing this sort of thing, and I keep saying that it's a red
herring.  Lack of static typing does _not_ prevent Python from being
scalable to large-scale and production environments.  Our experience at
FourThought, where many of our projects are small-enterprise systems
built with Python and sometimes CORBA, will make it very hard for anyone
to convince me so.  I think the experience of users such as eGroups
supports my feeling.  If anything, it is Java that I think is
tremendously over-rated for large-scale projects and I predict its
failure in that space will soon be an industry scandal.  I also don't
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.


-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org