W dniu środa, 23 sierpnia 2017 12:15:01 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Musiał. Musiał przeczytać o hd, tl, ttl, nil i null oraz wiedzieć, co robią
operatory v oraz &. I jeszcze parę innych rzeczy.
> >
> > Nie.
>
> Urodził się z tą wiedzą? Naprawdę?

Nie. Gdybyś przeczytał jedno zdanie za tym słowem,
pewnie zauważyłbyś, że było tam napisane
"Musiał nauczyć się języka".
Podejrzewam, że gdybyś przeczytał jeden post przed tym,
w którym wkleiłem ten cytat, nie wszczynałbyś tej
dyskusji.

> > Musiał nauczyć się języka, który potem zmieścił się w jego głowie.
>
> To stwierdzenie dotyczy wszystkich języków. Mam wrażenie,
> że ideologizujesz i dorabiasz mitologię do czegoś, co na to nie zasługuje.

Tak. Tylko że w przypadku niektórych języków rozwiązanie
tego problemu zajmuje pół godziny albo wymaga grzebania po dokumentacji,
żeby zarówno zapisać, jak i zrozumieć rozwiązanie, a w przypadku innych
-- kilkanaście sekund, i wszystko jest podane na dłoni.

Mogę podać inny przykład, bliższy temu, o czym tutaj jest mowa.
Kiedyś, dawno temu, jak jeszcze pisałem engine 3D w C++, to na podstawie
książki Stroustrupa skleciłem główną pętlę, której fragment wyglądał
tak, mniej więcej:

for (int i = 0; i < ticks_per_frame; i++) {
for_each(in_seq(sectors), bind2nd(mem_fun(&Sector::update), 0.07));
for_each(in_seq(portals), bind2nd(mem_fun(&Portal::update), 0.07));
for_each(in_seq(ropes), bind2nd(mem_fun(&Rope::update), 0.07));
}

Twórca języka dostarczył mi środki wyrazu, i kiedy czytam ten kod, jestem
z grubsza w stanie zrozumieć, co robią takie kwiatki, jak in_seq,
bind2nd czy mem_fun. Ale bez książki raczej bym czegoś takiego nie
napisał. Pewnie nawet bez kompilatora miałbym problem, czy umieścić
ampersand tu i ówdzie, czy nie umieszczać.

Dla odmiany taki chociażby Python pozwoliłby wyrazić te konstrukcje
np. tak:

for instance in range(ticks_per_second):
for sector in sectors:
sector.update(0.07)

for portal in portals:
portal.update(0.07)

for rope in ropes:
rope.update(0.07)

W Pythonie piszę rzadko, ale nie musiałem zerkać do dokumentacji,
żeby napisać powyższych kilka linijek.


> > Ale przynajmniej będziesz miał szanse je wypowiedzieć bez dokumentacji.
>
> Ale przecież operatory w Wolframie też można wypowiedzieć.
> Np. operator indeksowania (to te podwójne nawiasy) nazywa się
> Part.

Dziwne. Nie przyszło mi do głowy, żeby [[_ ;; ;; _]] wymówić "Part".
Prędzej wymówiłbym to jako "otwórz nawias kwadratowy, otwórz nawias
kwadratowy, coś, spacja, średnik, średnik, spacja, średnik, średnik,
spacja, coś, zamknij nawias kwadratowy, zamknij nawias kwadratowy".


> > Jednak w moim odczuciu linijka
> >
> > oddsEvens(x) = append(odds(x), evens(x))
> >
> > jest zdecydowanie czytelniejsza od
> >
> > oddsEvens[x_] := Join[x[[1 ;; ;; 2]], x[[2 ;; ;; 2]]]
>
> No bez jaj. Naprawdę nie zrozumiałeś?

Zrozumiałem, i to od razu, jak tylko wyjaśniłeś, co robi operator
[[_ ;; ;; _]]. Pewnie gdybyś nie wyjaśnił, to znając cel rozwiązania,
i tak bym odgadł, co ów dziwny splot symboli oznacza.
Stwierdzam tylko, że to pierwsze jest czytelniejsze.

> oddsEvens[x_] := Join[odds[x], evens[x]]
>
> Teraz lepiej?

Czytelniej.
Wątpliwości w dalszym ciągu wzbudza rola podkreślnika po argumencie
po lewej stronie znaku ":=", oraz to, dlaczego do wyrażenia tożsamości
użyto symbolu powszechnie używanego w informatyce w roli przypisania.

> Oczywiście, teraz potrzebujesz zdefiniować osobno czym jest odds[x_] oraz
evens[x_], np.:
>
> odds[x_]:=x[[1 ;; ;; 2]]
> evens[x_]:=x[[2 ;; ;; 2]]
>
> albo nawet:
>
> odds[x_]:=Part[x, 1 ;; ;; 2]
> evens[x_]:=Part[x, 2 ;; ;; 2]
>
> jeśli bardzo nie lubisz podwójnych nawiasów.

Podwójnych podwójnych średników też nie lubię.

> Ale uznałem, że taka "refaktoryzacja" jest tutaj przesadą,
> bo jeśli jakaś funkcja pomocnicza jest implementowana jedną
> operacją, to nie ma po co takiej funkcji definiować
> i można od razu rozwiązać właściwy (ten zadany) problem.

Zgadzam się.
Gdybyśmy zresztą nawet nie dysponowali funkcją Parts, moglibyśmy
ją sobie zdefiniować przy pomocy cons, car, cdr i rekurencji.

> > Nie przekonał do czego?
>
> A do czego miał przekonać? :-)

Że języki, które znamy, warunkują sposób, w jaki myślimy,
albo -- jak to powiedział Wittgenstein, "granice mojego języka
wyznaczają granice mojego świata".
Nie wiem zresztą, czy miał przekonać. Raczej miał stanowić
ilustrację tego, w jaki sposób ta maksyma odzwierciedla się
w kontekście języków programowania. Sądzę, że -- mimo wszystkich
zarzutów, jakie wysnułeś, dotyczących rozwiązania wymyślonego
przez Kaya (i które nb nijak się mają do tego, co chciałem
zakomunikować) -- stanowi dobrą ilustrację.

> > Że język jest narzędziem do myślenia.
>
> Każdy jest. Dlatego ten Twój przykład niczego szczególnego
> w tym zakresie nie pokazał. Ot, dawno temu jakiś koleś
> napisał długi i skomplikowany program na zrobienie prostej
> rzeczy.

Skoro mowa o kontekście, może przeczytaj sobie, kim był
ów "jakiś koleś".
Hegel co prawda ponoć mawiał, że jedną rzeczą, której uczy
nas historia, jest to, że niczego się nie potrafimy z historii
nauczyć, jednak sądzę, że warto próbować przezwyciężać
te nasze ułomności -- w szczególności warto przyglądać się
temu, jak historycznie kształtowały się nasze sposoby rozumienia
obliczania i komputerów.
Oczywiście, można sobie "być mądrym" i przyjść na gotowe.
(I wyciągać z historii wciąż ten sam jeden wniosek)

> Dzisiaj proste rzeczy robi się krótkimi programami,
> dzięki czemu można podnieść poziom i łatwiej/szybciej myśleć
> o rzeczach bardziej skomplikowanych.

Skoro mowa o kontekście, może zamiast pokazywać przykład
w Mathematice, która stosunkowo niewiele różni się od ISWIMa z lat 60.,
może spróbowałbyś pokazać rozwiązanie tego zadania w nowoczesnym
języku, jakim jest C++, żebyśmy zobaczyli, jak naprawdę "dzisiaj
się robi proste rzeczy"?