W dniu piątek, 25 sierpnia 2017 01:12:43 UTC+2 użytkownik M.M. napisał:
> 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?

Nie wiem. Ja nie myślę algorytmami, tylko relacjami
między pojęciami. W moim odczuciu myślenie, którego
uczy C++, jest raczej dość kulawe, co bierze się stąd,
że jest w nim dużo niespójności i przypadkowych decyzji.
W rezultacie tego rodzaju wzorzec może podszeptywać
programistom, że "z niespójnościami da się żyć" i że
"przypadkowe decyzje są nie do uniknięcia". Nawet jeśli
z niespójnościami da się żyć, a przypadkowe decyzje są
nie do uniknięcia, wydaje mi się, że to nie jest dobra
nauka.

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

Zgadzam się.

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

Nie znam takiego słowa. Może masz na myśli to, co określa
się mianem pseudokodu?

Ale skoro tak, to dlaczego ów "metakod" nie miałby być
językiem, który od razu można wykonać na komputerze?

> > 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?

Wrócę do tego wątku mniej więcej za miesiąc, proszę
o cierpliwość :)

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

Jasne, zdecydowanie tak.
To jest też powód, dla którego cenię Pythona -- bo daje wskazówki
odnośnie tego, jak należy w nim programować. Z tego też względu
wolę Scheme'a, bo nie stawia dziwacznych ograniczeń na nazewnictwo
zmiennych.

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

Masz na myśli Scalę, czy angielski? :)
Jeżeli idzie o Scalę, to przyznam, że nie do końca rozumiem
fenomen, ale chyba zamysł był taki, żeby ułatwić programistom
Javy wejście w świat programowania funkcyjnego.

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

No jo. Tyle że książek jest dużo.
Jak wspominałem, ja się uczyłem z "Język C++" Stroustrupa.
To może nie być zbyt dobra książka do nauki.

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

Nie wiem, czy we wszystkich. Myślę że Clojure albo Scala
mogłyby spokojnie pociągnąć. Kiedyś też zdarzało mi się przetwarzać
wielkie zbiory danych w Perlu, i radził sobie doskonale.

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

Zgadzam się, że to jest w praktyce wielki problem, dlatego
moim zdaniem powinniśmy się skupić na opracowywaniu tego rodzaju
narzędzi. Pewnie "linia najmniejszego oporu" przebiega przez ręczne
optymalizowanie aplikacji w C++, ale z punktu widzenia "rozwoju ludzkości"
bardziej racjonalne wydaje się wykonanie optymalizacji tylko raz
dla wszystkich programów, a nie tyle razy, ile jest programów.

Ale zgodzę się, że z dobrymi narzędziami jest taki problem,
że albo ich nie ma, albo nie wiemy o tym, że są.

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

Nie rozumiem jak można się zakochać w Javie :)

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

To jest akurat najprostsza rzecz: jeżeli masz program w C++ korzystający
z STLowych kolekcji, to łatwo powinno być napisać np. algorytm genetyczny,
który zadany zbiór przypadków testowych bada na różnych konfiguracjach
kolekcji.


> > 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ść.

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

Naprawdę, jedyne, co brak automatycznego zwalniania pamięci umożliwia,
to pisanie programów z wyciekami pamięci.

> > 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?

Mutacja, czyli modyfikacja istniejącego obiektu.
Na przykład takie coś, co wyszło w rozmowie z AK, w Pythonie:

a = [1,2,3]
b = [4,5,6]
a += b

w trzeciej linijce tablica "a" została zmodyfikowana, czy też
doszło do "mutacji". faktycznie może "mutacja" nie ma w języku polskim
najlepszej konotacji, ale często mówi się np. o obiektach albo zmiennych
niemutowalnych.

przykład, którym na razie się zajmowałem, to haskellowy wariant
quicksorta:

qsort [] = []
qsort (pivot:rest) = (qsort below) ++ [pivot] ++ (qsort above)
where below = [x | x <- rest, x < pivot]
above = [x | x <- rest, x >= pivot]

problem z tym, że ta funkcja nie jest "quick", i że -- tak jak
oryginalny Quicksort Hoare'a działał podstawiając elementy tablicy
w miejscu (czyli mutując tablicę), tak ten generuje bardzo dużo
śmieci. Ale istotę jego działania widać jak na dłoni.

> Jakby to działało, gdybyś od razu w C++ lub Javie napisał?

Za mniej więcej miesiąc podeślę, to będziesz mógł sam ocenić,
ale podejrzewam, że raczej bym czegoś takiego nie napisał w C++
ani w Javie