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?

do góry

> > Ja musiałem przeczytać dokumentację, o tutaj:
>
> Właśnie o to chodzi. A Alan Kay NIE MUSIAŁ przeczytać żadnej
> dokumentacji,

Musiał. Musiał przeczytać o hd, tl, ttl, nil i null oraz wiedzieć, co robią operatory
v oraz &. I jeszcze parę innych rzeczy.

> Owszem. hd, tl i ttl, czy car, cdr i cddr to nie są dobre nazwy.

No nie są. Ale po pierwszym dniu da się zapamiętać. Podobnie jak da się zapamiętać
jak wygląda indeksowanie list w Wolframie.

> Dla odmiany, żebyś nie wiem ile siedział w Mathematice, zawsze znajdą
> się jakieś operatory, których nie będziesz miał szans zrozumieć
> bez dokumentacji.

Dla odmiany, żebyś nie wiem ile siedział w Lispie czy innym SmallTalku, zawsze znajdą
się jakies funkcje, których nie będziesz miał szans zrozumieć bez dokumentacji.

> bez dokumentacji. I niestety, takie symbole jak # czy @ nie są
> samodokumentujące

Faktycznie nie są.

> (w przeciwieństwie do nazw funkcji)

W przeciwieństwie np. do funkcji ttl? Niestety nie bardzo.

> > Na poważnie, ten Twój przykład mnie kompletnie nie przekonał.
>
> Odnoszę wrażenie, że nawet do Ciebie nie dotarł.

Nie przekonał. Rozumiem, że parę dekad temu ktoś się jarał, że można rekurencyjnie
wyciągnąć z listy elementy na nieparzystych pozycjach. Parę dekad później mnie takie
coś nie jara.

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

Że mimo wszystko było to fajniejsze, niż istniejące alternatywy? Mogło tak być. Ale
dzisiaj mnie to nie przekonuje.

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

do góry

W dniu środa, 23 sierpnia 2017 11:01:44 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Ja musiałem przeczytać dokumentację, o tutaj:
> >
> > Właśnie o to chodzi. A Alan Kay NIE MUSIAŁ przeczytać żadnej
> > dokumentacji,
>
> Musiał. Musiał przeczytać o hd, tl, ttl, nil i null oraz wiedzieć, co robią
operatory v oraz &. I jeszcze parę innych rzeczy.

Nie. Musiał nauczyć się języka, który potem zmieścił się w jego głowie.
Język programowania stał się narzędziem do myślenia, a nie sposobem
wydawania komputerowi rozkazów.


> > Dla odmiany, żebyś nie wiem ile siedział w Mathematice, zawsze znajdą
> > się jakieś operatory, których nie będziesz miał szans zrozumieć
> > bez dokumentacji.
>
> Dla odmiany, żebyś nie wiem ile siedział w Lispie czy innym SmallTalku,
> zawsze znajdą się jakies funkcje, których nie będziesz miał szans
> zrozumieć bez dokumentacji.

Ale przynajmniej będziesz miał szanse je wypowiedzieć bez dokumentacji.

> > bez dokumentacji. I niestety, takie symbole jak # czy @ nie są
> > samodokumentujące
>
> Faktycznie nie są.
>
> > (w przeciwieństwie do nazw funkcji)
>
> W przeciwieństwie np. do funkcji ttl? Niestety nie bardzo.

Nie mówię o kryptycznych nazwach funkcji. Zawsze można wymyślić
nazwę, która nie będzie niczego nikomu mówiła.

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

> > > Na poważnie, ten Twój przykład mnie kompletnie nie przekonał.
> >
> > Odnoszę wrażenie, że nawet do Ciebie nie dotarł.
>
> Nie przekonał.

Nie przekonał do czego?

> Rozumiem, że parę dekad temu ktoś się jarał, że można rekurencyjnie
> wyciągnąć z listy elementy na nieparzystych pozycjach. Parę dekad
> później mnie takie coś nie jara.

Jednak nie dotarł.

> > Może przed skrytykowaniem najpierw spróbowałbyś zrozumieć kontekst tego,
> > o czym mowa?
>
> Że mimo wszystko było to fajniejsze, niż istniejące alternatywy?

Nie. Że język jest narzędziem do myślenia.
Nota bene Mathematica, której przykład podałeś, też jest językiem
aplikatywnym, którego zasadnicze założenia wywodzą się z Lispa,
i również można o nim wnioskować w terminach podstawieniowego
modelu obliczeń. To, czy wprowadzisz do języka podstawowy operator
do rozwiązania problemu X, czy musisz sobie ten operator sam
zdefiniować, jest sprawą drugorzędną (o ile oczywiście język
daje ci możliwość definiowania)

