> https://www.quora.com/Can-you-explain-to-non-coders-
the-most-impressive-code-youve-seen/answer/Panicz-Go
dek
>
> W ogólności pytanie "jaki jest najbardziej imponujący kod, jaki widziałeś" wydaje
mi się ciekawe, więc jeśli ktoś tu ma jakieś swoje obserwacje na ten temat, z chęcią
bym się dowiedział.

Przeczytałem. Najpierw formalności - nie spodobały mi się dwie uwagi już na samym
początku tekstu:

"Don't be surprised if understanding this answer would take you many days, weeks or
even months."

Nikt nie będzie zaskoczony, bo jeśli ktoś miałby tego nie zrozumieć, to by po prostu
nie doczytał. Czytanie długich tekstów jest niemodne, zwłaszcza takich, których się
nie rozumie od razu. Trochę też wygląda to na założenie, że czytelnik nie kuma bazy -
otóż samo pytanie do tego artykułu było skierowane do programistów (nie można być pod
wrażeniem jakiegokolwiek kodu, nie rozumiejąc go), więc zakładanie, że ktoś będzie
potrzebował miesięcy, żeby zrozumieć Twój wywód, jest aroganckie. Zwłaszcza ta część,
że ktoś w ogóle poświęci miesiące swojego życia na tak zaszczytne zadanie jak próba
zrozumienia akurat Twojego wywodu, z 40+ innych w tej samej dyskusji, spośród
niezliczonej liczby takich dyskusji na niezliczonej liczbie portali dyskusyjnych.
Realia publikowania na portalach społecznościowych są takie, że albo ktoś to od razu
zrozumie, albo od razu oleje. Nikt nie będzie inwestował cennych miesięcy życia na
zrozumienie akurat Twojego artykułu. Bez jaj.

"Frankly speaking, I've found most other answers here completely disappointing."

W takim razie, frankly speaking, sam się podsumowałeś tym wstępem.
I nie tylko dlatego, że dla wielu ludzi najbardziej imponujące są właśnie najprostsze
olśnienia, takie programistyczne Zen, jak wcześniejszy artykuł z wieżami Hanoi w 3
linijkach. Poprzednim zdaniem postawiłeś się ponad swoimi czytelnikami a tym zdaniem
postawiłeś się ponad autorami innych postów. I takie właśnie są dwa zdania z trzech z
pierwszego paragrafu Twojego tekstu. Bez jaj. Nie zachęcasz w ten sposób do rzeczowej
dyskusji.


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.
Czy to ma realne zastosowania? Nie wiem. Może mieć - obecnie żywe są dyskusje na
temat zastępowania różnych grup zawodowych przez AI i dla nas ciekawym pytaniem jest
to, czy można zastąpić programistę. Ale chyba trend jest w kierunku innych technik.
Ostatnio widziałem prezentację systemu asystenta programisty (w skrócie: podpowiadacz
w edytorze, czyli tak jak w Twoim artykule), który działał na zasadzie deep learning
z milionów plików źródłowych z GitHuba. Czyli "nauczył się" (cokolwiek to znaczy)
czytając istniejący już kod a potem podpowiada programiście całe garście kodu do tego
co chce zrobić. I mam wrażenie, że ML jest bardziej prawdopodobnym kierunkiem rozwoju
dla takich systemów. Zaletą takiego podejścia jest to, że ML działa jednakowo dobrze
na każdym języku programowania (w szczególności na tych najpopularniejszych),
natomiast to co pokazałeś w swoim artykule działa tylko w LISPie.

Sam artykuł oczywiście, jak zwykle, zniechęca do LISPa. Jak ktoś już lubi ten język,
to się będzie cieszył, ale też dla takiej publiczności nie było sensu takich podstaw
wykładać. A jak ktoś nie lubi, to nie polubi. Ile można wciskać ludziom, że
zagnieżdżone pary to dobra metoda na robienie list? Przecież to absurd.
W tym kontekście konsekwentnie bardziej podoba mi się podejście Wolframa, gdzie lista
jest podstawową konstrukcją wspieraną przez język:

head[elem1, elem2, elem3, ...]

bez sztucznego (!) ograniczenia na liczbę elementów. Nie ma zagnieżdżeń, jeśli nie są
potrzebne (ale mogą być, jeśli chcemy drzewa). W Wolframie fajny jest też pomysł na
wbudowany symbol Nothing, który "znika" z sekwencji elementów, jeśli się gdzieś
pojawi. Wtedy funkcję filtrującą "only" można zdefiniować tak:

only[condition_, list_] := Map[
Function[x,
If[condition[x], x, Nothing]
],
list
]

czyli mapujemy elementy na siebie albo na Nothing jeśli nie spełniają warunku, i
wtedy, przykładowo:

only[EvenQ, {1, 2, 3, 4, 5, 6, 7}]

{2, 4, 6}

Oczywiście nikt by tak nie zrobił, bo są gotowe funkcje filtrujące, ale ten przykład
pokazuje, że o listach można myśleć prosto. I wtedy poprzeczka przetwarzania struktur
danych jest konsekwentnie niżej - więc zapewne Twoje przykłady z artykułu dałoby się
zapisać dużo prościej, zamiast walczyć ze sztucznymi ograniczeniami języka.
Zagnieżdżone pary? No daj spokój. Palce można połamać, zupełnie bez satysfakcji.

Inna rzecz - czy konstrukcja if musi być podstawową w LISPie? W Wolframie nie musi
być, bo podstawą całego przetwarzania i tak jest pattern matching, czyli mogę sobie
zdefiniować własnego ifa:

myIf[True, x_, y_] := x
myIf[False, x_, y_] := y

Chociaż to nie jest właściwe technicznie określenie, można to rozumieć jako
przeciążanie funkcji na wartości pierwszego parametru.
To działa tak samo jak standardowy If, więc ten standardowy If nie musi być
"magiczną" funkcją, tylko może być biblioteczną. I konsekwentnie można sobie tak
zdefiniować inne warunkowe konstrukcje sterujące. LISP też tak umie, czy może musi
mieć ifa jako "magiczną" funkcję interpretera, bez której niczego nie dało by się
zrobić?

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