Hej,
gdyby ktoś był zainteresowany, to ostatnio opublikowałem na Quorze nieco przydługawy
artykuł (czy może raczej "małą książkę"?) objaśniający technikę Friedmana i Byrda
"uruchamiania ewaluatora od tyłu".

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

Pozdrawiam

do góry

Dnia Tue, 30 Jul 2019 06:58:03 -0700 (PDT), g...@g...com
napisał(a):

> Hej,
> gdyby ktoś był zainteresowany, to ostatnio opublikowałem na Quorze nieco
przydługawy artykuł (czy może raczej "małą książkę"?) objaśniający technikę Friedmana
i Byrda "uruchamiania ewaluatora od tyłu".
>
> 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ł.
>
> Pozdrawiam

Najbrdziej imponujący kod (w pierwszej 10-ce):
emulator karty sim w asemblerze sprzed ery Comp128v1.

do góry

On Wed, 31 Jul 2019 11:34:46 +0200, dantes wrote:

> Dnia Tue, 30 Jul 2019 06:58:03 -0700 (PDT), g...@g...com
> napisał(a):
>
>> Hej,
>> gdyby ktoś był zainteresowany, to ostatnio opublikowałem na Quorze nieco
przydługawy artykuł (czy może raczej "małą książkę"?) objaśniający technikę Friedmana
i Byrda "uruchamiania ewaluatora od tyłu".
>>
>> 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ł.
>>
>> Pozdrawiam
>
> Najbrdziej imponujący kod (w pierwszej 10-ce):
> emulator karty sim w asemblerze sprzed ery Comp128v1.

To jeśli chodzi o assembler to w latach dziewięćdziesiątych powstał program
muzyczny typu tracker o nazwie DigiBooster. Był to najbardziej zaawansowany
tracker na Amigę, a było ich wtedy wiele. Napisany przez dwóch braci z
Wrocławia. Kawał dobrego softu, np. Amiga hardwarowo miała 4 kanały
dżwiękowe, a DigiBooster pozwalał pracować na 128 kanałach, co było
ewenementem w tego typu sofcie.

Obecnie odkupiony i przepisany już na C.

http://www.digibooster.de/en/gallery.php


ps. fajne było to, że zgłaszałem chłopakom od DigiBoostera błędy i sugestie
co do rozwoju nowych wersji ...Pocztą Polską, to może być niewyobrażalne
dzisiaj :-)

--
pozdrawiam
Roman Tyczka

do góry

W dniu 31.07.2019 o 12:32, Roman Tyczka pisze:
> To jeśli chodzi o assembler to w latach dziewięćdziesiątych powstał program
> muzyczny typu tracker o nazwie DigiBooster. Był to najbardziej zaawansowany
> tracker na Amigę, a było ich wtedy wiele. Napisany przez dwóch braci z
> Wrocławia. Kawał dobrego softu, np. Amiga hardwarowo miała 4 kanały
> dżwiękowe, a DigiBooster pozwalał pracować na 128 kanałach, co było
> ewenementem w tego typu sofcie.
>
> Obecnie odkupiony i przepisany już na C.
>
> http://www.digibooster.de/en/gallery.php


