Russ P. a écrit :
On Jan 17, 1:43 pm, Paul Rubin <http://phr...@nospam.invalid> wrote:
Bruno Desthuilliers <bdesth.quelquech...@free.quelquepart.fr> writes:
Once again, there's quite a lot to learn from
the story of Ariane 5.
Do you know what actually happened with Ariane 5? The failure was
because "smart" humans overrode the language enforced protection by
casting a floating point number down to a 16-bit integer, which worked
ok in Ariane 4, but failed with an overflow on Ariane 5 where bigger
So this turns out to be an example of a failure due, not to the
*rigidity* of Ada, but to its *permissiveness* in allowing such a
cast.
Nope. This is an example of failure due to the *human* part of the
process - this happened because of a lack of testing / QA, not because
of a language feature or misfeature.
(snip)
This is one thing that Python gets right, automatically using bignums
rather than allowing int overflow. In that sense, Python has more
enforced protection than Ada.
True, but Ada does not have the luxury of just using doubles and
"bignums" everywhere, because it needs to work on cheap processors
too. But perhaps it could somehow be configured to do so by the user
if sufficiently powerful computers are being used.
Here the error was *not* to disable the overflow error checking (in the
context of Ariane 4), but to reuse the module as-is in another context.
As I already stated, no technology can protect us from this kind of
error. Ask yourself why this module was reused as-is, instead of going
thru the whole specs / tests / QA process again, and *perhaps* you'll
start to understand why I say that language-enforced access restrictions
are the wrong solution to a real problem.
--
http://mail.python.org/mailman/listinfo/python-list
