W dniu niedziela, 27 sierpnia 2017 13:47:08 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 27 sierpnia 2017 12:22:38 UTC+2 użytkownik AK napisał:
> > Użytkownik "fir" <p...@g...com> napisał:
> >
> > > a mozliwe bylo to dlatego ze wiekszosc potrzebych rzeczy rozkminilem wczesniej
..
> > > pewnie teraz gdy rozkminilem jeszcze wiecej moglbym napisac od zera asembler w
2 dni)
> >
> > I co z tego ?
> > Chopie nigdy nie bedziesz dobrym programista :(.
> >
> > Programowanie to sztuka/rzemioslo - tworzone "ku potomnosci" - znaczy: "dla
innych".
> > Ty widzisz tylko czubek wlasnego nosa i nikogo/niczego poza tym, co skutkuje
tworzeniem
> > nikomu niepotrzebnych (bo juz dawno zrobionych - rozkimanych) rzeczy - czyli
"wymyslaniem
> > kola na nowo".
> > Slowem: nie ty jestes tu podmiotem, ale "dzielo" (jego jakosc, a glownie
_przydatnosc_).
> > Dorosnij, jesli chcech byc programista, a nie jeno kolejnym pryszczatym
POspolitym
> > koderem-sobkiem :(
> >
>
> dziekujemy za wypowiedz...
>
> sam mam inna opinie ale nie bronie koledze miec swojej

swoja droga kolega jak zwykle skipnal istote mojej wypowiedzi
(tj rozkminiania vs wdrazanie - co jest ciekawym tematem duzo bardziej wartym
zastanowieni niz pisanie glupot)

do góry

W dniu niedziela, 27 sierpnia 2017 13:53:30 UTC+2 użytkownik M.M. napisał:
> to nie wiem czy
> warto, bo w sieci jest sporo materiałów.

warto bo na grupie w dyskusji material sie latwiej przyswaja -

do góry

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

do góry

On Sunday, August 27, 2017 at 2:08:56 AM UTC-4, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
> >> Ceownik/Krzyzowiec chcacy pisac w innych jezykach ? Raczej zupelny unikat.
> > To chyba ja już wiem, dlaczego mamy diametralnie inne perspektywy.
> > Obserwowałem tylko takich, którym bardzo zależało, wręcz wychodzili
> > sami z inicjatywą.
>
> ..i tak trzymaj ! (powaznie). Na innych szkoda zwyczajnie czasu.
>
> >> O wiele czesciej "muszacy" (vide slawetny Ober-Ayatollah C++
> > > Sektor van Skijlen)
> >
> > Jeśli musi a nie chce, to mamy mucha po urwaniu ostatniej nogi traci słuch :)
>
> Pracodawca/zycie/rzeczywistosc mu urwal wszystkie nogi (zmusil do C#:)
> Z satysfakcja obserwowalem jak zaczal.. chawilc C# :)
> (choc oczywiscie te jego chwalenia juz zawsze trzeba brac z rezerwa -
> zapewne znow chwali tylko to co.. ON sam zna/uzywa :)
>
> >> Mowilem tu lata temu wiec powtorze jakze IMHO ma wciaz prawdziwa maksyme:
> >>
> >> "Czym sie rozni programista C++? Tym, ze zanim jeszcze zakoduje,
> >> juz optymalizuje!"
> >
> > Ok, masz rację, że ta pokusa do optymalizacji się pojawia mimowolnie.
>
> Alez chce (i czynie to!), ale dopiero wtedy _gdy to rzeczywiscie jest potrzebne_,
> ale nie za wczasu.
> PS: Pamietam dobrze taki fakt z moje pierwszej "przemyslowej" pracy (WSK Rzeszow
87r).
> Kolega z zespolu - doskonaly inzynier i numeryk napisal w czystym ASM na PC obsluge
> floating point bo w/g niego orginalne emulatory z kompilatorow/osobne typu emu287
> byly za wolne - i fakt ze byly ale... Sprawa byla powazna bo dotyczyla metod FEM
ktorych
> obliczenia trwaly (uklady rownan rozniczkowych czastkowych) dniami i nocami.
> Kod byl doskonaly, scisle zoptymalizowany (timingi rozkazow uwzglednione itp).
> Wydawalo sie wypas (bo byl to z programistycznego punktu widzenia wypas!) choc ja
mialem
> wlasne zdanie w sensie celowosci tego, choc wiedza merytoryczna nie dorastalem
Koledze
> do piet (no ale mialm juz za soba kilka ladnych lat z duzych maszyc wiec..)
> Skutek finalny: _w praktyce_ zysk byl kilka procent , a za kilka miesiecy pojawili
sie AT-ki
> z koprocesorami i cala jego robota (kilka miesiecy) poszla sie zwyczajnie (...)
pasc :(

Przyklad kolegi w typ przypadku jest nie na miejscu - w czasie zaczynania
aptymalizacji kodu ale emulatora nie bylo wiadomo czy 80286 bedzie dostepny (a
dodatkowo z dalaczonym 80287 - w tamtych czasach duzo PC AT nie mialo dokladanego
20287 bo kosztowal extra - dodakowo byly ograniczenia COCOM na sprzedaz do
demoludow). W tym przypadku optymalizazja byla uzasadniona - jak to mowi przyslowie
(niestety po angielsku) - hindsight is always 20/20.
Na problem nad-optymalizacji C++ cierpia glownie programisci starszego pokolenia
ktorzy wiekszosc czasu spedzili walczac z kompilatorami w latach 90tych - gdzie
doswiadczony programista mogl zoptymalizowac kod lepiej niz kompilator.
W dzisiejszych czasach w wiekszosci przypadkow nowoczesny kompilator jest zawsze
lepszy od programisty w optymalizacji kodu na docelowy procesor (Co nie znaczy ze jak
programista spieprzyl kod to kompilator to poprawi).
>
> > Może coś nie tak z moją spostrzegawczością, ale naprawdę nie widzę w tym
> > nic cennego dla mnie.
>
> Ale zobaczysz :) Sam jestem ciekaw.
> Podstaw Pythona nauczysz sie w godzine.
>
Tak - wszyscy tak bardzo kochaja Pythona - zycze wielu skucesow w napisaniu
wielowatkowego programu w Pythonie (a dokladnie w CPythonie - najpopularniejszej
wersji) bez odwolywania sie do magicznych sztuczek. Python jest bardzo fajnym
jezykiem do prototypowania i szybkiej roboty - ale bez przesady - napisanie duzego
systemu w Pythonie to czysty masochizm.
> AK

do góry

On Monday, August 28, 2017 at 4:29:04 PM UTC+2, Adam M wrote:
> On Sunday, August 27, 2017 at 2:08:56 AM UTC-4, AK wrote:
> > Użytkownik "M.M." <m...@g...com> napisał:
> >
> > >> Ceownik/Krzyzowiec chcacy pisac w innych jezykach ? Raczej zupelny unikat.
> > > To chyba ja już wiem, dlaczego mamy diametralnie inne perspektywy.
> > > Obserwowałem tylko takich, którym bardzo zależało, wręcz wychodzili
> > > sami z inicjatywą.
> >
> > ..i tak trzymaj ! (powaznie). Na innych szkoda zwyczajnie czasu.
> >
> > >> O wiele czesciej "muszacy" (vide slawetny Ober-Ayatollah C++
> > > > Sektor van Skijlen)
> > >
> > > Jeśli musi a nie chce, to mamy mucha po urwaniu ostatniej nogi traci słuch :)
> >
> > Pracodawca/zycie/rzeczywistosc mu urwal wszystkie nogi (zmusil do C#:)
> > Z satysfakcja obserwowalem jak zaczal.. chawilc C# :)
> > (choc oczywiscie te jego chwalenia juz zawsze trzeba brac z rezerwa -
> > zapewne znow chwali tylko to co.. ON sam zna/uzywa :)
> >
> > >> Mowilem tu lata temu wiec powtorze jakze IMHO ma wciaz prawdziwa maksyme:
> > >>
> > >> "Czym sie rozni programista C++? Tym, ze zanim jeszcze zakoduje,
> > >> juz optymalizuje!"
> > >
> > > Ok, masz rację, że ta pokusa do optymalizacji się pojawia mimowolnie.
> >
> > Alez chce (i czynie to!), ale dopiero wtedy _gdy to rzeczywiscie jest potrzebne_,
> > ale nie za wczasu.
> > PS: Pamietam dobrze taki fakt z moje pierwszej "przemyslowej" pracy (WSK Rzeszow
87r).
> > Kolega z zespolu - doskonaly inzynier i numeryk napisal w czystym ASM na PC
obsluge
> > floating point bo w/g niego orginalne emulatory z kompilatorow/osobne typu emu287
> > byly za wolne - i fakt ze byly ale... Sprawa byla powazna bo dotyczyla metod FEM
ktorych
> > obliczenia trwaly (uklady rownan rozniczkowych czastkowych) dniami i nocami.
> > Kod byl doskonaly, scisle zoptymalizowany (timingi rozkazow uwzglednione itp).
> > Wydawalo sie wypas (bo byl to z programistycznego punktu widzenia wypas!) choc ja
mialem
> > wlasne zdanie w sensie celowosci tego, choc wiedza merytoryczna nie dorastalem
Koledze
> > do piet (no ale mialm juz za soba kilka ladnych lat z duzych maszyc wiec..)
> > Skutek finalny: _w praktyce_ zysk byl kilka procent , a za kilka miesiecy
pojawili sie AT-ki
> > z koprocesorami i cala jego robota (kilka miesiecy) poszla sie zwyczajnie (...)
pasc :(
>
> Przyklad kolegi w typ przypadku jest nie na miejscu - w czasie zaczynania
aptymalizacji kodu ale emulatora nie bylo wiadomo czy 80286 bedzie dostepny (a
dodatkowo z dalaczonym 80287 - w tamtych czasach duzo PC AT nie mialo dokladanego
20287 bo kosztowal extra - dodakowo byly ograniczenia COCOM na sprzedaz do
demoludow). W tym przypadku optymalizazja byla uzasadniona - jak to mowi przyslowie
(niestety po angielsku) - hindsight is always 20/20.
> Na problem nad-optymalizacji C++ cierpia glownie programisci starszego pokolenia
ktorzy wiekszosc czasu spedzili walczac z kompilatorami w latach 90tych - gdzie
doswiadczony programista mogl zoptymalizowac kod lepiej niz kompilator.
> W dzisiejszych czasach w wiekszosci przypadkow nowoczesny kompilator jest zawsze
lepszy od programisty w optymalizacji kodu na docelowy procesor (Co nie znaczy ze jak
programista spieprzyl kod to kompilator to poprawi).

W latach 90tych było inaczej. Kompilatory nie dość że kompilatory generowały
kiepski kod, to jeszcze nie umiały malutkich funkcji wstawiać inline.
Wszelkie próby napisać kodu przyjaznego dla kompilatora kończyły się
totalną sieczką z punktu programisty czytającego ten kod. W dzisiejszych
czasach nie widać dużych zmian w czasie wykonania po drobnej zmianie,
zatem mam pytanie: co to znaczy (w tym kontekście) że programista
spieprzył kod?


> >
> > > Może coś nie tak z moją spostrzegawczością, ale naprawdę nie widzę w tym
> > > nic cennego dla mnie.
> >
> > Ale zobaczysz :) Sam jestem ciekaw.
> > Podstaw Pythona nauczysz sie w godzine.
> >
> Tak - wszyscy tak bardzo kochaja Pythona - zycze wielu skucesow w napisaniu
wielowatkowego programu w Pythonie (a dokladnie w CPythonie - najpopularniejszej
wersji) bez odwolywania sie do magicznych sztuczek. Python jest bardzo fajnym
jezykiem do prototypowania i szybkiej roboty - ale bez przesady - napisanie duzego
systemu w Pythonie to czysty masochizm.

Dlaczego to masochizm? Myślałem że pisze się przyjemnie.

Pozdrawiam

do góry

On Monday, August 28, 2017 at 11:29:25 AM UTC-4, M.M. wrote:
> On Monday, August 28, 2017 at 4:29:04 PM UTC+2, Adam M wrote:
> > On Sunday, August 27, 2017 at 2:08:56 AM UTC-4, AK wrote:
> > > Użytkownik "M.M." <m...@g...com> napisał:
> > >
> > > >> Ceownik/Krzyzowiec chcacy pisac w innych jezykach ? Raczej zupelny unikat.
> > > > To chyba ja już wiem, dlaczego mamy diametralnie inne perspektywy.
> > > > Obserwowałem tylko takich, którym bardzo zależało, wręcz wychodzili
> > > > sami z inicjatywą.
> > >
> > > ..i tak trzymaj ! (powaznie). Na innych szkoda zwyczajnie czasu.
> > >
> > > >> O wiele czesciej "muszacy" (vide slawetny Ober-Ayatollah C++
> > > > > Sektor van Skijlen)
> > > >
> > > > Jeśli musi a nie chce, to mamy mucha po urwaniu ostatniej nogi traci słuch :)
> > >
> > > Pracodawca/zycie/rzeczywistosc mu urwal wszystkie nogi (zmusil do C#:)
> > > Z satysfakcja obserwowalem jak zaczal.. chawilc C# :)
> > > (choc oczywiscie te jego chwalenia juz zawsze trzeba brac z rezerwa -
> > > zapewne znow chwali tylko to co.. ON sam zna/uzywa :)
> > >
> > > >> Mowilem tu lata temu wiec powtorze jakze IMHO ma wciaz prawdziwa maksyme:
> > > >>
> > > >> "Czym sie rozni programista C++? Tym, ze zanim jeszcze zakoduje,
> > > >> juz optymalizuje!"
> > > >
> > > > Ok, masz rację, że ta pokusa do optymalizacji się pojawia mimowolnie.
> > >
> > > Alez chce (i czynie to!), ale dopiero wtedy _gdy to rzeczywiscie jest
potrzebne_,
> > > ale nie za wczasu.
> > > PS: Pamietam dobrze taki fakt z moje pierwszej "przemyslowej" pracy (WSK
Rzeszow 87r).
> > > Kolega z zespolu - doskonaly inzynier i numeryk napisal w czystym ASM na PC
obsluge
> > > floating point bo w/g niego orginalne emulatory z kompilatorow/osobne typu
emu287
> > > byly za wolne - i fakt ze byly ale... Sprawa byla powazna bo dotyczyla metod
FEM ktorych
> > > obliczenia trwaly (uklady rownan rozniczkowych czastkowych) dniami i nocami.
> > > Kod byl doskonaly, scisle zoptymalizowany (timingi rozkazow uwzglednione itp).
> > > Wydawalo sie wypas (bo byl to z programistycznego punktu widzenia wypas!) choc
ja mialem
> > > wlasne zdanie w sensie celowosci tego, choc wiedza merytoryczna nie dorastalem
Koledze
> > > do piet (no ale mialm juz za soba kilka ladnych lat z duzych maszyc wiec..)
> > > Skutek finalny: _w praktyce_ zysk byl kilka procent , a za kilka miesiecy
pojawili sie AT-ki
> > > z koprocesorami i cala jego robota (kilka miesiecy) poszla sie zwyczajnie
(...) pasc :(
> >
> > Przyklad kolegi w typ przypadku jest nie na miejscu - w czasie zaczynania
aptymalizacji kodu ale emulatora nie bylo wiadomo czy 80286 bedzie dostepny (a
dodatkowo z dalaczonym 80287 - w tamtych czasach duzo PC AT nie mialo dokladanego
20287 bo kosztowal extra - dodakowo byly ograniczenia COCOM na sprzedaz do
demoludow). W tym przypadku optymalizazja byla uzasadniona - jak to mowi przyslowie
(niestety po angielsku) - hindsight is always 20/20.
> > Na problem nad-optymalizacji C++ cierpia glownie programisci starszego pokolenia
ktorzy wiekszosc czasu spedzili walczac z kompilatorami w latach 90tych - gdzie
doswiadczony programista mogl zoptymalizowac kod lepiej niz kompilator.
> > W dzisiejszych czasach w wiekszosci przypadkow nowoczesny kompilator jest zawsze
lepszy od programisty w optymalizacji kodu na docelowy procesor (Co nie znaczy ze jak
programista spieprzyl kod to kompilator to poprawi).
>
> W latach 90tych było inaczej. Kompilatory nie dość że kompilatory generowały
> kiepski kod, to jeszcze nie umiały malutkich funkcji wstawiać inline.
> Wszelkie próby napisać kodu przyjaznego dla kompilatora kończyły się
> totalną sieczką z punktu programisty czytającego ten kod. W dzisiejszych
> czasach nie widać dużych zmian w czasie wykonania po drobnej zmianie,
> zatem mam pytanie: co to znaczy (w tym kontekście) że programista
> spieprzył kod?
Tzn ze kod jest napisany nieefektywnie z powodu np. uzycia zlego algorytmu (albo zle
skalujacego sie algorytmu) - wtedy nawet najlepiej optymalizujacy kompilator nic nie
da.
>
>
> > >
> > > > Może coś nie tak z moją spostrzegawczością, ale naprawdę nie widzę w tym
> > > > nic cennego dla mnie.
> > >
> > > Ale zobaczysz :) Sam jestem ciekaw.
> > > Podstaw Pythona nauczysz sie w godzine.
> > >
> > Tak - wszyscy tak bardzo kochaja Pythona - zycze wielu skucesow w napisaniu
wielowatkowego programu w Pythonie (a dokladnie w CPythonie - najpopularniejszej
wersji) bez odwolywania sie do magicznych sztuczek. Python jest bardzo fajnym
jezykiem do prototypowania i szybkiej roboty - ale bez przesady - napisanie duzego
systemu w Pythonie to czysty masochizm.
>
> Dlaczego to masochizm? Myślałem że pisze się przyjemnie.
Male programy do kilkunastu-tysiecy lini napisane w wieksszosci przez jednego
programiste lub maly zespol (2-3 osoby) dobrze wspolpracujacych programistow - jak
najbardziej - bardzo przyjemnie sie pisze.

Duze systemy po kilkaset tysiecy lini kodu napisane w duzym zespole pisze sie
fatalnie

Programy silnie wielowatkowe - pisanie tego w Pythonie to pomylka (lub sztuka dla
sztuki bo w najgorszym przypadku zamiast przyrostu predkosci mozemy dostac strate).
>
> Pozdrawiam

do góry

On Sunday, August 27, 2017 at 10:21:01 PM UTC+2, g...@g...com wrote:
> W dniu sobota, 26 sierpnia 2017 09:18:54 UTC+2 użytkownik M.M. napisał:
> 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:
> [...]
> No właśnie, i moim zdaniem to programy komputerowe powinny
> z automatu testować wszystko -- formułować różne "hipotezy"
> i dokonywać pomiarów.

Czyli programować w języku myślenia oznacza coś w rodzaju, żeby
programować komputery, może z wykształceniem matematycznym, ale na
pewno bez informatycznego. Hmmm idea fajna, a jak z tym jest w
praktyce? Podajesz linki do swoich sukcesów, może w praktyce to
jest bardziej możliwe niż mi się wydaje?


> 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++.
Czy możesz powiedzieć uczciwie, co zyskałeś na tym, a co straciłeś?


> 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.
O ile tylko nadaje się do jakiegoś zadania, to nie mam nic
przeciwko R. Ale właśnie aplikacji okienkowej nie chciałbym w
nim robić.


> 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.
Może bym musiał spróbować kiedyś.


> 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.
Miałem na myśli system, który z dużym prawdopodobieństwem
odgadnie cel jaki programista chce zrealizować. Przy odgadywaniu
jedynie może opierać się na analizie meta-kodu i jakiś dodatkowych
skąpych wskazówek, np. może zadać pytania tylko do sytuacji
dwuznacznych. Następnie wygeneruje sub-optymalny kod w C, z
wariantami dostosowanymi do różnych rozmiarów/rozkładów
danych wejściowych. Gdy piszę "cel", to nie mam na myśli
celu typu "pomoc w zarządzaniu firmą", ale raczej bardzo
rozległy zbiór algorytmów które dadzą te same dane
wyjściowe z dopuszczalnych wejściowych. AI ustalałaby jaki
to zbiór i z tego zbioru wybierałaby bardzo dobry, albo
wręcz najlepszy w jakimś sensie. Np. dajemy wagę 10 na
wydajność i 30 na zajętość pamięci i na drugi dzień mamy
implementacje maksymalnie zbliżoną do takich parametrów.


> Sztuczne sieci neuronowe stosuje się chyba bardziej
> w zagadnieniach klasyfikacji i estymacji, niż przy
> transformacji programów?
Teoretycznie można zastosować, sieci mogą reprezentować
klasy algorytmów i rozpoznawać do jakiej klasy należy
dany meta-kod. Jednak w praktyce zastosowanie sztucznych sieci do
transformacji programów byłoby niewyobrażalnie
trudne... Chociaż ostatnio straciłem pewność co kiepskich
możliwości sieci neuronowych w praktyce.

Kiedyś dawno temu drwiłem z sztucznych sieci neuronowych na
wiele sposobów. Mówiłem np. że jeśli są takie dobre i
uniwersalne, to dlaczego jedna sieć neuronowa nie uczy
drugiej, leczy zaprzęga się do tego celu "zewnętrzny"
algorytm. Człowiek (potencjalnie) może zrozumieć w
szczegółach działanie swojego mózgu i go ulepszyć.
Kilka dni temu wylegiwałem się na kanapie i mnie
olśniło, a właściwie to mnie zmroziło ze strachu, naprawdę
zaczęło mi bić serce ze strachu. Znalazłem zastosowanie
sieci neuronowej do ulepszenia działania samej siebie.
To ulepszenie oczywiście stanowi drobiazg (choć odczuwalny),
nie ma nic wspólnego z systemem który ma samoświadomość,
rozumie swój kod i go przepisuje na lepszy. Jednak zawsze
zaczyna się od drobiazgów.

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


> 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.
Myślę, że zabrnęliśmy w szczegół, taka czy siaka literka to
po prostu rzecz do omówienia w zespole.


> A one miały jakieś tytuły?
Tak, nie wszystkie mam do dziś w biblioteczce, niektóre wydałem,
zgubiłem, miałem pożyczone. Miałem ze 20 sztuk tego, począwszy
od C++ do idiotów, skończywszy na Lippmanie i Stroustrupie.
Dlaczego dopytujesz o konkretne tytuły? Teraz mam, licząc z
daleka i patrząc słabym wzrokiem, 13 tytułów na półce.


> Jedyny sposób, żeby się przekonać, to sprawdzić.
Trochę sprawdzałem w Javie.

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

Ok, ale jeśli podwaliny teoretyczne są takie dobre to dlaczego
programy napisane w Pythonie działają nadal wolno? Nikomu nie
chce się napisać porządnego kompilatora do Pythona?



> Czy są jakieś fundamentalne powody, dla których miałoby nie być
> możliwe?
Nie wiem. To ja pytam. Dlaczego programy napisane w Pythonie są
wolne?


> 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)
Mogę jakiś minimalny przykład poprosić, co jest w Javie
pracochłonne, a w Scali, Rybym, Pythonie, itd, łatwe?



> 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.
Może się nie zrozumieliśmy dlatego, że ja miałem na myśli skompilowany
program, a Ty myślisz o skompilowaniu przed testowaniem. Tak, na
poziomie kodu źródłowego (koncepcyjnie, niekoniecznie w realizacji)
takie zadanie jest trywialne.


> Ale nie zgadzamy się w kwestii rozumienia pojęcia "sztuczna inteligencja".
> Pewnie Ty rozumiesz to pojęcie dosłownie, a ja -- historycznie, [...]
Rozumiem dosłownie, ale niekoniecznie w dowolnym obszarze zastosowania.
Chodziło mi o AI zdolne do generowania sub-optymalnego kodu na podstawie
meta-kodu, albo na podstawie języka bardzo wysokiego poziomu.


> Dla mnie brzmi to jak oksymoron :)
To tylko przykład z mojej częstej praktyki.


