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