"Robert Klemme" <bob.news / gmx.net> wrote in message news:<2hgbi7Fbrr02U1 / uni-berlin.de>...
> Not exactly: With unit testing you control the coverage, i.e., you decide
> about the expected behavior and write tests for exactly this behavior.  So
> you *know* what is covered.  Of course, you can miss out something, but

I think that, with unit tests, you *think* you know what is covered. 
A rough count gives me 204 unit tests -- and 564 assertions -- in the
REXML unit test suite.  They all pass, and I *believe* that I've
tested everything, and yet -- somehow -- people keep finding bugs, and
providing specific assertions for cases that I haven't covered.

I do not consider inferred type checking to be any different.  In
fact, I expect type checking to find errors *before* I run the code,
and will find errors that my unit tests may miss, whereas unit tests
require running the code and only test for things that I've thought to
test for.

> No, I do a formal proof of every method in my head. ;-)))

:-)  I've found that, while you can make this claim for code written
in a functional language like Haskell, it is much more difficult to
make this claim with a straight face for code written in an OO
language.

> > If you had an entirely closed system, it is theoretically possible
> > that you could write unit tests for all possible cases -- but, then,
> > you'd have a matrix of all possible answers and you wouldn't need the
> > program, right?
> 
> That matrix would not make the program superfluous, because - depending on
> the problem - you still need the computer to do something.  You can't omit
> a car engine control software just because you know how it will behave in
> every situation, can you?

This is true, although, in that case I'd rather have a finite state
machine burned onto a PROM.

> Yes, of course.  I'm completely with you at that point.  It's just that I
> doubt effort and effect are balanced on this one: the implementation of
> such a feature is quite complex (and error prone in itself :-)) but the
> use is IMHO quite limited because of Ruby's dynamic nature.

Ah, ok.  We agree that the real question is whether the effort of
producing such a system will be worth the results.  We disagree about
(a) the worth of the effort, and (b) the practicality of the solution.
 I believe that type inferrence could cover 90% of Ruby code (in my
code, I'd say closer to 99%, as I write self-modifying code only
rarely) and that the value of the effort is high since it catches
errors *before* the code is executed.  You believe that self-modifying
code is much more common, and you assign it negative value since you
believe it would make people more sloppy.

My proposed solution does not require people to use the type
inferrence system, so the addition of a type inferrence system would
not impact you.  It would allow Ruby proponents to claim some measure
of type safety in Ruby, and it doesn't require any effort on the part
of Ruby programmers to use.  The only question, then, is whether
anybody wants it enough to implement it.  I believe it needs to be
bound in to the Ruby parser, so it is a C job.  I don't believe Matz
has any desire for the system, so I don't think it'll get written by
him, and I'm unlikely to write it unless somebody starts paying me to
do Ruby work -- I've got too many open source projects I'm working on
as it is.  As a result, I doubt we'll see type inferrence for Ruby any
time soon.

But that won't stop me advocating for it :-)

--- SER