On 2012-09-30 23:52, Maciej Sobczak wrote:
>> I musze przyznać, że gdyby software ariane był
>> "wyżyłowany co do cykla" to programiści nie powinni się zajmowac więcej
>> programowaniem.
> Jakieś podstawy do tego swierdzenia?

Doświadczenie. W systemie który "akurat" zmieścił się w 64kB ROM albo
*akurat* zmieścił się w 100% czasu przerwania są jakieś kompromisy.
Najczęściej dotyczące bezpieczeństwa własnie ("a, nie sprawdzaj tego
indeksu, na pewno nie będzie > 10 a 7 cykli do przodu").

> Bo ja wiem, że systemy latające bywają specyfikowane blisko kreski.

Blisko kreski (a w zasadzie za) był np. Apollo z AGC. Tylko dzięki temu
że ktoś znał na pamięc cały kod dali radę.

> To jest kompromis pomiędzy tym, co ma być a tym, co jest dostępne

To jest prawda w projektach budżetowych typu chiński sterownik do pieca.
W projektach takich jak rocket-science nie ma racji bytu, zawsze możesz
wziąść wiekszy, wziąść dwa itd. Nie ma większego? To masz zły hardware.

> i w danych ograniczeniach możliwe do zrealizowania.
> Analizę WCET robi się z jakiegoś konkretnego powodu a nie dla zabawy.

"
- Proszę pana, proszę pana, bo mi się tu napisało 17us kodu, to co robimy?
- Rżniemy bezpieczeństwo, przecież analitycy wyliczyli że wejdzie do
16us a hardware gotowy i nie można zmieniać!
"

>> Jeśli więc wymagana jest szybkośc to musisz pozegnać bezpieczeństwo.
> Albo nie. Najgorzej, jeśli mamy złą specyfikację
> - wtedy możemy napisać system, o którym "wiemy"
>, że będzie działał dobrze i będzie też działał szybko
>, ale przez jego użycie niezgodnie z założeniami wychodzi dupa.

> 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ę. Ten kawalek kodu nie miał prawa wejść w jakikolwiek
komputer sterujący rowerem bo jest niebezpieczny. Bajanie o tym że jakiś
tam parametr jakimś cudem mieścił się zazwyczaj w granicy jest
niebezpieczne i charakterystyczne dla "optymalizatorów w asm".

>>> Drugorzędny? Duperelek? I w czym ten duperelek jest napisany, co?
>> W czymś *prostym* co pozwoli na formalną weryfikacje.
> Np. w Adzie? Ten język powstał z myślą o ułatwieniu formalnej weryfikacji
>, chociażby przez minimalizację aliasingu, którego w C jest po sufit.

I ta formalna weryfikacja i jej myśl zmaterializowała się?

>>> Natomiast chamskie sztuczki w C++ *zawsze* są możliwe, bo do dyzpozycji
>>> są wskaźniki i reinterpret_cast (oraz memcpy, itd.).
>> Zupełnie jak w Adzie? Czekaj czekaj czy Ada jest nadzbiorem C++ w sensie
>> niskopoziomowego gówna? OMG!
> Nadzbiorem nie, bo się nie da.
> memcpy na dowolnych argumentach to już jest nadzbiór
>, bo każdy shit można tym zrealizować.
> W Adzie też to jest dostępne, ale trudno to nazwać nadzbiorem.

No patrz, Ada to taki jezyk z silnym typowaniem, super-wyjątkami,
genialną składnią i kupką szitu pozwalającą legalnie wszystko wsadzić
między bajki.

> Lepszość Ady polega na tym, że o ten shit trzeba prosić
>, natomiast w C trzeba prosić, żeby shitu nie było.

I teraz - tadaaaam - zmierzamy w kierunku oczywistym: bezpieczeństwo
kodu zależy nie od języka tylko od programisty. To zbiór czynników poza
językiem decyduje w najwiekszym stopniu o jakości kodu. Takie duperele
jak code review, formalna weryfikacja, analizy statyczne, dynamiczne,
testowanie, ... Ada akuratnie niewiele pomaga, nie na tyle żeby to
nazywać bezpiecznym kodem. Zapewne pierdyliard rzeczy poza Adą lepiej
weryfikuje kod niż język.

>>> W obu przypadkach ominięcie bezpiecznika można uznać za chamskie.
>> I możliwe. Game over.
> Ja też myślę, że powinniśmy zmierzać do końca tej dyskusji.

Ale nie, przecież trolowanie i flame na tym polegają że nie. Nie nie nie.

>> To oznacza że Ada pozwala na to samo co ASM.
> Tak. Ten język powstał również po to, żeby dało się w nim pisać systemy operacyjne.

A po co ? Nie można zrobić bezpiecznego języka do systemów nawigacji w
ktorym 2+2 nie musisz implementować na bitach i recznym testowaniem
overflow?