Does Python really follow its philosophy of "Readability counts"?
bdesth.quelquechose at free.quelquepart.fr
Sun Jan 18 16:20:54 CET 2009
Russ P. a écrit :
> On Jan 17, 1:43 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>> Bruno Desthuilliers <bdesth.quelquech... at 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
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.
>> 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.
More information about the Python-list