🚀 go-pugleaf

> W pierwszym dniu konferencji (11 czerwca, wtorek) odbędą się dwa równoległe tutoriale (http://ae2019.edc.pl/tutorials.html):
> 
> - T1: Controlling I/O Devices with Ada, oraz
> 
> - T2: An introduction to Ada.
> 
> Obydwa (i zwłaszcza ten drugi) mogą zainteresować osoby, które są ciekawe języka a nie znalazły do tej pory impulsu, żeby spróbować.

Miałem na studiach prawie 20 lat temu. Wnioski: szkoda sobie zawracać 
głowę - atrakcyjność Ady jest mniej więcej taka jak syrenki-kabrio w 
dzisiejszych czasach... - nie ten klimat i nie te czasy...
Nawet w Szap (ang. Usa) w najnowszym swym wynalazku F-35 wszystko 
zakodowali w C++ ... Najwyraźniej uznali że Ada to dziadostwo i ogólnie 
do nauki tego nie ma chętnych...
Inna sprawa, że F-35-coding-rules.pdf wprowadza takie ograniczenia, że z 
tego C++ zostaje może 25% przez co programowanie zgodnie z tymi 
zaleceniami jest bardziej prymitywne niż w latach 90 XXw (czyli z przed 
standaryzacji C++). Widać, że ktoś bardzo lubił Ada-ę i pomyślał, że w 
zasadzie można by tak samo programować w C++.

> Miałem na studiach prawie 20 lat temu.

No właśnie - jedną z głównych prezentacji (http://ae2019.edc.pl/keynotes.html) będzie "A 2020 View of Ada". Być może będzie to inna perspektywa, niż Twoje wspomnienia ze studiów.

> nie ten klimat i nie te czasy...

A konkretnie jaki klimat i jakie czasy? Przykładowo, Python zaczął swoją historię 29 lat temu. To nawet wcześniej, niż Twoje studia.

Po czym poznać, że klimat i czasy są właściwe?

> Nawet w Szap (ang. Usa) w najnowszym swym wynalazku F-35

"F-35 development started in 1992" (z Wikipedii).

Czyli wcześniej, niż Twoje studia. Dużo wcześniej. To zdecydowanie nie jest najnowszy wynalazek.

> wszystko 
> zakodowali w C++ ... Najwyraźniej uznali że Ada to dziadostwo

F-35 jest chyba najbardziej krytykowanym współczesnym samolotem.

"critics argued that the plane was "plagued with design flaws""

"The program received considerable criticism for cost overruns during development"

Czyli to chyba nie był najlepszy przykład. :-)

> Inna sprawa, że F-35-coding-rules.pdf wprowadza takie ograniczenia, że z 
> tego C++ zostaje może 25%

I to tylko dlatego, że to nie jest projekt cywilny. Bo gdyby był cywilny, to by zostało 5%.

> Widać, że ktoś bardzo lubił Ada-ę i pomyślał, że w 
> zasadzie można by tak samo programować w C++.

To nie wina Ady, tylko standardów lotniczych. Bo Ady też używa się tylko kilka procent. Pełna Ada to zupełnie inne zjawisko - ale o tym najlepiej dowiedzieć się na tutorialu (albo na całej konferencji).

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

On 18/04/2019 15:01, Maciej Sobczak wrote:
> F-35 jest chyba najbardziej krytykowanym współczesnym samolotem.
> "critics argued that the plane was "plagued with design flaws""
> "The program received considerable criticism for cost overruns during development"
> Czyli to chyba nie był najlepszy przykład. :-)

Kontrprzykład to Ariane-5 do której jako programistów zatrudnili 
hackerów dłubiących na poziomie bitów i całe to bezpieczeństwo Ady 
poszło w pizdu. Jak w większości "bezpiecznych" języków nic nie 
ogranicza przed hackerami emulującymi sobie w środku asembler.

Z chęcią bym zobaczył jakiś przykąłd porządnie zrobionego projektu w 
Adzie, ale będzie on zapewne albo akademicki i interesujacy, albo 
przemysłowy i zrobiony za pomocą jakiegoś odpowiednika MISRA czyli flaki 
z olejem.

>> nie ten klimat i nie te czasy...
> 
> Po czym poznać, że klimat i czasy są właściwe?

Tu poruszamy 2 sprawy:
1. Klimat - wspomniana "Syrenka kabrio" nie sprawdzi się u nas - nie ten 
klimat (często pada i mamy tu zimy).

2. Właściwe czasy - to szerszy temat:
- Model obiektowy Ady:
Ze strony: 
https://learn.adacore.com/courses/intro-to-ada/chapters/object_oriented_programming.html

Rzuciłem na to okiem i tak jak prawie 20 lat temu było i teraz jest to 
straszne...

- Czy mamy dla Ady:
	- środowiska programowania z dynamicznym sprawdzaniem poprawności kodu 
(jak w Qt Creator)
	- środowiska programowania z możliwością uruchamiania programu ze 
śledzeniem (debuger)
	- profiler (liczba wywołań funkcji i wykrywanie wycieków pamięci)
	- bibliotekę Gui (co np. z OpenGl - da się używać?)
	- wsparcie dla internacjonalizacji Gui
	- czy można w Ada pisać jednocześnie na wiele systemów operacyjnych 
(przenośnie)
	- czy Ada oferuje wyjątki (do zgłaszania błędów)
	- czy można dokumentować kod w komentarzach (Doxygen lub podobne)

Moim zdaniem to wszystko musi być jeśli chcemy zająć się programowaniem 
na poważnie i bez przyjmowania jakichś sztucznych ograniczeń. Przejście 
na inny język to nie tylko kwestia składni - wiele zależy od wsparcia w 
obszarach jakie wymieniłem. I tak się składa, że C++ ma to wszystko (i 
więcej). To dla tego język D nie może "zaistnieć" bo po prostu jest 
słabo wspierany, a nie to że jest zły (choć największe zło w nim polega 
na tym, że nie ma wielodziedziczenia).

Ja przy tym wszystkim zupełnie nie wiem gdzie można by pracować w 
Trójmieście (w którym mieszkam) profesjonalnie programując w Ada. Już 
będąc programistą C++ mam problem ze znalezieniem pracy... Jednak się 
tym nie zrażam, bo w C++ widzę rozsądek (wydajność, możliwości, 
składania i wsparcie) i potencjał. Wszystkie inne języki konkurencyjne 
nie mają któregoś z tych 4 zdroworozsądkowych parametrów lub nie mają 
potencjału.

Nie zrozum mnie źle: to dobrze, że jest wiele języków programowania. 
Jednak trzeba wiedzieć co one mogą i do czego ew. je stosować.
Obecnie jest tak, że do krytycznych zadań przy zaczynaniu nowego 
projektu i przy NORMALNYM podejmowaniu decyzji (opartym na doświadczeniu 
a nie na polityce czy tradycjach) nadaje się tylko C++. I faktycznie 
najważniejsze aplikacje jakich na co dzień się używa są pisane w C++ - 
to nie przypadek. A pozostałe języki w 90% też są kodowane w C++.

Ada stosowana jest w branży zbrojeniowej i może można na tym zarobić. 
Jednak ja zupełnie nie widzę jej przewagi nad C++, a wręcz przeciwnie 
widzę brak kompatybilności jeśli chodzi o popularne narzędzia i dostępne 
biblioteki (C i C++).

> Jak w większości "bezpiecznych" języków nic nie 
> ogranicza przed hackerami emulującymi sobie w środku asembler.

Mógłbyś rozwinąć tą myśl?!?

On 20/04/2019 13:46, Szyk Cech wrote:
>> Jak w większości "bezpiecznych" języków nic nie ogranicza przed 
>> hackerami emulującymi sobie w środku asembler.
> Mógłbyś rozwinąć tą myśl?!?

Ależ bardzo prosto. Ariane dupneła z powodu tego że ktoś w "bezpiecznym" 
języku zrobił założenie że coś zmieci się w 16 bitach. Typowe myślenie 
asemblerowca który wszędzie widzi bajty do oszczędzenia.

Tu masz fragmenty kodu:

https://hownot2code.com/2016/09/02/a-space-error-370-million-for-an-integer-overflow/

Wygląda jak asembler wydziobany ręcznie. I tak oto bezpieczny język 
posłużył jako platforma do napisania nispoziomowego kodu do manipulacji 
liczbami w sposób błędny. Dzień jak codzień. No i jeszcze księgowi 
dorzucili swoje:

"The protection of all 7 (including BH) variables wasn’t provided 
because the maximum workload for the IRS computer was declared as 80%."

> Tu masz fragmenty kodu:
> 
> https://hownot2code.com/2016/09/02/a-space-error-370-million-for-an-integer-overflow/ 

"The erroneous module was never properly tested in the new environment – 
neither the hardware, nor the level of system integration. Therefore, 
the flaws in the development and implementation were not detected."

Czyli poleciało nieprzetestowane. To zamyka temat: błąd programisty to 
jedno, ale brak przetestowania to strategiczne partactwo firmy która to 
robiła.

Żaden kod nie powinien być udostępniany bez przejścia specjalnie 
zdefiniowanej procedury testowej (choćby wykonywanej "ręcznie"). A kod 
krytyczny zawsze powinien być obłożony testami automatycznymi.

Niestety w polskich firmach dedykowani testerzy to wciąż egzotyka. Moim 
zdaniem te firmy są skazane na wymarcie - właśnie ze względu na 
partackie podejście do procesu wytwórczego.

> 2. Właściwe czasy - to szerszy temat:
> - Model obiektowy Ady:
> Ze strony: 
> https://learn.adacore.com/courses/intro-to-ada/chapters/object_oriented_programming.html
> 
> Rzuciłem na to okiem i tak jak prawie 20 lat temu było i teraz jest to 
> straszne...

Niezupełnie, bo akurat w ciągu tych 20 lat wprowadzono składnię, której 20 lat temu nie było.
Niemniej, faktem jest, że obiektowość w Adzie wygląda trochę inaczej, niż np. w Javie. Czy to gorzej czy lepiej, zdania są podzielone.

> - Czy mamy dla Ady:
> 	- środowiska programowania z dynamicznym sprawdzaniem poprawności kodu

Z dynamicznym? A po co z dynamicznym?
Do statycznego jest np. to:

https://www.adacore.com/codepeer

albo to:

http://www.adalog.fr/en/adacontrol.html

albo choćby kompilator w trybie sprawdzania poprawności (w odróżnieniu od trybu translacji).
 
> 	- środowiska programowania z możliwością uruchamiania programu ze 
> śledzeniem (debuger)

Kilka. Współcześnie rozwijany to GNAT Programming Studio:

https://www.adacore.com/gnatpro/toolsuite/gps

> 	- profiler (liczba wywołań funkcji i wykrywanie wycieków pamięci)

Ogólnie, GNAT oparty jest o GCC, więc wykorzystuje ten sam debugger, profiler i całą resztę dostępną w GCC.

> 	- bibliotekę Gui

Wszystkie poważne:

https://en.wikibooks.org/wiki/Ada_Programming/Libraries/GUI

> (co np. z OpenGl - da się używać?)

http://flyx.github.io/OpenGLAda/

> 	- wsparcie dla internacjonalizacji Gui

Przypuszczam, że razem z tymi bibliotekami powyżej.

> 	- czy można w Ada pisać jednocześnie na wiele systemów operacyjnych 
> (przenośnie)

Tak. Patrz wyżej, GNAT oparty jest o GCC.

> 	- czy Ada oferuje wyjątki (do zgłaszania błędów)

Tak, chociaż wyglądają one inaczej, niż w C++ (nie są obiektami ani wartościami).

> 	- czy można dokumentować kod w komentarzach (Doxygen lub podobne)

Czyli czy można generować dokumentację HTML z kodu na podstawie komentarzy? Pewnie można, sam kiedyś napisałem skrypt, który to robi.

> Moim zdaniem to wszystko musi być jeśli chcemy zająć się programowaniem 
> na poważnie

Nie. Na poważnie powinno być dużo więcej, zależnie od tworzonych systemów.

> Ja przy tym wszystkim zupełnie nie wiem gdzie można by pracować w 
> Trójmieście (w którym mieszkam) profesjonalnie programując w Ada.

Ja też nie wiem. Ale to nie zmienia faktu, że i tak zapraszam na tutorial. :-)

> Ada stosowana jest w branży zbrojeniowej

https://www.adacore.com/industries

> Jednak ja zupełnie nie widzę jej przewagi nad C++

