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

Groups > pl.comp.programming > #29619 > unrolled thread

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

Back to article view | Back to pl.comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

Ada i wszystko jasne... Nic bardziej chorego nie spłodził ludzki umysł...

[toc] | [next] | [standalone]

#29620

On Saturday, April 22, 2017 at 6:12:05 PM UTC+2, szyk...@gmail.com wrote:
> Ada i wszystko jasne... Nic bardziej chorego nie spłodził ludzki umysł...

Całkiem zgrabny i przemyślany język imperatywny. Jakieś konkretne zarzuty?

w.

[toc] | [prev] | [next] | [standalone]

#29621

On 4/22/2017 10:24 PM, Wojciech Muła wrote:
>> Ada i wszystko jasne... Nic bardziej chorego nie spłodził ludzki umysł...
> Całkiem zgrabny i przemyślany język imperatywny. Jakieś konkretne zarzuty?

1) Ariane5 z Overflow Space Agency
2) Nadmiarowe zuzycie klawiatury
3) VHDL

;D

[toc] | [prev] | [next] | [standalone]

#29623

On Sunday, April 23, 2017 at 10:29:18 AM UTC+2, Sebastian Biały wrote:

Ręce opadają...

> 1) Ariane5 z Overflow Space Agency

Program zrobił dokładnie to, do czego został zaprojektowany. To, że został użyty *w kontekście*, do którego nie został zaprojektowany, było winą złej integracji systemu a nie błędów w kodzie. Polecam lekturę raportu z fakapu.

> 2) Nadmiarowe zuzycie klawiatury

W Notepadzie. Programiści używają lepszych edytorów.

> 3) VHDL

Odwrotnie. To VHDL czerpał składnię z Ady. PL/SQL też, btw.

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

[toc] | [prev] | [next] | [standalone]

#29624

On Monday, April 24, 2017 at 1:29:37 PM UTC+1, Maciej Sobczak wrote:
> On Sunday, April 23, 2017 at 10:29:18 AM UTC+2, Sebastian Biały wrote:
> 
> Ręce opadają...
> 
> > 1) Ariane5 z Overflow Space Agency
> 
> Program zrobił dokładnie to, do czego został zaprojektowany. To, że został użyty *w kontekście*, do którego nie został zaprojektowany, było winą złej integracji systemu a nie błędów w kodzie. Polecam lekturę raportu z fakapu.
> 

Ciekawe.
Nie chce mi sie calego czytac. Moglbys krotko napisac, czy aby na pewno
uzycie jezyka z mocniejszym systemem typow ( np. dependent typing ) nie pomogloby
zapobiec katastrofie?

> > 2) Nadmiarowe zuzycie klawiatury
> 
> W Notepadzie. Programiści używają lepszych edytorów.
> 

Ciekawe, ze ciagle slysze narzekania, ze trzeba wiecej pisac.
Ale ni cholery nikt nie narzeka, ze im mniej trzeba pisac, tym trudniej
sie czyta.

--
Michal

[toc] | [prev] | [next] | [standalone]

#29626

W dniu poniedziałek, 24 kwietnia 2017 16:16:31 UTC+2 użytkownik Michal napisał:

> > > 1) Ariane5 z Overflow Space Agency
> > 
> > Program zrobił dokładnie to, do czego został zaprojektowany. To, że został użyty *w kontekście*, do którego nie został zaprojektowany, było winą złej integracji systemu a nie błędów w kodzie. Polecam lekturę raportu z fakapu.
> 
> Ciekawe.
> Nie chce mi sie calego czytac. Moglbys krotko napisac, czy aby na pewno
> uzycie jezyka z mocniejszym systemem typow ( np. dependent typing ) nie pomogloby
> zapobiec katastrofie?

