W dniu sobota, 26 sierpnia 2017 09:18:54 UTC+2 użytkownik M.M. napisał:

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

Trochę pokazałem w Haskellowej implementacji funkcji qsort.
Jeżeli idzie o szachy, to akurat swego czasu napisałem klienta
do gry w szachy (czyli bez sztucznej inteligencji), i zacząłem
od tego, że opisałem szachy komputerowi w taki sposób, jakbym
tłumaczył je człowiekowi -- czyli np. tak:

https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/schess/rules/ches
s.ss?at=default&fileviewer=file-view-default

Później stworzyłem engine "rozumiejący" tego rodzaju język
-- oprócz szachów opisałem jeszcze kilka innych gier, mianowicie
wikingowską grę planszową "tafl", np. tutaj:

https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/schess/rules/ard-
ri.ss?at=default&fileviewer=file-view-default

oraz "samotnika" (grę jednoosobową), trochę zainspirowany książką
Jamesa Gleicka "Bit, Energia, Informacja" i historią o Adzie Lovelace
i Charlesie Babbage'u:

https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/schess/rules/soli
taire.ss?at=default&fileviewer=file-view-default

Jeżeli idzie o samą rozgrywkę, ją opisałem algorytmiczne, bo w taki
sposób rozumiem grę jako człowiek -- tzn. że najpierw jeden gracz
wybiera bierkę, którą chce zagrać (spośród tych, którymi może zagrać),
następnie wybiera pole, na którym chce ją umieścić, i jeżeli wygrał,
to gra się kończy, a jeśli nie to gra kolejny gracz:

https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/schess/game.scm?a
t=default&fileviewer=file-view-default#game.scm-105

[konkretnie to, co opisałem powyżej, zapisałem w definicji metody
"gameplay", linie 105-114]. Ciekawostka jest taka, że gameplay jest opisany
w osobnym wątku, niż interfejs graficzny. Tak było łatwo zakodować, bo
tak było mi łatwo myśleć.


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

Na przykład o to, że niektóre pojęcia mają spejalną składnię
-- na przykład referencje -- a inne nie mają -- na przykład
stałe referencje (cref). Albo interfejsy w STLu, z których
nigdy nie potrafiłem korzystać inaczej, niż drobiazgowo patrząc
w dokumentację.

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

To też. Ostatnio zacząłem wkładać pracę w to, żeby
programista nie musiał myśleć o takich rzeczach, bo moim
zdaniem tego rodzaju decyzje utrudniają uchwycenie w kodzie
"istosty rzeczy"

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

No właśnie, i moim zdaniem to programy komputerowe powinny
z automatu testować wszystko -- formułować różne "hipotezy"
i dokonywać pomiarów.

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

Dobrego użyłeś słowa -- "reklamowano". Dla mnie wygląda na to,
że sukces C++ i Javy to w głównej mierze sukces marketingowy.

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

Jeżeli idzie o mnie, to kiedy zacząłem się uczyć Scheme'u,
studiując "Strukturę i Interpretację Programów Komputerowych",
kilka lat zajęło mi oduczenie się wszystkich nawyków, które
przyniosłem z C i C++.

> 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 wiem. Moim zdaniem system "R" to koszmarne nieporozumienie.
Aż mi przykro, że do czegoś takiego doszło, ale chyba jest to
bardziej fenomen socjologiczny, niż programistyczny.

Co do aplikacji okienkowych, to jedyny system, który do tej pory
widziałem, w którym pisanie tego rodzaju aplikacji było zrobione
w miarę dobrze, to Pythonowy Enaml. Wszystko inne, z czym miałem
styczość (w tym C# + WPF albo C# + WinForms, JavaScript + DOM,
C++ + Qt i inne tego rodzaju systemy) to nieporozumienie.

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

OK. Dla mnie "meta-kod" to "kod o kodzie" (tak jak Tarski
mówił o języku i metajęzyku w swojej słynnej dysertacji)

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

Zależy, co rozumiesz przez "sztuczną inteligencję",
ale historycznie rzecz biorąc jakieś bardziej dojrzałe
systemy sztucznej inteligencji mamy co najmniej od
lat 80.

> Swoją drogą, chyba opracowałem
> fajny model sztucznych sieci neuronowych, ale to jeszcze
> nie ta era, żeby programy zamieniały metakod na asembler :)

Sztuczne sieci neuronowe stosuje się chyba bardziej
w zagadnieniach klasyfikacji i estymacji, niż przy
transformacji programów?

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

Napisałem na ten temat pracę magisterską. Chciałbym ją
upublicznić, ale najpierw wolałbym się obronić, żeby się
nie okazało, że system antyplagiatowy zaklasyfikował moją
pracę jako plagiat jakiegoś cwaniaka.

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

Wszędzie trzeba się umówić.
Tyle że języki wywodzące się z C narzucają dziwne ograniczenia
na nazewnictwo zmiennych (z Haskellem zresztą jest podobnie).
W Lispie nikt nie robi notacji_podkreślnikowej ani camelCaseów',
bo można łączyć ze sobą słowa myślnikami, tak jak w europejskiej
typografii.

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

Z tego co słyszałem, bardzo dobrze się skalują.

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

