Najgorszy język programowania

W dniu 7.12.2025 o 11:07, Marek pisze:

Oczywiście, że w śród innego guana jest to najlepszy j. prog.

Nikt nie każe ci używać nonsensownych rozw. Ten j. jest b. elastyczny. np.: w tym j. nie ma nawet wspólnej kl. bazowej dla wszystkich typów (a tak jest np. w j. skryptowym Java).

Ja osobiście w ramach postulowanej przeze mnie izolacji proj. przezwałem typy wbudowane z j. C i C++, oraz przezwałem używane kl. z bibl. Qt własnymi typami (w j. pol.) (więcej na ten temat w całkowicie darmowym dok. PDF dostępnym na mojej s. WWW:

) i stworzyłem sobie 2 bibl.: jedną z podst. kl. i z podst. alg. potrzebnymi do prog. programów konsolowych, a drugą uzupełnioną o kontrolki graf. Obie te bibl. oparłem o Qt. I zapewniam wszystkich daje się normalnie prog. po polsku w j. C++.

Dodatkowo podam, że od 2005r. (rozp. proj. F-35), przemysł zbrojeniowy w SZAP/USONA powszechnie przechodzi z prog. w j. ADA na C++. Wygląda na to, że cała nagonka na j. C++ ma na celu ogłupienie cywilnych prog. C++ i utajnienie kol. wer. tego b. udanego j. prog. (zrobienie z niego "czarnego proj."). Tak jak to miało miejsce w przypadku następców sys. op. Plan 9 oraz popularnych w latach 1980 i 1990 dżojstkików (zastąpionych w cywilu pedalskimi padami). Oba te rozw. (i prawdopodobnie wiele innych) zostały zawłaszczone przez przemysł zbrojeniowy w SZAP/USONA. Ten temat podjąłem w "Odp. Na Apel Twórcy j. C++ Bjarne Stroustrup", dostępnym całkowicie za darmo z mojej s. WWW:

W dniu 7.12.2025 o 12:39, 🇵🇱Jacek Marcin Jaworski🇵🇱 pisze:

Tak elastyczny, że ciężko zrozumieć co ktoś inny nagrzmocił. Gdyby to służyło do jednorazowej komunikacji z komputerem to ok, ale języki programowania służą do wyrażania kodu zrozumiałego dla wszystkich.

Tak, to są wszystko nonsensy i głupoty języka, który wymaga niskopoziomowego sterowania.

Obejrzałem kilka przykłądów z filmu. Koleś, który ten film robił, nigdy nie pisał oprogramowania niskopoziomowego lub dużej skali:

