Typing system vs. Java

[brueckd at tbye.com]

On 31 Jul 2001, Christopher Barber wrote:

> > On 30 Jul 2001, Christopher Barber wrote:
> > > This is a bad example because the code is doing runtime, not compile-time
> > > checking.  I was talking about the advantages of compile-time checking.
> >
> > ?? Please review the example - that's compile-time checking there.
>
> No it isn't!  The (Integer) cast is not performed until run-time.

Thank goodness! I'll just remove that there and ... doh! it won't even
compile anymore. Hmm... there's actually a little of both there,
compile-time _and_ runtime checking.

> > > Here is how this would be written in Curl:
> > >
> > >    let v:{Array-of String} = {new {Array-of String}}
> > >    let s:String = "hi"
> > >    {v.append s}
> > >    let i:int = v[0]        || ERROR: can't assign a String to an int
> >
> > But what benefit have I gained?
>
> You have detected a bug at compile-time instead of run-time and you didn't
> have to write a unit-test to find it.

Take off your Curl glasses for just a moment and think Pythonically - that
is an error only because of the language-specific constraints - in Python
it's neither an error nor a problem.

My point is that, because Python is handling many of the details,
there are groups of problems that just aren't an issue here. For example,
a thorough assembly compiler might look at this code:

mov ax, 10
xor cx, cx
mov ax, 12

and say, "Hold on there! You're already using that register!", and issue a
warning. This does not, however, imply that any other language would
greatly benefit from this type of checking (except maybe internally). A C
compiler takes care of register allocation, and with it disappear a host
of related problems. Don't you think that it's possible that Python is
taking care of many of the type-related problems for you?

> The language does not force you to specify types, this would also be legal,
> but you would not see the problem until you actually executed the code:

Again, it's a problem _created_ by the constraints of the language, and/or
the division of labor between the language and the programmer. It doesn't
apply here (since we're supposedly exploring the weaknesses that _Python_
has without strict compile-time type checking.

> > The fact that the compiler can detect my breakage of the
> > language-specific rules doesn't really advance the notion that
> > strict compile-time checking is beneficial.
>
> Sure it does.  You might not believe that it is worth the trouble, but it
> clearly has some benefits.

And those benefits are? I'm still waiting for anyone to be specific about
these benefits. Someone finally brought up the
semi-automatic-integer-to-float promotion problem and maybe the potential
for some modest performance gains (thank you!), but that's about it. Each
person has to judge the costs vs benefits, but that seems like a pretty
paltry list of "plusses".

A few people have asserted that big Python programs would be unmanageable
without this compile-time checking, but it seemed like they were speaking
from other-language, and not Python, experience. Of the people who
frequent the list and have participated in large Python projects, nobody
has stepped forward and said, "we really had problems, and boy
compile-time checking would have solved problems X, Y, and Z.".

The whole reason I jumped on this thread was because I've never run into
those problems at all (in Python), and I don't think I can chalk it up to
luck or Good Clean Living. :) I was hoping someone could help me overcome
my ignorance in this area, but so far the discussion has only reinforced
this idea:

  Python's features and overall simplicity tend to eliminate or
  significantly reduce whole classes of problems, including many
  type-related problems. _Some_ strictly-,statically-typed languages
  introduce artifical complexities that cause more problems than they
  solve.

> > What is a real world problem that would not have existed if Python had
> > strict compile-time checking, and how common is such a problem?
>
> Here is a real-world problem: a developer wants to use a language with
> compile-time type checking and rejects Python because it doesn't have it.

This is pretty consistent with the whole body of arguments we've heard so
far: this feature is beneficial in other languages, so if Python doesn't
have it, Python is obviously lacking. To me that reasoning ignores the
fact that maybe, just maybe, there exists more than one solution to the
problem.

As languages evolve we generally find it a bargain to exchange a little
CPU for features that relieve developers of work and at the same time
eliminate developers' bugs. By moving from assembly to C the number of
bugs per _assembly_ line of code dropped dramatically. Is it too much to
imagine that the same does not hold true when moving on up the language
scale?

> Well, I actually used Python on a number of projects a couple of years ago and
> did spend more time than I would have liked writing tests to detect type
> consistency.

Wonderful! Can you please post some examples? Was this proactive testing
or was it triggered by problems you were seeing? If was the result of
problems, what were they?

-Dave