> 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'"
Mnie się podoba.


> 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.
Czyli zrobiłeś taki początek sztucznej inteligencji jaką miałem
na myśli. Mi to imponuje, ale mam też pytanie: jak z przekształcaniem
innych algorytmów?


> 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 bardzo zwięzłe. 30 linijek, 60, nawet 300 to bardzo mało. Może
będę musiał poczytać o Scheme :)


> [...]
> 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)
Brzmi to bardzo ciekawie.



> 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ę)
Chyba naprawdę poczytam o Scheme :)

Pozdrawiam

do góry

W dniu poniedziałek, 28 sierpnia 2017 18:39:17 UTC+2 użytkownik M.M. napisał:

> > No właśnie, i moim zdaniem to programy komputerowe powinny
> > z automatu testować wszystko -- formułować różne "hipotezy"
> > i dokonywać pomiarów.
>
> Czyli programować w języku myślenia oznacza coś w rodzaju, żeby
> programować komputery, może z wykształceniem matematycznym, ale na
> pewno bez informatycznego. Hmmm idea fajna, a jak z tym jest w
> praktyce? Podajesz linki do swoich sukcesów, może w praktyce to
> jest bardziej możliwe niż mi się wydaje?

Nie wiem, czy to, co zrobiłem, można nazwać "sukcesami".
Raczej określiłbym to mianem szkiców, ale owszem takie podejście
jest możliwe. Pewnie tak naprawdę największym problemem nie
jest nawet brak narzędzi, tylko sztywność ludzkiego myślenia
(którą moim zdaniem takie języki jak C++ tylko cementują)

