W dniu wtorek, 22 sierpnia 2017 14:54:08 UTC+2 użytkownik Maciej Sobczak napisał:
> > Faktycznie, właśnie coś takiego sobie myślę widząc zapis
> > x[[i ;; ;; s]].
>
> Bez czytania dokumentacji i przy pierwszym kontakcie ze składnią? Niezły jesteś.


To był sarkazm. Łatwo jest nawymyślać dużo dziwnej składni dla
języków programowania, która może się podobać twórcy tej składni
i ewentualnie jakiejś grupie jego fanbojów, ale która jest zupełnie
niezrozumiała dla osób z zewnątrz.

> Ja musiałem przeczytać dokumentację, o tutaj:
>
> http://reference.wolfram.com/language/ref/Part.html

Właśnie o to chodzi. A Alan Kay NIE MUSIAŁ przeczytać żadnej
dokumentacji, żeby rozwiązać ten problem przy pomocy podstawowych
operatorów i rekurencji.

> > Zresztą, jaka mogłaby być inna
> > interpretacja dla podwójnego średnika oddzielonego spacją w podwójnie
> > zagnieżdżonym nawiasie kwadratowym?
>
> Po rzuceniu okiem na linka powyżej (tak nawet bez przewijania, wystarczy początek
strony) interpretacja mogłaby być właśnie taka a nie inna.
>
> I wyobraź sobie, że o hd(x), tl(x) i ttl(x) też trzeba najpierw gdzieś przeczytać,
bo bez tego to są mnemoniki z epoki asemblera, chyba że mam losowo wybrać coś z tych
wyników:

Owszem. hd, tl i ttl, czy car, cdr i cddr to nie są dobre nazwy.
pewnie head i tail albo first i rest byłyby lepsze. Tym niemniej,
są to najprostsze możliwe koncepty, które wystarczy opanować,
żeby zrozumieć bardzo dużo kodu tego rodzaju.
Dla odmiany, żebyś nie wiem ile siedział w Mathematice, zawsze znajdą
się jakieś operatory, których nie będziesz miał szans zrozumieć
bez dokumentacji. I niestety, takie symbole jak # czy @ nie są
samodokumentujące (w przeciwieństwie do nazw funkcji)


> Pierwsze wyniki to: High Definition Toilet Total
>
> Teraz moja kolej: "jaka mogłaby być inna interpretacja"?
>
> Tak, znam LISPa i wiem co te skróty mogą oznaczać w Twoim SmallTalkowym cytacie,
ale jak trolować, to najlepiej w parach.
>
> Na poważnie, ten Twój przykład mnie kompletnie nie przekonał.

Odnoszę wrażenie, że nawet do Ciebie nie dotarł.

> Nieparzyste i parzyste elementy to pojęcia na tyle oczywiste, że nie powinny
wymagać rekurencyjnej rekonstrukcji ani sprawdzania cztery razy (!) czy coś jest
nullem, czy nie jest. Najśmieszniejsze jest to, że ten cytat był o wyższości czegoś
nad językiem opartym o wskaźniki - a tu proszę, cztery razy test na nulla, żeby
wybrać z listy co drugi element? No bez jaj. To jest strzał w stopę. Dobrze, że takie
języki to tylko historia.

Może przed skrytykowaniem najpierw spróbowałbyś zrozumieć kontekst tego,
o czym mowa?