1) Pretensje że C++ ma ficery takie jak inne jęzki (ukryty self w metodzie obiektu). 2) Nie rozumienie po co jest using namespace, więc wylanie tam szamba rozwiązuje problem. 3) C++ się zmienia i to straszne. Nikt nie wie w jakiej wersji pisze. Szczególnie jak jest Autorem. 4) Nie umiem pisać duzych projektów w C++ więc nikt nie umie. 5) Język jest blisko sprzetu i ma inne rozmiary inta. Straszne, wszystkie CPU powinny mieć najlepiej 32 bity i finito, reszta na stryczek. 6) Nie rozumiem unix IO więc nikt nie rozumie. 7) Patrzcie, jak łatwo można porównać gówno javastriptowe z szablonową bibliteką C++! Ależ to javascriptowe gówno jest lepsze jak Twój cały świat to stringi! 8) Niewiarygodne, że niskopoziomowe języki jak C++ nie pilnują samodzielnie Twoich pointerów w kontenerach! Co za skandal. 9) optional nie potrafi trzymać referencji. O jak szkoda. 10) W C++ nie ma GUI! Na szczęscie takie GUI istnieje w Pythonie na przykład, który (tylko niech nikt się o tym nie dowie) korzysta m.in. z Qt w C++. Poza tym to skandal, że język do pisania nieskopiomowego nie ma widgetów. Co za żałosny brak funkcjonalności jak się pisze soft do sterownika przemysłowego od hamulców. 11) Errory są nieczytelne, bo autor filmu jest idiotą, więc są nieczytelne. 12) Dzięki templates możemy mieć specjalizowane funkcje, ale one powiększają binaria! To skandal. Pownni nie powiekszać. Magicznie najlepiej. 13) Templaty tylko w nagłówkach, bo autor filmu to idiota i nie słyszał jak to się robi w cpp. 14) Metaprogramowanie złe, bo jedynye przykłady jakie miał idiota, to te których nie pojmował. 15) C++ jest winny tego, że IDE sobie nie radzą! 16) C++ jest winny, że nie ma refleksji. Nie to co zabawkowe gówna, jak Javascript, w których refleksja zaoszczędza tyyyyle czasu programisty (kosztem CPU, ale kto by to liczył). Zaryzykuję, że każdy projekt, który używa refleksji w miejscu poprawnych design patterns to gówno takie samo jak javascript. 17) C++ nie zapewnia inicjacji zmiennych, bezsensownie allokując czas CPU. Skandal. Potrzebujemy tu jakiejś dyrektywy UE, aby nie wykluczać niepełnosprawnych umysłowo programistów. 18) C++ domyślnie kopiuje. Skandal. Nie to, co C# który nie wiadomo co robi i zależy to od widzimisię typu, jak python, gdzie kompia lub referencja zależą od semantyki uzycia, albo jak js który nie wiadomo co robi, bo to i tak bez znaczenia dla klepacza frontendu następnego sklepu. 19) Autor ma awersję do explicit, które jest chyba w każdym coding standardzie 20) Zachowanie C++ zależy od architektury CPU na której pracuje. Skandal. Przeciez dokładnie o to chodziło, więc po co tak zrobili? Niepojęte. 21) "Nie rozumiem co to są korutyny, ale async w gównie JS jest zajebisty, choć dalej nie wiem jak działa." 22) Każdy powinien mieć obligatoryjnie garbage collector, nawet jeśli pisze na 4004, najlepiej w osobnym wątku i najlepiej typu stop-the-world. To się świetnie sprawdza w nawigacji samolotem. 23) Linus go nie lubi. Szach-mat debile od C++! Rusta też nie lubi, ale nie wnikajmy. 24) Exceptiony zwiększają program! Co prawda 30 lat temu, ale zawsze! 25) Nie da się pisać testów w jeden sposób. Zamiast tego jest ta cholerna wolność. 26) Żeby pisać testy, trzeba projekto podzielić na moduły. No to jest już przegięcie. Autor namęczyć się pisząc 10 milionów lini kodu monolitycznego .exe i nagle ktoś pyta jak odpalić unittesty? Co za bezczelny gówniarz, zero szacunku dla seniorów. 27) Destruktory wołają się tam, gdzie się wołać powinny. Skandal. 28) Najlepszy jest Rust, bo można wszystko zrobić tylko na jeden sposób. One man, one vision. No i po cichu można w nim pisać niebezpieczny kod, więc jak by co...

Podsumowując:

Autor to idiota, który nigdy niw widział śladu zastosowania C++ poza jakimiś graficznymi duperelami. Jego niepojmowanie, że GC jest bezużyteczne w połowie projektów C++ świaczy o bardzo nikłym pojmowaniu niszy, w której C++ siedzi. Promowanie Rusta jeszcze bardziej mnie przekunuje, że koleś nie wie co mówi. Ludzie wybierają C++ do pisania własnie w sposób *niebezpieczny* aby wydoić z implementacji każdy cykl CPU, a nie pieprzyć się z "automatcznym zwalnianiem pamięci, automatycznym inicjowaniem śmieci i GUI". To nie ten język.

