Dnia 01.10.2012 Maciej Sobczak <s...@g...com> napisał/a:
> W dniu poniedziałek, 1 października 2012 19:31:11 UTC+2 użytkownik Sebastian Biały
napisał:
>
>> > Tak właśnie było z Ariane 5, bo użyto tam modułu z poprzedniego
>> > modelu, gdzie był zarówno bezpieczny jak i szybki.
>> > No, ale w nowym modelu był już tylko szybki.
>>
>> Nie zgadzam się.
>
> Ale mi wisi, czy się zgadzasz, czy nie. Pisałem, już, że temat jest mi znany. Ty
najwyraźniej postanowiłeś się z nim zapoznać jedynie w takim zakresie, jaki jest Ci
potrzebny to trollowania.
>
> http://www.di.unito.it/~damiani/ariane5rep.html
>
> "The design of the Ariane 5 SRI is practically the same as that of an SRI which is
presently used on Ariane 4, particularly as regards the software."
>
> "The value of BH was much higher than expected because the early part of the
trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably
higher horizontal velocity values."
>
> Również, na temat projektowania pod kreskę:
>
> "It has been stated to the Board that not all the conversions were protected
because a maximum workload target of 80% had been set for the SRI computer."
>
>
> Ogólnie, poczytaj to, nie będziesz musiał tworzyć teorii z domysłów.


Jeśli potrzebowali wydajności, to mogli użyć wydajnego narzędzia,
jeśli potrzebowali bezpieczeństwa, to nie powinni "wyłączać
bezpieczników". Jeśli potrzebowali kompromisu, to trzeba było to co
się da zaimplementować w Ada bez "wyłączania bezpieczników" a część
wymagającą wydajności zrobić jawnie w czymś innym (C, ASM czy
czymkolwiek innym). Wtedy wiadomo, że to co w Ada ma swoje
"bezpieczniki" a dodatkowe rzeczy trzeba sprawdzić jako osobne,
niezależne moduły. Projektanci chcąc pogodzić wydajność i niezawodność
popełnili błąd mieszając kod wysokopoziomowy i niskopoziomowy w ramach
jednego "klocka" - kompromis nie zadziałał co jest chyba
wystarczającym dowodem na to, że to był zły pomysł. Wina nie leży tu w
użyciu tego czy innego języka (bo mechanizmy każdego języka mogą być
użyte dobrze lub źle), tylko na błędnym podejściu do sprawy.

Mechanizmy żadnego języka nie zwalniają od myślenia, mogą być pomocne,
ale nie zniwelują błędów w projekcie. Ślepa wiara w mechanizmy języka
może sprowadzić na manowce, bo zawsze może pojawić się coś tak
trywialnego, jak błąd w kompilatorze czy innym narzędziu i całe
cudowne mechanizmy mające zapewnić niezawodność mogą przestać działać
:D