Katastrofa wynikała z tego, że z pośpiechu wzięto moduł z mniejszej rakiety i po prostu trzymając kciuki wsadzono go do większej rakiety, której większa prędkość w czasie startu (zdaje się, że pozioma składowa) nie zmieściła się w założonym zakresie. Wynikający z tego wyjątek  (nie ma znaczenia, że z powodu wyłączenia wyjątków software'owych był to wyjątek hardware'owy) trafił do procedury obsługi polegającej na wysadzeniu całej rakiety w p*zdu.
Lepszy język? Tu nie było żadnego buga a program zachował się tak jak miał się zachować. Błąd był po stronie inżynierów systemowych, którzy złożyli do kupy rakietę z klocków z niewłaściwego pudełka. Żaden język przed tym specjalnie nie chroni.

> > > 2) Nadmiarowe zuzycie klawiatury
> > 
> > W Notepadzie. Programiści używają lepszych edytorów.
> 
> Ciekawe, ze ciagle slysze narzekania, ze trzeba wiecej pisac.
> Ale ni cholery nikt nie narzeka, ze im mniej trzeba pisac, tym trudniej
> sie czyta.

Jest jeszcze gorzej. Średnia szybkość klepania kodu w takich systemach to 1 (słownie: jedna) linia kodu na inżyniera na dzień. W tym czasie wokół tej jednej linii kodu powstaje kilka albo kilkanaście stron analiz, powiedzmy, że w Wordzie. Przy tych proporcjach radość z pisania kodu jest tak wielka, że każdą literkę się celebruje a ludzie się cieszą, że mogą sobie napisać "begin" albo nawet "BEGIN" (a co!) zamiast zwykłego jednego nawiasu, powiedzmy klamrowego. W takich warunkach trzeba nie mieć sumienia, żeby krytykować język za nadmiar pisania. :-)

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

[toc] | [prev] | [next] | [standalone]

#29627

On Mon, 24 Apr 2017 15:24:29 -0700 (PDT), Maciej Sobczak wrote:

>> Ciekawe, ze ciagle slysze narzekania, ze trzeba wiecej pisac.
>> Ale ni cholery nikt nie narzeka, ze im mniej trzeba pisac, tym trudniej
>> sie czyta.
> 
> Jest jeszcze gorzej. Średnia szybkość klepania kodu w takich systemach to 1 (słownie: jedna) linia kodu na inżyniera na dzień. W tym czasie wokół tej jednej linii kodu powstaje kilka albo kilkanaście stron analiz, powiedzmy, że w Wordzie. Przy tych proporcjach radość z pisania kodu jest tak wielka, że każdą literkę się celebruje a ludzie się cieszą, że mogą sobie napisać "begin" albo nawet "BEGIN" (a co!) zamiast zwykłego jednego nawiasu, powiedzmy klamrowego. W takich warunkach trzeba nie mieć sumienia, żeby krytykować język za nadmiar pisania. :-)

