Treść mojego pliku z komentarzem do F-35-coding-rules.pdf jaki wyparował mi z dysku i z repo git-a

Dzień dobry!

Dawno temu w Internecie krążył dokument F-35-coding-rules.pdf . I ja wtedy go sobie ściągnąłem na dysk i zarchiwizowałem. Przeczytałem go i negatywne wnioski zapisałem w pliku F-35-coding-rules.txt.
Teraz chciałem dodać coś do repo gita w którym sa oba te pliki i ze zdumieniem stwierdziłem, że ten plik wyparował z dysku i z lokalnego repo git-a. Z serwera git-a też chyba wyparował, bo dociągnięcie zmian z gałęzi master podało, że "Już aktualne."
Plik zniknął po ostatnim commicie który miałem 2022-06-01.

Treść pliku "F-35-coding-rules.txt":
"Nonsensy:

1. Brak użycia Unicode.
2. Ograniczenia #ifdef jedynie do plików nagłówkowych. Ciekawe jak sobie radzą pod różnymi systemami?!? - Już wiem - kompilacja warunkowa na poziomie plików a nie kodu - to jest prawidłowe podejście do wieloplatformowości.
3. Podkreślenia w nazwach zamiast dużych liter rozpoczynających każde słowo.
4. Zalecają używanie (w miarę możliwości) szablonów zamiast dziedziczenia!?!
5. Zabraniają użycia "continue" i "break".
6. Zakaz voilate - choć w prawie każdym programie wielowątkowym trzeba tego używać.
7. Globalne zmienne w klasach z kontrlą dostępu. Choć ja tak nie robię, to może powinienem...
8. Zabraniają używania wyjątków (try, catch)"

Ja osobiście SZAP-owców bym nie winił za to, bo to już lata minęły. Mi się wydaje że to nasi lokalni wariaci... Dostali ciśnienia w związku z zakupem tego "najnowocześniejszego na świecie wynalazku". I chyba mają problem, że programowanie tych milionów lini kodu było katorgą i karą dla tych niewolników którzy musieli się szarpać nie tylko z paranoją wbudowaną w C++ ale też z powyższymi paranoidalnymi, urzędowo narzuconymi ograniczeniami.

Miłego dnia!
Jacek Marcin Jaworski

Ale jakie jest pytanie?
W tej chwili przypomina to bezładny strumień myśli.

Google znajduje plik bez problemu: https://www.stroustrup.com/JSF-AV-rules.pdf

git niczego nie gubi. Jeśli dodałeś coś do repozytorium i nie przepisywałeś historii to wszystko nadal tam jest.

W celach edukacyjnych i zabicia chwilowej nudy, odniosę się do niektórych "nonsensów".

1. Brak użycia Unicode

To by się trzeba pilotów zapytać czy brak możliwości wyświetlania emotek to dla nich nonsens.

2. Ograniczenia #ifdef jedynie do plików nagłówkowych. Ciekawe jak sobie radzą pod różnymi systemami?!? - Już wiem - kompilacja warunkowa na poziomie plików a nie kodu - to jest prawidłowe podejście do wieloplatformowości.

Ale po co pisać wieloplatformowo skoro piszesz konkretnie pod system F-35? Wydaje mi się, że portowalny kod wprowadziłby złożoność by rozwiązać problem, który nie istnieje.

3. Podkreślenia w nazwach zamiast dużych liter rozpoczynających każde słowo.

Biblioteka standardowa C++ używa takiej konwencji.

5. Zabraniają użycia "continue" i "break".
8. Zabraniają używania wyjątków (try, catch)"

W tego typu systemach wielką uwagę przywiązuje się do przewidywalności kodu, wszelkie skoki, które powodują, że wykonanie skacze w inne miejsce sprawiają, że kod staje się mniej przewidywalny a wykonanie nie wykonuje się linijka po linijce. W takim układzie try catch chyba nie muszę tłumaczyć. continue i break wydają się kontrowersyjne, ale trzeba sobie uświadomić, że te konstrukcje to zakamuflowane goto tylko gorsze, bo nigdzie w kodzie nie ma jawnej etykiety. Gdy mamy wielokrotnie zagnieżdżone, złożone pętle, ciężko ocenić na pierwszy rzut oka gdzie skoczymy gdy natkniemy się na break.

