🚀 go-pugleaf

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.