W dniu poniedziałek, 21 sierpnia 2017 22:15:55 UTC+2 użytkownik s...@g...com
napisał:
> Ja odnoszę wrażenie, że obecnie programiści nie za bardzo wiedzą jaki język jest na
prawdę najlepszy i myślą, że w zasadzie to najbardziej zależy od zastosowania. Bo w
większości wypadków nie ważne jest jak jest szybki - liczy się jak szybko da się coś
zakodować.

Co więcej, niektórzy programiści (np. ja) śmią twierdzić, że
stwierdzenie, że "język programowania jest szybki", jest błędem
kategorialnym. Może można powiedzieć, że dany język posiada implementację
pozwalającą na szybkie wykonywanie napisanego w nim kodu. Ale w ogólnym
przypadku sprawa nie jest taka prosta.

> Ja natomiast mam inne zdanie na ten temat.
>
> Moim zdaniem (porównując najpopularniejsze języki: Asembler, C, C++, D, Java, PHP,
Python, JavaScript - tyle poznałem i mi to wystarczy) okazuje się, że C++ jest
najlepszy. Oto powody:

Jeżeli chcesz zrobić aplikację działającą w przeglądarce, C++ wiele Ci
nie pomoże -- niestety, jesteś raczej skazany na JavaScript, albo coś,
co się kompiluje do JavaScriptu (Elm, CoffeeScript, TypeScript, PureScript,
ClojureScript, ...)

Jeżeli zaś idzie o stwierdzenie, czy dany przekrój języków jest wystarczający,
to tak naprawdę kwestia nie jest taka oczywista. Ludwig Wittgenstein
stwierdził w "Traktacie logiczno-filozoficznym": "Granice mojego języka
oznaczają granice mojego świata". W podobnym duchu rozumował Paul Graham,
formułując swój "Blub paradox": http://www.paulgraham.com/avg.html

Najlepszy język, jaki znamy, nie pozwala nam obiektywnie spojrzeć na jego wady.
Dopiero znajomość wielu różnych języków pozwala widzieć wady i zalety
w pooszczególnych przypadkach. Moim zdaniem Haskell jest pod wieloma
względami dużo lepszy niż C++. Ale pewnie warto się zapoznać z odmiennymi
sposobami myślenia, takimi z jakimi masz do czynienia w przypadku
języków takich jak Forth, Prolog, Smalltalk czy Scheme.

> 1. Bez udziwnień obsługuje standardowe API obecnych systemów operacyjnych (czyli
C). D ma niby wsparcie dla funkcji C ale trzeba je zdeklarować w języku D.

W C++ też musisz zadeklarować te funkcje jako extern "C".
Zaś jeżeli idzie o udziwnienia, to name mangling jest jednym
z największych, jakie widziałem.

> 2. Zapewnia wszystko to co język obiektowy powinien mieć - a nawet więcej niż wiele
innych języków, bo ma wielodziedziczenie i szablony. I to wszystko ma bez udziwnień -
są to cechy naturalne tego języka.

Szablony zdają mi się jednym wielkim udziwnieniem. Tym bardziej,
że nie zostały zaprojektowane w celu, do którego finalnie zaczęły
być używane.

> Tak więc nie jest uczciwe porównywanie tego języka do Asemblera. Tu bym porównał
raczej Asemblera do łopaty, a C++ do koparki, a języki skryptowe do mini koparek.

W ogóle mówienie o asemblerze jako języku to pomyłka.

> 3. Kompiluje się do kodu maszynowego i przez to działa w sposób naturalny - jak to
przewiduje producent procesora. Jego pliki wykonywalne są najmniejsze z możliwych,

No chyba nie są.

> są prawie tak szybkie jak programy asemblerowe i działają samodzielnie (wymagając
jedynie bibliotek dll - jeśli tak zostały skompilowane - a często wymaga tego
licencja biblioteki). Nie wymaga żadnego interpretera, ani żadnych "maszyn
wirtualnych" które nic nie dają prawdziwemu programiście (bo gdy do C++ przechodzi
się z Asemblera to ręczne zarządzanie pamięcią jest czymś naturalnym i intuicyjnym -
ja w ten sposób się uczyłem, bo to wydawało mi się najsensowniejsze i nadal tak mi
się wydaje). Poza tym obecnie w C++ zarządzanie pamięcią często ogranicza się do
podania "rodzica" jako parametr konstruktora i on usuwa ten nowy obiekt (Qt tak jest
zrobione), lub używa się "sprytnych wskaźników" które usuną obiekt kiedy trzeba (to
implementuje biblioteka standardowa).

Czyli masz miliard różnych sposobów zarządzania pamięcią, co w konsekwencji
utrudnia wnioskowanie o tym, co się wydarzy

> 4. Umożliwia dobrą separację interfejsu (deklaracji) i implementacji. Są pliki *.h
które dobrze opisują zawartość plików *.cpp. To trzeba docenić, bo tego nie ma w
innych (wymienionych) językach z wyjątkiem C.

W Haskellu separacja interfejsu od implementacji jest dużo lepsza
niż w C++

> 5. Jest przenośny. Umiejętnie pisane programy (w Qt ;] ) są bez problemowo
przenośne. A kod nieprzenośny daje się izolować (można wyłączać całe pliki *.cpp i
kompilować warunkowo). Ta przenośność teoretycznie nie jest obarczona jakimś spadkiem
wydajności czy innymi ukrytymi kosztami. Teoretycznie programy C++ są przenośne na
każdą platformę na którą jest odpowiednio aktualny kompilator C++. Jednak ważniejszym
ograniczeniem jest wsparcie danej platformy przez dostawców bibliotek.

Python też jest przenośny między różnymi platformami (w końcu jest napisany
w C). Podobnie Haskell. Scheme jest tak przenośny, że aż ciężko to sobie
wyobrazić. Są kompilatory Scheme do C, kompilatory do kodu maszynowego
popularnych platform, kompilatory do JavaScriptu, interpretery w JavaScripcie,
implementacje na JVM i na CLR.

Zresztą C wydaje się bardziej przenośny niż C++. Z pewnością dużo łatwiej
napisać dla niego kompilator.

> 6. C++ żyje własnym życiem bez dominacji jednej firmy która by narzucała innym jaki
ten język ma być. Nie kompatybilne zmiany się nie przyjmują, bo ludzie chcą mieć
wybór - np.: pod Windows kompilator VC++, a pod Linuxem g++...

Python tak samo. Haskell tak samo. Racket tak samo.