Dnia 08.10.2012 Maciej Sobczak <s...@g...com> napisał/a:
> 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?

Taki, że nikt nie potraktowałby tego kawałka kodu narzędziami do Ady
(których wcześniej używał i go nie zawiodły, więc im ufał). Sam
pisałeś, że sprawa została w pewnym sensie zlekceważona (na zasadzie
"wcześniej działało, to i teraz zadziała"), gdyby projektant wymusił
napisanie tego od zera i w innym języku (i co by nie mówić, to
napisanie tego w C dało by zysk na szybkości i zajętości pamięci, a z
tego co pisałeś, to właśnie ze względu na obciążenie rzędu 80%
zrezygnowano z zabezpieczeń), to byłoby to gruntownie sprawdzone jako
niezależny od reszty "klocek". W sumie nie jest ważne w jakim języku,
może być i Ada, byleby nikt nie oparł się pokusie "skopiowania starego
kodu" czy stosowania rutynowych testów bazujących na
"bezpiecznikach". Zarządzanie projektem to nie tylko zarządzanie
specyfikacjami itp., to przede wszystkim zarządzanie ludźmi, a ludzie
to nie maszyny - jeśli system zarządzania projektem nie wymusza
właściwych procedur postępowania i stosowania właściwych mechanizmów,
to prędzej czy później znajdzie się ktoś, kto sobie "uprości" życie :D

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


Moduł nie jest poprawny czy niepoprawny sam z siebie, a jedynie w
kontekście danych jakie przetwarza. Nie pisz, że moduł był poprawny,
bo nie był, to tak jak ja bym powiedział, że buty które mam w szafie
są ok, bo chodziłem w nich jak miałem 5 lat i działały bez zarzutu, a
że teraz mam 36 lat to tylko drobny szczegół (buty oczywiście mogą
nadal działać w kontekście innego 4-latka, ale w moim już nie działają
poprawnie).


>> Ś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)?
>

Taka, że ktoś założył, że skoro moduł przeszedł testy ze starym
systemem, to jest poprawny i nie trzeba "wnikać", automatyczne testy w
nowym systemie nie wykazały niezgodności (bo "bezpieczniki" nie
zadziałały) ale całościowo w praktyce system poległ. Nie twierdzę, że
to wina Ady jako języka, to wina człowieka, który za bardzo zaufał
istniejącemu kodowi oraz mechanizmom wykrywania błędów zawartymi w
języku.

Kwestia indywidualnego podejścia, ja wolę wybierać odpowiednie
narzędzia do rozwiązywanego problemu, inni wolą przystosowywać jedno
narzędzie do wszystkich problemów :D Każdy ma prawo mieć swoje zdanie
i nikt nikogo do niczego nie musi przekonywać, wyraziłem swoją opinię
i to wszystko, nie podchodź do tego jak do "świętej wojny" :D
Z mojej strony EOT