Pomijając już ten specyficzny przypadek to Michał ma rację w szerokim
pojęciu. Zacieranie rączek z zaoszczędzenia 50% kodu jest krótkowzroczne. 
Niedawno wklejałem tu do rozkminy 3 linijki kodu JS napisane tak, że nie
wiadomo było o co kaman. 
Ale nawet pisząc czytelny kod to fakt mniejszej czy większej liczby
klepnięc w klawiaturę jest tak znikomym ułamkiem całego procesu kodowania,
że nie wiem po co się to w ogóle porusza. Zwłaszcza, że współczesny edytor
redukuje różnicę w pisaniu pomiędzy BEGIN a { do minimum. 

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#29628

W dniu 2017-04-25 o 08:29, Roman Tyczka pisze:
> On Mon, 24 Apr 2017 15:24:29 -0700 (PDT), Maciej Sobczak wrote:
>
>>> Ciekawe, ze ciagle slysze narzekania, ze trzeba wiecej pisac.
>>> Ale ni cholery nikt nie narzeka, ze im mniej trzeba pisac, tym trudniej
>>> sie czyta.
>>
>> Jest jeszcze gorzej. Średnia szybkość klepania kodu w takich systemach to 1 (słownie: jedna) linia kodu na inżyniera na dzień. W tym czasie wokół tej jednej linii kodu powstaje kilka albo kilkanaście stron analiz, powiedzmy, że w Wordzie. Przy tych proporcjach radość z pisania kodu jest tak wielka, że każdą literkę się celebruje a ludzie się cieszą, że mogą sobie napisać "begin" albo nawet "BEGIN" (a co!) zamiast zwykłego jednego nawiasu, powiedzmy klamrowego. W takich warunkach trzeba nie mieć sumienia, żeby krytykować język za nadmiar pisania. :-)
>
> Pomijając już ten specyficzny przypadek to Michał ma rację w szerokim
> pojęciu. Zacieranie rączek z zaoszczędzenia 50% kodu jest krótkowzroczne.
> Niedawno wklejałem tu do rozkminy 3 linijki kodu JS napisane tak, że nie
> wiadomo było o co kaman.
> Ale nawet pisząc czytelny kod to fakt mniejszej czy większej liczby
> klepnięc w klawiaturę jest tak znikomym ułamkiem całego procesu kodowania,
> że nie wiem po co się to w ogóle porusza. Zwłaszcza, że współczesny edytor
> redukuje różnicę w pisaniu pomiędzy BEGIN a { do minimum.
>

Bo to zależy, ja natomiast poprawiam kody pisane metodą c/p... Ludzie z 
jednej strony oszczedzaja linie czy 2 piszac w jednej linii cale if/else 
a z drugiej potrafia wymodzić fujkcję mającą 1500 linii i wiele 
zagłębień, a teraz to spróbuj zanalizować. Dodatkowo mnóstwo kodu 
powtarzającego się, a teraz minimalna zmiana i musisz szukac wszystkich 
wystąpień po całym kodzie. Tak więc ja wolę zanim zacznę pisać 
przeanalizować problem zanim zacznę pisać, bo okazuje się, że zajmie to 
tyle samo czasu, kod będzie krótszy i czytelniejszy.

-- 
http://kaczus.ppa.pl
http://kaczanowska.info

[toc] | [prev] | [next] | [standalone]

#29629

On Monday, April 24, 2017 at 11:24:30 PM UTC+1, Maciej Sobczak wrote:
> W dniu poniedziałek, 24 kwietnia 2017 16:16:31 UTC+2 użytkownik Michal napisał:
> 
> > > > 1) Ariane5 z Overflow Space Agency
> > > 
> > > Program zrobił dokładnie to, do czego został zaprojektowany. To, że został użyty *w kontekście*, do którego nie został zaprojektowany, było winą złej integracji systemu a nie błędów w kodzie. Polecam lekturę raportu z fakapu.
> > 
> > Ciekawe.
> > Nie chce mi sie calego czytac. Moglbys krotko napisac, czy aby na pewno
> > uzycie jezyka z mocniejszym systemem typow ( np. dependent typing ) nie pomogloby
> > zapobiec katastrofie?
> 
> Katastrofa wynikała z tego, że z pośpiechu wzięto moduł z mniejszej rakiety i po prostu trzymając kciuki wsadzono go do większej rakiety, której większa prędkość w czasie startu (zdaje się, że pozioma składowa) nie zmieściła się w założonym zakresie. Wynikający z tego wyjątek  (nie ma znaczenia, że z powodu wyłączenia wyjątków software'owych był to wyjątek hardware'owy) trafił do procedury obsługi polegającej na wysadzeniu całej rakiety w p*zdu.
> Lepszy język? Tu nie było żadnego buga a program zachował się tak jak miał się zachować. Błąd był po stronie inżynierów systemowych, którzy złożyli do kupy rakietę z klocków z niewłaściwego pudełka. Żaden język przed tym specjalnie nie chroni.
> 

No właśnie tu jest pytanie - czy może pomóc uchronić. Diabeł tkwi w szczegółach.
Przecież nie wzięli chyba kompilatu (binarki) z jednej maszyny i nie zainstalowali tego na drugiej "jak leci". Podejrzewam, że _jakiś_ proces kompilacji/budowania i testowania itp jednak był.

Czy dobry język (i - co najwazniejsze - wiążąca się z takim językiem metodyka ) pozwoliłby uniknąć tego rodzaju błędu (przepełnienie zakresu) - chociażby poprzez "kłucie w oczy" ewidentnym problemem (zgłaszanym przez kompilator).