Znajomość Ady będzie Twoją przewagą gdy będziesz pisał, nawet w C++.

-- 
Maciej Sobczak

Problem jest znacznie bardziej. Testowanie to proteza. Czasem
 pomaga. Raczej nie szkodzi. Ale rozwiązaniem jest inne spojrzenie
 na to czym jest bug, czym jest program itd. Myśleliśmy że
 komputery będą wolne od ludzkich słabości. Ale tak nie jest.
 Musimy nauczyć się akceptować i określić co chcemy akceptować.
 Przykładowo: czy jeżeli automatyczne lądowanie F35 może zakończyć
 się śmiercią pilota to jest to ok? Dodatkowe dane:
 prawdopodobieństwo jest znacznie mniejsze niż gdy pilotuje
 człowiek - ale większe niż zero i - gdyby napisać lepiej program
 byłoby mniejsze.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

W dniu wtorek, 23 kwietnia 2019 21:27:13 UTC+2 użytkownik slawek napisał:
> Problem jest znacznie bardziej. Testowanie to proteza. Czasem
>  pomaga. Raczej nie szkodzi.

?
Testowanie to proteza?!
"Zbudowaliśmy dla państwa samolot. Nie, nie przetestowaliśmy, ale w teorii wszystko powinno działać."
"Jutro oddajemy most do użytku. Nie testowaliśmy, ale mamy na miejscu inżyniera. Jak by się działo coś złego, to naprawi"

Testowanie jest integralną częścią budowy każdego systemu.

> Ale rozwiązaniem jest inne spojrzenie
>  na to czym jest bug, czym jest program itd. Myśleliśmy że
>  komputery będą wolne od ludzkich słabości. Ale tak nie jest.

?!
"Mój komputer pierdzi jak się obeżre grochu"
"Zrezygnowaliśmy z instalacji kolejnej aplikacji, bo komputer powiedział, że jest już zmęczony i chce iść spać"
"Tegoroczne wybory zostają odwołane z powodu strajku maszyn obliczeniowych"
"Komputer powiedział, że nie będzie uruchamiał aplikacji finansowych w piątek 13tego, bo to przynosi pecha"

>  Musimy nauczyć się akceptować i określić co chcemy akceptować.

Kolega opowiadał historię, jak koleżanki jego mamy z pracy korzystające z Windowsa 95 wezwały go kiedyś, bo miały problem z wyskakującym niebieskim ekranem.
Miały na ten temat różne hipotezy - że na przykład jak się przejdzie przez drzwi, to się robi niebieski ekran, albo że jak się będzie podlewało kwiat, itd.

Ludzie są aż za dobrzy w wymyślaniu nierzeczywistych przyczyn dla zjawisk.
(Dowodem na to jest istnienie wielu religii i kultów).

Rzeczywistą przyczyną problemu był WinNuke. Kolega powiedział, żeby odłączyły komputery od sieci, i wtedy problem rzeczywiście zniknął.

Tym, czego musimy się nauczyć, nie jest akceptowanie, tylko rozumienie.
Idealnie byłoby, gdyby użytkownik systemu mógł łatwo rozumieć zasady działania systemu, którego używa, i samemu móc go zmieniać.
W świecie komputerów to nie jest jakiś "utopijny ideał".

>  Przykładowo: czy jeżeli automatyczne lądowanie F35 może zakończyć
>  się śmiercią pilota to jest to ok?

Nie, to nie jest ok.

> Dodatkowe dane:
>  prawdopodobieństwo jest znacznie mniejsze niż gdy pilotuje
>  człowiek - ale większe niż zero i - gdyby napisać lepiej program
>  byłoby mniejsze.

I gdyby go dobrze wytestować, żeby przynajmniej znać ryzyko.

On Wednesday, April 17, 2019 at 8:43:22 PM UTC+2, Szyk Cech wrote:
> Inna sprawa, że F-35-coding-rules.pdf wprowadza takie ograniczenia, że z 
> tego C++ zostaje może 25% przez co programowanie zgodnie z tymi 
> zaleceniami jest bardziej prymitywne niż w latach 90 XXw (czyli z przed 
> standaryzacji C++). Widać, że ktoś bardzo lubił Ada-ę i pomyślał, że w 
> zasadzie można by tak samo programować w C++.

Nie, ktoś znał bardzo dobrze C++ i wywalił wszystkie niebezpieczne
i błędogenne konstrukcje. C++ zachęca do pisania w stylu "write
once, debug endlessly", co się słabo sprawdza przy sterowaniu
maszyną wartą sześcio-, czy siedmiocyfrową kwotę.

Zadanie dla chętnych: w ilu miejscach może tu polecieć wyjątek?
Type1 i Type2 to jakieś klasy dostarczone przez użytkownika,
nic o nich nie wiemy.

Type1 fun(Type2 a, Type2 b)
{
   if (a.get_value() > b.get_value()) {
      return a.get_foo();
   }
   
   return a.get_bar() + b.get_foo();
}

w.

> Zadanie dla chętnych: w ilu miejscach może tu polecieć wyjątek?

Kogo to obchodzi? Moje (proste i sprawdzone w praktyce w programowaniu w 
C++ z Qt od 10 lat) zasady obsługi wyjątków są takie:

1. Każda klasa wyjątku dziedziczy po std::exception (tego przestrzegają 
też klasy wyjątków Qt),

2. Obstawiamy funkcję main czymś takim:

#define MAIN_CONSOLE_CATCH \
     catch(Exception& aEx)   \
     {   \
         QTextStream lErr(stderr);   \
         lErr << QObject::tr("Exception occurs! Sender: %1, Error code: 
%2\nMessage:\n%3").arg(aEx.senderName()).arg(aEx.errorCode()).arg(aEx.what()).toUtf8() 
<< endl << flush;  \
         return EXIT_FAILURE;    \
     }   \
     catch(std::exception& aEx)  \
     {   \
         QTextStream lErr(stderr);   \
         lErr << QObject::tr("Exception 
occurs!\nMessage:\n%1").arg(aEx.what()).toUtf8() << endl << flush;    \
         return EXIT_FAILURE;    \
     }   \
     catch(...)  \
     {   \
         QTextStream lErr(stderr);   \
         lErr << QObject::tr("Unknown exception occurs!") << endl << 
flush;   \
         return EXIT_FAILURE;    \
     }


3. Obstawiamy wszystkie funkcje obsługi zdarzeń
4. Obstawiamy wszystkie funkcje wątków, obie czymś takim:

#define STANDARD_CATCH \
     catch(Exception& aEx) \
     { \
         gCritical(QObject::tr("Exception occurs!\n%1").arg(aEx.what()), 
aEx.senderName(), static_cast<quint64>(aEx.errorCode())); \
     } \
     catch(std::exception& aEx) \
     { \
         gCritical(QObject::tr("Exception occurs!\n%1").arg(aEx.what()), 
QObject::tr("Unkonwn"), 
static_cast<quint64>(EnergoKodTools::eErrorCode::eUnknown)); \
     } \
     catch(...) \
     { \
         gCritical(QObject::tr("Unknown exception occurs!"), 
QObject::tr("Unkonwn"), 
static_cast<quint64>(EnergoKodTools::eErrorCode::eUnknown)); \
     }

Gdzie gCritical jest czymś takim:

inline void gCritical(QString aText, QString aSender, quint64 aErrorCode)
{
     Errors::instance()->error(aText, eErrorType::eCritical, aSender, 
aErrorCode);
     gMessage(QMessageBox::Critical, QObject::tr("Critical"), aText, 
QStringLiteral("Error: %1\nModule: %2\nCode: 
%3").arg(aText).arg(aSender).arg(aErrorCode));
}

Errors to klasa "silnik", singleton zbierania błędów (do ew. 
wyświetlenia i ew. zaraportowania).
A gMessage to:

inline void gMessage(QMessageBox::Icon aIcon, QString aShortText, 
QString aInformativeText, QString aDetailedText = QStringLiteral(""))
{
     QTextStream lErrStream(stderr);
     lErrStream << QObject::tr("%1 
%2\n%3").arg(qApp->applicationName()).arg(aShortText).arg(aInformativeText);
     if(!aDetailedText.isEmpty())
         lErrStream << endl << aDetailedText;

     QMessageBox lMessage;
     lMessage.setText(aShortText);
     lMessage.setInformativeText(aInformativeText);
     lMessage.setDetailedText(aDetailedText);
     lMessage.setIcon(aIcon);
     lMessage.exec();
}

I wtedy wszystko jest proste...

On 07/05/2019 21:15, Wojciech Muła wrote:
> Zadanie dla chętnych: w ilu miejscach może tu polecieć wyjątek?
> Type1 i Type2 to jakieś klasy dostarczone przez użytkownika,
> nic o nich nie wiemy.
> 
> Type1 fun(Type2 a, Type2 b)
> {
>     if (a.get_value() > b.get_value()) {
>        return a.get_foo();
>     }
>     
>     return a.get_bar() + b.get_foo();
> }

Skoro nic o nich nie wiemy to obsługa tego wyjątku ma znaleźć się w 
kodzie który coś o Type1 i Type2 wie czyli pewnie poziom niżej. Inaczej 
kończysz na try {} catch(...) to jest jeszcze gorsze.

Wyjątki nie łapie się po każdym dodawaniu. Łapie się tam gdzie wiadomo 
co z nimi zrobić.

> Wyjątki nie łapie się po każdym dodawaniu. Łapie się tam gdzie wiadomo 
> co z nimi zrobić.

Bardzo dobrze.
Problem tylko w tym, że bardzo rzadko wiadomo, co z nimi zrobić. Często sprowadza się to do pokazania użytkownikowi komunikatu o błędzie. Albo do wrzucenia go do logu. Oba te przypadki nie mają zastosowania w systemach krytycznych takich jak sterowanie samolotem.
W szczególności, standard kodowania dla tego samolotu w ogóle zabrania używania wyjątków.

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

On Tuesday, May 7, 2019 at 10:52:14 PM UTC+2, heby wrote:
> On 07/05/2019 21:15, Wojciech Muła wrote:
> > Zadanie dla chętnych: w ilu miejscach może tu polecieć wyjątek?
> > Type1 i Type2 to jakieś klasy dostarczone przez użytkownika,
> > nic o nich nie wiemy.
> > 
> > Type1 fun(Type2 a, Type2 b)
> > {
> >     if (a.get_value() > b.get_value()) {
> >        return a.get_foo();
> >     }
> >     
> >     return a.get_bar() + b.get_foo();
> > }
> 
> Skoro nic o nich nie wiemy to obsługa tego wyjątku ma znaleźć się w 
> kodzie który coś o Type1 i Type2 wie czyli pewnie poziom niżej. Inaczej 
> kończysz na try {} catch(...) to jest jeszcze gorsze.
> 
> Wyjątki nie łapie się po każdym dodawaniu. Łapie się tam gdzie wiadomo 
> co z nimi zrobić.

Ale łapanie wyjątku to jest połowiczne rozwiązanie problemu. W szczególności,
jeśli wyjątek może pójść w dowolnym miejscu kodu (w tym przykładzie jest co
najmniej 13 miejsc, skąd może coś polecieć), to jaki będzie stan obiektu na
rzecz którego wołano metodę? Czy np. taki obiekt można bezpiecznie używać
dalej (stan wewnętrzny pozostał spójny)? Albo chociaż wywołać destruktor?
A co jeśli wyjątek leci z miejsca, o którym wierzyłeś, że nigdy nie poleci
i jednak dostajesz terminate?

w.

On 08/05/2019 07:54, Maciej Sobczak wrote:
>> Wyjątki nie łapie się po każdym dodawaniu. Łapie się tam gdzie wiadomo
>> co z nimi zrobić.
> Bardzo dobrze.

To jakiś egzamin?

> Problem tylko w tym, że bardzo rzadko wiadomo, co z nimi zrobić.

I jaki to ma związek z narzekaniem na jezyk C++?

> Często sprowadza się to do pokazania użytkownikowi komunikatu o błędzie.

Nie wiem co to znaczy "często", ale u mnie raczej nie.

> Oba te przypadki nie mają zastosowania w systemach krytycznych takich jak sterowanie samolotem.

Ale przecież przykład miał służyć marudzeniu o bezdennnym dziadostwie C++.

> W szczególności, standard kodowania dla tego samolotu w ogóle zabrania używania wyjątków.

Standardy kodowania zawiarają dużo więceń wykluczeń, wiele z nich 
generuje po stronie programisty emulacje zachowań wykluczonych.

Taki mały przykłąd z systemu krytycznego:

return a() && b() && c() && d() ... ;

To jest emulacja wyjątku w środowisku gdzie wyjątków ma nie być. Wyszło 
jak zwykle. Parcie na systemy ograniczone wcale nie generuje lepszego 
jakościowo kodu, co najwyżej generuje kod który lepiej ogarnia się 
formalną weryfikacją a i to jest mocno naciągane.

On 08/05/2019 15:32, Wojciech Muła wrote:
> Ale łapanie wyjątku to jest połowiczne rozwiązanie problemu. W szczególności,
> jeśli wyjątek może pójść w dowolnym miejscu kodu (w tym przykładzie jest co
> najmniej 13 miejsc, skąd może coś polecieć), to jaki będzie stan obiektu na
> rzecz którego wołano metodę?

Taki w jakim paradygmacie napisałeś kod. Mogłeś napisać pure function, 
mogłeś napisać kod z oparciem o transakcje z RAII, mogłeś totalnie sp... 
i napisać kod bazujacy na sideeffectach globalnych. Przecież jest wybór 
i akurat C++ pozwala napisać kod cholernie bezpiecznie i cholernie 
niebezpiecznie na raz. Ba, lisp też i ada też. To się załatwia code 
review i kilkoma developerami w zespole którzy potrafią zrozumieć na 
pisać kod aby nie trzeba było go debugować "endlessly" a to czy to C++ 
nie jest jakoś specjalnie istotne bo każdy język jest Turing-complete 
wiec poziom spieprzenia można osiągnąć identyczny.

Przedstawiona funkcja jest generyczna. Jeśli by ta funkcja miała 
dodatkowo zajmować się ogarnianiem stanu swoich argumentów wejściowych i 
łapaniem bilionów detalicznych exceptionów a nastepnie szukaniem w 
szklanej kuli co z nimi zrobić to niestety ale taki programista nie ma 
racji bytu w dowolnej branży bo to najzwyczajniej spieprzony kod jest i 
to w najgorszy możliwy sposób.

> Czy np. taki obiekt można bezpiecznie używać
> dalej (stan wewnętrzny pozostał spójny)?

Nigdy tego nie wiesz. Ale AKURAT ten znienawidzony C++ ma całkiem 
przyzwoite metody ograniczania działania sideeefectów jak scope i RAII. 
Po ich uzyciu jestem w stanie kontrolować sideeefecty znacząco wygodniej 
niż w innych językach imperatywnych, w sytuacjach krytycznych. Tylko że 
można też pisać kod funkcyjnie i tego nie robić. Masz wybór.

No tak, zapomniałem że standarny produkcji automatyki do dildo 
zabraniają używania RAII, pętli while, tabulacji i nieparzystych 
wartości inta.

Ariane pokazało że wybranie Ady nie powoduje że ludzie piszą kod 
bezpiecznie, dalej pisali w asemblerze. Nie wybór języka jest istotny 
tylko programisty. Wybrali hackerów, mają kupę a nie bezpieczny kod bez 
względu na koszerność języka.

> Albo chociaż wywołać destruktor?

Zawsze wywoła destruktor, *ZAWSZE* za wyjątkiem przypadku buga w 
kompilatorze. Chyba że lubisz longjmp. Widziałem już w "krytycznie 
bezpiecznym kodzie" wiec idiotów nie brakuje.

> A co jeśli wyjątek leci z miejsca, o którym wierzyłeś, że nigdy nie poleci
> i jednak dostajesz terminate?

To wykrywam to w unit testach i poprawiam buga. Ostatecznie ktos umiera 
bo mu rozrusznik nie zadziałał. Boeing nie ma z tym dzisiaj jak widać 
problemu, Toyota nie miała ze swoim pedłem gazu itd itp. Najzwyczajniej 
nie da się ogarnąć systemu mającego kilka tyś lini kodu formalnie a 
pojedyncze przypadki kiedy się to udało, jak L4, są raczej 
potwierdzeniem że wymaga to nadludzkiego wysiłku. A zakładanie że pisze 
się kod bez bugów jest absurdem. Jesteśmy zbudowani z białka i nic na to 
nie poradzimy choć potrafimy to znacząco poprawiać używając inżynierii 
(o)programowania znanej od lat co najmniej 60. Ani Toyota ani Ariane nie 
są przykładem używania tych technik bo w obu wypadkach można było je 
zasymulować wcześniej invitro.

A co sie stanie jak w ten kod trafi meteoryt z Neptuna? Jesteś na to 
przygotowany?

> > Bardzo dobrze.
> 
> To jakiś egzamin?

A jakbym normalnie i zgodnie z grupowymi zwyczajami zawalił Cię bluzgami, to by nie był? :-)

> > Problem tylko w tym, że bardzo rzadko wiadomo, co z nimi zrobić.
> 
> I jaki to ma związek z narzekaniem na jezyk C++?

Myślałem, że narzekamy na standard kodowania. Zakaz używania wyjątków jest dosyć uniwersalny, niezależny od języka.

> > Często sprowadza się to do pokazania użytkownikowi komunikatu o błędzie.
> 
> Nie wiem co to znaczy "często", ale u mnie raczej nie.

Interesujące. Ale to może (!) oznaczać, że obsługujesz wyjątki relatywnie blisko ich wystąpienia.

> Ale przecież przykład miał służyć marudzeniu o bezdennnym dziadostwie C++.

Właśnie zgubiłem się, co hejtujemy. Jeśli C++, to niesłusznie (co za niespodzianka!), bo zakaz wyjątków jest niezależny od języka.

> Taki mały przykłąd z systemu krytycznego:
> 
> return a() && b() && c() && d() ... ;
> 
> To jest emulacja wyjątku w środowisku gdzie wyjątków ma nie być. Wyszło 
> jak zwykle. Parcie na systemy ograniczone wcale nie generuje lepszego 
> jakościowo kodu, co najwyżej generuje kod który lepiej ogarnia się 
> formalną weryfikacją a i to jest mocno naciągane.

Niezupełnie. W takich systemach może być wymaganie na pokrycie testami każdej ścieżki. Jeżeli są wyjątki, to tych ścieżek nawet nie widać a rozstrzygnięcie automatyczne ile ich jest i gdzie może wymagać dostępu do całego kodu i nawet wtedy może być nierealne. Natomiast użycie iloczynu logicznego tak jak powyżej, chociaż wątpliwe stylistycznie, jest jednak lokalne - tzn. analizę wszystkich ścieżek da się zrobić w ramach tylko tego wyrażenia. Wtedy znacznie łatwiej spełnić wymaganie pokrycia testami.
Dlatego nie zgadzam się z określeniem "wyszło jak zwykle". Ten przykład da się obronić. Stylistycznie słaby (subiektywnie), ale broni się na poziomie procesu.

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

> Ariane pokazało że wybranie Ady nie powoduje że ludzie piszą kod 
> bezpiecznie, dalej pisali w asemblerze. Nie wybór języka jest istotny 
> tylko programisty.

Też nie. Tzn. programiści lubią wierzyć w swoją wyjątkowość, ale przedstawione przez Ciebie przykłady (Ariane, Toyota, Boeing) akurat wskazują na błędy w zarządzaniu i w wymaganiach. Programista może być perfekcjonistą, ale perfekcyjnie zaimplementowane złe wymagania albo system złożony do kupy z niewłaściwych komponentów i tak będą się rozpadać i zabijać.
Procesy jakościowe (o ile są przestrzegane) w ogóle nie zakładają, że programista będzie perfekcyjny. Wręcz przeciwnie - założenie jest właśnie takie, że programista spieprzy wszystko, co się da. Jakość wynika z procesów integralnych (z weryfikacji) a nie z deweloperskich. Pytanie, czy takie procesy integralne są. Problem w tym, że łatwo z nich zrezygnować.

> Wybrali hackerów, mają kupę a nie bezpieczny kod bez 
> względu na koszerność języka.

Wybór języka wpływa na to, jak łatwo jest coś spieprzyć. A ponieważ zakładamy, że programista spieprzy wszystko co może, to wybór języka jest ważny. Żeby mógł spieprzyć jak najmniej.

> > A co jeśli wyjątek leci z miejsca, o którym wierzyłeś, że nigdy nie poleci
> > i jednak dostajesz terminate?
> 
> To wykrywam to w unit testach i poprawiam buga.

Unit testy nie wykrywają wyjątków. Chyba że mamy inne rozumienie tego terminu.

> A co sie stanie jak w ten kod trafi meteoryt z Neptuna? Jesteś na to 
> przygotowany?

Jeśli takie są wymagania, to powinien być.

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

On Tue, 7 May 2019 12:15:04 -0700 (PDT), Wojciech Muła wrote:

> Zadanie dla chętnych: w ilu miejscach może tu polecieć wyjątek?
> Type1 i Type2 to jakieś klasy dostarczone przez użytkownika,
> nic o nich nie wiemy.
> 
> Type1 fun(Type2 a, Type2 b)
> {
>    if (a.get_value() > b.get_value()) {
>       return a.get_foo();
>    }
>    
>    return a.get_bar() + b.get_foo();
> }
> 
> w.

Ja tak z ciekawości, bo napisałeś dalej, że jest tych miejsc 13, czy
mógłbyś je wskazać? Nie programuję w C++, więc widzę tylko możliwość
wysypki w wywołaniach metod (zarówno w nich samych jak i na ich braku czyli
nilu). Ale z tego i tak nie wyjdzie aż 13. Czy masz tu na myśli jeszcze
przeciążanie operatorów? Co jeszcze?

-- 
pozdrawiam
Roman Tyczka

On 09/05/2019 08:04, Maciej Sobczak wrote:
> Myślałem, że narzekamy na standard kodowania.

Nie, tu padło jakieś hasło "C++ zachęca do pisania w stylu "write
once, debug endlessly"". Problem w tym że to jest walidne w każdym 
języku a w c++ z roku na rok o dziwo coraz mniej.

> Zakaz używania wyjątków jest dosyć uniwersalny, niezależny od języka.
>>> Często sprowadza się to do pokazania użytkownikowi komunikatu o błędzie.
>> Nie wiem co to znaczy "często", ale u mnie raczej nie.> 
> Interesujące. Ale to może (!) oznaczać, że obsługujesz wyjątki relatywnie blisko ich wystąpienia.

Może, ale może też oznaczać że nie mam wyświetlacza i wiem po co je rzucam.

>> return a() && b() && c() && d() ... ;
>> To jest emulacja wyjątku w środowisku gdzie wyjątków ma nie być. Wyszło
>> jak zwykle. Parcie na systemy ograniczone wcale nie generuje lepszego
>> jakościowo kodu, co najwyżej generuje kod który lepiej ogarnia się
>> formalną weryfikacją a i to jest mocno naciągane.
> Niezupełnie. W takich systemach może być wymaganie na pokrycie testami każdej ścieżki.

Nie. W typowym systemie nie wymaga się pokrycia *każdej* ścieżki, wymaga 
się pokrycia określonego procentu. Ba, wymaga się pokrycia nie tylko 
ściezki wykonywania kodu, ale np. zbioru wartości danych zmiennych.

Jeśli masz kilkaset tyś lini kodu to nie jest mozliwe pokrycie go w 100% 
bo bywa że liczba stanów wejściwych i ich kobinacji przekracza zdrowy 
rozsądek. Ludzie robiący systemy krytyczne używają specjalistycznych 
narzędzie do oceny czy dany kod spełnia warunki czy nie, często są to 
zabawki oparte o randomizacje. I prawie nigdy to nie jest 100%. 100% to 
można sobie osiągnąć w kodzie do migania diodą czy przedsionkiem serca.

> Jeżeli są wyjątki, to tych ścieżek nawet nie widać

Mało kto patzy na kod. Do testowania pokrycia stosuje się automatykę. 
Ona widzi wyjątki tak samo jak logjmp.

> a rozstrzygnięcie automatyczne ile ich jest i gdzie może wymagać dostępu do całego kodu i nawet wtedy może być nierealne.

Zmartwie Cie. Zazwyczaj dostep do całego kodu nie jest potrzebny jeśli 
*formalnie* coś udowodnisz w module w środku. To że przez funkcję 
generyczną przelatują wyjąki i robią bałagan ze stanem czegośtam nie 
jest absolutnie problemem funkcji generycznej tylko kodu na zewnątrz. O 
to tu chodzi: przedstawiony przykład przez Wojtka jest kompletnie 
pozbawiony sensu, funkcje generyczne nigdy, przenigdy, nie powinny 
zajmować się sytuacjami zwiazanymi ze światem zewnątrznym a już na pewno 
nie obsługiwać cudze sideeffecty.

Nie stosuje wyjątków w praktyce. Ale stosuje dość intensywne testowanie 
w praktyce. Gdybym miał tam dorzucić wyjątki jakoś niespecjalnie by mnie 
to zmartwiło, co najwyżej powiększyło zbiór testów.

> Natomiast użycie iloczynu logicznego tak jak powyżej, chociaż wątpliwe stylistycznie, jest jednak lokalne
 >- tzn. analizę wszystkich ścieżek da się zrobić w ramach tylko tego 
wyrażenia. Wtedy znacznie łatwiej spełnić wymaganie pokrycia testami.

Znowu Cie zmartwie: możesz pokryć tą generyczną funkcję testami w 100% a 
i tak ktoś rzuci wyjątkiem który przez nią przeleci inną ścieżką, 
podobnie scheduler preemptive może zmienić stan globalny albo meteoryt z 
Neptuna puknąć w serwer. Ogólnie można zbadać *wszystkie* ściezki, ale 
obawiam się że w praktyce to jest tylko akademicki pogląd, w przemyśle 
nawet w aplikacjach do latania stosuje się śmiesze liczby w rodzaju 99% 
itp. które mają związek z realnym poglądem na świat i doświadczeniem z 
faktycznymi możliwościami ogarniania kodu przez białko.

Zleceniodwaca może oczywiście chcieć 100% ale wtedy będzie czekał na 
software przez 10 lat.

System w którym lata milion wyjątków jest do dupy. Ale narzekanie że 
funkcja generyczna jest do dupy bo może przez nią przelecieć wyjątek 
jest absurdalne.

> Dlatego nie zgadzam się z określeniem "wyszło jak zwykle". Ten przykład da się obronić. Stylistycznie słaby (subiektywnie), ale broni się na poziomie procesu.

Oczywiscie że da się obronić, w końcu skoro nie można uzywać normalnych 
technik programowania, jak wyjątki, to przeciez lepiej je koślawo 
zaemulować. Tak samo jak miszczofie C żałośnie emulują RAII i uważają to 
za punkt honoru.

On 09/05/2019 08:21, Maciej Sobczak wrote:
>> Ariane pokazało że wybranie Ady nie powoduje że ludzie piszą kod
>> bezpiecznie, dalej pisali w asemblerze. Nie wybór języka jest istotny
>> tylko programisty.
> 
> Też nie. Tzn. programiści lubią wierzyć w swoją wyjątkowość, ale przedstawione przez Ciebie przykłady (Ariane, Toyota, Boeing)
> akurat wskazują na błędy w zarządzaniu i w wymaganiach.

Oczywiście, ja tylko odczarowuje durny pogląd "weźmy Adę, będzie 
bezpiecznie". Bez ludzi majcych pojęcie o bezpieczeństwie nigdzie się z 
tym nie dojdzie a w spełnianiu wymogów akurat hackerzy są bardzo dobrzy 
na co przykłądem jest to że jednak dali radę w Ariane spełnic wymogi.

> Procesy jakościowe (o ile są przestrzegane) w ogóle nie zakładają, że programista będzie perfekcyjny.
> Wręcz przeciwnie - założenie jest właśnie takie, że programista spieprzy wszystko, co się da.

Ciesze się że się zgadzamy.

> Jakość wynika z procesów integralnych (z weryfikacji) a nie z deweloperskich. Pytanie, czy takie procesy integralne są. Problem w tym, że łatwo z nich zrezygnować.

Tu się nie zgadzam. Można poprawnie zweryfikować dowolną kupę. Jakośc 
developerki nie ma wpływu wprost na magiczne 100% ale ma duży wpływ na 
obniżanie tego 100% do "no, szefie, nie damy rady 80%, mozemy ze 70% i 
tyle bo Steve spier... i nikt nie wie jak to działa". Wymogi nie są z 
betonu i dziwnym trafem potrafią sobie pływać w trakcie procesu produkcji.

>> Wybrali hackerów, mają kupę a nie bezpieczny kod bez
>> względu na koszerność języka.
> Wybór języka wpływa na to, jak łatwo jest coś spieprzyć.

Więc w C++ z roku na rok coraz trudniej spieprzyć. Oczywiście za 
wyjątkiem reszty świata która używa MISRA i dalej uważa że nie wymyślono 
nic bezpieczniejszego niż ręczną emulacje C++ w C.

> A ponieważ zakładamy, że programista spieprzy wszystko co może, to wybór języka jest ważny. Żeby mógł spieprzyć jak najmniej.

A mimo to spieprzył. Ariane zdetonowała z powodu używania bezpiecznego 
języka w niebezpieczny sposób. Czekamy na nastepny język o śmiesznej 
nazwie gdzie będzie jeszcze więćej bezstanowości, korutyn, monad i całej 
masy innych niezwykle przydatnych rzeczy do pisania niebezpiecznego kodu 
w asemblerze. Go, Dart, Kotlin, TypeScript. Co tam ostatnio wymyślili 
bezpieczniejszego bo od tygodnia nie zaglądałem na weba?

>>> A co jeśli wyjątek leci z miejsca, o którym wierzyłeś, że nigdy nie poleci
>>> i jednak dostajesz terminate?
>> To wykrywam to w unit testach i poprawiam buga.
> Unit testy nie wykrywają wyjątków. Chyba że mamy inne rozumienie tego terminu.

ASSERT_THROW. ASSERT_NO_THROW. Całkiem fajnie wykrywają.

>> A co sie stanie jak w ten kod trafi meteoryt z Neptuna? Jesteś na to
>> przygotowany?
> Jeśli takie są wymagania, to powinien być.

Więc jesli mógłbym prosić, przygotuj swoją funkcję na obsługę wyjątków. 
We wszystkich nastu miejscach. Zabawmy się w taki wymóg. Potem łatwo 
udowodnimy że std::vector pisali dyletanci bo przecież nie uwględnili że 
z konstruktora kopiującego element może wylecieć wyjątek i zamkniemy 
narzekanie o C++ konkluzją że jest do dupy i dlatego uzywa się MISRA-C 
gdzie wszystko jest do dupy ale weryfikowalnej formalnie dupy a taka 
jest znacząco lepsza.

On Thursday, May 9, 2019 at 11:32:28 AM UTC+2, Roman Tyczka wrote:
> On Tue, 7 May 2019 12:15:04 -0700 (PDT), Wojciech Muła wrote:
> 
> > Zadanie dla chętnych: w ilu miejscach może tu polecieć wyjątek?
> > Type1 i Type2 to jakieś klasy dostarczone przez użytkownika,
> > nic o nich nie wiemy.
> > 
> > Type1 fun(Type2 a, Type2 b)
> > {
> >    if (a.get_value() > b.get_value()) {
> >       return a.get_foo();
> >    }
> >    
> >    return a.get_bar() + b.get_foo();
> > }
> > 
> > w.
> 
> Ja tak z ciekawości, bo napisałeś dalej, że jest tych miejsc 13, czy
> mógłbyś je wskazać? Nie programuję w C++, więc widzę tylko możliwość
> wysypki w wywołaniach metod (zarówno w nich samych jak i na ich braku czyli
> nilu). Ale z tego i tak nie wyjdzie aż 13. Czy masz tu na myśli jeszcze
> przeciążanie operatorów? Co jeszcze?

To czego nie zauważyłeś na pierwszy rzut oka to niejawne konwersje.
Np. get_bar może zwrócić instancję klasy Kotek, ale operator dodawania
jest zdefiniowany dla Pieska --- i jeśli Pieska da się utworzyć
z Kotka, to mamy dwa konstruktory konwertujące, które oczywiście mogą
rzucić wyjątki. Ponadto argumenty są przekazywane przez kopie, więc 
wołany jest konstruktor kopiujący Type1, który potencjalnie może
coś rzucić. Tak samo wyniki zwracane mogą być typów konwertowalnych 
do Type2 i przed 'return' będzie konwersja, które może się nie powieść.

C++ trochę ten problem rozwiązał przez jawne zabronienie niejawnych
konwersji :) (słówko explicit), ale to musi być wyrażone wprost
w programie.

w.

> Nie, tu padło jakieś hasło "C++ zachęca do pisania w stylu "write
> once, debug endlessly"". Problem w tym że to jest walidne w każdym 
> języku a w c++ z roku na rok o dziwo coraz mniej.

Tak. Oczywiście potrzeba, żeby programiści z roku na rok też robili postępy w tym, jak korzystają z tego języka.

> > Niezupełnie. W takich systemach może być wymaganie na pokrycie testami każdej ścieżki.
> 
> Nie. W typowym systemie nie wymaga się pokrycia *każdej* ścieżki, wymaga 
> się pokrycia określonego procentu.

Co to jest "typowy system"? Bo w konteście całej ludzkiej aktywności programistycznej, w ogóle wymaganie weryfikacji czegokolwiek jest niszowe. A jak jesteśmy w niszach, to trudno mówić o "typowym systemie".
W niszach są standardy i procesy. Nie spotkałem wymagań w procentach pokrycia.

> Ba, wymaga się pokrycia nie tylko 
> ściezki wykonywania kodu, ale np. zbioru wartości danych zmiennych.

Też w procentach?

> Jeśli masz kilkaset tyś lini kodu to nie jest mozliwe pokrycie go w 100%

No to może za dużo jest tych linii? Albo ktoś je napisał a dopiero potem zorientował się, że warto by zrobić jakąś weryfikację. To niedobrze.
 
> Ludzie robiący systemy krytyczne używają specjalistycznych 
> narzędzie do oceny czy dany kod spełnia warunki czy nie, często są to 
> zabawki oparte o randomizacje. I prawie nigdy to nie jest 100%. 100% to 
> można sobie osiągnąć w kodzie do migania diodą czy przedsionkiem serca.

Trochę się motasz. Przedsionek serca to system krytyczny. Miganie diodą też nim może być, zależy co to za dioda. A jeśli masz system, w którym ktoś napisał kilkaset tyś. linii a potem się zorientował, że nie może ich pokryć, to może jednak ten system od samego początku nie był tak bardzo krytyczny i tylko ludzie sobie dodają fasonu twierdząc, że jest.

> > Jeżeli są wyjątki, to tych ścieżek nawet nie widać
> 
> Mało kto patzy na kod.

:-D

W takim razie faktycznie mówimy o różnych niszach.

> Do testowania pokrycia stosuje się automatykę. 
> Ona widzi wyjątki tak samo jak logjmp.

Nie. Nie widzi.
Cytat ze standardu do F-35 (bo tam zaczęliśmy):

"
AV Rule 208:
C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
Rationale: Tool support is not adequate at this time.
"

Problem w tym, że nadal jest "not adequate". I bardzo możliwe, że zawsze tak będzie.

> Zmartwie Cie. Zazwyczaj dostep do całego kodu nie jest potrzebny jeśli 
> *formalnie* coś udowodnisz w module w środku. To że przez funkcję 
> generyczną przelatują wyjąki i robią bałagan ze stanem czegośtam nie 
> jest absolutnie problemem funkcji generycznej tylko kodu na zewnątrz.

Zmartwię Cię. Wymaganie pokrycia dotyczy kodu obiektowego a nie źródłowego. Na tym poziome nie ma już wiedzy o tym, który kawałek kodu był generyczny a który nie.

> Znowu Cie zmartwie: możesz pokryć tą generyczną funkcję testami w 100% a 
> i tak ktoś rzuci wyjątkiem

Nie rzuci, bo jest zakaz. Właśnie po to.

> w przemyśle 
> nawet w aplikacjach do latania stosuje się śmiesze liczby w rodzaju 99%

A dlaczego nie dało się pokryć tego brakującego 1%?
 
> Zleceniodwaca może oczywiście chcieć 100% ale wtedy będzie czekał na 
> software przez 10 lat.

F-35 próbują zrobić od 1992. 10 lat to by był megasukces. :-)

> System w którym lata milion wyjątków jest do dupy. Ale narzekanie że 
> funkcja generyczna jest do dupy bo może przez nią przelecieć wyjątek 
> jest absurdalne.

A kod obiektowy, w którym jest milion nieprzetestowanych rozgałęzień jest OK?

> Oczywiscie że da się obronić, w końcu skoro nie można uzywać normalnych 
> technik programowania, jak wyjątki, to przeciez lepiej je koślawo 
> zaemulować.

Ale ja uważam, że tam nie ma emulacji wyjątków. To jest inny mechanizm, zaaplikowany w innym celu. Dlatego da się go obronić, chociaż oczywiście przyznaję, że stylistycznie jest słaby.

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

> Oczywiście, ja tylko odczarowuje durny pogląd "weźmy Adę, będzie 
> bezpiecznie".

Ale nie ma takiego poglądu. Jest inny: potrzeba, żeby było jak najbezpieczniej, więc na każdym kroku podejmijmy takie decyzje, które zwiększają nasze szanse na bezpieczny efekt. Wybór języka jest jednym z wymiarów, w którym można się do tego efektu zbliżyć lub oddalić.

To trochę jak z zapinaniem pasów w samochodzie. Albo z wyborem rodzaju pieca gazowego. Itd.

> > Jakość wynika z procesów integralnych (z weryfikacji) a nie z deweloperskich. Pytanie, czy takie procesy integralne są. Problem w tym, że łatwo z nich zrezygnować.
> 
> Tu się nie zgadzam. Można poprawnie zweryfikować dowolną kupę.

Można, ale jeśli terminy gonią...

> Jakośc 
> developerki nie ma wpływu wprost na magiczne 100% ale ma duży wpływ na 
> obniżanie tego 100% do "no, szefie, nie damy rady 80%, mozemy ze 70% i 
> tyle bo Steve spier... i nikt nie wie jak to działa".

Z innej perspektywy można powiedzieć, że ma wpływ na *koszt* osiągnięcia tych 100%, jeśli i tak trzeba, żeby było 100%. Lepsza deweloperka to niższy koszt weryfikacji.

Bo są (co najmniej) dwa sposoby robienia projektów: przy założonej z góry jakości i przy założonym z góry budżecie.

> Wymogi nie są z 
> betonu i dziwnym trafem potrafią sobie pływać w trakcie procesu produkcji.

Tak. Ale wymogi jakościowe mogą być narzucone regulacjami, np. prawnymi albo certyfikacyjnymi. Wtedy nie pływają.

> Więc w C++ z roku na rok coraz trudniej spieprzyć. Oczywiście za 
> wyjątkiem reszty świata która używa MISRA i dalej uważa że nie wymyślono 
> nic bezpieczniejszego niż ręczną emulacje C++ w C.

A co jest złego w MISRA-C++?

> > A ponieważ zakładamy, że programista spieprzy wszystko co może, to wybór języka jest ważny. Żeby mógł spieprzyć jak najmniej.
> 
> A mimo to spieprzył.

Może spieprzył mniej? Może gdyby spieprzył więcej, to rakietę by szlag trafił jeszcze przed startem?

> Ariane zdetonowała z powodu używania bezpiecznego 
> języka w niebezpieczny sposób.

Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.

> Czekamy na nastepny język o śmiesznej 
> nazwie gdzie będzie jeszcze więćej bezstanowości, korutyn, monad i całej 
> masy innych niezwykle przydatnych rzeczy

Tu się zgadzam. Ciekawe, czy Godek to czyta. :-)
Ale akurat Ada nie ma związku z żadną z tych rzeczy.

> Co tam ostatnio wymyślili 
> bezpieczniejszego bo od tygodnia nie zaglądałem na weba?

Właśnie wygląda na to, że te wszystkie wynalazki są zwykle odgrzebywane z 30-letnich letargów. W ogóle nie ma niczego nowego, to są kombinatoryczne złożenia starych rzeczy.

> > Unit testy nie wykrywają wyjątków. Chyba że mamy inne rozumienie tego terminu.
> 
> ASSERT_THROW. ASSERT_NO_THROW. Całkiem fajnie wykrywają.

Ale to nie są unit testy.

> Więc jesli mógłbym prosić, przygotuj swoją funkcję na obsługę wyjątków. 

Jest zakaz wyjątków. Właśnie po to, żebym nie musiał przygotowywać.

> Potem łatwo 
> udowodnimy że std::vector pisali dyletanci

Nie zgadzam się. std::vector to bardzo dobra klasa. Po prostu nie dla tej niszy.

> i zamkniemy 
> narzekanie o C++ konkluzją że jest do dupy i dlatego uzywa się MISRA-C 
> gdzie wszystko jest do dupy ale weryfikowalnej formalnie dupy a taka 
> jest znacząco lepsza.

Zależnie od potrzeb, może tak właśnie być. I nie widzę w tym nic złego. Tzn. wolałbym, żeby było jeszcze lepiej, ale jeśli jest tylko tak jak może być, to niech tak będzie.

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

On 10/05/2019 08:03, Maciej Sobczak wrote:
>> Nie, tu padło jakieś hasło "C++ zachęca do pisania w stylu "write
>> once, debug endlessly"". Problem w tym że to jest walidne w każdym
>> języku a w c++ z roku na rok o dziwo coraz mniej.
> Tak. Oczywiście potrzeba, żeby programiści z roku na rok też robili postępy w tym, jak korzystają z tego języka.

O tym piszę od początku jako elemencie niezbędnym obok bezpiecznego języka.

>>> Niezupełnie. W takich systemach może być wymaganie na pokrycie testami każdej ścieżki.
>> Nie. W typowym systemie nie wymaga się pokrycia *każdej* ścieżki, wymaga
>> się pokrycia określonego procentu.
> Co to jest "typowy system"?

Taki który jest na tyle typowy że produkuje się do niego bardzo, ale to 
bardzo drogie narzędzia do kontrolowania procesu produkcji. Zacznij od 
pojęcia "test plan".

https://en.wikipedia.org/wiki/Test_plan

> Bo w konteście całej ludzkiej aktywności programistycznej, w ogóle wymaganie weryfikacji czegokolwiek jest niszowe.

Jeśli to coś miga diodą to masz rację. Ale jak już steruje czymkolwiek 
to przegapiłeś rewolucję. Nie wejdziesz na rynek aplikacji krytycznych 
bez bardzo rozbudowanego mechanizmu weryfikacji który sam podlega 
regorystycznej weryfikacji.

> A jak jesteśmy w niszach, to trudno mówić o "typowym systemie".

Typowy system critical safe. Nikt tu nie mówi o pisaniu migania diodą i 
narzekania że wyjątki są do tego kiepskie.

> W niszach są standardy i procesy. Nie spotkałem wymagań w procentach pokrycia.

Poczytaj o testplanach w okolicy pojęcia IpCore i programowania hardware.

>> Ba, wymaga się pokrycia nie tylko
>> ściezki wykonywania kodu, ale np. zbioru wartości danych zmiennych.
> Też w procentach?

Tak. Np. ze wszystkich 2^32 adresów IP przetestowaliśmy 5% i wydają się 
działać w duperelowatym kawałku kodu do migania diodą jak przyjdzie 
pakiet broadcast.

>> Jeśli masz kilkaset tyś lini kodu to nie jest mozliwe pokrycie go w 100%
> No to może za dużo jest tych linii? Albo ktoś je napisał a dopiero potem zorientował się, że warto by zrobić jakąś weryfikację. To niedobrze.

Nie, weryfikacja powstaje *zanim* napiszesz kod. Tylko że ludzie piszący 
wymagania wiedzą że coś jest nierealne do osiągnięcia jak 100% pokrycia 
itd itp. Zarządza się ryzykiem.

> Trochę się motasz. Przedsionek serca to system krytyczny. Miganie diodą też nim może być, zależy co to za dioda.
> A jeśli masz system, w którym ktoś napisał kilkaset tyś. linii a potem się zorientował, że nie może ich pokryć

Zorientował się przed napisaniem kodu. Oszacował ryzyko, w każdym 
punkcie systemu inaczej. Ryzyko mikrokernela jest wysokie i tam stopień 
pokrycia i wymagania co do jakosci są wyższe. Dla sterownika wentylatora 
nie są tak wyśrubowane a do sterownika poświetlenia klawiatury są niskie.

>, to może jednak ten system od samego początku nie był tak bardzo krytyczny i tylko ludzie sobie dodają fasonu twierdząc, że jest.

Nie dalej nie czaisz. Obecnie pisanie systemów krytycznych podlega pod 
bardzo restrykcyjne zasady. W nich samego pisania jest mało, znacznie 
więcej jest dokumentowania wymagań, śledzenia zmian, akceptacji, 
odpowiedzialności itp itd tylko że w przeciwieństwie do banków tutaj 
całosć procesu jest automatyzowana w miarę możliwości w całości.

>> Do testowania pokrycia stosuje się automatykę.
>> Ona widzi wyjątki tak samo jak logjmp.
> Nie. Nie widzi.
> Cytat ze standardu do F-35 (bo tam zaczęliśmy):
> "
> AV Rule 208:
> C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
> Rationale: Tool support is not adequate at this time.

To trzeba zmienić tool.

> Problem w tym, że nadal jest "not adequate". I bardzo możliwe, że zawsze tak będzie.

Mało porawdopodobne. Standardy tego typu powstają kiedy obecni 
użytkownicy szczali jeszcze w pieluchy. Wystarczy zauważyć że w ciągu 10 
lat projkekt LLVM z pomysłu stał się praktycznie kombajnem do 
weryfikacji i to zaskakującej jakości jak na projekt "akademicki".

> Zmartwię Cię. Wymaganie pokrycia dotyczy kodu obiektowego a nie źródłowego. Na tym poziome nie ma już wiedzy o tym, który kawałek kodu był generyczny a który nie.

I źródłowego, i wynikowego i każdego innego który ma wpływ na 
bezpieczeństwo.

Przykładowo narzędzia do weryfikacji potrafią powiązać dowolną linijkę 
kodu źródłowego z wymaganiem formalnym i śledzić zmiany.

>> Znowu Cie zmartwie: możesz pokryć tą generyczną funkcję testami w 100% a
>> i tak ktoś rzuci wyjątkiem
> Nie rzuci, bo jest zakaz. Właśnie po to.

Przypuszczam że Ariane miała zakaz przepełniania zmiennych. Nawet może 
ktoś pogroził paluszkiem.

>> w przemyśle
>> nawet w aplikacjach do latania stosuje się śmiesze liczby w rodzaju 99%
> A dlaczego nie dało się pokryć tego brakującego 1%?

Bo wymaga to 99% czasu więcej? Szacujący ryzyko ocenia na ile chce mieć 
system działający vs system w wiecznej fazie produkcji.

>> System w którym lata milion wyjątków jest do dupy. Ale narzekanie że
>> funkcja generyczna jest do dupy bo może przez nią przelecieć wyjątek
>> jest absurdalne.
> A kod obiektowy, w którym jest milion nieprzetestowanych rozgałęzień jest OK?

Ale co to ma wspólnego z fukcją generyczną?

Kod obiektowy w którym jest milion nieprzetestowancyh rozgałęzień ma 
milion miejsc do poprawienia na weryfikacji. Zakasujesz rękawy i 
pokrywasz albo masz w zespole człowieka który nie dopuści do takiego 
dziadostwa. Ale spokojnie, autoamty do weryfikacji też nie odpuszczą a 
na samym końcu ktoś się pod tym podpisuje i to jego złapią za jaja w 
razie wypadku.

On 10/05/2019 08:21, Maciej Sobczak wrote:
> A co jest złego w MISRA-C++?

Nikt go nie używa. Zacytuje jednego z developerów MICRA-C: "Znowu te 
pedały coś wymyśliły". Po prostu jest niekoszerny. Najbardziej widać to 
w automatyce przemysłowej i kontrolerach. Mimo że nawet 8-bitowy 
procesor skorzystał by z kodu pisanego w C++ to typowy developer uC 
nawet go kijem nie ruszy bo jednak nic lepszego niż void* nie wymyślono.

>>> A ponieważ zakładamy, że programista spieprzy wszystko co może, to wybór języka jest ważny. Żeby mógł spieprzyć jak najmniej.
>> A mimo to spieprzył.
> Może spieprzył mniej? Może gdyby spieprzył więcej, to rakietę by szlag trafił jeszcze przed startem?

Może. Problem w tym że to nie ma znaczenia. Ktoś napisał w języku z 
silnym typowaniem i fikuśnymi wyjątkami kod w asemblerze który przedarł 
się przez code review, weryfikację i był sterowany przez księgowych.

Zaznaczam że gdyby ktokolwiek obecnie zapytał mnie jak to zrobic to w 
przypływie mojej ignorancji napisałbym klasę do obsługi arytmetyki z 
saturacją, być może z możliwością wymiany jej na bezpośrednie wsparcie 
hardware co przecież dziwne nie jest.

Tutaj nadziubdziali żałosny asm.

Albo core review składał się z takich samych hackerów jak ten miszczu 
albo też code review nie było i cała ta Ada to pic na wodę. I nie 
mówiłbym tego gdyby nie to że przez te ostatnie naście lat widziałem 
troszkę kodu "bezpiecznego" i funta kłaków bym za wiele kawałków nie 
dał, to po prostu dobrze udokumentowane i przetestowane g...

>> Ariane zdetonowała z powodu używania bezpiecznego
>> języka w niebezpieczny sposób.
> Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.

Tak. Na przykład Verilog. Język z wbudowaną wadą projektową i 
najbardziej rozbudowanym systemem weryfikacji do zastosowań krytycznych. 
Dzień jak codzień w IT.

>> Czekamy na nastepny język o śmiesznej
>> nazwie gdzie będzie jeszcze więćej bezstanowości, korutyn, monad i całej
>> masy innych niezwykle przydatnych rzeczy
> Tu się zgadzam. Ciekawe, czy Godek to czyta. :-)
> Ale akurat Ada nie ma związku z żadną z tych rzeczy.