Standardowy Strach Na Wróble, tylko tym razem mocno rozdmuchany. Autor stara się wyeksmitować C++ z zagadnień, w kórych go się nie używa, lub gdzie jego użycie jest śladowe i często bezsensowne.

W dniu 7.12.2025 o 15:00, heby pisze:

Mógłbyś rozwinąć temat lub podać jakiś link do odpowiedniego art.?

TPO: Szacun za to, że chciało ci się oglądać do końca te hype stworzone na zamówienie tajnej policji. Ja osobiście nie oglądam YT (ani podobnych s. WWW z filmami) - powody podałem w rap.:

Chwytam idę: extern z konkretyzacją szablonu, czyli sztuczka rodem z C zastosowana w C++. Teraz mam kol. pyt.: Czy twoje doświadczenie wskazuje na to, że ta sztuczka jest używalna w praktyce? Pytam z czystej ciekawości, bo mi ta sztuczka wydaje się b. upierdliwa.

Tak. Przy czym z małym twistem: jest niezwykle mało programistów C++ majacych o niej pojęcie. Wiec tak, ale to nie oznacza, że wszędzie jest tego pełno. Kto używa, ten używa jako normalnego narzędzia.

Odwrotnie. Pozwala tworzyć kod szablonowy i jednocześnie pięknie separować hpp od cpp. Razem z koncepcją ipp (inkludowalne pliki z implementacją, używane w boost) pozwala calkowicie usunąć niedogodności instancjonowania templates, o których bredzi autor filmu. Używam tego intensywanie zarówno w dużych aplikacjach jak i w miniaturowym kodzie na AVR.

Dzięki za wyjaśnienia. Jednak widzę, że podane przez Ciebie linki nie prowadzą do art. które opisują tą sprawę wyczerpująco, bo wspominasz o ipp, który one nie omawiają. Ta ostatnia sprawa jest pobieżnie opisywana na stackoverflow i w archiwum listy dyskusyjnej bibl. boost. Dlatego mi się wydaje, że opis tego rozw. był by dobrym tematem na osobny art. Jednak puki co bez przykładowego, DZIAŁAJĄCEGO kodu ta sztuczka dla mnie pozostaje to jedynie ciekawostką.

ipp nie są tylko do templates, ale do innych zastosowań. Możesz je traktować jako alternatywę dla explicit instantiation ale również do modularyzacji kodu dużych klas.

Hardkorzy od C używali czasem, w powiązaniu z makrami, do emulacji C++, z przyczyn religijnych (i do dzisiaj używają, to już kult).

Boost jest przykładem działającego przykładu.

Tu masz jakiś mikro dla explicit instantiation:

Tu masz jakąs biblitekę korzystającą z explicit instantiation:

Co do ipp, to oczywiście boost.

A nie do optymalnego rozwiązania problemu? Czyli zarówno czytelności, prędkości, objętości, dostepności dev, przenośności itd itp? Tylko do wyrażania kodu zrozumiałego dla wszystkich?

W dniu 7.12.2025 o 13:20, io pisze:

Skoro czegoś nie rozumiesz, to nie jest to wina języka. To twoja wina :]

Ależ zarzut jest raczej taki, że zmienia się tak bardzo, że to powoduje zamęt. Przynajmniej u zwykłych praktyków bo przecież nie u omnipotentów wszystkowiedzących jak Seba.

Akurat w filmie kilka razy autor podkreśla, to że właśnie ma doświadczenie z dużymi projektami i jego punkt widzenia wynika z tego doświadczenia. Gdy się przyjrzy dobrze apologetom C++ to się okazuje, że ich doświadczenie to najczęściej Hello World!.

