W dniu czwartek, 1 sierpnia 2019 14:26:26 UTC+2 użytkownik Maciej Sobczak napisał:
> > > A teraz konkretnie - technika faktycznie ciekawa, ale pomijając zupełnie
podstawowy wykład z LISPa dałoby się to zmieścić w kilku procentach objętości.
> >
> > Chciałbym to zobaczyć.
>
> Usuń z artykułu ten wykład o podstawach LISPa i zobacz, co zostało. Np. po co
tłumaczyć ludziom, że operatory and i or można zaimplementować przy użyciu
konstrukcji if? Generalnie - niepotrzebna dłużyzna.

Dla jednych potrzebna, dla innych niepotrzebna.
Generalnie ludzie uczą się języka czytając przykłady, a nie reguły.
Jeżeli kogoś to nudzi, to łatwo sobie przeskoczy do kolejnego akapitu.

> > Żadne AI nie będzie raczej w stanie wyrazić moich myśli precyzyjniej, niż ja sam.
>
> I znowu myślenie egocentryczne. Problem z AI nie polega na tym, że zrobi coś lepiej
od nas, tylko że nasza robota nie będzie potrzebna i konsekwentnie nasze zdanie o
naszej indywidualnej wyższości nad jakimś tam AI nikogo nie będzie interesować.

Nasza robota nigdy nie była potrzebna.
No chyba że robisz w rolnictwie, czy ewentualnie budowlance.

> Tzn. dzięki AI programowanie może zostać zepchnięte do roli hobby albo cepelii, tak
jak np. ręcznie dziergane szaliki albo inna ceremika rekreacyjna.

Ostatnio natrafiłem na ciekawy wywiad z Jackiem Dukajem, ocierający nieco o ten
temat:
https://www.youtube.com/watch?v=UuEPplXAtJQ

> Natomiast co do prezycji myśli - bez przesady, akurat w tej dziedzinie nie
błyszczymy. Niektórzy uważają, że właśnie brak precyzji pozwolił nam przetrwać i
ewoluować ("we would never survive if we weren't a bit crazy"), ale akurat w
dziedzinach formalnych to nas raczej ogranicza.

Brak precyzji jest cechą charakterystyczną języka naturalnego (i w pewnej mierze
języka matematyki).
Jest to cecha, której w pewnej mierze oczekujemy po języku naturalnym (nawet jeśli
nie zawsze zdajemy sobie z tego sprawę).
Notacje formalne mają cel przeciwny - uczą dyscypliny bardzo rygorystycznego
wyrażania się. Próby formalizacji języka naturalnego zawsze zawodzą (i m.in. dlatego
np. język Inform 7 raczej nigdy nie odniesie większego sukcesu).

Precyzja, którą uzyskujemy, jest trudna, ale moim zdaniem warto ją praktykować.

> > To co pokazałem w swoim artykule to po prostu idea, którą najwygodniej wyrazić w
Lispie.
>
> Konsekwentnie się nie zgadzam, z racji tego, że w LISPie w ogóle mało co się
wygodnie wyraża. Zagnieżdżone pary? Rekurencja? Daj spokój.

Spróbuj przełożyć konstrukcję Byrda i Friedmana na język Wolframa.
Sam z chęcią zobaczę, jaki będzie efekt.

> > > Sam artykuł oczywiście, jak zwykle, zniechęca do LISPa.
> >
> > Powiedz coś więcej na ten temat. W jaki sposób zniechęca?
>
> Cytaty:
>
> "Aren't all those closing parentheses beautiful?"
> "The heavily parenthesized syntax of LISP may not be particularly readable."

Raczej bym powiedział, że "oddaje sprawiedliwość".
Lisp nie jest doskonałą notacją, ale to pewnie dlatego, że nie ma czegoś takiego, jak
"doskonała notacja". Za to do meta-programowania jest najlepszą notacją, jaką znam.

> > Nie rozumiem. Jakiego ograniczenia na liczbę elementów?
>
> Wykład o LISPie zawsze kładzie nacisk na to, że albo mam jeden obiekt albo parę. I
że jak chcę czegoś więcej, to jest to jakaś rzeźba z par. To nie jest ograniczenie? A
potem się okazuje, że zmiana N-tego elementu wymaga rekurencji. Oczywiście, można to
wszystko ukryć pod przystępnymi funkcjami bibliotecznymi, ale po co przykrywać
problem, którego można po prostu nie mieć?

Nadal nie rozumiem. Jaka rzeźba z par? Jak chcesz tworzyć listę elementów a, b, c, to
piszesz po prostu (list a b c) albo '(a b c).
LISP daje też potężny operator "quasiquote", który pozwala na budowanie złożonych
struktur w efektywny sposób.

> > A co jeśli owa wartość Nothing miałaby zostać przekazana jako argument do
funkcji?
>
> Na to też są sposoby, bo w takich specjalnych przypadkach można sterować dokładnym
czasem ewaluacji. Niemniej, pytanie jest zasadne, ale zawsze można też odpowiedzieć,
że można udawać, że takiego ficzeru w ogóle nie ma (tak jak go nie ma w innych
językach), wtedy też nie powstaje problem z przekazywaniem Nothing jako parametr.

No, dla mnie to od początku brzmiało jak ficzer, którego lepiej udawać, że nie ma.

> > W kilku miejscach - tam, gdzie poziom zagnieżdżeń przesłaniał istotę rzeczy -
użyłem notacji Haskella.
>
> Rozumiem. Czyli do programowania w LISPie potrzeby jest Haskell, żeby przekazać
czytelnikowi o co chodzi w LISPowym kodzie.
> Właśnie takie efekty mam na myśli.

Ale co w tym złego? Większość odpowiedzi i tak jest w języku angielskim.
Składnia Haskella ma swoją wartość, tak jak składnia Lispa.
(do wartości składni Wolframa nie jestem przekonany)

> > > Inna rzecz - czy konstrukcja if musi być podstawową w LISPie?
>
> > To o co pytasz to absolutne podstawy lambda-rachunku.
> >
> > https://www.cl.cam.ac.uk/teaching/Lectures/funprog-j
rh-1996/all.pdf
> > rozdział 3
>
> OK, czyli nie musi.
> Ale żeby prawda i fałsz musiały wtedy być funkcjami? Daj spokój.

Proszę, oto spokój.

> > Inna rzecz - czy pattern matching musi być podstawą w Wolframie?
>
> Tak działa ewaluacja w Wolframie (to się nazywa "term rewriting":
https://en.wikipedia.org/wiki/Rewriting). To podstawowy mechanizm, i tak dobrze udaje
inne mechanizmy, że większość ludzi o nim zapomina, sądząc, że to jest po prostu
"normalny wieloparadygmatowy język programowania".

Czyli musi.