> > 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++.
> Czy możesz powiedzieć uczciwie, co zyskałeś na tym, a co straciłeś?

Nie wydaje mi się, żebyśmy -- ucząc się nowych rzeczy -- coś tracili.
Jeżeli idzie o to, co zyskałem, to przede wszystkim właśnie zdolność
do patrzenia na programowanie jako na "esencję myśli", choć
pewnie nie brzmi to zbyt zrozumiale w oderwaniu od konkretnych
przykładów.

> > 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.
> Może bym musiał spróbować kiedyś.

Zdecydowanie polecam!

> > 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.
> Miałem na myśli system, który z dużym prawdopodobieństwem
> odgadnie cel jaki programista chce zrealizować.

Ale dlaczego system miałby cokolwiek odgadywać? Dlaczego
programista nie miałby wprost wyrażać tego, co chce osiągnąć?

Tym zresztą wydaje mi się programowanie w swojej istocie:
praktyką mającą rozjaśnić zdolność formułowania myśli.

> Przy odgadywaniu
> jedynie może opierać się na analizie meta-kodu i jakiś dodatkowych
> skąpych wskazówek, np. może zadać pytania tylko do sytuacji
> dwuznacznych. Następnie wygeneruje sub-optymalny kod w C, z
> wariantami dostosowanymi do różnych rozmiarów/rozkładów
> danych wejściowych.

