🚀 go-pugleaf

Dzień dobry!

Poniżej odp. na apel autora j. C++ Bjarne Stroustrup z Danii, w którym 
wzywa społeczność C++ do obrony tego j. prog. O jego apelu dowiedziałem 
się z art. na s. WWW 
https://ithardware.pl/aktualnosci/tworca_c_jezyk_zagrozony_usa_rust-39456.html 
.

Moim zdaniem nie ma "cudownego sposobu" na eliminację błędów w kodach 
prog. pisanych przez ludzi. Można za to wskazać sposoby ich wykrywania i 
poprawiania.

Najważniejszymi narzędziami programisty pomocnymi w prog. wysokiej 
jakości kodu są: specyfikacja techniczna i testy automatyczne. Moim 
zdaniem wszelkie problemy z atakami typu "buffer-overflow" wynikają albo 
z nieprecyzyjnej specyfikacji technicznej, albo ze zbyt słabych testów 
aut. I nie ma to związku z żadnym j. prog. Po prostu niedbałe prog. bez 
ich dopracowania i tak będą niedbałe i dziurawe. Jedyne co może się 
okazać konieczne to wydłużenie procesu projektowania i testowania 
oprogramowania. Tak by nadać mu wysoką jakość. Na pewno należy 
dopracowywać wszelkie formaty i protokoły stosowane w sieci Internet. 
Być może do testów aut. należało by używać sztucznej inteligencji, która 
metodami siłowymi testowała by wart. typowe oraz w kol. etapach testów 
wart. skrajne jakie są dopuszczalne, a w kol. testach wart. które nie są 
dopuszczalne w specyfikacji technicznej.

Do projektowania protokołów sieciowych i formatów danych oraz do 
kodowania nie używał bym sztucznej inteligencji z tego powodu, że to 
sprawia zagrożenie utraty przez ludzi kompetencji w tych dziedzinach.

W odniesieniu do pow. art. tekst taki jak, cytat:

"Presja ze strony regulatorów
Nie bez znaczenia są także zmiany regulacyjne. Amerykańska CISA 
opublikowała w październiku ubiegłego roku raport zalecający, by do 1 
stycznia 2026 r. producenci mieli plan eliminacji luk pamięciowych lub 
przeszli na języki bezpieczne dla pamięci. Stroustrup uznał to za 
"realne zagrożenie" dla C++.

Rząd USA proponuje następujące języki:
Rust
Go
C#
Java
Swift
JavaScript
Ruby"

jest nonsensowny z tego powodu, że na tej liście tylko Rust i Go są j. 
prog. a reszta to j. skryptowe. Obie grupy j. są nieporównywalne i mają 
inne zastosowania.

Moja końcowa myśl jest taka, że wygląda na to że trafne są moje 
wcześniejsze przewidywania, które opublikowałem w 
https://energokod.pl/komentarze-do-ksiazek/2025-01-19%20F-35%20-%20Zasady%20Kodownia%20-%20komentarz.pdf 
i że faktycznie rząd SZAP/USONA chce wycofać z rynku cywilnego j. C++ i 
że chcą zrobić z niego kol. "czarny proj.". Bo na przekór pow. 
propagandzie SZAP/USONA uruchamia kol. proj. militarne oparte o prog. 
kodowane w j. C++ (patrz wzmiankę o przepisaniu z j. ADA na j. C++ 
oprogramowania nowych wer. rakiet samosterujących dalekiego zasięgu w 
mieś. Nowa Technika Wojskowa, nr 11/2024 art. "JASSM niejedno ma imię, 
czyli AGM-158B-2, B-3, D oraz LRASM i JASSM-XR", aut. Michała Gajzlera).
Znamy to z przeszłości: wcześniej tak było np. z sys. op. Plan9, który 
był stworzony przez twórców sys. op. Unix. Sys. op. Plan9 był genialny i 
przełomowy, jednak porzucony. Co było kol. proj. twórców sys. op. UNIX? 
Pozostaje tajemnicą bez odp. Jednak ja to wiem: następca sys. op. Plan9 
należał do "czarnych proj." czyli tajnych i to na zawsze.
Problemy z niedbałymi prog. kodowanymi w j. C i C++ mogą stać się 
pretekstem do utajnienia kol. wer. tych j. prog.

Jak ktoś ma kontakt z p. Bjarne Stroustup (lub z Komitetem Centralnym 
C++) i zna j. ang. to było by b. dobre gdyby przetłumaczył ten tekst i 
mu go podesłał. Ja zdałem maturę z j. ang. jednak nie czuję się w tym j. 
zbyt swobodnie.

Miłego dnia!
-- 
Jacek Marcin Jaworski
Moja s. WWW to https://energokod.pl .