🚀 go-pugleaf

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

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

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.

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

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

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

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

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

> > 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-jrh-1996/all.pdf
> rozdział 3

OK, czyli nie musi.
Ale żeby prawda i fałsz musiały wtedy być funkcjami? Daj 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".

-- 
Maciej Sobczak * http://www.inspirel.com