W dniu poniedziałek, 8 października 2012 19:00:36 UTC+2 użytkownik Baranosiu napisał:

> 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).

I czym to coś różniłoby się od Ady z wyłączonymi bezpiecznikami? Jaki byłby zysk z
napisania tego kawałka w C?

> Wtedy wiadomo, że to co w Ada ma swoje
>
> "bezpieczniki" a dodatkowe rzeczy trzeba sprawdzić jako osobne,
>
> niezależne moduły.

Nie różni się to niczym od sprawdzenia modułów z wyłączonymi bezpiecznikami. Nie
sprawdzono tego, więc równie dobrze nie sprawdzono by tych modułów, gdyby były
napisane w C.

> Projektanci chcąc pogodzić wydajność i niezawodność
>
> popełnili błąd mieszając kod wysokopoziomowy i niskopoziomowy w ramach
>
> jednego "klocka"

Chyba mieszasz pojęcia. Kod może być bezpieczny będąc niskopoziomowym. Poziom
abstrakcji i poprawność to dwie niezależne sprawy. Nie ma sensu mówić, że projektanci
pomieszali kod wysokopoziomowy i niskopoziomowy tylko na podstawie tego, że gdzieś
bezpieczniki były włączone a gdzieś wyłączone, bo poziom abstrakcji tych kawałków
mógł być niezależny (w szczególności mógł być taki sam).

> - kompromis nie zadziałał co jest chyba
>
> wystarczającym dowodem na to, że to był zły pomysł.

Nadal chyba nie czytałeś tego raportu. Przypomnę: ten kod został stworzony dla
poprzedniego modelu rakiety, gdzie był w 100% poprawny, bo działał w ramach innych
warunków technicznych. Przeniesiono moduł do nowej rakiety, która miała inne
prędkości i w ten sposób poprawny moduł stał się niepoprawny. To nie jest kwestia
kompromisów w kodzie, tylko błędu wdrożeniowego.

Coś w tym stylu: ktoś każe Ci napisać program, który dodaje liczby z zakresu od 0 do
100. Da się. Potem gość bierze ten gotowy program i wrzuca do niego liczby większe,
niż 100. Program się wywala. Czy to był błąd programisty? Nie ma sensu rozwodzić się
and tym, czy właściwie pomieszałeś kod niskopoziomowy z wysokopoziomowym albo które
kawałki powinieneś napisać w C, bo nie tu powstał problem. Problem powstał przez złe
użycie gotowego i poprawnego w swoim oryginalnym kontekście modułu.

> Ś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ć

Tak. I jaki z tego wniosek w kontekście tematu dyskusji (cokolwiek nim było)?

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com