W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał:

> Zależy do czego. Rzecz z bibliotekami ma się tak,
> że ich użyteczność ogranicza się zazwyczaj do celu,
> w jakim zostały zrobione. Mówiąc inaczej, to są przetarte
> szlaki, i do rozwiązania typowych problemów z reguły
> pewnie wystarczą.
No tak. Ale, o ile się nie mylę, podobnie jest w każdym języku.
Część zadań rozwiązuje się przy pomocy środków jakie są
dostarczane na poziomie języka, a drugą część na poziomie
środków z bibliotek. Jeśli jest więcej na poziomie
języka i język umożliwia bardziej zwartą składnię, to
można odnieść wrażenie, że język jest lepszy do danego
zadania. Lepszy w sensie że trzeba mniej kodu wpisać,
zapewne jest. Poza tym to nie wiem... Napisałeś kilka
postów powyżej, że niektóre języki nie są tylko językami
programowania, ale językami myślenia. Jeśli się myśli
algorytmami, to pewnie masz rację, chociaż... napiszę poniżej
coś o pewnym programie do gry w szachy. Ale jeśli myśli się
optymalnym rozwiązaniem danego problemu, to może język
C++ jest językiem myślenia?

> Dlatego jeżeli C++ pomaga Ci w osiąganiu Twoich celów,
> to jak najbardziej korzystaj z niego.
> Ale stąd jest jeszcze daleka droga do powiedzenia, że jest
> "najlepszy",
Bez kontekstu powiedzenie o czymś że jest najlepsze w ogóle
nie ma sensu.


> tak jak niektóre osoby by chciały. Być może
> w niektórych sytuacjach rzeczywiście będzie najlepszy,
> ale nie w jakimś absolutnym sensie, tylko w sensie przygodnym
> -- bo akurat nikt nie zrobił lepszych bibliotek dla innych
> języków. C++ jako abstrakcyjna notacja do komunikowania
> i zapisywania idei raczej się nie nadaje.
Pewnie że nie, bo do tego celu najlepszy jest metakod.

Miałem napisać coś o programie do gry w szachy. Otóż
był on napisany w C++ i procedura alpha-beta nie odbiegała
dużo od meta-kodu - ale oczywiście metakodem nie była.


> Nie jest dobrym
> narzędziem dla umysłu (choć może jest dobrym narzędziem
> dla przemysłu)
Może zależy jaki umysł? Jeśli umysł jest nastawiony na
optymalizację kodu, to może jest dobrym językiem dla
umysłu?


> Dziś rozmawiałem o tym z kolegą z pracy. Opowiadał, że
> na pierwszym roku studiów miał za zadanie zrobienie kalkulatora
> GUI na Windows. Powiedział, że męczył się z tym zadaniem
> 3 dni w C++, podczas gdy jego kolega przyszedł i zrobił w C#
> w 3 godziny.
Jeden wygenerował kod GUI, a drugi wklepał - stąd różnice.
Jeśli trzeba szybko napisać program, to C++ nie jest
dobrym wyborem, poza sytuacją gdy do danego problemu są
dobre biblioteki. Do C++ dziś jest wiele dobrych bibliotek,
co powoduje, że C++ do wielu zadań jest w miarę dobrym
wyborem nawet jeśli kryterium jest czas utworzenia programu.
W QT też zdarzało mi się wyklikać w 3 dni dużą aplikację,
której czas wykonania był szacowany na 1-2 miesiące. Fakt
że to zdarzało się bardzo rzadko.


> Z C++ jest taki problem, że to nie jest język, tylko
> worek różnych ficzerów, które czasem do siebie pasują,
> a czasem nie. Jeżeli chcesz pisać w C++ tak jakby był
> Javą, to możesz to zrobić. Jeżeli chcesz w nim pisać
> tak, jakby to było C, to też możesz. Niektórzy powiedzą,
> że to dobrze, bo "język daje wolność". Jednak ja nie
> uważam, że to jest dobra wolność, bo jeżeli masz w zespole
> programistów z różnym backgroundem, to każdy będzie mógł
> pisać po swojemu.

Ja się wykłócałem i to w innych językach o sposób nazywania
zmiennych, pól, metod i klas. I to nie o to że nazwa jest
zbyt skrótowa i za mało mówi, czy zbyt rozwlekła i odciąga
uwagę od istoty kodu, tylko o to, kiedy duża litera, kiedy
znak podkreślenia. Każdy ma jakiś swój background. W zespole
trzeba przyjąć jakieś zasady. Ja z reguły nastawiałem się
solidny szkielet aplikacji, w ramach szkieletu były moduły, a
moduł oznaczał cokolwiek. W ramach modułu była duża wolność,
ryzyko wywalenia całego modułu było akceptowalne, natomiast
zazębianie się modułu z całą aplikacją było według bardzo
rygorystycznych zasad.