Na codzień mam do czynienia z VHDL. To taka ada + troche ekstra składni. 
Pisanie bezpieczne w tym języku polega głównie na obchodzeniu przez 
programistów silnego typowania chałupniczymi workaroundami. Stąd 
popularnośc Veriloga, można tam pisać co się chce a i tak sie jakoś 
skompiluje. Ludzie nie potrzebują bezpicznych jezyków i ograniczeń. 
Ludzie są leniwi i potrzebują dodawać inta do stringa a wynik ma być 
taki jak ma być i już.

>>> Unit testy nie wykrywają wyjątków. Chyba że mamy inne rozumienie tego terminu.
>> ASSERT_THROW. ASSERT_NO_THROW. Całkiem fajnie wykrywają.
> Ale to nie są unit testy.

To są narzędzia do wykrywania wyjątków w unit testach co oznacza że za 
ich pomocą można pisać unit testy testujące wyjątki.

>> Więc jesli mógłbym prosić, przygotuj swoją funkcję na obsługę wyjątków.
> Jest zakaz wyjątków. Właśnie po to, żebym nie musiał przygotowywać.

No ale to nie udowania tezy że rzucanie wyjątku przez generyka jest 
bezpieczne czy niebezpieczne. To tylko chowanie głowy w piasek z braku 
argumentacji.

