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