Why don't other programming languages have ranges?

Don nospam at nospam.com
Thu Jul 29 10:54:50 PDT 2010


retard wrote:
> Thu, 29 Jul 2010 12:11:21 +0200, Don wrote:
> 
>> Jim Balter wrote:
>>> "Walter Bright" <newshound2 at digitalmars.com> wrote in message
>>> news:i2nkto$8ug$1 at digitalmars.com...
>>>> bearophile wrote:
>>>>> You have to think about proofs as another (costly) tool to avoid
>>>>> bugs/bangs,
>>>>> but not as the ultimate and only tool you have to use (I think
>>>>> dsimcha was
>>>>> trying to say that there are more costly-effective tools. This can be
>>>>> true,
>>>>> but you can't be sure that is right in general).
>>>> I want to re-emphasize the point that keeps getting missed.
>>>>
>>>> Building reliable systems is not about trying to make components that
>>>> cannot fail. It is about building a system that can TOLERATE failure
>>>> of any of its components.
>>>>
>>>> It's how you build safe systems from UNRELIABLE parts. And all parts
>>>> are unreliable. All of them. Really. All of them.
>>> You're being religious about this and arguing against a strawman. While
>>> all parts are unreliable, they aren't *equally* unreliable. Unit tests,
>>> contract programming, memory safe access, and other reliability
>>> techniques, *including correctness proofs*, all increase reliability.
>> I have to disagree with that. "Correctness proofs" are based on a total
>> fallacy. Attempting to proving that a program is correct (on a real
>> machine, as opposed to a theoretical one) is utterly ridiculous. I'm
>> genuinely astonished that such an absurd idea ever had any traction.
> 
> What's your favorite then? 100% unit test coverage?

A completely independent code reviewer helps, too. It really helps if 
you're aggressively trying to break the code.

I agree with Walter's statement that ALL of the components are 
unreliable, and I think it's important to realize that proofs are the 
same. Even in the case where the program perfectly implements the 
algorithm, there can be bugs in the proof. Very many mathematical proofs 
published in peer-reviewed journals have subsequently been found to have 
errors in them.
I think the value in 'correctness proofs' mainly comes from the fact 
that they have some kind of independence from the code. In practice, you 
run your code, and find bugs in the proof...

My feeling is that the value of any reliability technique depends on how 
independent it is from the code you're testing.






More information about the Digitalmars-d mailing list