On Friday, August 25, 2017 at 11:35:46 AM UTC+2, g...@g...com wrote:
> 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.
Tu się robi ciekawie, ale z góry się obawiam, że przejrzystej
rozmowy nie przeprowadzimy na temat myślenia algorytmami,
pojęciami, czy optymalizacją. Ale muszę zapytać: jak to jest
myśleć relacjami? Przykładowo piszę grę w szachy, jak to
jest myśleć relacjami?


> 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.
Nie wiem. O jakie przypadkowe decyzje chodzi? Czy
chodzi o to, że jedno zadanie można zrealizować na
wiele sposobów, czyli że można użyć wektora, tablicy,
wskaźników i programista myśli co lepsze, a nie jak
po prostu zrealizować zadanie? Jeśli wydajność jest
ważna, to testuje się wszystko, a jeśli nie, to albo
bierze się Javę, albo programuje w C++ tak jak w Javie,
czyli bierze się wektor.

> 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.
Kiedyś tak mówili o basicu. Słyszałem nawet, że kto programuje w
basicu, to już nie może się nauczyć programowania w innych
językach, bo ma tak dużo złych nawyków. Potem Javę reklamowano
jako język w którym łatwo pisać programy nie zawierające
błędów i że jest językiem pozbawionym wad C++. Teraz chyba
Java też jest niedobra bo jest ruby, R i inne pytony.

Jeśli chodzi o zalety programowania w C++, to ja zauważyłem
jedno. Programiści którzy zadali sobie trud nauki programowania
w C++, potem lepiej i szybciej odnajdowali się w innych
środowiskach.

Nie wiem czy nasza rozmowa do czegoś doprowadzi. W niektórych
językach na pewno można uzyskać bardziej zwarte rozwiązanie
niektórych problemów niż w innych. I to jest faktem. Kiedyś
używałem R do zadań optymalizacyjnych, np. do trenowania sztucznych
sieci neuronowych. Można było w R zrobić bardzo wiele przy pomocy
małej ilości kodu. Jakbym chciał w R napisać aplikację okienkową,
to też byłoby tak gładko? Chyba nie?

> Nie znam takiego słowa. Może masz na myśli to, co określa
> się mianem pseudokodu?
Tak, mnie jakoś lepiej brzmi meta-kod. Pseudo kojarzy mi się z
podróbką, ale zapewne o tym samym mówimy.


> Ale skoro tak, to dlaczego ów "metakod" nie miałby być
> językiem, który od razu można wykonać na komputerze?
Nie wiem dlaczego, może dlatego że jeszcze nie mamy
sztucznej inteligencji? Swoją drogą, chyba opracowałem
fajny model sztucznych sieci neuronowych, ale to jeszcze
nie ta era, żeby programy zamieniały metakod na asembler :)



> Wrócę do tego wątku mniej więcej za miesiąc, proszę
> o cierpliwość :)
To napisz chociaż co planujesz?


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

W C++ trzeba się umówić jak co nazywamy.


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

Ciekawe jak potem działają programy napisane w scali.


>
> > > Pytanie, skąd się uczyłeś C++a
> > Z literatury.
>
> No jo. Tyle że książek jest dużo.
I dużo miałem na biurku.

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

Bardzo w to wątpię. Myślę, że z powodu narzutu pamięciowego te
dane w RAM by się nawet nie zmieściły.


> > > 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.
Idea fajna, ale czy to jest w ogole możlie? Człowiek może przepisać
program z Javy na C++, ale bez dokumentacji też nie zawsze mu się
uda. Sztucznej inteligencji jeszcze nie ma.


> 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.
Masz rację, tylko pytanie, czy to jest możliwe?


> 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 :)
Nie ma tu nic do rozumienia, albo język się podoba, albo nie.


> 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.
Ja zazwyczaj podstawiam kilka kombinacji i mierzę czas wykonania. Moim
zdaniem sensowne używanie algorytmów genetycznych do optymalizowania
kodu będzie możliwe też dopiero gdy będzie dostępna sztuczna inteligencja.
Do takich zadań jest potrzebna procedura, która rozstrzygnie, czy dwa
programy dadzą takie same dane wyjściowe dla dowolnych dopuszczalnych
danych wejściowych. W przeciwnym razie programista musi ograniczyć
zbiór rozwiązań dla AG, a to już nie jest ani proste, ani przyjemne.

>
>
> > > 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.
To jednak się zgadzamy co do tego, niepotrzebnie się rozpisywalem powyżej :)


> Naprawdę, jedyne, co brak automatycznego zwalniania pamięci umożliwia,
> to pisanie programów z wyciekami pamięci.
Już pisałem o tym. Weka jest napisana w Javie. Nie ma więc wycieków pamięci.
Moje programy pewnie jakieś wycieki czasami mają. Gdy jednak uczę prosty
preceptron w środowisku Weka, to z systemu znika 1.2GB - 1.5GB RAM. Danych
mam z 80tys wierszy i 15 kolumn. Gdy to samo robię w C++, to nie wiem
czy chociaż 3MB są potrzebne. Czas uczenia w C++ jest o rzędy wielkości
mniejszy. Czy Wekę pisali idioci? Oczywiście nie!!! Napisano ją "bardzo
dobrze w Javie".

Czasami patrzę jak używają programu do czegoś związanego z CNC. Program
ten jest napisany w Pythonie. Program ten używa algorytmów których nie
znam tak dobrze jak uczenie perceptronu, więc nie chcę się wypowiadać
kategorycznie, ale na oko, też zajmuje za dużo pamięci, za często się
zawiesza i za późno jest reakcja na działania użytkownika.

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

Podoba mi się, choć nie rozumiem. Piękny zwarty kod, bym chciał
tak na co dzień programować. Czy mierzyłeś wydajność w porównaniu do
C++? Czy tam jest już zawarte inne sortowanie gdy danych jest
zbyt mało na quick sorta?


> 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.
Aha, czyli moje pytania powyżej są już nieważne. Tu się zgadzam z
Tobą, mnie też się podoba ten zapis, widać jak na dłoni, pomimo że
nie rozumiem składni języka.


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


Pozdrawiam