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.