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