> > > > 2) Nadmiarowe zuzycie klawiatury
> > > 
> > > W Notepadzie. Programiści używają lepszych edytorów.
> > 
> > Ciekawe, ze ciagle slysze narzekania, ze trzeba wiecej pisac.
> > Ale ni cholery nikt nie narzeka, ze im mniej trzeba pisac, tym trudniej
> > sie czyta.
> 
> Jest jeszcze gorzej. Średnia szybkość klepania kodu w takich systemach to 1 (słownie: jedna) linia kodu na inżyniera na dzień.

W przypadku "web apps" to rzędy wielkości więcej. Codziennie się przepisuje to, co napisało się wczoraj - zgodnie z zasada "refactor mercilessly" i generalnie "agile".

--
Michal

[toc] | [prev] | [next] | [standalone]

#29632

> Przecież nie wzięli chyba kompilatu (binarki) z jednej maszyny i nie zainstalowali tego na drugiej "jak leci".

Tego nie wiem, ale nie zdziwiłbym się. W końcu skoro moduł był przetestowany (a był, w poprzedniej rakiecie), to z punktu widzenia integratora nadawał się do użycia.

> Podejrzewam, że _jakiś_ proces kompilacji/budowania i testowania itp jednak był.

I tutaj Ada ma wystarczające mechanizmy, żeby w procesie kompilacji wykryć niezgodności zakresów. Nie ma znaczenia, czy tego procesu kompilacji w ogóle nie było, czy też był ale nie skorzystano z tych mechanizmó - w żadnym z tych przypadków nie można obwiniać języka.

> Czy dobry język (i - co najwazniejsze - wiążąca się z takim językiem metodyka ) pozwoliłby uniknąć tego rodzaju błędu (przepełnienie zakresu) - chociażby poprzez "kłucie w oczy" ewidentnym problemem (zgłaszanym przez kompilator).

Problemy integracyjne nie są zgłaszane przez kompilator. To jest kwestia zarządzania wymaganiami i co ciekawe, dzisiaj też nie ma na to dobrych uniwersalnych metod.

> > Jest jeszcze gorzej. Średnia szybkość klepania kodu w takich systemach to 1 (słownie: jedna) linia kodu na inżyniera na dzień.
> 
> W przypadku "web apps" to rzędy wielkości więcej. Codziennie się przepisuje to, co napisało się wczoraj - zgodnie z zasada "refactor mercilessly" i generalnie "agile".

I co? Lepiej jest?

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

[toc] | [prev] | [next] | [standalone]

#29635

On Wednesday, April 26, 2017 at 3:46:50 PM UTC+2, Maciej Sobczak wrote:
> > > Jest jeszcze gorzej. Średnia szybkość klepania kodu w takich systemach to 1 (słownie: jedna) linia kodu na inżyniera na dzień.
> > 
> > W przypadku "web apps" to rzędy wielkości więcej. Codziennie się przepisuje to, co napisało się wczoraj - zgodnie z zasada "refactor mercilessly" i generalnie "agile".
> 
> I co? Lepiej jest?

Oczywiscie. No... moze nie lepiej, ale na pewno zwinniej :P

--
Michal

[toc] | [prev] | [next] | [standalone]

#29630

On 4/25/2017 12:24 AM, Maciej Sobczak wrote:
> Katastrofa wynikała z tego, że z pośpiechu wzięto moduł z mniejszej rakiety
> i po prostu trzymając kciuki wsadzono go do większej rakiety

I nikt nie wpadł na to żeby napisać testy jednostkowe, lub nawet 
symulator fizyki całej rakiety. Podobnie nikt nie wpadł na to samo przy 
ostatnim overflow sondy marsjańskiej. Overflow Space Agency. Bo 4 bajty 
sa lepsze niż 8, pamięć jest droga.

> , której większa prędkość w czasie startu (zdaje się, że pozioma składowa)
> nie zmieściła się w założonym zakresie.

