Typing system vs. Java

[brueckd at tbye.com]

On Fri, 3 Aug 2001, John Schmitt wrote:

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

Well, expressing your types correctly does not mean your program has no
bugs. I guess the debate has at least these two main parts: just what
percentage of bugs would be eliminated by correct and detailed types, and
does the effort to correctly specify them yield enough benefit to make it
worth it?

My take is that, especially in Python, type-related bugs make up an
extremely small segment of all bugs, and the examples I've seen of
specifying all that type information dramatically increase the complexity
of the source code, even to the point of possibly _introducing_ bugs.

> > - 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? :-)

That comment was based _solely_ on the added size and complexity of the
type-checking version. While I obviously can't guarantee that in all cases
my assertion stands ( like I said before, I'm no ML expert) I do know that
these rules generally hold, and that's the basis of my statement:

- more lines of code tends to mean more bugs (all bugs are human error,
all humans are error-prone, the more opportunities you create for error,
the more errors occur)
- more complex code is buggier than straightforward code (consider code
that is so obvious that it is self-documenting vs. code so complex that
the ratio of comments to code statements is > 1)
- in addition to being buggier, more code and more complexity increases
the cost of: development, maintenance, and transfer of ownership if for no
other reason than the fact that your brain has to do that much more
processing

These rules are pretty universal (when applied to humans); they don't just
apply to software development. The more details I have to manage, the more
likely I am to screw something up.

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

I didn't think we were originally, but the example posted came from a
newbie question. ;-)

> but the compiler will find the bug for
> you if it was written ML'ically (as opposed Pythonically?) unless I am much
> mistaken.

I would agree that it could find type-related bugs, and perhaps the
stricter type model expands the realm of those bugs so that more are
caught, but I don't think that any ML makes the grandiose claim that all
bugs fall into that category.

Also, it goes back to the question of just how much that costs you. You
and your business have a non-zero tolerance level of bugs (unless you're
doing some sort of formal validation of all your code). Why? Because
there's other factors like time-to-market, budgets, and so on. (For
personal programming, there's the time-to-bordem-with-this-idea factor)

How bad is it if your customer finds a bug, anyway? This discussion so far
has assumed that when your customer finds a defect it's deadly to your
business. This isn't always the case. Extreme Programming, for example, is
all about releasing early and often. It's obviously not always possible or
correct to use XP, but when you do then both you and your customers
_expect_ to find bugs, and it's okay: they find a bug, you add it to your
internal tests, and they get the fix in a few days or weeks. That being
the case, the work to add strict type checking better have a huge payoff
or you're wasting valuable development time (because you're slowing down
the development pace to build in checks for specific types of bugs, but as
soon as you release you get higher quality testing that covers all types
of bugs).

-Dave