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

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

Ada Tutorial - w Instytucie Lotnictwa

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

Contents

  Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-04-17 10:41 -0700
    Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-17 20:43 +0200
      Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-04-18 06:01 -0700
        Re: Ada Tutorial - w Instytucie Lotnictwa Sebastian Biały <heby@poczta.onet.pl> - 2019-04-19 19:24 +0200
          Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-20 13:46 +0200
            Re: Ada Tutorial - w Instytucie Lotnictwa Sebastian Biały <heby@poczta.onet.pl> - 2019-04-20 15:02 +0200
              Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-20 16:20 +0200
                Re: Ada Tutorial - w Instytucie Lotnictwa slawek <x.y@org.org> - 2019-04-23 21:27 +0200
                  Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-04-24 00:11 -0700
              Re: Ada Tutorial - w Instytucie Lotnictwa Borneq <borneq@antyspam.hidden.pl> - 2019-08-04 18:11 +0200
        Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-04-20 13:43 +0200
          Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-04-22 11:51 -0700
      Re: Ada Tutorial - w Instytucie Lotnictwa Wojciech Muła <wojtek.mula@gmail.com> - 2019-05-07 12:15 -0700
        Re: Ada Tutorial - w Instytucie Lotnictwa Szyk Cech <szykcech@spoko.pl> - 2019-05-07 21:38 +0200
        Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-07 22:52 +0200
          Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-07 22:54 -0700
            Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-08 19:31 +0200
              Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-08 23:04 -0700
                Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-09 18:19 +0200
                  Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-09 23:03 -0700
                    Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-10 20:33 +0200
                      Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-12 23:29 -0700
          Re: Ada Tutorial - w Instytucie Lotnictwa Wojciech Muła <wojtek.mula@gmail.com> - 2019-05-08 06:32 -0700
            Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-08 19:51 +0200
              Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-08 23:21 -0700
                Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-09 18:34 +0200
                  Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-09 23:21 -0700
                    Re: Ada Tutorial - w Instytucie Lotnictwa heby <heby@poczta.onet.pl> - 2019-05-10 21:00 +0200
                      Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-12 23:40 -0700
                        Re: Ada Tutorial - w Instytucie Lotnictwa AK <nobody@nowhere.net> - 2019-05-13 09:27 +0200
                          Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-05-13 03:05 -0700
                            Re: Ada Tutorial - w Instytucie Lotnictwa AK <nobody@nowhere.net> - 2019-05-14 00:53 +0200
                              Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-05-13 23:51 -0700
                                Re: Ada Tutorial - w Instytucie Lotnictwa AK <nobody@nowhere.net> - 2019-05-15 21:25 +0200
                                  Re: Ada Tutorial - w Instytucie Lotnictwa godek.maciek@gmail.com - 2019-05-15 23:55 -0700
                          Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-14 00:55 -0700
                            Re: Ada Tutorial - w Instytucie Lotnictwa Adam M <amorawski@magna-power.com> - 2019-05-14 06:25 -0700
                              Re: Ada Tutorial - w Instytucie Lotnictwa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-05-14 23:09 -0700
        Re: Ada Tutorial - w Instytucie Lotnictwa Roman Tyczka <noemail@because.no> - 2019-05-09 11:32 +0200
          Re: Ada Tutorial - w Instytucie Lotnictwa Wojciech Muła <wojtek.mula@gmail.com> - 2019-05-09 10:29 -0700

Page 2 of 2 — ← Prev page 1 [2]

#32551

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.

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

#32553

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

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

#32539

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.

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

#32541

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?

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

#32544

> 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

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

#32547

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.

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

#32550

> 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

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

#32552

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.

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

#32554

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

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

#32555

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

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

#32556

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.

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

#32557

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

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

#32558

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)

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

#32562

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

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

#32564

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.

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

#32559

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

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

#32560

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.

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

#32561

> 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

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

#32545

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

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

#32548

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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web