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.