Ciekawostka -- William Byrd pracuje nad edytorem "Barliman",
który jest zdolny do czegoś w tym rodzaju. W zeszłym roku
miał na ten temat interesującą prezentację (tyle że pokazywał
na raczej prostych przykładach):

https://www.youtube.com/watch?v=er_lLvkklsk

> > A one miały jakieś tytuły?
> Tak, nie wszystkie mam do dziś w biblioteczce, niektóre wydałem,
> zgubiłem, miałem pożyczone. Miałem ze 20 sztuk tego, począwszy
> od C++ do idiotów, skończywszy na Lippmanie i Stroustrupie.
> Dlaczego dopytujesz o konkretne tytuły? Teraz mam, licząc z
> daleka i patrząc słabym wzrokiem, 13 tytułów na półce.

Pytam z ciekawości. Czasem zdarza mi się oglądać prezentacje
Suttera i Meyersa (który -- jak wspominałem -- odwrócił się
ostatnio od C++ w stronę D)

> > Jedyny sposób, żeby się przekonać, to sprawdzić.
> Trochę sprawdzałem w Javie.

Wydaje mi się, że warto spróbować np. Haskella, bo on jednak
produkuje natywny kod, a leniwa ewaluacja potrafi niekiedy
drastycznie ograniczyć zużycie ramu (a innym razem wręcz przeciwnie,
ale to inna historia)

