Benjamin Scott wrote:
> On Mon, 29 Jan 2001, Kevin D. Clark wrote:
> > I realize this is nit-picking, but...
>
> Subject line changed accordingly. ;-)
>
> > I have to disagree with the Camel book here. A program is correct when it
> > is correct, and no sooner.
>
> The point was, how do you define "correct"? Just because something
> compiles? Just because it runs to completion without encountering a fatal
> error? Because it does what you want it to? Because someone has "proved it
> correct"?
doesn't matter how you define "correct", a program is correct when it mets the
applicable definition of correctness, and not before. As you said, below.
I agree completely, if it is sufficient to just get from A to B without regard for
how you got there and what if any side-effects resulted, that is the definition of
correctness and the program is correct if it runs and solves the requirement
before your boss gets too antsy, but if the requirement is to know how you got
there and to be able to reproduce it and to say that no undesireable side-effects
will result and that you can be confident that all side-effects have been
foreseen, then it will take a bit more for the program to meet that definition of
"correctness". But using locality of reference for the definition of correctness
means you can both be correct :-)
> The reason I like that quote is that it is adaptive. A program is "correct"
> when it fulfills your needs. If your needs include a rigorous analysis of the
> algorithms and logic, then that's fine. But if you just need to get from A to
> B, then so long as you end up at B, how you got there doesn't matter so much,
> so long as you get there in time.
[...snip...]
> > Larry Wall turned green when he learned that billions of dollars (no
> > exageration) get moved around the financial markets every day because of
> > how some Perl scripts act. I'm certain that Larry doesn't fully believe
> > in this rule.
>
> I imagine if you're dealing with billions of dollars, then simply running
> the program against a few test cases isn't going to constitute sufficient
> testing. :-)
I don't have to imagine. Been there, done that. You'd be appalled.
:-)
Usually, there is rigorous testing. Sometimes the ability to foresee what should
be (or even should have been) tested, and thus the testing itself, is lacking.
Sometimes it just gets slighted. No big deal, when you misplace a billion or two
it gets noticed and fixed pretty quick :-)
--Brucem
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
