-
Data: 2019-09-06 12:06:02
Temat: Re: Jak to robią w NASA
Od: "M.M." <m...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]On Friday, September 6, 2019 at 10:33:01 AM UTC+2, Mateusz Viste wrote:
> On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
> > A uzasadnienia i tak i tak nie będzie.
>
> AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
> widziałem by kiedykolwiek sam cokolwiek mądrego napisał. Niemniej (a
> raczej tym bardziej) jestem pod wrażeniem cierpliwości którą kolega
> wykazuje.
Rozmowa, a przynajmniej któryś post, wydała się bardzo ciekawa i, nawet
nie byłem cierpliwy, tylko zwyczajnie chciałem się dowiedzieć jaka
jest (najlepiej kompletna) lista argumentów za tym, że C++ nie nadaje
się do tworzenia niezawodnych systemów. I, rzecz jasna, jaka jest
alternatywa dla C++, bo jak C++ ma wady, a nie ma nic wyraźnie lepszego,
to żadne argumenty mnie nie przekonają.
Warto zobaczyć ile błędów było w różnych kompilatorach w różnych językach.
Do C/C++ jest dużo niezależnych kompilatorów, można więc łatwo zrobić
testy krzyżowe - to już jest mocny argument za użyciem C++. Ja często
bym wolał coś w okolicach języka D, ale D nie ma takiego wsparcia jak C++,
więc używam C++.
Potem koszty, ciekawe ile kosztuje dobry programista w niszowym-dedykowanym
języku? Może dwóch programistów w C++ napisze bezpieczniejszy kod, niż
jeden (za te same pieniądze) w niszowym-dedykowanym języku?
Potem mnogość bibliotek. Do C++ jest całkiem sporo, często biblioteki są
pisane natywnie w C/C++, a dopiero później robi się port do innych języków.
Robienie portu to dodatkowa okazja do popełnienia błędów, więc bezpieczniej
jest w natywnej. A jeśli do dedykowanego języka nie ma bibliotek, to ciekawe
ile błędów narobią, albo ile czasu stracą na tworzenie/portowanie swojej biblioteki?
Może w tym czasie poprawili by właściwy kod aplikacji w C++?
Kolejna sprawa, napisałem w C/C++ sporo, w tym też kilka pewnych aplikacji.
Defakto były to malutkie aplikacje, ale wcale nie były trywialne obliczeniowo.
Z powodu agresywnej optymalizacji są zaprzeczeniem bezpiecznego stylu
programowania. Mimo to, działają do dziś, od wielu lat nie miałem zgłoszenia
błędu. Jeśli aplikacja nie musi być super zoptymalizowana (mowa o optymalizacji
na jeden procesor, bo w zamian za to, aplikację nadal można optymalizować na
klastry i/albo GPU) to można w C++ stworzyć aplikację składającą się np. w 98% z
czytelnego i bezpiecznego kodu. Pozostałe 2% nie jest kulą u nogi, lecz pomaga
utrzymać jeszcze większy porządek w tych 98%, stanowi dobrze wydzielone
procedury wielokrotnie użyte (a więc dobrze przetestowane) w kodzie.
Co tu by jeszcze dorzucić na korzyść C/C++... Może to, że jeśli aplikację
jednak trzeba trochę zopytmalizować na jeden procesor, to do C/C++ są
bardzo dobre optymalizatory. Więc w takich przypadkach w C++ można sobie
napisać czytelnie, a martwi się optymalizator. W innych językach które
nie mają takiego wsparcia może trzeba jakieś haki czasami w kodzie robić,
żeby procesor/ram nadążył.
Oczywiście C++ ma wady, ale te wady wynikają ani z języka, ani z narzędzi,
ani z bibliotek, lecz z ogromnej swobody programowania jaką daje język
C++. Jeśli, szczególnie mniej doświadczony, programista dostanie wiele
swobody, to niewykluczone że użyje jej przeciwko bezpieczeństwu systemu.
W C++ np. nie ma obowiązku inicjowania zmiennych przy deklaracji, a domyślnie
są inicjowane tylko w określonych sytuacjach. Jeśli ktoś w krytycznych
systemach zbagatelizuje ten problem, uzna np. że jego kod jest na tyle
dobry, że nie będzie odczytów przed inicjacją, to cóż... można przenieść
rozmowę na grunt czy to wina programisty, czy języka, narzędzi i bibliotek.
Moim zdaniem to wina programisty, a kompilatory w C++ dają sporo ostrzeżeń
przy ryzykownych konstrukcjach.
Nie chce mi się dalej ciągnąć, bo autor nie powiedział co jest takiego
złego w C++.
Pozdrawiam
Następne wpisy z tego wątku
- 06.09.19 12:57 Mateusz Viste
- 06.09.19 15:42 Maciej Sobczak
- 06.09.19 16:06 Mateusz Viste
- 06.09.19 17:06 AK
- 06.09.19 17:11 AK
- 06.09.19 18:22 M.M.
- 06.09.19 18:29 g...@g...com
- 06.09.19 19:14 g...@g...com
- 06.09.19 20:28 M.M.
- 06.09.19 21:03 Maciej Sobczak
- 06.09.19 21:12 Mateusz Viste
- 06.09.19 21:25 Maciej Sobczak
- 06.09.19 23:00 g...@g...com
- 06.09.19 23:59 g...@g...com
- 07.09.19 01:48 g...@g...com
Najnowsze wątki z tej grupy
- Nowa ustawa o ochronie praw autorskich - opis problemu i szkic ustawy
- Alg. kompresji LZW
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
Najnowsze wątki
- 2025-03-16 Nowa ustawa o ochronie praw autorskich - opis problemu i szkic ustawy
- 2025-03-16 Nowa ustawa o ochronie praw autorskich - opis problemu i szkic ustawy
- 2025-03-16 Najlepszy akumulator 12V
- 2025-03-16 Co powinno spotkać "adwokatów dwóch" uczestniczących w przesłuchaniu świadka do którego nie dopuszczono adwokata świadka?
- 2025-03-16 Przednich p-mgielnych nie wolno bez mgły
- 2025-03-16 Co w KANADZIE wolno komercyjnie (na razie się nie czepili?)
- 2025-03-16 silnik-chwilówka
- 2025-03-16 Prokurator Wrzosek "Bezstronna" nie przyczynia się do śmierci (dowodnie) - oświadcza bodnatura [Dwie Kacze Wieże]
- 2025-03-15 kraje nieprzyjazne samochodom
- 2025-03-15 parking Auchan
- 2025-03-15 Art. 19.1 ustawy o ochronie praw autorskich
- 2025-03-15 przegląd za mną
- 2025-03-15 Na co komu okna
- 2025-03-15 Mój elektryk
- 2025-03-15 Fejk muzyczny czy nie fejk