Why don't other programming languages have ranges?

Walter Bright newshound2 at digitalmars.com
Tue Jul 27 12:02:36 PDT 2010


retard wrote:
> Mon, 26 Jul 2010 14:04:53 -0700, Walter Bright wrote:
>> http://www.drdobbs.com/blog/archives/2009/10/safe_systems_fr.html
>>
>> http://www.drdobbs.com/blog/archives/2009/11/designing_safe.html
>>
>> Sadly, it's a topic that has not penetrated software engineering
>> instructional materials, and programmers have to learn it the hard way
>> again and again.
> 
> But these are your articles

Yes.

> with no cited sources about the software methodologies.

As I said, it hasn't penetrated the software literature. It's one of the reasons 
I wrote that, I feel it's a contribution, not a retread.

I did not invent those ideas, they come from my working at Boeing learning how 
the aviation system builds reliable systems from unreliable parts. (Not just 
mechanical systems, Boeing applied those rules to its software subsystems.)


> It seems like they're written afterwards to advertise the 
> features implemented in D.

Or maybe it's the other way around, that the features in D were designed to 
support those ideas. Why would I waste my time implementing complex features if 
I had to after-the-fact come up with some justification for them? Please 
remember that nobody is paying me to do this, I'm not saying "Yes Sir! Three 
bags full, Sir!" to some middle-management phb.

I'm often wrong, but I really do believe that D's feature set is a good and 
justifiable one.


> The contract programming only covers a small 
> runtime dynamic part of programming. There's no mention about automated 
> theorem proving. No word about exceptions nor sandboxing with virtual 
> machines. Why? Because these would make D look ridiculous.

That misses the point about reliability. Again, you're approaching from the 
point of view that you can make a program that cannot fail (i.e. prove it 
correct). That view is WRONG WRONG WRONG and you must NEVER NEVER NEVER rely on 
such for something important, like say your life. Software can (and will) fail 
even if you proved it correct, for example, what if a memory cell fails and 
flips a bit? Cosmic rays flip a bit?

Are you willing to bet your life?


> How the web programming world works:
> 
> ''I'm not a real programmer. I throw together things until it works then 
> I move on. The real programmers will say "yeah it works but you're 
> leaking memory everywhere. Perhaps we should fix that." I'll just restart 
> apache every 10 requests.'' -- Rasmus Lerdorf
> 
> It it widely accepted that web applications fail often. It suffices if 
> the developers are fixing bad code eventually, but the remaining parts 
> should work reasonably well. Either a process is restarted or exceptions 
> are used to catch small error conditions so the server could server 
> *something* . I'm talking about practical web applications, not X-ray 
> machines.

It's retarded (!) to pretend that this is how one makes reliable systems.


More information about the Digitalmars-d mailing list