> > 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.
>
> Ok, ale jeśli podwaliny teoretyczne są takie dobre to dlaczego
> programy napisane w Pythonie działają nadal wolno? Nikomu nie
> chce się napisać porządnego kompilatora do Pythona?

Nie wiem. Mi się nie chce, na przykład.
Swego czasu Peter Norvig zrobił porównanie Pythona do Common Lispa,
o tutaj; http://norvig.com/python-lisp.html

> > Czy są jakieś fundamentalne powody, dla których miałoby nie być
> > możliwe?
> Nie wiem. To ja pytam. Dlaczego programy napisane w Pythonie są
> wolne?

Podejrzewam, że to raczej kwestie społeczne, niż technologiczne.
Ale nie wiem, bo nie siedziałem w Pythonie na tyle głęboko, żeby
sięgać po narzędzia w rodzaju PyPy -- dla moich potrzeb CPython
z reguły wystarczył, a większej aplikacji w tym języku raczej
nie chciałbym pisać, choćby ze względu na brak statycznej kontroli
typów.

> > 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)
> Mogę jakiś minimalny przykład poprosić, co jest w Javie
> pracochłonne, a w Scali, Rybym, Pythonie, itd, łatwe?

Na przykład chcesz wygenerować listę trójek pitagorejskich o współczynnikach
mniejszych od 100, i przekazać ją do jakiejś funkcji f.
W takim np. Haskellu byś napisał

f [(x,y,z) | x <- [1..100], y <- [x..100], z <- [y..100], x^2+y^2==z^2]

w Pythonie byłoby podobnie, choć nieco bardziej rozwlekle (i bez kontroli typów)

f([(x,y,z) for x in range(1,100) for y in range(x,100) for z in range(y,100)
if x**2 + y**2 == z**2])

A jak by takie coś wyglądało w Javie albo C++?
Ja sobie wyobrażam mniej więcej coś takiego:

#include <bardzo dużo nagłówków>

List<Tuple<int, int, int> > triples;
for(int x = 1; x < 100; ++x)
{
for(int y = x; y < 100; ++y)
{
for(int z = y; z < 100; ++z)
{
if(pow(x, 2) + pow(y, 2) == pow(z, 2))
{
triples.add(new Tuple<int, int, int>(x, y, z));
}
}
}
}
f(triples);

Oczywiście, nawiasów klamrowych można by było nie używać,
ale wtedy przyszedłby manager i powiedział (słusznie) że takie
są standardy kodowania w firmie.

Co do Javy to nie wiem, bo nie używałem, ale wyobrażam sobie,
że podobnie (zresztą to Ty mi powiedz, bo może się mylę)

> > 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.
> Może się nie zrozumieliśmy dlatego, że ja miałem na myśli skompilowany
> program, a Ty myślisz o skompilowaniu przed testowaniem. Tak, na
> poziomie kodu źródłowego (koncepcyjnie, niekoniecznie w realizacji)
> takie zadanie jest trywialne.

No, robienie tego rodzaju rzeczy na skompilowanym kodzie to chyba
robienie sobie mocno pod górkę?

> > Ale nie zgadzamy się w kwestii rozumienia pojęcia "sztuczna inteligencja".
> > Pewnie Ty rozumiesz to pojęcie dosłownie, a ja -- historycznie, [...]
> Rozumiem dosłownie, ale niekoniecznie w dowolnym obszarze zastosowania.
> Chodziło mi o AI zdolne do generowania sub-optymalnego kodu na podstawie
> meta-kodu, albo na podstawie języka bardzo wysokiego poziomu.

Ale do generowania kodu i do opisywania języków mamy bardzo dobre narzędzia.
Wystarczy spojrzeć sobie np. na taki Inform 7.

> > 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.
> Czyli zrobiłeś taki początek sztucznej inteligencji jaką miałem
> na myśli. Mi to imponuje, ale mam też pytanie: jak z przekształcaniem
> innych algorytmów?