Powtarzam, wyjątek czy nie, nie jest kwestią funkcji generycznych jego 
obsługa. Jakiekolwiek kombinowanie w tym temacie to błąd projektowy.

> > Co to jest "typowy system"?
> 
> Taki który jest na tyle typowy że produkuje się do niego bardzo, ale to 
> bardzo drogie narzędzia

Ciekawy pogląd, z którym się nie zgodzam. Typowy system (ogólnie: produkt) to taki, który przez swoją typowość znajduje się w mainstreamie, gdzie akurat podaż narzędzi jest największa. W rzeczywistości tak duża, że można z góry założyć jako normę, że wszystkie narzędzia są darmowe. Od edytorów przez kompilatory po systemy kontroli wersji aż po narzędzia do zarządzania zespołem. Wszystko za friko. To jest teraz typowe.

Drogie narzędzia robi się wtedy, gdy ktoś nie ma wyjścia i musi je kupić. Bo w szczególności nikomu nie chce się ich robić. To są z natury nietypowe (niszowe) rzeczy.

> Zacznij od 
> pojęcia "test plan".
> 
> https://en.wikipedia.org/wiki/Test_plan

No i co z nim? Na tej stronie ani razu nie pojawia się słowo "expensive". Ba, nawet słowo "tool" się nie pojawia, więc chyba w ogóle żadnych narzędzi nie trzeba mieć.

