Typing system vs. Java

John Schmitt jschmitt at vmlabs.com
Sat Aug 4 02:00:00 CEST 2001

> -----Original Message-----
> From: brueckd at tbye.com [mailto:brueckd at tbye.com]
> Sent: Wednesday, August 01, 2001 6:56 PM
> To: python-list at python.org
> Subject: Re: Typing system vs. Java
> On 1 Aug 2001, Donn Cave wrote:
> > | Right. My assertion is that this causes more problems 
> than it solves
> > | because you seldom know your "intent" in that much 
> detail, much less your
> > | future intent. Seems like ultra strict type checking 
> might work well in
> > OK, another example, happy to be able to accommodate your request.
> > >From today's comp.lang.python, someone asks, how come my program
> > doesn't work?  His case seems a ways away from space 
> station control.
> >
> ...
> > And the run time error is a TypeError: unsubscriptable object.
> > He's baffled enough by this to post to comp.lang.python instead
> > of figure it out himself.
> [ snipped 10 lines of Python ]
> [ snipped 30 - 40 lines of type-checking OCaml ]
> > Hope you find this useful.
> Very! Thank you. Here's what it shows me:
> - A Python newbie like the original poster is going to get a 
> heck of a lot
> further than an OCaml newbie trying to accomplish the same thing in a
> strict type-checking way (I wonder how many posts he would 
> have sent to
> c.l.ocaml?). A veteren Pythonista won't have too many chances 
> for causing
> that bug because the Python version will be so short and simple.

A Python newbie will probably get more done simply because it's easier to
learn Python than ML, yeah, probably true.

> - The cost of finding the Python bug (type-related or not) is probably
> quite lower than the cost of finding a bug in the same OCaml code. If
> nothing there's 66 to 75% fewer lines of code to sift through 
> so you'll
> narrow the search a lot quicker (I realize you're new to 
> OCaml, but the
> poster is new to Python).

I'm following this conversation with great interest and I think I'm grokking
everything up to here.  

As for finding this bug, well, isn't the point of ML that *the compiler
finds the bug* way before it ever gets to a customer?  I guess that assumes
that you've expressed your types correctly.  If you had not expressed your
types correctly, that would be a bug related to the semantics of their
meaning (a 'logic error' as described in an earlier post).  That is, you
knew exactly what they types mean and expressed exactly that.

> - If the function later needs to be modified to be more flexible with
> different types or even just a little extra functionality, 
> the Python one
> is gonna be a breeze. I'd feel confident about a quick change 
> followed by
> some quick testing. I'd feel much more nervous about 
> modifying the other
> one.

I'm not sure if you're being fair here.  I've only done a small amount of ML
(in school, some years ago) but your question is pretty hand-wavey and
contrived to make your point.  I much prefer coding in Python, but I
wouldn't make the claim you just made there.  How about becoming fluent in
ML and then doing a detailed analysis? :-)

> - After a little experience using Python, the cost of finding that bug
> will drop dramatically (how long would it take you, Donn, to figure it
> out? 30 seconds maybe?) as will the likelihood of that bug 
> occurring, but
> the cost of creating the OCaml type-checking version will 
> remain more or
> less constant - you'll always have to write about that much code. So
> you'll fight your way through the learning curve only to find that by
> doing so what you learned just went down in value. ;-)

Obviously the barrier to entry for ML is quite a bit higher than Python,
(are we still talking about newbies?) but the compiler will find the bug for
you if it was written ML'ically (as opposed Pythonically?) unless I am much


I withhold judgement of whether strong, static typing will help or hurt
productivity.  I'm inclined to think that The Python Way might turn out to
be more productive for the majority of programmers and for lots of
programming problems.  I don't know how you would go about demonstrating
that, and I would certainly want to be very proficient in both systems
before I felt qualified to make an assertion either way.

I don't think C and C++ (and Java, I guess) are good examples of strong,
static typing and so not really useful if you want to have a discussion
about strong, static typing.

Here's a nice article you might like to read that talks more about this
whole subject.  Be warned, the article is from a guy who wants to find a way
to add some of this stuff (typing a la ML) to Perl.  It's not a
Python-centric article.



More information about the Python-list mailing list