Raczej bym powiedział, że udało mi się przerzucić sznurek przez Wielki Kanion
(a może nawet przez Nie Taki Wielki Kanion), niż wybudować most.
Ale też raczej nie nazywałbym tego "sztuczna inteligencją", tylko próbą
wypracowania metodologii tworzenia wydajnych programów które są też
łatwe do zrozumienia dla ludzi, a jednocześnie skalowalne i przenośne
(w przeciwieństwie do C++, który pozwala tworzyć wydajne programy,
które są potem trudne do zrozumienia i albo nieskalowalne, albo
nieprzenośne)

> > 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 bardzo zwięzłe. 30 linijek, 60, nawet 300 to bardzo mało. Może
> będę musiał poczytać o Scheme :)

Ciekawostka, o której dowiedziałem się niedawno, to że Alexander Stepanov
swoją koncepcję iteratorów, przeniesioną potem do STLa, najpierw
rozwijał właśnie w Scheme:
http://stepanovpapers.com/schemenotes/notes.pdf

> > 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)
> Brzmi to bardzo ciekawie.

Jeżeli idzie o "autoaplikatywność", to najciekawszy wynik, jaki znam,
nosi nazwę "Projekcji Futamury". Zgrabnie opowiedział o tym Tom Stuart:

https://www.youtube.com/watch?v=n_k6O50Nd-4

do góry

W dniu sobota, 26 sierpnia 2017 12:00:17 UTC+2 użytkownik AK napisał:

> > 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.
>
> A co niby jet zlego w mutacji?

Pokazywałem już przykład. Mutowalność umożliwia dokonywani rzeczy
w rodzaju "spooky action at a distance". Największym problemem jest
nielokalność, a to z tego względu, że komputery, które konstruujemy,
nie radzą sobie z nią najlepiej. Przy konstruowaniu systemów współbieżnych
dopuszczenie mutowalności wprowadza drastyczne komplikacje,
ponieważ trzeba wprowadzać dodatkowe mechanizmy zapewniające spójność
danych, które nie dość, że generują dodatkowe narzuty czasowe,
to są trudne w używaniu i mogą w łatwy sposób zepsuć cały system.

> W zyciu nie wystepuje ? Hę ?:)

Występuje, podobnie jak np. nowotwory.
Jednak zaletą języków programowania jest to, że one nie muszą
modelować życia, a mogą być konstruowane tak, żeby wygodnie się
nam w nich myślało, i żeby unikać różnego rodzaju błędów, które
zdarza się nam niekiedy popełniać.

do góry

On Tuesday, August 29, 2017 at 3:26:48 PM UTC+2, g...@g...com wrote:
> W dniu poniedziałek, 28 sierpnia 2017 18:39:17 UTC+2 użytkownik M.M. napisał:
>
> > > No właśnie, i moim zdaniem to programy komputerowe powinny
> > > z automatu testować wszystko -- formułować różne "hipotezy"
> > > i dokonywać pomiarów.
> >
> > Czyli programować w języku myślenia oznacza coś w rodzaju, żeby
> > programować komputery, może z wykształceniem matematycznym, ale na
> > pewno bez informatycznego. Hmmm idea fajna, a jak z tym jest w
> > praktyce? Podajesz linki do swoich sukcesów, może w praktyce to
> > jest bardziej możliwe niż mi się wydaje?
>
> Nie wiem, czy to, co zrobiłem, można nazwać "sukcesami".

Podałeś programy które były zwarte, przejrzyste i umiały
rozwiązać jakieś problemy. Jest to argument za tym, że
można w jakimś stopniu osiągnąć, do czego miałem wątpliwości.
Oczywiście jest to sukces w jakimś stopniu, następnym
stopniem byłby język jeszcze bardziej wysokopoziomowy.

> Raczej określiłbym to mianem szkiców, ale owszem takie podejście
> jest możliwe. Pewnie tak naprawdę największym problemem nie
> jest nawet brak narzędzi, tylko sztywność ludzkiego myślenia
> (którą moim zdaniem takie języki jak C++ tylko cementują).
Próbuję rozluźnić swoje myślenie, ale to chyba nie o to chodzi :)
Raczej chodzi o odwalenie bardzo ciężkiej roboty. Robota ta
sprowadzałaby się do zaprojektowania nowego, bardzo wysokopoziomowego
języka programowania i narzędzi, przynajmniej efektywnego kompilatora.


> > > 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++.
> > Czy możesz powiedzieć uczciwie, co zyskałeś na tym, a co straciłeś?
>
> Nie wydaje mi się, żebyśmy -- ucząc się nowych rzeczy -- coś tracili.
I oczywiście nie pytałem o to co straciłeś przez naukę, chociaż też
się traci, zawsze jest chociażby koszt alternatywny. Dzięki temu
że pozbyłeś się nawyków z C++, a nabraleś nowych, możesz zapewne jedne
zadania rozwiązywać (w jakimś sensie) lepiej, a inne gorzej. Pytałem o
jakiś przegląd takich zadań.


> Jeżeli idzie o to, co zyskałem, to przede wszystkim właśnie zdolność
> do patrzenia na programowanie jako na "esencję myśli", choć
> pewnie nie brzmi to zbyt zrozumiale w oderwaniu od konkretnych
> przykładów.
Już wyjaśniliśmy co to znaczy, chodzi po prostu o opis algorytmów w
bardziej naturalnym a mniej formalnym języku, chodzi o język
programowania bardzo wysokiego poziomu.

> > > 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.
> > Miałem na myśli system, który z dużym prawdopodobieństwem
> > odgadnie cel jaki programista chce zrealizować.
>
> Ale dlaczego system miałby cokolwiek odgadywać? Dlaczego
> programista nie miałby wprost wyrażać tego, co chce osiągnąć?

Nie chodziło mi o takie odgadywanie, jak pokerzysta odgaduje
karty przeciwnika. Raczej chodziło mi o to co opisałem jak
rozumiem sztuczną inteligencję na potrzeby naszej rozmowy.
Chodziło o to, aby kompilator ustalił jaki algorytm realizuje
wpisany kod przez programistę, następnie aby kompilator odszukał
zbioru równoważnych algorytmów i zaproponował kilka najlepszych
algorytmów z tego zbioru. Programista mógłby wprost podawać
zakresy danych, wartości, rozmiary danych w trakcie profilowania.

Słowa "odgadywać" użyłem tylko dlatego, że nie znam algorytmu
który dany kod klasyfikuje do zbioru algorytmów.

> Tym zresztą wydaje mi się programowanie w swojej istocie:
> praktyką mającą rozjaśnić zdolność formułowania myśli.
Dla inżyniera "zaprogramować" znaczy "zrozumieć". Języki
programowania są bardzo jednoznaczne. Jeśli potrafimy
napisać program który rozwiązuje jakiś problem, to jednoznacznie
możemy stwierdzić, że rozumiem ten problem. Więc jest
dużo prawdy w tym co mówisz, bez względu na użyty
język programowania.

