Re: Why Generics?

tzvika.barenholz@xxxxxxxxx wrote:

> > > Remember that you must always fail as early as possible! Generics
> > > turn Runtime Errors (class cast exceptions) into compile time errors.
> > > This
> > > has tremendous values.
> >
> > For this to have "tremendous value" then it must be the case that class
> > cast exceptions are being thrown in expensive-to-change code (deployed
> > or late in testing) on frequent basis. That is not my experience.
[...]
> It greatly depends on whether or not you ship your code. Of course if
> it's you who is the 'client' or someone in the next cubicle, you are
> right. But sometimes its halfway around the world.

This is something of a simplification. I agree that code that has shipped
(however far it's gone physically) has a higher cost to change than code that
has not shipped. Code that has shipped to many customers has a higher cost
than code that has shipped to only a few, or even none. Etc. But what your
analysis misses is factoring in the probability of there being a problem in the
first place. If that were mathematically, exactly, zero then clearly it
doesn't matter how far the code has shipped. If the probability is low enough
then even when multiplied by the large cost of late changes, the resulting
probable cost is low.

It is not enough to say "it would be bad if it happened", you also have to ask
how likely it is to happen before you decide what preventative measures are
justified.

As others have said, class cast exceptions are so rare that many people have
never even seen one -- not even in development code (I never have) -- so the
probability of there being one in any given shipped application is very low.
Given that multiplier, it is unlikely that there is "tremendous" value to be
found in "eliminating" them. Not unless the cost of failure is absolutely
stratospheric (hundreds of human lives, say).

BTW, if you really mean that you think this is a serious issue (I have no
reason to suppose that you do) then you shouldn't be using Java -- there are
many possible errors that it /could/ catch at compile time, but actually leaves
until runtime. E.g null pointer exceptions, infinite loops, array bounds
exceptions, illegal modification of supposedly read-only objects, etc. Not
that testing any or all of these would be without its own cost in flexibility,
expressiveness, and usability of the language, but they /could/ be tested for.
Null pointer exceptions /do/ happen in real life, yet null-ness isn't part of
Java's type system... <shrug/>

-- chris


.

Relevant Pages

  • Re: AMD planning 45nm 12-Core Istanbul Processor ?
    ... demonstrated many times here) clueless about real life practice. ... To have formal verification possible one has to have formal specification to ... software boner had just cost his high-profile publicly-traded company ... Making software immune to errors costing 1e+9$ with probability greater ...
    (comp.sys.ibm.pc.hardware.chips)
  • Stats probLems--heLLLLLP
    ... The signi cance level of a test is the probability that the null ... A group of physicians subjected the polygraph to the ... process has a xed cost of $1000 per week plus $5 for every meal ... but 33 percent of retired Canadians have debts." ...
    (sci.stat.consult)
  • Re: Why Generics?
    ... turn Runtime Errors into compile time errors. ... class cast exceptions are being thrown in expensive-to-change code on frequent basis. ... many customers has a higher cost than code that has shipped to only ... factoring in the probability of there being a problem in the first ...
    (comp.lang.java.programmer)
  • Re: Renewables in power cuts
    ... If a probability is less than winning ... >concomitant to that what the energy cost per kWhr of renewable energy ... I'm not sure I'm excited about the spinning reserve cost anyway. ... If renewables contributed a much larger ...
    (uk.environment)
  • Re: An optimization problem
    ... following certain discrete distribution. ... One approach to enumerating "all possible value ... cost appears in an outcome. ... "uniform" probability space (assuming the i.i.d. ...
    (sci.math)