> Mogło tak być. Ale dzisiaj mnie to nie przekonuje.

Nie przekonuje do czego?

do góry

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

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

> 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. I co ciekawe, jest to po prostu inna
składnia na to samo, więc a[[idx]] oraz Part[a,idx] to są te same operacje. Różnią
się tylko w pisowni. Podobnie, x+y to Plus[x,y]. Itd.
Oznacza to też, że każdy program w Wolframie można napisać nie używając żadnych
operatorów. Czyli jeśli nieczytelne operatory są dla Ciebie problemem i wolisz
samodokumentujący się zapis słowny, to w Wolframie możesz mieć tego nawet więcej, niż
w SmallTalku.

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

oddsEvens[x_] := Join[odds[x], evens[x]]

Teraz lepiej? 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.
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.

> Nie przekonał do czego?

A do czego miał przekonać? :-)

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

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

do góry

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

do góry

On Wed, 23 Aug 2017 02:01:42 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> Nie przekonał. Rozumiem, że parę dekad temu ktoś si?=
> ? jarał, że można rekurencyjnie wyciągnąć z=
> listy elementy na nieparzystych pozycjach. Parę dekad późni=
> ej mnie takie coś nie jara.



Ok, to /może/ być pasjonujące, tzn. może jarać. Tzn. mnie to
niespecjalnie, ale różni ludzie lubią różne rzeczy: kogoś jara kurs
rupii, kogoś jara starocerkiewnosłowiański, kogoś jara hodowla
gołębi, a kogoś zabawy pejczem. Rekursyjne (w PL nie ma czegoś
takiego jak "rekurencja") operacje na listach nie są czymś mniej
godnym bycia źródłem jarania niż powyższe.

Ale jest pewien dinks: po co to?

Bo w 2017 program wyciągający elementy nieparzyste z listy to
ewentualnie coś pomiędzy zadaniem domowym dla gimbazy a pytaniem od
headhuntera.

Dodatkowo pojawia się pytanie: jak bardzo głęboko metafizyczne
znaczenie ma podzielność przez dwa elementów nie numerowanych? Ale to
inksza inkszość i na razie nie ma co w tym kopać.

do góry

On Wed, 23 Aug 2017 02:29:13 -0700 (PDT), g...@g...com
wrote:
> 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]]]

W moim odczuciu w Matlabie byłoby też prościej

B = [ A(1:2:end), A(2:2:end) ]


Tyle że odczucia są subiektywne, a więc lepiej zostawić je humanistom
i innym specjalistom od mniemamologii stosowanej.

Bo powoli dryfujemy w stronę kłótni czy lepiej jest pisać append czy
Join.

do góry

On Wed, 23 Aug 2017 02:29:13 -0700 (PDT), g...@g...com
wrote:
> Nota bene Mathematica, której przykład podałeś, te?=
> ? jest językiem
> aplikatywnym, którego zasadnicze założenia wywodzą si=
> ę z Lispa,



Wow!

Czyli co się z czego?

Przypominam, że sam fakt iż język ma listy jako struktury danych to
trochę cienko na tezę "wywodzi się z Lispa".

do góry

W dniu środa, 23 sierpnia 2017 15:24:51 UTC+2 użytkownik slawek napisał:

> > Nota bene Mathematica, której przykład podałeś, te?=
> > ? jest językiem
> > aplikatywnym, którego zasadnicze założenia wywodzą si=
> > ę z Lispa,
>
>
>
> Wow!
>
> Czyli co się z czego?
>
> Przypominam, że sam fakt iż język ma listy jako struktury danych to
> trochę cienko na tezę "wywodzi się z Lispa".

Ech...

https://pl.wikipedia.org/wiki/Macsyma
https://pl.wikipedia.org/wiki/Information_Processing
_Language

(i jeśli rozumiesz po angielsku)

http://www-formal.stanford.edu/jmc/history/lisp/lisp
.html
https://en.wikipedia.org/wiki/ISWIM
http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf
http://worrydream.com/refs/Backus-CanProgrammingBeLi
berated.pdf

do góry

W dniu środa, 23 sierpnia 2017 15:13:26 UTC+2 użytkownik slawek napisał:

> gołębi, a kogoś zabawy pejczem. Rekursyjne (w PL nie ma czegoś
> takiego jak "rekurencja")

https://pl.wikipedia.org/wiki/Rekurencja

do góry