Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > pl.comp.programming > #29637

Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017

From Sebastian Biały <heby@poczta.onet.pl>
Newsgroups pl.comp.programming
Subject Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017
Date 2017-04-27 19:53 +0200
Organization ATMAN - ATM S.A.
Message-ID <odtb6q$445$1@node2.news.atman.pl> (permalink)
References (6 earlier) <485788e8-89fb-4b37-a38c-924662107718@googlegroups.com> <odo0is$9aj$1@node1.news.atman.pl> <90c9e163-335e-4a23-a369-6a940ad1dc97@googlegroups.com> <odqhim$sgp$1@node1.news.atman.pl> <ed68da9e-067a-43d0-804c-619f24779251@googlegroups.com>

Show all headers | View raw


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.

Back to pl.comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 szykcech@gmail.com - 2017-04-22 09:12 -0700
  Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Wojciech Muła <wojtek.mula@gmail.com> - 2017-04-22 13:24 -0700
    Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Sebastian Biały <heby@poczta.onet.pl> - 2017-04-23 10:29 +0200
      Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-24 05:29 -0700
        Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Michal <michal@kleczek.org> - 2017-04-24 07:16 -0700
          Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-24 15:24 -0700
            Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Roman Tyczka <noemail@because.no> - 2017-04-25 08:29 +0200
              Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-04-25 08:44 +0200
            Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 michal@kleczek.org - 2017-04-25 05:19 -0700
              Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-26 06:46 -0700
                Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 michal@kleczek.org - 2017-04-26 13:59 -0700
            Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Sebastian Biały <heby@poczta.onet.pl> - 2017-04-25 19:21 +0200
              Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-04-26 08:58 +0200
              Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-26 06:53 -0700
                Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Sebastian Biały <heby@poczta.onet.pl> - 2017-04-26 18:23 +0200
                Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-27 06:16 -0700
                Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Sebastian Biały <heby@poczta.onet.pl> - 2017-04-27 19:53 +0200
                Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Maciej Sobczak <see.my.homepage@gmail.com> - 2017-04-27 23:09 -0700
        Re: 22nd Int.Conf. Reliable Software Technologies, Ada-Europe 2017 Sebastian Biały <heby@poczta.onet.pl> - 2017-04-24 20:19 +0200

csiph-web