> Dla odmiany, wydaje mi się, że języki, które narzucają
> na programistę więcej ograniczeń, jak np. Clojure, w którym
> wszystko jest niemutowalne, w rezultacie dają kod dużo
> lepszej jakości. Ładnie to ujął Runar Bjarnason w swojej
> prezentacji, której tytuł mówi już dość wiele: "Constraints
> Liberate, Liberties Constrain":
> https://www.youtube.com/watch?v=GqmsQeSzMdw
Żałuję teraz że nie znam tego języka, byśmy porozmawiali.

> Pytanie, skąd się uczyłeś C++a
Z literatury.

> I jeżeli im mają i im działa, to dobrze. Ale trzeba mieć
> świadomość, że to jest w dużej mierze owoc tego, co się im
> jako firmie udało wyrzeźbić z tego kloca, jakim jest C++.
> A jeśli rzeźbili, to podejrzewam, że było dużo prób i błędów.
> Pytanie, ile te próby i błędy kosztowały.

Ja się zgadzam, że C++, za wyjątkiem sytuacji gdy już są
gotowe biblioteki, nie jest najlepszym języku do szybkiego
wykonania aplikacji. Natomiast jak "rzeźbiłem z tego kloca"
aplikację która obsługiwała bazę ram 1TB, to w C++ chociaż
mogłem wyrzeźbić, a we wszelkich innych językach/narzędziach
by padło przy 100GB, a może przy 20GB. W rozwiązaniu
pilotażowym opartym o PHP + JS + PgSQL nawet nie ruszyło.


> Ja jestem całkowicie przeciwny. Jedyną rzeczą, jaka powinna się liczyć
> przy pisaniu kodu, jest wygoda programisty i łatwość refaktoryzacji.
> Jeżeli wszystko ma działać szybko, powinniśmy tworzyć dobre narzędzia
> optymalizujące.
Mi też tak mówili wiele razy, wiele osób, w wielu sytuacjach.
A potem narzędzi optymalizacyjnych nie było i dupa. Pewnie że
ja też bym chciał programować tylko w Javie, bo się zakochałem w
tym języku. Gdy wydajność nie jest ważna, to powinno się sięgać
po takie języki.

> To też jest problem, że jak chcesz mieć kontener, to musisz
> wybrać, czy to jest kontener z STL, czy Qt. Ale tego problemu
> nie da się rozwiązać, zachowując kompatybilność wsteczną.
Gdy wydajność nie jest ważna, to się bierze pierwszy z
brzegu i potem konwertuje, jeśli np. biblioteka gui nie
akceptuje std::vector. Gdy jest ważna, to szablon się
parametryzuje szablonem sparametryzowanym przez jeszcze trzy
inne szablony i sprawdza każdy wariant - i mamy typową
sieczkę optymalizacyjną, a nie kod podatny na refaktoryzację i
rozwój.


> Też nie wiem. Języki etniczne ciężko jest ze sobą porównywać,
> bo wszystkie są raczej złożone i idiosynkratyczne.
hmmm


> Tyle że programiści często myślą, że to, że C++ daje dużą kontrolę
> nad sprzętem, to dobra rzecz.
> Myślę, że jest dokładnie odwrotnie. Im mniej intymnych szczegółów
> język może wiedzieć o systemie, na którym jest uruchamiany, tym
> lepszą robotę mogą odwalić narzędzia uruchomieniowe.
Taka jest teoria. W praktyce byśmy musieli mieć sztuczną inteligencję
do kompilowania kodu w językach wysokiego poziomu. Kompilator
musiałby wiedzieć jakiej puli algorytmów może użyć aby zapewnić
poprawne wyjście dla wszystkich dozwolonych wejść.


> Nawet nie tylko można, ale i się pisze. Całą masę. Zresztą
> C++ też tak zaczynał.
No tak.

> Dlaczego miałbyś chcieć język bez automatycznego zwalniania pamięci?
Dlatego że wierzę, że dla takiego języka i sposobu programowania
jaki taki język pociąga za sobą, można w praktyce jeszcze napisać
kompilator generujący bardzo efektywny kod. A programowanie byłoby
wygodniejsze niż w C++.


> Nie wiem, nie używałem nigdy (i wolałbym nie używać), ani nie implementowałem.
Ok.

> Ostatnio implementowałem dużo algorytmów grafowych czysto funkcyjnie,
> ale niestety powodowało to narzut złożoności algorytmicznej w stosunku
> do wersji korzystających z mutacji.
> Stąd teraz mam taką zabawę, że wymyślam metody automatycznej
> transformacji programów napisanych funkcyjnie w wydajniejsze
> programy stosujące mutację.
Nie wiem co to jest mutacja. Jak to się zachowuje po optymalizacji,
spadła złożoność algorytmiczna? Jakby to działało, gdybyś od razu w
C++ lub Javie napisał?

Pozdrawiam