"Sean Russell" <ser / germane-software.com> schrieb im Newsbeitrag
news:83173408.0405250629.6c4ab7a3 / posting.google.com...
> "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.

D'accord.

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

Definitely!

> > > 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.  That was just an example - the first that came to mind and
apparently not quite good.  The point was just that there is software that
finds a solution to a problem (which you need not execute if you know the
outcome) and software that has to be run to be really useful (accounting
systems, web servers...).

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

Exactly.  Maybe we should start a poll to get a clearer view what other
people think about this.

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

Go ahead!  I'll be watching you... :-))

Kind regards

    robert