Stare dzieje, gdy marzeniem był ZxSpectrum z interpreterem Basicem, i w
Bajtku był opisany ToBoS (https://pl.wikipedia.org/wiki/ToBoS-FP)
kompilator Basica do kodu maszynowego.
Duże wrażenie przykład wzoru na sinusa, gdzie zastosowano wielomiany
Czebyszewa, podczas gdy w Basicu był wyliczany ogólną metodą - szeregiem
z silniami,

do góry

> 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

do góry

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

Jakieś namiary ?

do góry

W dniu 31.07.2019 o 16:18, Borneq pisze:
> > 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.
>
> Jakieś namiary ?

Widzę tu dwie możliwości: jedna to podpowiadanie kodem, drugie to
potężna refaktoryzacja typu "wydziel x kodu jakąś klasę, odpowiednio
poprzenoś metody , zalezności mają być takie by się kompilowało"

do góry

W dniu środa, 31 lipca 2019 14:59:28 UTC+2 użytkownik Maciej Sobczak napisał:
> > 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ł.

Podejrzewam, że większość osób może być zaskoczona, ponieważ taki format odpowiedzi
raczej rzadko zdarza się na Quorze.

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

Aroganckie? Mnie napisanie tego tekstu zajęło kilka miesięcy, a zrozumienie
podstawowych rzeczy - co najmniej kilka lat. Daniel Friedman stwierdził kiedyś, że
zrozumienie opisanego przeze mnie silnika wnioskującego - kilkunastu linijek kodu -
zajęło mu ponad rok.

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

Tego nie mogę wiedzieć (i sądzę, że Ty też nie).
Ale dotychczasowe reakcje na artykuł były raczej przychylne, i wydają się sugerować,
że określenie "nikt" to raczej spore niedoszacowanie.

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

Nie rozumiem, w jaki sposób "postawiłem się ponad swoimi czytelnikami".
Stwierdzając, że zrozumienie czegoś może zająć kilka miesięcy?
Pomijając kwestię, że owo "postawienie się ponad nimi" jest logicznie niewykonalne,
bo nie mogę a priori powiedzieć, kto ten tekst przeczyta.

Zaś co do "stawiania się ponad autorami innych postów", to owszem, ja sam nie
wyniosłem z ich lektury nic wartościowego. To mnie stawia w tym samym szeregu z
ewentualnymi innymi czytelnikami, którzy mieli podobne odczucia.

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

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

No właśnie, wydaje mi się, że w owym dopowiedzeniu "cokolwiek to znaczy" jest
pogrzebany pies.
Nie traktuję programowania jako "produkowania kodu", tylko jako precyzyjną formę
wyrażania myśli. Żadne AI nie będzie raczej w stanie wyrazić moich myśli
precyzyjniej, niż ja sam.

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

To co pokazałem w swoim artykule to po prostu idea, którą najwygodniej wyrazić w
Lispie. Kilka lat temu Will Byrd przyjechał do Poznania, gdzie na konferencji
PolyConf pokazał tę technikę zaimplementowaną dla prostego języka imperatywnego:

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

> Sam artykuł oczywiście, jak zwykle, zniechęca do LISPa.

Powiedz coś więcej na ten temat. W jaki sposób zniechęca?

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

Nie rozumiem. Jakiego ograniczenia na liczbę elementów?

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

A co jeśli owa wartość Nothing miałaby zostać przekazana jako argument do funkcji?

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

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

W kilku miejscach - tam, gdzie poziom zagnieżdżeń przesłaniał istotę rzeczy - użyłem
notacji Haskella.

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

To o co pytasz to absolutne podstawy lambda-rachunku.
If jest definiowalny w oparciu o lambda-wyrażenia. Zamieściłem go jako część
ekspozycji, ponieważ wydaje mi się łatwy do zrozumienia dla "nie-programistów".

https://www.cl.cam.ac.uk/teaching/Lectures/funprog-j
rh-1996/all.pdf
rozdział 3

Inna rzecz - czy pattern matching musi być podstawą w Wolframie? W LISPie nie musi
być, i jeśli chcesz, możesz sobie zdefiniować swój własny.

do góry

On Wednesday, July 31, 2019 at 4:18:18 PM UTC+2, Borneq wrote:
> > prezentację systemu asystenta programisty (w skrócie: podpowiadacz w
> > edytorze, czyli tak jak w Twoim artykule), który działał na zasadzie
> > deep learning
>
> Jakieś namiary ?

https://www.theverge.com/2019/7/24/20708542/coding-a
utocompleter-deep-tabnine-ai-deep-learning-smart-com
pose

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

do góry

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

> 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

do góry