[Types-sig] Static typing considered HARD

[Paul Prescod]

Uche Ogbuji wrote:
> 
> 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.  

Yes, in terms of implementation, but no, matching names to objects is
not the responsibility of the parser. It is conceptually another layer
that works on the output of the parser. Whether it works on a complete
parse tree or incrementally is another issue.

> C/C++ also does not have "execute" 

Sorry, I didn't mean to talk just about compilation. I was talking about
the whole path from raw text to executable code. I need to talk about
the whole path because Python does name recognition at runtime.

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

Nobody is suggesting that we take those features out.

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

What can you do dynamically in Python that you cannot do with
reflections and introspection? I've written "map", "apply" and the Y
combinator in Java so I'm pretty confident that the issue is really just
syntax and ease of use, not capabilities.

You could prove me wrong by showing a Python programming pattern that
could not be straightforwardly duplicated using Java reflection.

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

You can build large-scale and production environments in TCL or Basic if
you are dedicated enough. The question is whether the language is
working with your or working against you. It seems obvious to me that it
is not too much to ask for a language compiler to help you avoid
mistakes at least the same degree that PowerPoint does.

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

So in Java I find spelling mistakes by typing:

"javac foo.java"

and in Perl I find them by typing:

use strict

perl foo.pl

and in Python I find them by hiring a team of testers to test every code
path (perhaps through a GUI), find bugs, report them through a
bugtracking system and have developers work on the reports. Does this
sound competitive?

I am teaching Python today to XML people. When I got to the attributes
part the first thing they caught onto (without me hinting) was that
spelling mistakes could go undetected for weeks. One student said that
if I knew someone "on the inside" I need to talk to them about it
because it is a major problem for him. Another student said that in
another dynamic language they used, misspellings were 60% of the bug
reports from users in the field.

Yes, testing is important, but if you elevate it to the status of "any
bugs not caught are the fault of testers" then you get to the point
where the language takes no responsibility at all. That way lies Perl:
"oh, didn't you WANT me to convert that boolean to a socket object for
you? You should have tested better." If that's our mentality, Python
throws way too many exceptions for problems it could silently leave to
testers.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Math -- that most logical of sciences -- teaches us that the truth can
be highly counterintuitive and that sense is hardly common.
	K.C.Cole, "The Universe and the Teacup"