6. Zakaz voilate - choć w prawie każdym programie wielowątkowym trzeba tego używać.

Jest wręcz odwrotnie, w prawie każdym, współczesnym programie wielowątkowym nie trzeba go używać. Od C++11 mamy do dyspozycji narzędzia do zapewnienia atomowości w systemach wielowątkowych, które nie są już UB, a C++20 oznaczył volatile jako deprecated dla niepoprawnych zastosowań w systemach wielowątkowych https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1152r4.html
A jeśli chodzi o F-35, to albo mieli natywne narzędzia do zapewnienia atomowości dostarczane przez platformę, albo nie potrzebowali tworzyć kodu wielowątkowego. Taki jawny zapis to pewnie po to, by walczyć z przyzwyczajeniami programistów z innych systemów.

Ad.4 i Ad.7 za mało kontekstu, żebym mógł się wypowiedzieć.

Nie została niestety podana argumentacja dlaczego cytowane punkty zostały uznane jako nonsensy. Niektóre z nich jak zakaz używania volatile to wręcz oznaka dobrego stylu (i to piętnaście albo i więcej lat temu), a niektóre z nich jak zakaz continue czy try catch wynika bezpośrednio z rygorystycznych wymagań specyficznego systemu. Dlatego moim zdaniem podsumowująca opinia autora wątku o programistach tworzących system dla F-35 jest nie tylko niecelna, ale i krzywdząca. Moim zdaniem, punkty do których się odniosłem były napisane nie przez urzędnika, ale przez fachowca, który wiedział co robi.

several napisał(a):

Ad.4 i Ad.7 za mało kontekstu, żebym mógł się wypowiedzieć.

Co do Ad. 4 to:

• Dziedziczenie wprowadza minimalne opóźnienie (nie wiem czy w F 35 jest to ważne) - > templaty nie wprowadzają
• Nadużywanie wielopoziomowego dziedziczenia jest ostarżane o komplikowanie kodu

Ogólnie punkty 4, 5 i 8 powodują że kod jest bardziej w stylu funkcyjnym co IMHO jest zawsze dobre

@Energo Koder: Dlaczego uważasz, że zasady tworzenia kodu awioniki muszą mieć sens w innych zastosowaniach, np. w pisaniu Tetrisa? Pewnie spora część kodu, który mieli na starcie jest starsza niż my, spora część kodu będzie żyć dłużej niż my. Może priorytetem było coś innego niż napisanie ładnego kodu, w nowoczesnej odmianie C++?

piotrpo napisał(a):

@Energo Koder: Dlaczego uważasz, że zasady tworzenia kodu awioniki muszą mieć sens w innych zastosowaniach, np. w pisaniu Tetrisa?

Ogólnie się zgodzę, że C++ jest na tyle przekomplikowanym językiem, że świadomie trzeba wybierać z czego się korzysta przy kodowaniu.
Moim zdaniem największe znaczenie w rozwoju składni C++ miał standard 98, i 11. Natomiast biblioteka STL jest kompletnie nie do użytku. Dlatego chcąc programować w obiektowym, kompilowanym j. prog. pozostaje C++ i Qt (od wersji 4 z 2005r. w zakresie C++ nie jest rozwijana). Jest tak, gdyż j. D, mimo, że jest działa i to w wersji 2.xx, to jest na razie pułkownikiem (z uwagi na brak IDE z debugerem i z powodu braku profilera).
Od 2011r. Komitet Centralny C++ dodaje tylko nowe triki ktore nic nie wnoszą poza dążeniem do uniemożliwienia zrozumienia "nowoczesnego kodu C++".

W C++ jest wiele problemów jakich nie ma w D ani w Pytonie: w C++ nie działają f. wirtualne w konstruktorach i destruktorach, brak dziedziczenia operatorów, brak wsparcia Unicode w nazwach, nienormalnie dopasowanie typów: przekleństwo ambigous. Brak ABI wyłącza C++ z całego szeregu zastosowań: nie nadaje się do progr. sys. op., nie współpracuje z innymi językami na poziomie klas (robić to można tylko dzięki ABI z C), nie da się sprzedawać skompilowanych bibliotek (można jedynie sprzedawać skompilowane biblioteki z interfejsem w czystym C).
Tej góry ich własnego guana Stostrupy z Komitetu Centralnego nie chcą ruszyć!