Dość komiczna argumentacja, czyli nie ma guja w C++ bo jest przecież w pythonie, który korzysta z qt który z kolei korzysta z (podobno) przestarzałego C++... Już pomijając awersję do pythona, że z mojego punktu widzenia jako zwykłego usera jakiekolwiek narzędzie, które było pilnie do uruchomienia na szybko a na nieszczęście zostało napisane w pythonie (po jaki *uj?) to nie działało. Albo python za stary, albo brak jakiś modułów a pip install module nie działa bo to coś tam koliduje z systemowym pakietowaniem. Za każdym razem jak widzę coś w pythonie to mnie krew zalewa bo już wiem za na 99% nie zadziała bo zgodnie z aktualną modą każdy nowy program w pythonie będzie wymagał zawsze jakieś egzotycznej biblioteki/modułu której akurat się nie mam. Widać python działa wg zasady że jak chcesz się napić piwa to musisz kupić cały browar. Kiedyś znajomy podzielił się podobną opinią mówiąc "dziwni ci programiści pythona, bo żaden niczego sam nie umie napisać by działało "standalone" tylko muszą korzystać z innych (modułów) co jest irytujące.". Ja wiem na pierwszy rzut ucha można machnąć rękami, że ktoś nie rozumie idei biblioteki. Co do zasady - tak. Ale z pkt. widzenia użytkownika to on nie potrzebuje pythona, użytkownik potrzebuje spełnienia tzw. paradygmatu exe: potrzebuje narzędzia *działającego* as is a dokładniej to nawet nie potrzebuje narzędzia tylko ważny jest efekt (jak widać teoria Levitt'a, że user potrzebuje efektu a nie narzędzia nie ogranicza się tylko do marketingu). Jak idę do sklepu kupując auto to chcę auto kompletne, jeżdżące. A nie, że sprzedawcą mówi, że u nas są tylko budy, silnik musi pan ściągnąć z... Koła z...

Zadziwiające, że ten argument zawsze pada bezrefleksyjnie. Po co zatem narzędzie, który ogarnia tylko niewielki ułamek użytkowników a ogromna większość tylko psuje nim większość co zrobi dyskwalifikuje narzędzie a nie userów.

Jeśli problem zawęża się *tylko* do rozwiązania problemu i ma spełnić jedynie paradygmat exe to tak. Ale gdy kod wchodzi w skład projektów ciągle rozwijanych i modyfikowanych to czy kwestia prawidłowego zrozumienia nie jest kluczowa?

Wuciąłeś dokładnie to, o czym pisałem. Wybór języka programowania jest zbiorem decyzji z różnych dziedzin. Samo pojmowanie języka nie jest dostatecznie dobrym argumentem, jest wręcz najgorszym. Inaczej mielibyśmy kernele pisane w BASICu.

Czyżby? Wielokrotnie (w projektach skali korpo) spotkałem się z wyborem typu Heniek wybrał [tu pada język lub architektura] bo tylko on na tym się zna (czyli kernel w Basicu). Drugi rodzaj wyboru to: nikt nie wie dlaczego tak wybrano, bo technologia przyszła z dobrodziejstwem inwentarza spółki jaką się kupiło. Życie pokazuje zupełnie coś innego.

Refleksja jest dostateczna. Pewne techniki pisania w C++ są mało znane. To datego, że większośc programistów na rynku C++ to tak naprawdę C+. Jakieś klasy ale nie za dużo, templaty unikają jak ognia, zero pojęcia o arachitekturze dużej skali, linkowanie ogarnia jedyny w firmie senior z brodą, a że on należy do kultu C, to klnie przy tym i potem wychodza z tego takie debilizmy jak wspomniany film na YT.

Niewiele tu pomaga literatura, ksiązki które omawiają takie problemy praktycznie nie istnieją. Prościej napisać kolejną o Node.js niż o boost.

Bez przejścia przez szkołę zycia w firmie, która te techniki uzywa na codzień, nie masz szans sie z nimi zapoznać.

Ja mialem okazję np. ogarnąć closures w parsere spirit, bo taki kod musiałem rozwijać. Google kiedyś prezentowało na ten temat 0 wyników.

To powoduje, ze pisanie w C++ nie jest dla każdego. Wręcz, z biegiem lat, coraz mniej programistó migrujacych z różnych gówien, jak JS, nadaje się to pisania kodu w C++. Nawet nie z powoduj języka, tylko braku śladu pojęcia o architekturze komputerów. Tłumaczenie programiście, przez 5 godzin, czym jest wskaźnik już przerabiałem. To nie ma znaczenia, czy w C czy C++. On tego nie pojmuje. To całkiem niezły programista jest, zna frameworki o których nie słyszałem i nie potrfiłbym ich uzyć.

Pokolenie wychowane na Z80/6502 czy Amidze powoli wykrusza się do stanowisk managerskich, nowi nie mają pojęcia jak działa hardware. W efekcie czego na koniec nie będzie komu tego utrzymywać, jak w COBOLu. No dobra, przesadzam, AI będzie. I niewątpliwie przepisze kernel Linuxa do JS. Idę o zakłąd, że da radę, bo już próby były. Ależ ciekawe czasy przed nami.

Nie, z powodu, że większość społeczeństwa nie potrafi kierować ciągnikiem sidłowym nie wynika, że ciągniki siodłowe są do zaorania. Znaczy są do orania, ale ... no ...

Czyli jaki zamęt? Jak napiszesz kod w jakiejś wersji C[++] i odpalisz na nowszej wersji to połowa nie zadziała?

Gdzie ten zamęt? Bo się jedna linia na milion nie skompilowała? Ona się zazwyczaj nie kompiluje z powodu błedu.

Ale pokaż mi praktyki, gdzie Ci się zasiał zamęt, że ktoś zmienił kompiltor z C++XX na C++XX++.

Dziwne, mam doswiadczenie z zajebiście duża bazą kodu w C++ i jakoś nie widzę problemów z utrzymaniem tej bazy. To wynika z dyscypliny.

Natomaist to nie są jedyne moje doświadczenia. W wielku firmach mają podejście "zlinkujmy to wszystko w chuj" i potem na bazie tego generują się jakieś debilne opinie o tym jaki C++ jest nienadający się do niczego.

Nie, to "lokalni architekci" nie nadają się do niczego. Nie mają pojęcia jak projektować, modularozować, ciąć abstrakcjami, dynamizować bazę kodu. Bo oni 20 lat temu pisali aplikację ktora miała 10tyś lini kodu, a teraz ma 10mln lini kodu i dalej wymusząją te techniki, bo obecnie są architektami z władzą decyzyjną.

No i ta fobia, na widok słowa "refaktoring", która powoduje że menagement dostaje ataku sraczki.

Nie, argumentacja jest taka, że pod spodem tych wszystkich biblitek graficznych nowoczesnych jezyków bardzo często jest sobie GUI w C/C++.

Jakie to ironiczne. Język, kóry nie ma GUI jest bazą kodu dla biblitek GUI.

Z grubsza dotyczy to wszystkich języów programowania z systemami pakietowymi. Ostatnio z przyczyn pozalogicznych, zajmuje się Node.js. Takiej ilosci konfliktów systemu pakietowego nie widziałem nigdy. To się nie mieści w głowie. Aż napisałem skrypt który instaluje kazdy pakiet osobno w konkretnej wersji, bo drugi raz przez to piekło nie chcę przechodzić. Zapytałem znajomego jak oni z tym żyją. Powiedział, że raz ustawionego środowiska się nie rusza, tylko dyski klonuje. Aha.

Idiotyczny argument bo społeczeństwo powszechnie nie rzuca się na kierowanie ciągników siodłowych poza *wykwalifikowanymi* do tych celów. Możemy pominąć liczbę wykwalifikowanych idiotów przynoszących szkodę jazdą ciągnikiem siodłowym jako nieznaczący promil w skali powszechnego transportu.

Natomiast skala nieprawidłowego użycia i dostępu do kwestii w temacie wątku jest ogromna. Usprawiedliwianie się tym, że tylko niewielu się zna nie rozwiązuje problemu.