[Types-sig] Static typing considered HARD

[Uche Ogbuji]

David Ascher wrote:
> > > 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.
> 
> Actually, I think you've picked the wrong example here.  The engineering
> manager at eGroups is frustrated at his inability to check their Python
> code at compile-time, and it's not an accident that Scott Hassan (CTO of
> egroups) coauthored with another eGrouper the pylint type-checking tool
> they announced a few weeks ago.  Typechecking at compile time is a huge
> issue for them.  (Interestingly, as of a few months ago, Python wasn't
> their bottleneck -- their DB system was).

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.

> 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.


-- 
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