Typing system vs. Java

[Donn Cave]

Quoth <brueckd at tbye.com>:
| 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 Perl version could be shorter yet, maybe half the lines.  So even
fewer bugs?

| - 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).

The compiler sifted through the lines of code.

| - 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.

Fine!  You'll overcome your nervousness, sit down and start coding
in those new types or whatever.  Maybe later, you'd do it with more
confidence.  But confident or not, OCaml won't let you go until you
have accounted for those new types, wherever necessary in the program.
OCaml doesn't let your confidence become a liability.

| - 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. ;-)

Perversely missing the point.  For sure, once the bug came to my
attention, it took much less than 30 seconds to find it.  But should
we count the time it took my client to get me a traceback?  The time
it the solution took getting to the client, properly installed?
If I spent extra hours wrestling with a few lines of code, and the
reward is a modest improvement in reliability, it might well be worth
it even if I don't do space shuttle gigs.  If I spent the same time
staring at my Python code, that bug might or might not jump out at
me.  Or I could test the bejeezus out of it, which would surely take
much longer, and the magic inputs to get to that bug might or might
not come up.

I don't mean to pitch OCaml here, this is about types and Python.
OCaml just happens to be the most serious type checking language
I sort of barely know, and maybe it's a poor example because the
parts that were really about type checking were sort of lost in
the noise.  (Yet that was actually part of the point - type
checking per se doesn't need to add wads of declarations.)

But your criticisms seem a little misguided.  If your point is
that Python is good for quick hacks, and OCaml isn't, fine.  I'll
buy that.  But what about type checking and serious programming?

I guess you don't want any more examples of problems type checking
could solve?

	Donn Cave, donn at drizzle.com