Który to zakres ustalił jakiś miłośnik assemblera i oszczędzacz bajtów. 
Wiem, widzialem kod w okolicy tego buga, z raportu. Nie ma on żadnego 
związku z Adą. To czysty assembler napisany (wyhackowany bardziej) w 
języku wyższego poziomu ze wszystkimi możliwymi wadami takiego cuda. I 
jestem pewien że jest tona dokumentacji podpisanej ważnymi podpisami.

[toc] | [prev] | [next] | [standalone]

#29631

W dniu 2017-04-25 o 19:21, Sebastian Biały pisze:
> On 4/25/2017 12:24 AM, Maciej Sobczak wrote:
>> Katastrofa wynikała z tego, że z pośpiechu wzięto moduł z mniejszej
>> rakiety
>> i po prostu trzymając kciuki wsadzono go do większej rakiety
>
> I nikt nie wpadł na to żeby napisać testy jednostkowe, lub nawet
> symulator fizyki całej rakiety. Podobnie nikt nie wpadł na to samo przy
> ostatnim overflow sondy marsjańskiej. Overflow Space Agency. Bo 4 bajty
> sa lepsze niż 8, pamięć jest droga.
>
>> , której większa prędkość w czasie startu (zdaje się, że pozioma
>> składowa)
>> nie zmieściła się w założonym zakresie.
>
> Który to zakres ustalił jakiś miłośnik assemblera i oszczędzacz bajtów.
> Wiem, widzialem kod w okolicy tego buga, z raportu. Nie ma on żadnego
> związku z Adą. To czysty assembler napisany (wyhackowany bardziej) w
> języku wyższego poziomu ze wszystkimi możliwymi wadami takiego cuda. I
> jestem pewien że jest tona dokumentacji podpisanej ważnymi podpisami.
>

Nie widziałem kodu, więc nie wiem, jak było tam, ale z pewnego 
doświadczenia z producentami sprzętu i systemów opartych na tych 
sprzętach, wiem, że ważna jest też konfiguracja takowego. Jeśli zestawy 
sa niepowtarzalne, to trzeba taką konfiguracje dla niego przeprowadzić 
osobno, defaultowo moga być urządzenia ustawione, aby reagowały np na 
kazde wydarzenie (przykład po oddaniu jednej trasy tramwajowej w Łodzi, 
często "brakowało prądu" - otóż powód był prozaiczny - urządzenia nie 
były skonfigurowane dla tej trakcji - bo nie mogły być, bo urzadzenia 
zgodnie z założeniami przetaru były dostarczone i zamontowane 2 miesiące 
wcześniej, ale prąd doprowadzo dopiero na dzień przed uruchomieniem 
całości, nasi wspaniali urzednicy zapomnieli, że takie urządzenia trzeba 
konfigurować indywidualnie po pomiarach zrobionych w rzeczywistości, bo 
są to rzeczy niepowtarzalne, a domyślna konfiguracja po prostu wszystko 
co wyglądało podejrzanie traktowała jako wyjątek i odcinany był dopływ 
prądu) Więc Mógł być to nawet i dobrze oprogramowany moduł, ale 
niewłaściwie skonfigurowany do nowych zadań - nowych, bo jak ktoś tu 
wspomniał miał pracowac w innych warunkach niż wcześniej.

-- 
http://kaczus.ppa.pl

[toc] | [prev] | [next] | [standalone]

#29633

> I nikt nie wpadł na to żeby napisać testy jednostkowe,

Napisał. Do poprzedniej rakiety.

> lub nawet 
> symulator fizyki całej rakiety.

Z powodu oszczędności? Albo z powodów historycznych, bo nie było jeszcze tej dyskusji na pl.comp.programming i nie mogli się z niej dowiedzieć, że powinni byli taki symulator napisać?
I jaki to ma związek z użytym językiem?
I gdzie ostatnio widziałeś praktykę pisania takich symulatorów?

> Podobnie nikt nie wpadł na to samo przy 
> ostatnim overflow sondy marsjańskiej.

Nikt nie napisał symulatora Marsa?

> Który to zakres ustalił jakiś miłośnik assemblera i oszczędzacz bajtów. 
> Wiem, widzialem kod w okolicy tego buga, z raportu. Nie ma on żadnego 
> związku z Adą.

