Typing system vs. Java

brueckd at tbye.com brueckd at tbye.com
Tue Jul 31 02:19:57 CEST 2001

On 30 Jul 2001, Christopher Barber wrote:

> > The compiler made me stick in the cast to an Integer, but it didn't solve
> > any problems for me (the code is still wrong). The only result is that the
> > compiler can now say, "Hey, it's not my fault - you're the one who cast it
> > to an Integer!".
> 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.

> 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? The only reason it's an error to begin
with is because the language is forcing me to name the type. 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.
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? (I'm not
saying those problems don't exist - I'm just desperate for some examples
so I can understand the other side of the issue).

I guess my thinking is something like this: _if_ the language forces the
programmer to be very involved with details like type information, then
some sort of strict, compile-time checking is a Good Thing. _If_, however,
the programmer doesn't have to deal with those issues (or at least not to
the same degree), then many of the related problems go away (or are
present to a much smaller degree), and therefore the ability to check for
those problems is much less beneficial. For example, Python handles most
of the details surrounding memory usage, and as a result Python programs
are generally free from corrupted/lost memory problems, and features to
detect such problems just aren't worth as much.

The few times I've had this sort of conversation I've kind of felt that
people's reasoning was like "I use language X. Language X without strict
compile-time checking would make big programs a mess. Therefore, big
Python programs would be a mess."

I've seen big Python programs that are messy, but not much evidence that
the messiness is related to type problems (but sloppy programmers). I've
also seen big Python programs that are far easier to maintain and modify,
and have far fewer bugs, than what their equivalents would be in
"stricter" languages, so now I'm fishing for examples to show me where the
reverse is true.


More information about the Python-list mailing list