A one miały jakieś tytuły?

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

Jedyny sposób, żeby się przekonać, to sprawdzić.

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

Sztucznej inteligencji jest dość sporo. I nie mam na myśli
jakichś systemów deep-learningowych, które naśladują działanie
ludzkiego mózgu (i czasem robią naprawdę imponujące rzeczy),
ale raczej pomysły w rodzaju superkompilatora Valentina Turchina,
albo systemu Burstalla-Darlingtona do transformacji programów,
albo systemu Boyera-Moore'a do dowodzenia twierdzeń o własnościach
programów. To są rzeczy z lat 80. XX wieku.

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

Czy są jakieś fundamentalne powody, dla których miałoby nie być możliwe?

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

Nie jestem pewien. Herbert Simon i Allen Newell robili w IPL naprawdę
imponujące rzeczy, ale raczej nie dałoby się zakochać w tym języku.
Z Javą mam podobne odczucie -- z niektórych prostych rzeczy czyni
rzeczy wymagające sporego wysiłku (pewnie sporo zmieniło wprowadzenie
lambdy w Javie 8 pod tym względem, ale nie powiedziałbym, żeby lambdy
stanowiły kanoniczną część Javy)


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

Jeżeli korzystasz w swoim programie z gotowych kolekcji, które mają
kompatybilne interfejsy, ale różnią się charakterystyką wydajnościową,
to użycie algorytmów genetycznych do optymalizacji rodzajów kolekcji,
z których chcesz korzystać, jest trywialne.

> > > > 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 :)

Ale nie zgadzamy się w kwestii rozumienia pojęcia "sztuczna inteligencja".
Pewnie Ty rozumiesz to pojęcie dosłownie, a ja -- historycznie,
jako pewien ruch zapoczątkowany przez McCarthy'ego i Minsky'ego, który
nie dał nam myślących maszyn, ale dał bardzo wiele praktycznych
narzędzi w rodzaju tych, które zostały opisane w książce Petera Norviga
"Paradigms of Artificial Intelligence Programming" (którą gorąco polecam)

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

Dla mnie brzmi to jak oksymoron :)

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

To właściwie jest główny przykład wałkowany w mojej magisterce.

Oczwiście, zapis [x | x <- rest, x < pivot] czytamy jako
"te spośród elementów listy 'rest', które są mniejsze od
elementu '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.
> 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.

Pokazywałem ten przykład w swojej magisterce, opisując, w jaki sposób
można stworzyć system reguł, pozwalający przekształcać mniej więcej
tak zapisanego quicksorta w implementację porównywalną wydajnościowo
z C.

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

W swojej pracy mam:
- opis składni BNF języka Scheme, składający się z dwóch reguł i kilku
nieformalnych dopowiedzeń
- implementację maszyny wirtualnej, modelującej z grubsza działanie
i zestaw instrukcji typowych procesorów, zaimplementowaną w 200 linijkach
języka Scheme (śmiem twierdzić, że tak czytelnego, jak tylko się da)
- asembler przekształcający kod z etykietami do kodu z ustalonymi
adresami, w 30 linikach
- interpreter języka Scheme w nim samym, w ok. 60 linijkach
- kompilator używanego przeze mnie podzbioru Scheme'u do zestawu rozkazów
powyższej maszyny wirtualnej, zajmujący ok. 300 linijek

wszystko to jest działającym, przetestowanym kodem, który opracowywałem
podczas interaktywnej pracy z systemem.

gdybym chciał zrobić coś takiego dla C++, to pewnie samo uporanie się
z jego składnią zajęłoby 10 razy tyle, co te wszystkie rzeczy razem wzięte,
ale w międzyczasie pewnie zgubiłbym wątek. (oczywiście nie chodzi
o ilość linijek, tylko o "intelektualną ogarnialość", ale liczba
jest mimo wszystko jakąś tam metryką)

mam też system do dowodzenia twierdzeń, którego prostota bierze się stąd,
że podzbiór języka Scheme, który sobie wybrałem jako język źródłowy,
jest zasadniczo czysto funkcyjny, czyli nie ma w nim instrukcji przypisania
(w języku docelowym już jest, dzięki czemu możliwe są pewne optymalizacje).

co do C++ i Javy, to oczywiście mógłym go używać jako metajęzyka do
opisywania przekształceń, ale nie spodziewałbym się, żebym coś w ten
sposób zyskał, a poza tym nie mógłbym liczyć na to, że wynik mojej
pracy mógłby mieć szansę stosować się sam do siebie (pewnie też dużo
bym stracił na czytelności)

To jest zresztą chyba mój największy zarzut do C++: stwarza wrażenie,
jakby język był czymś danym z góry przez twórców języka, którzy mają
zawsze rację. Scheme dla odmiany jest językiem, którego implementacja
jest ćwiczeniem dla studentów, a przy okazji bardzo dobrze nadaje się
do pisania czytelnych programów. A przy tym istnieją też implementacje,
których wydajność jest porównywalna z C (konkretnie, firma Cisco wypuściła
ostatnio do Open-Source'a kompilator Chez Scheme, który ma taką reputację,
a przy tym pozwala na inkrementalną kompilację)