Co jednak, gdy do danego problemu używamy sieci neuronowej
mającej 60mln wag? Tego żaden geniusz nie zrozumie :)



> > Przy odgadywaniu
> > jedynie może opierać się na analizie meta-kodu i jakiś dodatkowych
> > skąpych wskazówek, np. może zadać pytania tylko do sytuacji
> > dwuznacznych. Następnie wygeneruje sub-optymalny kod w C, z
> > wariantami dostosowanymi do różnych rozmiarów/rozkładów
> > danych wejściowych.
>
> Ciekawostka -- William Byrd pracuje nad edytorem "Barliman",
> który jest zdolny do czegoś w tym rodzaju. W zeszłym roku
> miał na ten temat interesującą prezentację (tyle że pokazywał
> na raczej prostych przykładach):
>
> https://www.youtube.com/watch?v=er_lLvkklsk
Będę musiał spojrzeć.



> > > A one miały jakieś tytuły?
> > Tak, nie wszystkie mam do dziś w biblioteczce, niektóre wydałem,
> > zgubiłem, miałem pożyczone. Miałem ze 20 sztuk tego, począwszy
> > od C++ do idiotów, skończywszy na Lippmanie i Stroustrupie.
> > Dlaczego dopytujesz o konkretne tytuły? Teraz mam, licząc z
> > daleka i patrząc słabym wzrokiem, 13 tytułów na półce.
>
> Pytam z ciekawości. Czasem zdarza mi się oglądać prezentacje
> Suttera i Meyersa (który -- jak wspominałem -- odwrócił się
> ostatnio od C++ w stronę D)
Z ciekawszych to Lippman "model obiektu w C++" i Stroustrap "projektowanie i
rozwój języka C++". Bieleckiego tytułu nie pamiętam, a już nie mam jej
na swojej półce.


> > > Jedyny sposób, żeby się przekonać, to sprawdzić.
> > Trochę sprawdzałem w Javie.
>
> Wydaje mi się, że warto spróbować np. Haskella, bo on jednak
> produkuje natywny kod, a leniwa ewaluacja potrafi niekiedy
> drastycznie ograniczyć zużycie ramu (a innym razem wręcz przeciwnie,
> ale to inna historia)
Ok.


> > > 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.
> >
> > Ok, ale jeśli podwaliny teoretyczne są takie dobre to dlaczego
> > programy napisane w Pythonie działają nadal wolno? Nikomu nie
> > chce się napisać porządnego kompilatora do Pythona?
>
> Nie wiem. Mi się nie chce, na przykład.
> Swego czasu Peter Norvig zrobił porównanie Pythona do Common Lispa,
> o tutaj; http://norvig.com/python-lisp.html
W tej chwili nie załadowała mi się strona.

>
> > > Czy są jakieś fundamentalne powody, dla których miałoby nie być
> > > możliwe?
> > Nie wiem. To ja pytam. Dlaczego programy napisane w Pythonie są
> > wolne?
>
> Podejrzewam, że to raczej kwestie społeczne, niż technologiczne.
> Ale nie wiem, bo nie siedziałem w Pythonie na tyle głęboko, żeby
> sięgać po narzędzia w rodzaju PyPy -- dla moich potrzeb CPython
> z reguły wystarczył, a większej aplikacji w tym języku raczej
> nie chciałbym pisać, choćby ze względu na brak statycznej kontroli
> typów.
Hmmm czyli jaki język jest najlepszy do pisana dużych aplikacji,
rzędu 30 koderów (plus reszta zespolu) i dwa lata czasu?


> > > 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)
> > Mogę jakiś minimalny przykład poprosić, co jest w Javie
> > pracochłonne, a w Scali, Rybym, Pythonie, itd, łatwe?
>
> Na przykład chcesz wygenerować listę trójek pitagorejskich o współczynnikach
mniejszych od 100, i przekazać ją do jakiejś funkcji f.
> W takim np. Haskellu byś napisał
>
> f [(x,y,z) | x <- [1..100], y <- [x..100], z <- [y..100], x^2+y^2==z^2]
>
> w Pythonie byłoby podobnie, choć nieco bardziej rozwlekle (i bez kontroli typów)
>
> f([(x,y,z) for x in range(1,100) for y in range(x,100) for z in range(y,100)
> if x**2 + y**2 == z**2])
>
> A jak by takie coś wyglądało w Javie albo C++?
> Ja sobie wyobrażam mniej więcej coś takiego:
>
> #include <bardzo dużo nagłówków>
>
> List<Tuple<int, int, int> > triples;
> for(int x = 1; x < 100; ++x)
> {
> for(int y = x; y < 100; ++y)
> {
> for(int z = y; z < 100; ++z)
> {
> if(pow(x, 2) + pow(y, 2) == pow(z, 2))
> {
> triples.add(new Tuple<int, int, int>(x, y, z));
> }
> }
> }
> }
> f(triples);

C++ przegrywa na starcie, bo ilość kodu jest większa o konieczność
zdefiniowania funkcji, zmiennych, nazw typu. Zobacz ten kod:
gen( max_d , max , prev, depth, vals[], f_mkVector, f_test ) {
vector v;
if( depth == max_d ) {
if( f_test(vals) )
v = f_mkVector( vals , depth );
} else for( i=prev ; i<max ; i++ ) {
vals[depth] = i;
v += gen( max_d , max , i , depth+1 , vals , f_test );
}
return v;
}

Ma tylko 6 linijek kodu obliczeniowego, reszta to definicje i
deklaracje. Jest mocno sparametryzowany. Może pracować na
dowolnym zakresie zmiennych, na dowolnej głębokości. Można
podać dowolny uchwyt do funkcji testującej i budującej dane
wyjściowe. Hmmm w C++ jest dużo kodu pełniącego rolę informacyjną
dla kompilatora, kodu algorytmicznego nie ma aż tak dużo, a
parametryzowanie wskaźnikami do funkcji, lub obiektami wirtualnym
powoduje, że kod jest bardzo uniwersalny.


Przy tym zadaniu mój "język myślenia" wyglądał tak:
buduj( max_depth, depth, reszta_parametrów ) {
if( max_depth == depth ) {
if( testuj(...) )
return wynik;
}
for( i=0 ; i<max ; i++ )
wynik += buduj( max_depth, depth+1 , ... );
return wynik;
}
Hmmm podobny do kodu algorytmicznego w C++.