Cały czas o tym piszę. To nie jest wina tego języka.

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

[toc] | [prev] | [next] | [standalone]

#29634

On 4/26/2017 3:53 PM, Maciej Sobczak wrote:
>> I nikt nie wpadł na to żeby napisać testy jednostkowe,
> Napisał. Do poprzedniej rakiety.

I kto wyleciał z roboty za niedbalstwo i debilizm?

>> lub nawet
>> symulator fizyki całej rakiety.
> Z powodu oszczędności?

Niemożliwe. Nie, po prostu niemożliwe. Mozna oszczędzać na farbie, ale 
nie na testach. Żartujesz, prawda? Tam nie ma aż takich kretynów, prawda?

> Albo z powodów historycznych, bo nie było jeszcze tej dyskusji
 > na pl.comp.programming i nie mogli się z niej dowiedzieć, że powinni 
byli taki symulator napisać?

Przecież tam są sami najlepsi i pisza w najlepszych językach. Sami 
wiedzą że testujemy oprogramowanie od dawna. Testujemy na wielu 
poziomach. Testy integracyjne systemów musza mieć jakiś input. Za nim 
wystrzelili pierwszą mogli to symulować. Testy nie musza być dokładne 
żeby wykryc błedy oveflow czujników w oczywistych sytuacjach. To *TAKIE* 
oczywiste.

> I jaki to ma związek z użytym językiem?

Myślę że ten wypadek pokazuje jak pusty jest mit o bezpieczeństwie Ady. 
Zawsze trafi się idiota co wykorzysta tej język jak assembler. Co gorsza 
nie jeden.

> I gdzie ostatnio widziałeś praktykę pisania takich symulatorów?

*WSZĘDZIE*. Poza Overflow Space Agency oczywiście. Tam nadrabiają tonami 
dokumentacji z podpisami Ważnych Ludzi Od Pospisów.

Ogólnie to się testowanie nazywa. Pewnie, można robić testowanie na 
rózne sposóby. Ale ciezko napisać nawigację rakiety bez symulatora 
zjawisk fizycznych. Choć kto bogatemu zabroni?

>> Podobnie nikt nie wpadł na to samo przy
>> ostatnim overflow sondy marsjańskiej.
> Nikt nie napisał symulatora Marsa?

Nikt nie napisał symualtora otwierania spadochronu i obliczenia 
przeciążeń na żywym programie nawigacyjnym. Założono jak zwykle że 4 
bajty wystarczą. Widuje takie podejście w całym świecie embedded i 
przypuszczam że ten sam gatunek programisty jest odpowiedzialny za 
pisanie firmware komputerów nawigacyjnych.

> Cały czas o tym piszę. To nie jest wina tego języka.

Język jest winien tworzenia idiotycznej atmosfery bezpieczeństwa w 
ktorej obniża się jakość "bo jest bezpieczny, to po co sprawdzać czy 
dobrze napisałem".

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. Nie pamiętam czy pracowałw Overflow Space Agency. Nie 
wykluczam tego po ostatniej wpadce z Marsem.

[toc] | [prev] | [next] | [standalone]

#29636

On Wednesday, April 26, 2017 at 6:23:52 PM UTC+2, Sebastian Biały wrote:

> > I jaki to ma związek z użytym językiem?
> 
> 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, które te mechanizmy mogłyby dać.

Parafrazując - samochód utonął w rzece razem z kierowcą a Ty pokazujesz, jak pusty jest mit o bezpieczeństwie poduszek powietrznych.
 
> > I gdzie ostatnio widziałeś praktykę pisania takich symulatorów?
> 
> *WSZĘDZIE*.

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

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. Może przyjmij jakąś jedną spójną wersję. Nawet błędną, ale jedną.

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

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.

Ogólnie - słabe.

> 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 pozwala obniżyć rygor pokrycia testami 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.

To są ciekawe tematy, ale jeśli chcesz podyskutować, to przestań trollować. Na pytania chętnie odpowiem, ale z trollowaniem nie chce mi się walczyć.

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