Jednak cała sztuka polega na tym, by odróżnić triki od tego co faktycznie działa i się sprawdza. 25 lat temu tą pracę analityczną wykonał Walter Bright z SZAP i zakasał rękawy i zakodował j. D w wer. 1.xxx i 2.xxx. Podsumowując: Wyjątki się sprawdzają. Dziedziczenie się sprawdza. Brak powodów by nie dziedziczyć operatorów. Brak powodów by nie działały f. wirtualne w konstruktorach i destruktorach. break, continue to coś naturalnego w językach wywodzących się z C. Dodatkowo w F-35-coding-rules.pdf zabraniają więcej niż 1 komenda return w f. Co też jest nonsensem.

Myślę, że głównym powodem wprowadzenia tych wszystkich ograniczeń w F-35-coding-rules.pdf była chęć zwiększenia jakości kodu. Jednak wydaje się, że zrobiono to odgórnie, bez oglądania się na programistów. Te wymogi nazywam nonsensownymi dlatego, że to rozwiązanie typu "mamy epidemię i od teraz wszyscy pracują w domach". A gdzie stanowiska konstruktorskie? A gdzie maszyny produkcyjne? A gdzie wsparcie kolegów z zespołu? A gdzie kontakt z ludźmi? To szaleństwo!

Takie sprawy należy sobie "rozklepywać" na zimno i nazywać po imieniu.

piotrpo napisał(a):

@Energo Koder: Dlaczego uważasz, że zasady tworzenia kodu awioniki muszą mieć sens w innych zastosowaniach, np. w pisaniu Tetrisa?

Nie zauważyłem słowa "awioniki". Taki samolocik to jednak dużo więcej kodu niż tylko "frontend" na dwóch monitorach dla pilota. Wyobraź sobie, że takie samoloty prawdopodobnie (słyszałem to o F-117) bez "aktywnego sterowania" wcale by nie latały. Mi się wydaje, że to jest jakaś odmiana SI.

@Energo Koder: Tak, programowanie działające na pokładzie myśliwca 5 generacji to nie tylko frontend. Faktycznie on bez oprogramowania nie poleci (nasze F-16 zresztą też nie). Lotnictwo to bardzo konserwatywna branża i ma zupełnie inne priorytety niż np. elektronika użytkowa. Dlatego w dokumencie, który powstał 20 lat temu opisują standardy kodowania obowiązujące 40 lat temu, a może i wcześniej, bo pewnie spora część tego dokumentu została stworzona przy okazji jakiegoś wcześniejszego programu.
Koszt projektu F-35 to jak do tej pory 1.7 biliona dolarów (europejskiego biliona). Myślisz, że ktokolwiek zaryzykuje narażenie takiej kasy, bo programistom by się pisało łatwiej, albo trochę szybciej (taniej)? W statku powietrznym, który może spaść na ziemię przenosząc B-61? Czy może rezygnacja z wszystkiego co może być potencjalnie ryzykowne staje się z automatu zbyt ryzykowne?

Energo Koder napisał(a):

piotrpo napisał(a):

@Energo Koder: Dlaczego uważasz, że zasady tworzenia kodu awioniki muszą mieć sens w innych zastosowaniach, np. w pisaniu Tetrisa?

Nie zauważyłem słowa "awioniki". Taki samolocik to jednak dużo więcej kodu niż tylko "frontend" na dwóch monitorach dla pilota. Wyobraź sobie, że takie samoloty prawdopodobnie (słyszałem to o F-117) bez "aktywnego sterowania" wcale by nie latały. Mi się wydaje, że to jest jakaś odmiana SI.

ale głupoty. Od dawna żaden samolot nie jest w stanie dobrze latać bez sterowania wspomaganego komputerowo(fly-by-wire). To wynika z nowoczesnych konstrukcji.W takim f-35 będziesz miał kupe różnych układów od pewnie jakiś ogólnych procesorów po dużą ilość procesorów sygnałowych(albo olbrzymie bloki jak np. radar). Ograniczenia takie postawiono na soft bo zwyczajnie lockhed musiał wynieść takie doświadczenia z poprzednich smaolotów. A że wydali tyle hajsu watpię że zrobili sobie dla jaj takie a nie inne coding guidlines. Z resztą o czym my mówimy szukasz dokumentu który łatwo w necie znaleźć w zasadzie wyskakuje jako 1 wynik z google.