> Nie wejdziesz na rynek aplikacji krytycznych 
> bez bardzo rozbudowanego mechanizmu weryfikacji który sam podlega 
> regorystycznej weryfikacji.

Tak.

> > A jak jesteśmy w niszach, to trudno mówić o "typowym systemie".
> 
> Typowy system critical safe.

Właśnie o to pytam. Bo w moim rozumieniu nie ma czegoś takiego. Każdy jest nietypowy.

> Poczytaj o testplanach w okolicy pojęcia IpCore i programowania hardware.

Gdzie mogę o tym poczytać?

> Tylko że ludzie piszący 
> wymagania wiedzą że coś jest nierealne do osiągnięcia jak 100% pokrycia 
> itd itp. Zarządza się ryzykiem.

Nie w sotfwarze. W HW chyba obowiązuje kultura myślenia w procentach, bo tak się zarządza ryzykiem w odniesieniu do systemów fizycznych (np. mechanicznych), gdzie występują przypadkowe błędy produkcji, degradacja (zmęczenie) materiału, itd. Tak można też liczyć hardware w sensie hardware. Natomiast software nie ma takich zjawisk i dlatego zarządzanie ryzykiem w ten sam sposób nie ma sensu. Ludzie, którzy projektują hardware jadą jeszcze na tej kulturze wyniesionej z systemów fizycznych, ale w branży pojawiło się już zrozumienie, że VHDL czy inny Verilog to software a nie hardware i pojwinno się to robić według procesów software'owych a nie hardware'owych.
Czyli programowanie hardware'u przy użyciu procentów to ściema.

Bo alternatywą jest konsekwentne przeniesienie myślenia procentowego na software a to by był koniec systemów krytycznych w ogóle.

> Zorientował się przed napisaniem kodu. Oszacował ryzyko, w każdym 
> punkcie systemu inaczej.

A na jakiej podstawie oszacował?

> Nie dalej nie czaisz. Obecnie pisanie systemów krytycznych podlega pod 
> bardzo restrykcyjne zasady.

W procentach? To się nie rozumiemy.

> W nich samego pisania jest mało, znacznie 
> więcej jest dokumentowania wymagań, śledzenia zmian, akceptacji, 
> odpowiedzialności itp itd tylko że w przeciwieństwie do banków tutaj 
> całosć procesu jest automatyzowana w miarę możliwości w całości.

Niestety nie. Bo te restrykcyjne zasady dotyczą też narzędzi i w wielu przypadkach nie opłaca się automatyzować (!), bo weryfikacja automatu też jest kosztem, w dodatku przez management traktowanym jako uboczny - co jest zrozumiałe, klient płaci za produkt, a nie za automat użyty przy tworzeniu tego produktu.
I to właśnie dlatego pisania jest mało. Bo gdyby dało się wszystko zautomatyzować, to programiści by tylko pisali a cała reszta by się działa automatycznie. Mała ilość pisania jest właśnie miarą tego, jak bardzo ta branża jest niezautomatyzowana.

> > Cytat ze standardu do F-35 (bo tam zaczęliśmy):
> > "
> > AV Rule 208:
> > C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
> > Rationale: Tool support is not adequate at this time.
> 
> To trzeba zmienić tool.

Na jaki? Może tam w Ameryce nie wiedzą?

> > Problem w tym, że nadal jest "not adequate". I bardzo możliwe, że zawsze tak będzie.
> 
> Mało porawdopodobne. Standardy tego typu powstają kiedy obecni 
> użytkownicy szczali jeszcze w pieluchy. Wystarczy zauważyć że w ciągu 10 
> lat projkekt LLVM z pomysłu stał się praktycznie kombajnem do 
> weryfikacji i to zaskakującej jakości jak na projekt "akademicki".

I nadal jest to "not adequate". Bo kombajnem to on sobie może być, ale restrykjcyjne reguły, o których sam wspomniałeś, wykluczają go z użycia.

> Przypuszczam że Ariane miała zakaz przepełniania zmiennych. Nawet może 
> ktoś pogroził paluszkiem.

Zapewne. Ale zakaz rzucania wyjątków jest łatwiejszy, bo można to sprawdzić grepem.

> > A dlaczego nie dało się pokryć tego brakującego 1%?
> 
> Bo wymaga to 99% czasu więcej?

Własnie pytam, dlaczego. Cóż takiego tam jest, że wymaga 99% czasu więcej?

> Szacujący ryzyko ocenia na ile chce mieć 
> system działający vs system w wiecznej fazie produkcji.

Ale regulacje prawne nie określają, na ile działający ma być system. Zwłaszcza software'owy, gdzie nie można się tłumaczyć wadami materiałowymi, albo zmęczeniem struktury.

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

> > A co jest złego w MISRA-C++?
> 
> Nikt go nie używa.

Właśnie pytam, dlaczego.

> Po prostu jest niekoszerny.

Ciekawa obserwacja. Ale w takim razie ogólnie jesteśmy w lesie, bo to nie powinno być kryterium wyboru metod albo technologii.
Niemniej, jeśli nikt nie używa C++, to po co dyskutujemy o wyjątkach w C++?

> Ktoś napisał w języku z 
> silnym typowaniem i fikuśnymi wyjątkami kod w asemblerze który przedarł 
> się przez code review, weryfikację i był sterowany przez księgowych.

Co trzeba poprawić?

> Zaznaczam że gdyby ktokolwiek obecnie zapytał mnie jak to zrobic to w 
> przypływie mojej ignorancji napisałbym klasę do obsługi arytmetyki z 
> saturacją, być może z możliwością wymiany jej na bezpośrednie wsparcie 
> hardware co przecież dziwne nie jest.

I w jaki sposób by to pomogło rakiecie Ariane?
Ona rozwaliła się nie przez to, że ktoś napisał brzydki kod, tylko przez to, że bezrefleksyjnie złożono do kupy moduły z nowej i starej rakiety.
Twoja klasa nie pomogłaby dokładnie tak samo, jak Ada nie pomogła. Przez tych samych księgowych.
Tu widać, że programiści, nawet jeśli czasem są problemem, to zwykle nie są rozwiazaniem. Sorry.

> > Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.
> 
> Tak. Na przykład Verilog.

No właśnie. Czemu nie VHDL?

> Na codzień mam do czynienia z VHDL. To taka ada + troche ekstra składni. 
> Pisanie bezpieczne w tym języku polega głównie na obchodzeniu przez 
> programistów silnego typowania chałupniczymi workaroundami. Stąd 
> popularnośc Veriloga, można tam pisać co się chce a i tak sie jakoś 
> skompiluje. Ludzie nie potrzebują bezpicznych jezyków i ograniczeń. 
> Ludzie są leniwi i potrzebują dodawać inta do stringa a wynik ma być 
> taki jak ma być i już.

Bardzo ciekawa obserwacja.
I jak to można naprawić?

Tylko nie pisz, że "gdyby zatrudnili porządnych programistów...", bo to jest argument od czapy.

> >>> Unit testy nie wykrywają wyjątków. Chyba że mamy inne rozumienie tego terminu.
> >> ASSERT_THROW. ASSERT_NO_THROW. Całkiem fajnie wykrywają.
> > Ale to nie są unit testy.
> 
> To są narzędzia do wykrywania wyjątków w unit testach co oznacza że za 
> ich pomocą można pisać unit testy testujące wyjątki.

Nie, bo unit testy nie testują wyjątków. Chyba że mamy inne rozumienie tego terminu.

> Powtarzam, wyjątek czy nie, nie jest kwestią funkcji generycznych jego 
> obsługa.

Ale one nie muszą go obsługiwać (pojęcie "obsługi wyjątków" jest w ogóle słabe, bo nie wskazuje, co się do tej obsługi zalicza; zwijanie stosu i omijanie istniejącego kodu to obsługa czy nie?). Ważne, żeby te wszystkie rozgałęzienia były pokryte testami. A nie są. Więc jest źle.

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

On 2019-05-13 08:40, Maciej Sobczak wrote:
>>> Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.
>>
>> Tak. Na przykład Verilog.
> 
> No właśnie. Czemu nie VHDL?
> 
>> Na codzień mam do czynienia z VHDL. To taka ada + troche ekstra składni.
>> Pisanie bezpieczne w tym języku polega głównie na obchodzeniu przez
>> programistów silnego typowania chałupniczymi workaroundami. Stąd
>> popularnośc Veriloga, można tam pisać co się chce a i tak sie jakoś
>> skompiluje. Ludzie nie potrzebują bezpicznych jezyków i ograniczeń.uktu dec
>> Ludzie są leniwi i potrzebują dodawać inta do stringa a wynik ma być
>> taki jak ma być i już.
> 
> Bardzo ciekawa obserwacja.
> I jak to można naprawić?
> 
> Tylko nie pisz, że "gdyby zatrudnili porządnych programistów....",
>  bo to jest argument od czapy.

