>From: Roger Racine <[log in to unmask]>
>Validation is not a complete (nor even a very good)
>test of a compiler's correctness. A compiler is much too complex to find
>all errors with any set of tests that might finish in a reasonable
>time. So a "validated" compiler comes with errors. I would much rather
>use an unvalidated compiler that is used by a million other people than a
>validated compiler used by a few thousand.
But for validated compiler you know which scenarios were tested and passed,
while for just "widely used" compiler all that you know is that the most often
used scenarious were tested -- and you don't know neither which they are nor
the exact results of that massive random testing for any particular feature.
So, if you rely on "millions of users" then you essentially rely on folklore.
Moreover, this kind of argument "habit of millions is better ground that
infrastructure of thousands" lead directly to the preference of Astrology
against Astronomy, doesn't it?
>Just that Program
>Managers are not terribly interested in portability. Portable software
>will help the -next- project, not the current one. So one can argue that
>Program Managers are being short-sighted (which, unfortunately, is their
I think that it is very true, especially the notice in parenthesis. And this
implies that the strategic decisions should not be dropped to the tactical
>But I do not think validated
>compilers are in any way safer than unvalidated compilers.
I'd like to mention here, that every vendor has some internal validation
technology. Therefore the difference is not between "validated" and "unvalidated",
but between publicly validated and internally validated. In the first case
a customer may check the scope of validation, while in the second case the
customer may rely only to a vendor's reputation and on vague estimates from
a user's community.
Alexander Kopilovitch [log in to unmask]