On 4/27/2017 3:16 PM, Maciej Sobczak wrote:
>> Myślę że ten wypadek pokazuje jak pusty jest mit o bezpieczeństwie Ady.
> Ten wypadek pokazuje, że jak się nie korzysta z mechanizmów języka, to nie będzie
pozytywnych efektów

Czyli nie pisali w Adzie. Dziwne, bo się tym wielu ludzi chwalilo, na
newsach też często czytam że krytyczny soft pisze się w Adzie.

> Parafrazując - samochód utonął w rzece razem z kierowcą a Ty pokazujesz
>, jak pusty jest mit o bezpieczeństwie poduszek powietrznych.

Inaczej: mit Ady doprowadza do twierdzeń z gatunku "moj samochód ma
poduszki powietrzne, więc nie zatonie". Zauważ że decyzje biznesowe
dotyczące wyboru technologii prawie nigdy nie podlegają osobie która ma
o nich pojęcie. W korpo w szczegolnosci, w ESA nie wiem, może.

>>> I gdzie ostatnio widziałeś praktykę pisania takich symulatorów?
>> *WSZĘDZIE*.
> Bad news: nie wszędzie byłeś.

Brawo.

> W szczególności nie byłeś tam, gdzie się tego nie robi. To obniża efektywność tej
dyskusji.

Nie, nie obniża, przeciez to trolowanie. Pokazuje jednak dośc istotne
zjawisko: wszedzie powinno się doprowadzać do testow z uzyciem jakiegoś
inputu rzeczywistego. W przypadku rakiety symulacja nie była by trudna
do zrobienia. Policzenie na kartce siły ciągu, przyspieszenia i kilku
innych parameterów też jest w zasiegu. Nie zrobiono tego. Mimo że
wystarczający model wykrywający takie bugi jest w zasiegu studenta
mechaniki/fizyki.

> W Twoim trollowaniu są proste błedy logiczne - w tym samym poście twierdzisz
>, że systemy krytyczne piszą idioci i jednocześnie że "wszędzie" pisze się
symulatory procesów fizycznych.

Wszedzie pisze się testy. Przynajmniej wszedzie w ciezkiej i drogiej
informatyce. Akuratnie nie musza być symulatorami fizyki, bywają. Taki
matlab kroi z tego niebotyczną kasę.

> Może przyjmij jakąś jedną spójną wersję. Nawet błędną, ale jedną.

Proszę: caly świat testuje oprogramowanie in vitro poza esą ktora robi
to na hura. O ile w przypadku Ariane 5 to mogła być wpadka jakich wiele,
to następna, prawie identyczna zaczyna zastanawiać. Zrobili testy tego
kodu *PO* katastrofie sondy. Zabawne, naprawdę. Wychodzi na to że się
dało i to dosc szybko, przetestować kod. Mnie by nie było stać na
wysyłanie w ciemno kodu z tonami podpisów.

>>> Cały czas o tym piszę. To nie jest wina tego języka.
>> Język jest winien tworzenia idiotycznej atmosfery bezpieczeństwa
> Nie. To wybór języka wynika z tej atmosfery. Atmosfera była wcześniej i jest
niezależna od użytego języka.
> Naprawdę.

Tu bez wątpienia mogło by godzinami rozmawiać kilku filozofów co z czego
wynika.

> Dlatego właśnie w projektach w C nie jest lepiej - a byłoby
>, bo przecież z tego co piszesz, wtedy nie byłoby "idiotycznej
> atmosfery bezpieczeństwa" i obniżania jakości. Więc jakość powinna
> być wyższa. A wiadomo, że nie jest. Czyli znowu masz błąd logiczny w Twoim
trollowaniu.

Nigdzi nie pisałem o uzywaniu C więc ciezko się wywodzi o czyjejś logice
na podstawie wyssanych z palca cytatów.

Co do jakości: więcej testowania niekoniecznie ją podnosi. Gdyby
testowani Ariane5 invitro to kod dalej by wyglądał jak wypociny hackera
od asm. Zmniejsza tylko szanse na błąd takiego kalibru.

>> Kiedyś czytalem wypociny pewnego przygłupa od Ady który twierdził że
>> język jest tak znakomity że już nawet nie testują częsci kodu bo wiadomo
>> że działa dobrze.
> Wykorzystanie statycznych metod analizy

Nie wykorzystują. Pisza i od razu jest dobrze, tak powiedział.

> pozwala obniżyć rygor pokrycia testami

Pod warunkiem że bugi tkwią w składni lub algorytmice. Gorzej gdy w
zakresach. Ale obniżyć zawsze warto, wiadomo, jak oszczędzać to na
rzeczach krytycznych.

> i to wynika z procesów a nie z zastosowanego języka. Takie strategie
stosuje się
> niezależnie od użycia Ady, w C również. I nie dotyczy to tylko latania w kosmos,
> ale również np. cywilnej branży lotniczej.

Mówisz np o DO-254. No więc coś Ci powiem o tym. Akuratnie ilośc
testowania kodu w hardware i software rośnie. Nigdy tak wiele nie
testowano i robimy tego coraz więcej. Mozna powiedzieć że testowanie
eksplodowalo jakieś 10 lat temu i ta eksplozja trwa. Wyrosły ogromne
metodyki, od korporacyjnych po detaliczne, jak testować *każdy* aspekt
kodu/hardware. Od testow jednostkowych przez radomizacje, po symulacje
fizyki i obieg dokumentów.

Nikt tu niczego nie ogranicza. Wręcz przeciwnie. EDA rośnie prawie
wyłącznie w dziedzinie weryfikacji. Obecnie hardware i software zlewają
sie w jedno, wiec dotyczy to rownież firmware embedded.

> To są ciekawe tematy, ale jeśli chcesz podyskutować, to przestań trollować.

Czasem trzeba. Inaczej programisci Ady będa chodzili tak samo nadęci jak
programiści VHDLa mimo że świat jest hektary dalej w metodach
weryfikacji niż silne typowanie i ładne exceptiony.

> Na pytania chętnie odpowiem, ale z trollowaniem nie chce mi się walczyć.

Nie ma pytań: ESA dała dupy dwukrotnie w ten sam sposób. Nie pomogła im
Ada bo na idiotów nie ma rady.

Spuśc troche powierza. Zarobiłem zaczepkę z mrugnięciem i od razu
zaczynasz straszliwą dyskusję i edukowanie kogo popadnie i kiwaniem
palcem. Zważ że inni mają tez jakieś punkty widzenia i czasem trzeba
odsunąć się od swojej pracy żeby zobaczyć jak wiele błedow popełniamy w
programowaniu.

Ja widze jak się weryfikuje hardware/firmware w dużej skali, z miejsca
gdzie siedzę. Nie zgadzam się z tym że na tym się oszczędza. Nie,
pompuje się mld dolarow w weryfikacje na całym świecie, wiele procent
tej weryfikacji zalezy rownież od symulatorów fizyki. Powstało tysiące
firm dostarczających narzedzia aby robić to lepiej, szybciej. Wszyscy
weryfikują. To jest teraz ważniejsze od pisania kodu.