Nie od czapy, ale sedno sprawy.
Jak w każdym rzemiośle oprócz materiału, narzędzi, maszyn itp..
o końcowej jakości produktu *w dużej mierze* decyduje właśnie dobry
fachowiec.
To, że branża IT o tym dawno zapomniała i wciąż udaje (wzorem prof. 
Marciniaka), że każdego dobrego fachowca można zastąpić skonczoną
liczbą studentów, to jej problem główny. Jeśli tego nie zmieni
(nie wróci do korzeni) to tysiace MISR czy auto-weryfikatorów nie
pomoże.
Branża IT zapomniałą nawet jak sie "tworzy" fachowca:
Wpierw uczeń (dobrych kilka lat), czeladnik (dobrych kilka lat),
potem pracownik (ale bez możliwości spieprzenia - tam gdzie można
zepsuć wciaż dzała i wykonuje mistrz), dopiero z czasem (wciąż
pod nadzorem i przyzwoleniem mistrza - bo to on wie co jest
"krytyczne" a co nie) roboty "rynkowe". Po wielu latach dopiero
można założyć "własną kużnię".
A w IT? nawet uC?
Dwa lata po studiach to już Experienced Senior Developer ;)

AK

W dniu poniedziałek, 13 maja 2019 09:27:56 UTC+2 użytkownik AK napisał:
> On 2019-05-13 08:40, Maciej Sobczak wrote:
> >>> Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.
> >>
> >> Tak. Na przykład Verilog.
> > 
> > No właśnie. Czemu nie VHDL?
> > 
> >> Na codzień mam do czynienia z VHDL. To taka ada + troche ekstra składni.
> >> Pisanie bezpieczne w tym języku polega głównie na obchodzeniu przez
> >> programistów silnego typowania chałupniczymi workaroundami. Stąd
> >> popularnośc Veriloga, można tam pisać co się chce a i tak sie jakoś
> >> skompiluje. Ludzie nie potrzebują bezpicznych jezyków i ograniczeń.uktu dec
> >> Ludzie są leniwi i potrzebują dodawać inta do stringa a wynik ma być
> >> taki jak ma być i już.
> > 
> > Bardzo ciekawa obserwacja.
> > I jak to można naprawić?
> > 
> > Tylko nie pisz, że "gdyby zatrudnili porządnych programistów....",
> >  bo to jest argument od czapy.
> 
> Nie od czapy, ale sedno sprawy.
> Jak w każdym rzemiośle oprócz materiału, narzędzi, maszyn itp..
> o końcowej jakości produktu *w dużej mierze* decyduje właśnie dobry
> fachowiec.
> To, że branża IT o tym dawno zapomniała i wciąż udaje (wzorem prof. 
> Marciniaka), że każdego dobrego fachowca można zastąpić skonczoną
> liczbą studentów, to jej problem główny. Jeśli tego nie zmieni
> (nie wróci do korzeni) to tysiace MISR czy auto-weryfikatorów nie
> pomoże.
> Branża IT zapomniałą nawet jak sie "tworzy" fachowca:
> Wpierw uczeń (dobrych kilka lat), czeladnik (dobrych kilka lat),
> potem pracownik (ale bez możliwości spieprzenia - tam gdzie można
> zepsuć wciaż dzała i wykonuje mistrz), dopiero z czasem (wciąż
> pod nadzorem i przyzwoleniem mistrza - bo to on wie co jest
> "krytyczne" a co nie) roboty "rynkowe". Po wielu latach dopiero
> można założyć "własną kużnię".
> A w IT? nawet uC?
> Dwa lata po studiach to już Experienced Senior Developer ;)

Mogę w tym kontekście polecić esej Paula Grahama:
http://www.paulgraham.com/re.html

Znam programistów, którzy mimo ponad 10 lat doświadczenia
wciąż umieją mniej, niż ogarnięci studenci 1-go roku informatyki.

Ale ogólnie branża wydaje się na tyle złożona, że proste maksymy nie mają tu prostego zastosowania. Może z czasem się to ustabilizuje.

On 2019-05-13 12:05, godek.maciek@gmail.com wrote:
> W dniu poniedziałek, 13 maja 2019 09:27:56 UTC+2 użytkownik AK napisał:
>> On 2019-05-13 08:40, Maciej Sobczak wrote:
>>>>> Są też systemy pisane w niebezpiecznych językach w niebezpieczny sposób.
>>>>
>>>> Tak. Na przykład Verilog.
>>>
>>> No właśnie. Czemu nie VHDL?
>>>
>>>> Na codzień mam do czynienia z VHDL. To taka ada + troche ekstra składni.
>>>> Pisanie bezpieczne w tym języku polega głównie na obchodzeniu przez
>>>> programistów silnego typowania chałupniczymi workaroundami. Stąd
>>>> popularnośc Veriloga, można tam pisać co się chce a i tak sie jakoś
>>>> skompiluje. Ludzie nie potrzebują bezpicznych jezyków i ograniczeń.uktu dec
>>>> Ludzie są leniwi i potrzebują dodawać inta do stringa a wynik ma być
>>>> taki jak ma być i już.
>>>
>>> Bardzo ciekawa obserwacja.
>>> I jak to można naprawić?
>>>
>>> Tylko nie pisz, że "gdyby zatrudnili porządnych programistów....",
>>>   bo to jest argument od czapy.
>>
>> Nie od czapy, ale sedno sprawy.
>> Jak w każdym rzemiośle oprócz materiału, narzędzi, maszyn itp..
>> o końcowej jakości produktu *w dużej mierze* decyduje właśnie dobry
>> fachowiec.
>> To, że branża IT o tym dawno zapomniała i wciąż udaje (wzorem prof.
>> Marciniaka), że każdego dobrego fachowca można zastąpić skonczoną
>> liczbą studentów, to jej problem główny. Jeśli tego nie zmieni
>> (nie wróci do korzeni) to tysiace MISR czy auto-weryfikatorów nie
>> pomoże.
>> Branża IT zapomniałą nawet jak sie "tworzy" fachowca:
>> Wpierw uczeń (dobrych kilka lat), czeladnik (dobrych kilka lat),
>> potem pracownik (ale bez możliwości spieprzenia - tam gdzie można
>> zepsuć wciaż dzała i wykonuje mistrz), dopiero z czasem (wciąż
>> pod nadzorem i przyzwoleniem mistrza - bo to on wie co jest
>> "krytyczne" a co nie) roboty "rynkowe". Po wielu latach dopiero
>> można założyć "własną kużnię".
>> A w IT? nawet uC?
>> Dwa lata po studiach to już Experienced Senior Developer ;)
> 
> Mogę w tym kontekście polecić esej Paula Grahama:
> http://www.paulgraham.com/re.html
> 
> Znam programistów, którzy mimo ponad 10 lat doświadczenia
> wciąż umieją mniej, niż ogarnięci studenci 1-go roku informatyki.

Ależ też znam.
Takich jest z 10%. Reszta to jednak zjawisko dokładnie odwrotne.
Braki pokrywane wybujałą pewnością siebie (tez typowe zjawisko
socjologiczne).

> 
> Ale ogólnie branża wydaje się na tyle złożona, że proste maksymy
nie mają tu prostego zastosowania. Może z czasem się to ustabilizuje.

Bzdury godocie. Branza jak kazda inna.
Sa o badziej zlozone branze (lotnictwo, mechanika, fizyka/numeryka,
chemia, nawet metalurgia, niektore biotechnologie).
IT psuje od lat brak "rak do pracy" co powoduje nieustanne psienie
"fachowcow" co zwieksza brak "rak do pracy" co.. i kolo sie zamyka.
Mechanizmy (w tym psychologiczno/socjologiczne) sa dokladnie
takie jak gdzie indziej.

PS: Juz w pierwszej pracy (~1990), gdy zacznalo sie "ssanie" na
fachowcow (malutkie wtedy w stosunku dzisiejszego, ale jednak) i
zaczely dzialac "mechanizmy" wywiesilem sobie na biurkiem taki
ogolny "roadmap":
1. radosne planowanie
2. chybione wykonanie
3. szukanie winnych
4. karanie niewinnych
5. nagradzanie tych co nie brali udzialu

To pozostaje aktualne i uniwersalne do dzisiaj.
O czym to swiadczy? Ano o tym ze oprocz "zlych fachowcow"
drugim "kamieniem u nogi "ciagnacym jakosc w IT w dol jest
szeroko pojety management (inna/odlegla warta elektronow).

AK

W dniu wtorek, 14 maja 2019 00:53:20 UTC+2 użytkownik AK napisał:

> > Ale ogólnie branża wydaje się na tyle złożona, że proste maksymy
> nie mają tu prostego zastosowania. Może z czasem się to ustabilizuje.
> 
> Bzdury godocie. Branza jak kazda inna.

No widzisz.
A gdybyś w latach 90., zamiast wieszać sobie na ścianie ironiczny plan szukania kozłów ofiarnych zrobił wyszukiwarkę opierającą się na ważeniu grafu ilością odsyłaczy, które prowadzą do danej strony, mógłbyś teraz być wśród najbogatszych ludzi na świecie.

Gdybyś kilka lat później stworzył forum, w którym użytkownicy zamiast odpowiadać mogliby klikać "lubię to", byłoby Cię stać, żeby oddawać miliardy dolarów na dobroczynność.

Branże w rodzaju lotnictwa mają bardzo wysoki próg wejścia, a błędy w nich popełniane mogą kosztować ludzkie życie. Serwisy do dzielenia się zdjęciami kotków nie mają tego problemu - tu w najgorszym razie użytkownik nie zobaczy kotka. (Albo jacyś wieśniacy dokonają samosądu. Ale to nie Twój problem)

> > Tylko nie pisz, że "gdyby zatrudnili porządnych programistów....",
> >  bo to jest argument od czapy.
> 
> Nie od czapy, ale sedno sprawy.
> Jak w każdym rzemiośle oprócz materiału, narzędzi, maszyn itp..
> o końcowej jakości produktu *w dużej mierze* decyduje właśnie dobry
> fachowiec.

I tu jest właśnie różnica pomiędzy systemami krytycznymi a "normalnymi", gdzie obowiązują reguły rzemieślnicze (używam tego słowa w pozytywnym sensie "craftmanship", żeby nie było).

Jeżeli masz firmę, która robi cokolwiek niekrytycznego, to od jakości programistów zależy jakość produktu tak samo, jak od jakości jakiegokolwiek innego rzemieślnika zależy jakość tego co tworzy. Tu jest pełna zgoda. Co więcej, od ich jakości zależy nawet to, jak bardzo możesz odpuścić temat weryfikacji. W idealnym przypadku możesz w ogóle nie robić żadnej weryfikacji, bo produkt będzie po prostu dobry i po prostu odniesie sukces. Tak samo, jak Linux odniósł sukces, chociaż jądro Linuksa w ogóle nie ma unit testów.

Powtórzę na wszelki wypadek: jądro Linuksa nie ma unit testów.

I najwyraźniej nie jest to żaden problem.

Natomiast jak robisz system krytyczny, to podlegasz regulacjom, standardom i certyfikacjom. I ciekawostka jest taka, że np. w branży lotniczej standardy jakości nie obejmują bezpośrednio rekrutacji. Tzn. rekrutacja jest pod lupą w takim samym stopniu, jak np. zakup długopisów albo żarówek.
Czyli w myśl tych standardów jakość produktu nie bierze się z genialności kodera klepiącego kod (jak ktoś się uważa za genialnego, to niech sobie Linuksa poklepie, z pożytkiem dla wszystkich). Jakość bierze się z *weryfikacji* a nie z klepania. Właściwie to w zgodzie ze standardami (!) można by generować kod losowo tak długo aż przejdzie weryfikację.

Dlatego kod napisany przez genialnego programistę sam w sobie jest *bezwartościowy*. Słyszałem określenie "there is no quality built in" w odniesieniu do naklepanego poza procesem kodu i to dobrze określa obowiązujący stan umysłu.

Jakość bierze się z weryfikacji a nie z klepania kodu. I jeśli jakości nie ma, to znaczy tylko tyle, że weryfikacja była słaba.

Dlatego mądre internetowe stwierdzenia "gdyby zatrudnili dobrych programistów" po każdym upublicznionym fakapie, w którym zginęli ludzie, są od czapy. To nie ta branża.

> To, że branża IT

Tak. Zgadzam się. Tylko że IT i systemy krytyczne to są odrębne branże.
No chyba że zaczniemy je integrować i na siłę stosować metody jednej w drugiej. Ale zgadnijcie dlaczego Google odpuścił temat autonomicznych pojazdów... Przecież nie z powodu jakości programistów.

