Typing system vs. Java

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

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

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

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

-Dave