[toc] | [prev] | [next] | [standalone]

#29637

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.

[toc] | [prev] | [next] | [standalone]

#29638

On Thursday, April 27, 2017 at 7:53:32 PM UTC+2, Sebastian Biały wrote:

> Czyli nie pisali w Adzie.

Nie ma systemów napisanych w 100% w Adzie. To, że wywaliło się w tym kawałku, gdzie Ada nie była wykorzystana (albo nie była wykorzystana w pełni) pokazuje, że problem nie był w Adzie. Dla mnie to logiczne.

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

W tym samym poście twierdzisz, że pisali, i że nie pisali.

> Zauważ że decyzje biznesowe 
> dotyczące wyboru technologii prawie nigdy nie podlegają osobie która ma 
> o nich pojęcie.

Nadal nie wykazałeś, że decyzja o wyborze technologii była zła.

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

Proszę: https://en.wikipedia.org/wiki/List_of_software_bugs

Jak widać, "cały świat" testuje. Na symulatorach, zapewne.

> > Wykorzystanie statycznych metod analizy
> 
> Nie wykorzystują.

Wykorzystują, bo część takich metod jest wpisana w język, np. w system typów.

> Pisza i od razu jest dobrze, tak powiedział.

Niech zgadnę - zrobiłeś skrót z cudzej skróconej wypowiedzi? A może za tą wypowiedzią stoi jakiś bardziej przemyślany proces? Ale nie, na pewno na świecie jest N-1 idiotów.

> > pozwala obniżyć rygor pokrycia testami
> 
> Pod warunkiem że bugi tkwią w składni lub algorytmice. Gorzej gdy w 
> zakresach.

Właśnie testowanie zakresów da się w ten sposób wykluczyć najszybciej.

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

Skoro rośnie, to kiedyś była mniejsza. Ariane 5 to było 20 lat temu.
To, że 20 lat później masz poczucie wyższości nad tamtymi ludźmi to nie jest wielkie osiągnięcie. Trzeba było tam być 20 lat temu.

> Nigdy tak wiele nie 
> testowano

Przecież cały czas o tym piszę. W Ariane 5 wsadzono moduł z mniejszej rakiety, bez kompletnych testów integracyjnych.

> > To są ciekawe tematy, ale jeśli chcesz podyskutować, to przestań trollować.
> 
> Czasem trzeba. Inaczej programisci Ady będa chodzili tak samo nadęci

Akurat ci, których znam, są raczej skromni. Zdaje się, że swiadomi swoich ograniczeń.

> Spuśc troche powierza. Zarobiłem zaczepkę z mrugnięciem i od razu 
> zaczynasz straszliwą dyskusję

Nie wyrażam się z pogardą o nikim. Nikogo nie nazwałem idiotą ani debilem. I tak dalej. Nawet nie ja zacząłem tą dyskusję. Przeczytaj swoje posty i porównaj.

Dyskutujemy czy trollujesz dalej?

> Nie zgadzam się z tym że na tym się oszczędza.

Oszczędza się właśnie na tym, bo weryfikacja nie produkuje żadnych artefaktów. I widać to zwłaszcza w waterfallu, który był (i nadal jest) popularną metodą w takich systemach.

BTW:

http://www-users.math.umn.edu/~arnold/disasters/ariane5rep.html

"It is not mandatory, even if preferable, that all the parts of the subsystem are present in all the tests at a given level."

Jak również:

"A large number of closed-loop simulations of the complete flight simulating ground segment operation, telemetry flow and launcher dynamics were run in order to verify [...]"

Porównaj to ze swoimi wypowiedziami na temat tego, co zrobili albo czego nie zrobili albo co zrobiłby każdy student, albo co robią wszyscy na całym świecie, itd.
I przede wszystkim, przeczytaj ten raport.

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

[toc] | [prev] | [next] | [standalone]

#29625

On 4/24/2017 2:29 PM, Maciej Sobczak wrote:
> Ręce opadają...

Nic dziwnego skoro wyciąłeś ostatnią linijkę ;)

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web