Typing system vs. Java

[brueckd at tbye.com]

> To me, the benefit of Java or Python over Perl comes into play with
> large apps.  For my purposes (no flames please!), Perl works great for
> small scripts and stuff, but its almost total lack of typing,
> prototyping, etc. causes major trouble with larger projects.

Hi John,
Can you elaborate on this "major trouble" with some specific examples?
This is sort of straying from your original post but I've had people
tell me similar things before but I've yet to run into the problems they
feared. Maybe it's a knee-jerk reaction to all that sudden freedom and
flexibility that comes with a loosely-typed languaged?

In most jobs I've used C/C++ or Java and for me the stronger the typing
rules the more problems (and in turn bugs) it caused. I haven't sat down
to really ponder why but I have noticed a few recurring problems.

One is that stronger types introduce a lot more complexity. In Java I
spend a lot of time creating new classes just to act as simple data
structures.  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. And darn it, if I want to pull them out of the
Vector I have to cast them back to their class - even though both I and
the objects in the Vector already know what they are.

Now if I want those point/color tuples to sometimes have a color index and
other times use an RGB value, what do I do? Once again I just can't store
the correct value in there, I have to go and extend my class to take
either, or if the resulting classes are different enough I have to create
a whole new class and form both into some sort of class hierarchy. Or I
could have them both implement a common interface.  Sheesh! Too often I've
seen rather convoluted class hierarchies or next-to-worthless interfaces
because there's some functions to which different objects need to be
passed so the language forces me to relate the classes in some way, even
when it doesn't make much sense. Forcing the developer to explicitly state
that common ground really adds to the complexity - too often it forces the
developer to make design decisions he/she is not really ready to make.

Strong typing seems to prevent a very small class of errors at great
expense, and none of the errors it prevents should escape good testing
(which you should have anyway).

With Python you can add any sort of checking that you want. You can have
your methods reject objects that aren't of a certain type or that don't
have certain methods/member variables, but I just haven't seen too many
cases where this is a problem.

Like I said, I haven't devoted a ton of time to thinking about why the
weaker typing of Python is actually a huge advantage to me in large
projects, but it seems that stronger types force you to define everything
in more exact terms, thereby adding complexity and forcing you to specify
your design in more detail than you may really have.

If nothing else, for large projects the Python versions are much smaller
and simpler, and as a result are usually less buggy and easier to manage.

-Dave