revcorey napisał(a):

Energo Koder napisał(a):

piotrpo napisał(a):

@Energo Koder: Dlaczego uważasz, że zasady tworzenia kodu awioniki muszą mieć sens w innych zastosowaniach, np. w pisaniu Tetrisa?

Nie zauważyłem słowa "awioniki". Taki samolocik to jednak dużo więcej kodu niż tylko "frontend" na dwóch monitorach dla pilota. Wyobraź sobie, że takie samoloty prawdopodobnie (słyszałem to o F-117) bez "aktywnego sterowania" wcale by nie latały. Mi się wydaje, że to jest jakaś odmiana SI.

ale głupoty.

Jak temat jest ci znany, to chyba banały a nie gupoty?!?
W sumie dyskusja nie ma sensu jak ktoś tego nie rozumie i wyzywa od głupków.

Od dawna żaden samolot nie jest w stanie dobrze latać bez sterowania wspomaganego komputerowo(fly-by-wire). To wynika z nowoczesnych konstrukcji.

Nic takiego nie ma miejsca. W ruskich wynalazkach w czasach Mig-29 standardem był zdwojony system sterowania: elektroniczny i mechaniczny. Ja po prostu chciałem podać przykład, że w F-117 wcale nie może być sterowania czysto mechanicznego.
Czy to są głupoty?

A to że się czepiacie wcześniejszych wpisów i nie widzicie zmiany poglądów, to tylko świadczy o próbie szufladkownia mnie. Nikt z was nie podał w.w. tu (dnia: 2022-07-04 22:48) wad C++. Sam musiałem to rozklepać. A fakt, że podoba się wam bardziej Jawa z Krypt, to też choroba słabujących na umyśle.

Ja w brew głupiej, sianej tu, propagandzie wcale nie zakładam mojej 100% poprawności światopoglądowej ani naukowej ani zawodowej. Jednak by zmienić swoje poglądy muszę mieć coś więcej niż teksty jakiegoś debila typu "ale głupoty".
W przypadku o którym tu mówimy mamy faktycznie doczynienia ze tematyką wytwarzania systemów wojskowych. Ja powiem szczerze, że b. mnie ciekawi ta tematyka i chętnie bym sobie poczytał o metodach zapewnienia jakości tym projektom. Dla mnie b. przykre jest to jak prowadzi się projekty w polskich fimrach, tak jakby żadnych takich metod nie było. Jednak mimo interesowania się militariami od 30 lat nigdzie nie spotkałem nawet artykułu na temat metodologii prowadzenia projektów wytwarzania nowoczesnego sprzętu wojskowego.

Wygląda na to, że to nie jest temat techniczny!
To jest zwykły flame jak to: "C++ zły niedobry i w ogóle powinien być zaorany".

Ergo IMO powinno to wylądowywać w innym dziale, bo wartości technicznej nie widzę.

Energo Koder napisał(a):

W C++ jest wiele problemów jakich nie ma w D ani w Pytonie: w C++ nie działają f. wirtualne w konstruktorach i destruktorach, brak dziedziczenia operatorów, brak wsparcia Unicode w nazwach, nienormalnie dopasowanie typów: przekleństwo ambigous. Brak ABI wyłącza C++ z całego szeregu zastosowań: nie nadaje się do progr. sys. op., nie współpracuje z innymi językami na poziomie klas (robić to można tylko dzięki ABI z C), nie da się sprzedawać skompilowanych bibliotek (można jedynie sprzedawać skompilowane biblioteki z interfejsem w czystym C).
Tej góry ich własnego guana Stostrupy z Komitetu Centralnego nie chcą ruszyć!

• brak wsparcia Unicode w nazwach
• przekleństwo ambigous - należy poczytać jak działa overload resolution to się okaże, że to wymiata. Trzeba jednak znać narzędzie, którego się używa.
• Brak ABI totalna nieprawda - wykorzystując C jest łatwiej, ale to nieprawda, że się nie da

• przekleństwo ambigous - należy poczytać jak działa overload resolution to się okaże, że to wymiata. Trzeba jednak znać narzędzie, którego się używa.

A jak to "overload resolution" będzie po polsku? Bo ja słabuję z tym j. ang.