> A w IT? nawet uC?
> Dwa lata po studiach to już Experienced Senior Developer ;)

Tak. Jest takie zjawisko. I na razie nie widać, żeby to się miało odwrócić.

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

On Tuesday, May 14, 2019 at 3:55:18 AM UTC-4, Maciej Sobczak wrote:
> > > Tylko nie pisz, że "gdyby zatrudnili porządnych programistów....",
> > >  bo to jest argument od czapy.
> > 
> > Nie od czapy, ale sedno sprawy.
> > Jak w każdym rzemiośle oprócz materiału, narzędzi, maszyn itp..
> > o końcowej jakości produktu *w dużej mierze* decyduje właśnie dobry
> > fachowiec.
> 
> I tu jest właśnie różnica pomiędzy systemami krytycznymi a "normalnymi", gdzie obowiązują reguły rzemieślnicze (używam tego słowa w pozytywnym sensie "craftmanship", żeby nie było).
> 
> Jeżeli masz firmę, która robi cokolwiek niekrytycznego, to od jakości programistów zależy jakość produktu tak samo, jak od jakości jakiegokolwiek innego rzemieślnika zależy jakość tego co tworzy. Tu jest pełna zgoda. Co więcej, od ich jakości zależy nawet to, jak bardzo możesz odpuścić temat weryfikacji. W idealnym przypadku możesz w ogóle nie robić żadnej weryfikacji, bo produkt będzie po prostu dobry i po prostu odniesie sukces. Tak samo, jak Linux odniósł sukces, chociaż jądro Linuksa w ogóle nie ma unit testów.
> 
> Powtórzę na wszelki wypadek: jądro Linuksa nie ma unit testów.
> 
> I najwyraźniej nie jest to żaden problem.
> 
> Natomiast jak robisz system krytyczny, to podlegasz regulacjom, standardom i certyfikacjom. I ciekawostka jest taka, że np. w branży lotniczej standardy jakości nie obejmują bezpośrednio rekrutacji. Tzn. rekrutacja jest pod lupą w takim samym stopniu, jak np. zakup długopisów albo żarówek.
> Czyli w myśl tych standardów jakość produktu nie bierze się z genialności kodera klepiącego kod (jak ktoś się uważa za genialnego, to niech sobie Linuksa poklepie, z pożytkiem dla wszystkich). Jakość bierze się z *weryfikacji* a nie z klepania. Właściwie to w zgodzie ze standardami (!) można by generować kod losowo tak długo aż przejdzie weryfikację.
> 
> Dlatego kod napisany przez genialnego programistę sam w sobie jest *bezwartościowy*. Słyszałem określenie "there is no quality built in" w odniesieniu do naklepanego poza procesem kodu i to dobrze określa obowiązujący stan umysłu.
> 
> Jakość bierze się z weryfikacji a nie z klepania kodu. I jeśli jakości nie ma, to znaczy tylko tyle, że weryfikacja była słaba.
> 
> Dlatego mądre internetowe stwierdzenia "gdyby zatrudnili dobrych programistów" po każdym upublicznionym fakapie, w którym zginęli ludzie, są od czapy. To nie ta branża.
> 
> > To, że branża IT
> 
> Tak. Zgadzam się. Tylko że IT i systemy krytyczne to są odrębne branże.
> No chyba że zaczniemy je integrować i na siłę stosować metody jednej w drugiej. Ale zgadnijcie dlaczego Google odpuścił temat autonomicznych pojazdów... Przecież nie z powodu jakości programistów.
> 
> > A w IT? nawet uC?
> > Dwa lata po studiach to już Experienced Senior Developer ;)
> 
> Tak. Jest takie zjawisko. I na razie nie widać, żeby to się miało odwrócić.
> 
> -- 
> Maciej Sobczak * http://www.inspirel.com

Zgadzam się z szanownym kolegą w 100% ale powoli branżą lotnicza o której kolega pisze ze ścislą weryfikacja systemów krtycznych przestaje isnieć (nie wspomnę o branży samochodowej gdzie ścisła weryfikację systmów krytycznych odpuszczono sobie już dawno na zasadzie jeśli koszty odszkodowań są niższe od zysków to robimy tak by było taniej) - przykład ostatnie fiasko Boeinga - zaczyna sie projektowanie systemów przez ksiegowych a nie przez inzynierów.

> Zgadzam się z szanownym kolegą w 100% ale powoli branżą lotnicza o której kolega pisze ze ścislą weryfikacja systemów krtycznych przestaje isnieć (nie wspomnę o branży samochodowej gdzie ścisła weryfikację systmów krytycznych odpuszczono sobie już dawno na zasadzie jeśli koszty odszkodowań są niższe od zysków to robimy tak by było taniej) - przykład ostatnie fiasko Boeinga - zaczyna sie projektowanie systemów przez ksiegowych a nie przez inzynierów.

Tak, jest problem. Ale akurat ostatnie fiasko Boeinga nie pokazuje, że cokolwiek się zaczęło, bo zjawisko zbytniego spoufalenia wykonawców (Boeing) z certyfikatorami (FAA) wcale nie powstało skokowo i w ostatnim czasie.
I problem został rozpoznany a korekta oczywiście ma kierunek odwrotny, czyli likwidacja spoufalenia i spadek wzajemnego zaufania.
Przykładowy komentarz:

https://www.rt.com/news/454229-european-air-regulator-doesnt-trust-faa/

I zauważ, że w tym komentarzu nie ma ani słowa o wpływie księgowych na dalszy proces.
Więc jest szansa, że jednak to nie księgowi będą mieć ostatnie słowo.

Jak będzie w przyszłości - nie wiemy. Ale akurat branża lotnicza tym się różni od przykładowej moto, że jest absurdalnie czuła na ilość wypadków, w sensie pojedynczych zdarzeń, które przechylają szalę z jednego ekstremum w drugie. Jak się rozwali jeden samolot, to wszyscy udają, że to siła wyższa, na którą nikt nie miał wpływu; ale jak się rozwali drugi, to jest międzynarodowy kryzys. Dlatego kultura tworzenia systemów krytycznych w tej branży przetrwa dłużej. Tzn. dłużej, niż np. w moto.
Jak długo i co będzie po niej - nie wiemy.

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

On 2019-05-14 08:51, godek.maciek@gmail.com wrote:
> W dniu wtorek, 14 maja 2019 00:53:20 UTC+2 użytkownik AK napisał:
> 
>>> Ale ogólnie branża wydaje się na tyle złożona, że proste maksymy
>> nie mają tu prostego zastosowania. Może z czasem się to ustabilizuje.
>>
>> Bzdury godocie. Branza jak kazda inna.
> 
> No widzisz.
> A gdybyś w latach 90., zamiast wieszać sobie na ścianie ironiczny plan szukania kozłów ofiarnych zrobił wyszukiwarkę opierającą się na ważeniu grafu ilością odsyłaczy, które prowadzą do danej strony, mógłbyś teraz być wśród najbogatszych ludzi na świecie.

Mlokosie. Na czym wyszukiwarke?
W tych latach (1987) byl COCOM i nawet zwykle kompilatory C sciagalo
sie nielegalnie po nocach po roznych BBSach (bo Inetu _w ogole_ nie bylo 
wtedy). Te BBSy dzialaly z zawrotna szybkoscia 2400b/sec, a tu mi tu o
jakiejs wyszukiwarce. Heh

> Gdybyś kilka lat później stworzył forum, w którym użytkownicy zamiast odpowiadać mogliby klikać "lubię to", byłoby Cię stać, żeby oddawać miliardy dolarów na dobroczynność.
> 

Heh. Poczytaj sobie np. o firmie Logotec. Wyprzedzala nie tylko Polske,
ale i byla na topie w swiecie w zakresie mobilnych aplikacji (m.in.
glowna nagroda Microsoftu za tworzene srodowiska developersiego
do tworzenia aplikacji mobilnych).
I co? I nie ma firmy. Dlaczego? Bo wtedy nie bylo komorek a handheldy
z WinCE i Palm byly drogie, a siec miala raptem 9600b/sek (choc to 
ostatnie nie bylo przeszkoda).
Skutkiem firma upadla choc jej Web@DDM (jestem pomyslodawca nazwy heh :)
wyprzedzal "epoke".
Znam jeszcze inne przypadki tego typu wiec Twoje "swiatle rady" zachowaj
zarozumialy mlokosie dla siebie.

> Branże w rodzaju lotnictwa mają bardzo wysoki próg wejścia, a błędy w nich popełniane mogą kosztować ludzkie życie.

.. a tam zaczynalem w 1987. Wpierw jako tokarz, potem programista metod
numerycznych (i nie tylko).
Wiec przestan mnie mlokosie pouczac co powinienem a co nie.
Pojecia nie masz co wtedy mozna bylo, a co nie i _jak_ nalezalo dzialac.

AK

W dniu środa, 15 maja 2019 21:25:35 UTC+2 użytkownik AK napisał:
iejs wyszukiwarce. Heh
> 
> > Gdybyś kilka lat później stworzył forum, w którym użytkownicy zamiast odpowiadać mogliby klikać "lubię to", byłoby Cię stać, żeby oddawać miliardy dolarów na dobroczynność.
> > 
> 
> Heh. Poczytaj sobie np. o firmie Logotec. Wyprzedzala nie tylko Polske,
> ale i byla na topie w swiecie w zakresie mobilnych aplikacji (m.in.
> glowna nagroda Microsoftu za tworzene srodowiska developersiego
> do tworzenia aplikacji mobilnych).
> I co? I nie ma firmy. Dlaczego? Bo wtedy nie bylo komorek a handheldy
> z WinCE i Palm byly drogie, a siec miala raptem 9600b/sek (choc to 
> ostatnie nie bylo przeszkoda).
> Skutkiem firma upadla choc jej Web@DDM (jestem pomyslodawca nazwy heh :)
> wyprzedzal "epoke".
> Znam jeszcze inne przypadki tego typu wiec Twoje "swiatle rady" zachowaj
> zarozumialy mlokosie dla siebie.

To Ty stwierdziłeś, że branża (IT? uC?) to "branża jak każda inna".
W latach 90. przyszli założyciele Googla uderzali do wielkiego molocha kapitałowego Yahoo!, który indeksował Internet. I co? I zostali odprawieni z kwitkiem.
Nikt wówczas nie potrafił przewidzieć, co jest naprawdę potrzebne.
(Może nie "nikt", ale bardzo nieliczni. Ale raczej "wydawało im się",
niż "naprawdę wiedzieli")

Kiedy Facebook debiutował na giełdzie, mój kolega twierdził, że to absurdalne, że jego wartość jest większa od wartości koncernu General Motors. Ale jakimś cudem doszło do tego, że Facebookowi udało się osiągnąć masę krytyczna użytkowników i zostać "portalem społecznościowym całego świata", a w rezultacie "kontrolować myśli" miliardów ludzi na świecie.

Nie znam się na tym na tyle dobrze, żeby powiedzieć, dlaczego to Facebook, a nie np. grono.net, osiągnął taki sukces. Nie wiem, czy ktokolwiek się na tym zna (może tak?)

Ale owszem, moje, jak je nazywasz, "światłe rady" można sobie otrzaskać o kant tyłka, i to jest właśnie ich sednem. Żeby odnieść sukces w tej branży, wystarczy akurat przypadkiem być we właściwym miejscu we właściwym czasie i rozumieć coś, czego nikt inny nie rozumie. Nie wiem, czy tak jest w każdej branży - ale wydaje się, że księgowi czy lekarze czy inżynierowie budownictwa nie są w podobnej sytuacji.

On 4/20/19 3:02 PM, Sebastian Biały wrote:
> Ależ bardzo prosto. Ariane dupneła z powodu tego że ktoś w "bezpiecznym" 
> języku zrobił założenie że coś zmieci się w 16 bitach. Typowe myślenie 
> asemblerowca który wszędzie widzi bajty do oszczędzenia.

Bezpieczeństwo języka ma znaczenie,
wyobraźmy sobie że rakieta mam wykonać jakiś manewr a tu wyskakuje błąd 
"method NNN not found" bo oprogramowanie zostało napisane w 
interpretowanym Pythonie ;-)
albo łazik ląduje na Księżycu, a tu włączyła się aktualizacja Windows.:))
W skromniejszym przypadku: cenne są milisekundy a tu włącza się Garbage 
Collector.

W takim Rust kompilator robi wiele sprawdzeń za nas.