Typing system vs. Java

[Christopher Barber]

<brueckd at tbye.com> writes:

> > >  For example, if I need to store a list of points and color
> > > values I can't just make an array of (x,y,color) tuples. I need to
> > > create a class to hold them and then create instances and store them in
> > > an array or Vector.
> >
> > You seem to be complaining about the lack of tuples, not static type-checking
> > per-se.
> 
> Hmmm... no, because in Java, for example, to store something in the
> container (be it tuple or whatever), the container would have to be
> declared as one that can contain my type of object, and to get my object
> back out I'd have to explicitly state what it is. 

Ok.  You are complaining about lack of tuples AND parameterized container
types.

> want to store the integer 5 in a Java Hashtable, you can't just stick it
> in there, instead you do a "new Integer(5)" to create an Object
> descendent that can be stored in Hashtable. Then to get it out:
> 
> int foo = ((Integer)myHashTable.get(someKey)).intValue(); // bleh
> 
> What's the value-add of strong typing here?

Nothing.  It only does you good if your type system is good enough.  If you
have to resort to runtime casts then it does not buy you anything.
 
> > do not have a good code coverage tool.  If the compiler can catch a type error
> > for me at compile-time, that is at least one less unit test I have to write.
> 
> How so? The type checking imposed by compilers like Java don't seem to
> solve any real problems - all they do is free the compiler from blame:
>
> Vector v = new Vector();
> String s = "hi";
> v.addElement(s);
> Integer i = (Integer)v.elementAt(0);
> 
> 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.

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

Besides providing compile-time type checking, this allows the compiler to
generate much better code than it could otherwise do without the type
information.

> Others on here have pointed out that using C++/Java as an example of a
> strongly-typed language is a mistake, so maybe my opinion is closer to
> "the typing systems in C++ and Java tend to cause me more work and
> problems" and not strong, static typing.

Perhaps.  I also would not paint C++ with the same brush as Java since it also
has parameterized types.  C++ is weak in other ways in that you can use casts
to subvert the type system.

> > for you.  It would really be nice if Python could add some sort of optional
> > type declarations.  It should be technically feasible.
> 
> I don't think the technical feasability is the main thing keeping them
> out. Can you help me better see how the value outweighs the cost? (I'm not
> saying the value is 0, only that for me the cost has always *seemed* to be
> greater than the benefit.

The cost must be paid by whoever designs and implements such a feature.  Users
would not have to use it if they don't want to.  At least one benefit would be
that anal programmers like myself would be more willing to consider using
Python for critical projects.  Adding type declarations would also allow
significant code generation optimizations.

- Christopher