> Oczywiście, nawiasów klamrowych można by było nie używać,
> ale wtedy przyszedłby manager i powiedział (słusznie) że takie
> są standardy kodowania w firmie.
Można bylo jeszcze posłużyć się rekurencją. Kodu jest więcej
niż w Pythonie, ale procedura jest uniwersalna, dla różnych
funkcji testujących i budujących wynik.

> Co do Javy to nie wiem, bo nie używałem, ale wyobrażam sobie,
> że podobnie (zresztą to Ty mi powiedz, bo może się mylę)
Bardzo podobnie bym napisał w Javie.

Chyba że dopuszczasz poslużenie się bibliotekami, to jest
http://www.cplusplus.com/reference/algorithm/next_pe
rmutation/
Ale to już nie jest porównanie języków, tylko dostępnych bibliotek.




> > > 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.
> > Może się nie zrozumieliśmy dlatego, że ja miałem na myśli skompilowany
> > program, a Ty myślisz o skompilowaniu przed testowaniem. Tak, na
> > poziomie kodu źródłowego (koncepcyjnie, niekoniecznie w realizacji)
> > takie zadanie jest trywialne.
>
> No, robienie tego rodzaju rzeczy na skompilowanym kodzie to chyba
> robienie sobie mocno pod górkę?

Zależy jak to jest użyte. Sieczkę templatów przeplatanych ifdefami
można zawsze zrobić ;-)


> > > Ale nie zgadzamy się w kwestii rozumienia pojęcia "sztuczna inteligencja".
> > > Pewnie Ty rozumiesz to pojęcie dosłownie, a ja -- historycznie, [...]
> > Rozumiem dosłownie, ale niekoniecznie w dowolnym obszarze zastosowania.
> > Chodziło mi o AI zdolne do generowania sub-optymalnego kodu na podstawie
> > meta-kodu, albo na podstawie języka bardzo wysokiego poziomu.
>
> Ale do generowania kodu i do opisywania języków mamy bardzo dobre narzędzia.
> Wystarczy spojrzeć sobie np. na taki Inform 7.

Rozmawialiśmy o języku myślenia z kompilatorem generującym
sub-optymalny kod asemblerowym. Nie znam Informu, dałby radę? Jeśli tak, to
czemu python nie ma szybkiego kompilatora?



> > > 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.
> > Czyli zrobiłeś taki początek sztucznej inteligencji jaką miałem
> > na myśli. Mi to imponuje, ale mam też pytanie: jak z przekształcaniem
> > innych algorytmów?
>
> Raczej bym powiedział, że udało mi się przerzucić sznurek przez Wielki Kanion
> (a może nawet przez Nie Taki Wielki Kanion), niż wybudować most.
> Ale też raczej nie nazywałbym tego "sztuczna inteligencją", tylko próbą
> wypracowania metodologii tworzenia wydajnych programów które są też
> łatwe do zrozumienia dla ludzi,

CHyba wiem dlaczego trudno się nam dogadać. Nie zdefiniowaliśmy, co to
oznacza łatwe do zrozumienia dla ludzi. Mnie się C++ na początku wyawał
bardzo robaczywy (czytaj: miał nadmiar operatorów), a potem stał się
przejrzysty. Pojęcie "trudny" już po krótkim treningu może zmienić się
na "łatwy".

Zastanawiam się co się pojawiło w moim umyśle, gdy wymyśliłem nowy
rodzaj sztucznych sieci neuronowych. Hmmmm to nawet nie był metakod.
Chyba pojawił się wykres z przebiegiem funkcji i zarys dowodu, że
to się wyuczy dowolnych danych uczących. A co się pojawialo gdy
wymyśliłem algorytmy do uczenia tych sieci? Zazwyczaj pojawiała się
tylko jedna pętla. Dla mnie taki język programowania jest językiem
myślenia i jest łatwy. Jednak dla innych on będzie nie tylko
trudny, ale nigdy nie będzie zrozumiał, ponieważ mam za sobą
setki godzin przemyśleń i ta jedna pętla w trakcie kodowania skojarzy
mi się z drugą pętlą, a ta druga z setką ifów, o których myślałem
nawet lata temu. Może nie ma czegoś takiego jak łatwy język
programowania w języku myślenia, bo język myślenia jest tylko pozornie
łatwy? W języku myślenia nie musimy ŚWIADOMIE myśleć o każdym
szczególe, ponieważ te szczegóły podpowie nam podświadomość
gdy będą potrzebne. A to że nie myślimy o zawiłych szczegółach w
danej chwili ŚWIADOMIE, nie oznacza że w ogóle nie są one elementem
języka myślenia.

Myślę że ulegamy złudzeniu chcąc zrobić język programowania tak
bardzo przyjazny dla ludzi, aby miał on coś wspólnego z językiem
myślenia. Ulegamy złudzeniu dlatego, że nie jesteśmy świadomi
potężnego mechanizmu kojarzenia jaki zachodzi w naszym umyśle.
Taki język nigdy nie powstanie, chyba że komputer pozna nasze
myśli i skojarzenia.

> a jednocześnie skalowalne i przenośne
> (w przeciwieństwie do C++, który pozwala tworzyć wydajne programy,
> które są potem trudne do zrozumienia i albo nieskalowalne, albo
> nieprzenośne)
Kompilatory C++ są na wiele platform, biblioteki też. A zrównoleglanie w
ogóle bywa trudne, napisz np. optymalnie zrównoleglany algorytm
cięć alpha-beta w dowolnym języku. Zrównoleglanie prostych algorytmów to
jedna linijka dzięki OpenMP. A podobno robią wersję OpenMP na środowisko
rozproszone... Na starym forku też nie tak ciężko się zrównoleglało.



> > > 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 bardzo zwięzłe. 30 linijek, 60, nawet 300 to bardzo mało. Może
> > będę musiał poczytać o Scheme :)
>
> Ciekawostka, o której dowiedziałem się niedawno, to że Alexander Stepanov
> swoją koncepcję iteratorów, przeniesioną potem do STLa, najpierw
> rozwijał właśnie w Scheme:
> http://stepanovpapers.com/schemenotes/notes.pdf
Jestem zaciekawiony tym językiem.


>
> > > 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)
> > Brzmi to bardzo ciekawie.
>
> Jeżeli idzie o "autoaplikatywność", to najciekawszy wynik, jaki znam,
> nosi nazwę "Projekcji Futamury". Zgrabnie opowiedział o tym Tom Stuart:
>
> https://www.youtube.com/watch?v=n_k6O50Nd-4
Ok, dzięki za linka.


Pozdrawiam

do góry