W dniu czwartek, 1 sierpnia 2019 14:26:26 UTC+2 użytkownik Maciej Sobczak napisał:
> > > 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.

Dla jednych potrzebna, dla innych niepotrzebna.
Generalnie ludzie uczą się języka czytając przykłady, a nie reguły.
Jeżeli kogoś to nudzi, to łatwo sobie przeskoczy do kolejnego akapitu.

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

Nasza robota nigdy nie była potrzebna.
No chyba że robisz w rolnictwie, czy ewentualnie budowlance.

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

Ostatnio natrafiłem na ciekawy wywiad z Jackiem Dukajem, ocierający nieco o ten
temat:
https://www.youtube.com/watch?v=UuEPplXAtJQ

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

Brak precyzji jest cechą charakterystyczną języka naturalnego (i w pewnej mierze
języka matematyki).
Jest to cecha, której w pewnej mierze oczekujemy po języku naturalnym (nawet jeśli
nie zawsze zdajemy sobie z tego sprawę).
Notacje formalne mają cel przeciwny - uczą dyscypliny bardzo rygorystycznego
wyrażania się. Próby formalizacji języka naturalnego zawsze zawodzą (i m.in. dlatego
np. język Inform 7 raczej nigdy nie odniesie większego sukcesu).

Precyzja, którą uzyskujemy, jest trudna, ale moim zdaniem warto ją praktykować.

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

Spróbuj przełożyć konstrukcję Byrda i Friedmana na język Wolframa.
Sam z chęcią zobaczę, jaki będzie efekt.

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

Raczej bym powiedział, że "oddaje sprawiedliwość".
Lisp nie jest doskonałą notacją, ale to pewnie dlatego, że nie ma czegoś takiego, jak
"doskonała notacja". Za to do meta-programowania jest najlepszą notacją, jaką znam.

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

Nadal nie rozumiem. Jaka rzeźba z par? Jak chcesz tworzyć listę elementów a, b, c, to
piszesz po prostu (list a b c) albo '(a b c).
LISP daje też potężny operator "quasiquote", który pozwala na budowanie złożonych
struktur w efektywny sposób.

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

No, dla mnie to od początku brzmiało jak ficzer, którego lepiej udawać, że nie ma.

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

Ale co w tym złego? Większość odpowiedzi i tak jest w języku angielskim.
Składnia Haskella ma swoją wartość, tak jak składnia Lispa.
(do wartości składni Wolframa nie jestem przekonany)

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

Proszę, oto 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".

Czyli musi.

do góry

> Spróbuj przełożyć konstrukcję Byrda i Friedmana na język Wolframa.
> Sam z chęcią zobaczę, jaki będzie efekt.

Normalnie mi się nie chce, mam inne zainteresowania.
Ale gdybym miał jakoś wesprzeć swój argument, to tutaj jest jakaś tabelka:

https://blog.wolfram.com/2012/11/14/code-length-meas
ured-in-14-languages/

Z jakiejś statystyki wyszło, że programy w CommonLisp (to chyba najbliższy przykład
do tej dyskusji) są ~6 razy dłuższe, niż w Wolframie. Nie wiem, czy ta statystyka
rozciąga się też na Twoje przykłady, ale nie widzę powodu, żeby nie.

> Lisp nie jest doskonałą notacją, ale to pewnie dlatego, że nie ma czegoś takiego,
jak "doskonała notacja". Za to do meta-programowania jest najlepszą notacją, jaką
znam.

A dlaczego akurat do meta-programowania jest najlepsza?

> Nadal nie rozumiem. Jaka rzeźba z par? Jak chcesz tworzyć listę elementów a, b, c,
to piszesz po prostu (list a b c) albo '(a b c).

Ładnie i wygodnie. To jak np. zamienić miejscami elementy ostatni z przedostatnim?

[Nothing]
> No, dla mnie to od początku brzmiało jak ficzer, którego lepiej udawać, że nie ma.

Dlaczego? Bardzo fajny. Zwłaszcza jak się go zwraca z funkcji wywołanej w jakiejś
pętli. Nie muszę wtedy usuwać "pustych" elementów w dodatkowym kroku.
Właśnie dlatego moja funkcja "only" była krótsza (i czytelniejsza) od Twojej w
LISPie. Stąd się biorą potem takie tabelki, jak ta z linku powyżej.

> > Rozumiem. Czyli do programowania w LISPie potrzeby jest Haskell
>
> Ale co w tym złego?

Zależy, jakie masz cele w życiu. Język, który nie pozwala skupić się na problemie,
nie pomaga.

> (do wartości składni Wolframa nie jestem przekonany)

To ciekawe, bo mój znajomy mówi, że Wolfram mu się nie podoba, bo jest za bardzo
LISPowaty. :-)
I ja się z nim zgadzam, że Wolfram jest LISPowaty. Tylko że on jest LISPowaty tylko w
takim stopniu, w jakim jest to użyteczne.

> > > Inna rzecz - czy pattern matching musi być podstawą w Wolframie?
>
> Czyli musi.

Ale co w tym złego?

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

do góry

W dniu piątek, 2 sierpnia 2019 10:32:21 UTC+2 użytkownik Maciej Sobczak napisał:
> > Spróbuj przełożyć konstrukcję Byrda i Friedmana na język Wolframa.
> > Sam z chęcią zobaczę, jaki będzie efekt.
>
> Normalnie mi się nie chce, mam inne zainteresowania.
> Ale gdybym miał jakoś wesprzeć swój argument, to tutaj jest jakaś tabelka:
>
> https://blog.wolfram.com/2012/11/14/code-length-meas
ured-in-14-languages/
>
> Z jakiejś statystyki wyszło, że programy w CommonLisp (to chyba najbliższy przykład
do tej dyskusji) są ~6 razy dłuższe, niż w Wolframie. Nie wiem, czy ta statystyka
rozciąga się też na Twoje przykłady, ale nie widzę powodu, żeby nie.

Czasem w radiu słyszę reklamy, że producent leku przeprowadził niezależne badania, z
których wynika, że ich produkt jest najlepszy. Nie przekonują mnie, tak samo jak
powyższe statystyki (zresztą wiadomo, jak to jest ze statystykami).

Trochę też rozczarowuje brak APLa w ich rankingu - pewnie wyszłoby jeszcze krócej,
niż Mathematica, i by się musieli tłumaczyć.

W każdym razie "krócej" nie zawsze znaczy "lepiej". Kiedyś przekomarzałem się na ten
temat z Jonem Harropem. Zadanie polegało na tym, żeby napisać program
przekształcający program używający rekurencji do takiego, który używa Y-kombinatora.
O jego rozwiązaniu faktycznie można powiedzieć, że było krótsze, ale było też
zdecydowanie mniej czytelne.

Archiwa dyskusji (wraz z rozwiązaniem w Mathematice) można sobie poczytać tutaj:
https://www.quora.com/Why-is-Haskell-not-homoiconic/
answer/Jon-Harrop-2/comment/31109325
natomiast moje roziązanie w Schemie (wraz z nieco bardziej szczegółowym wyjaśnieniem)
można znaleźć tu:
https://github.com/panicz/master-thesis/blob/master/
chapters/B.tex

> > Lisp nie jest doskonałą notacją, ale to pewnie dlatego, że nie ma czegoś takiego,
jak "doskonała notacja". Za to do meta-programowania jest najlepszą notacją, jaką
znam.
>
> A dlaczego akurat do meta-programowania jest najlepsza?

Chyba dlatego, że ma najmniejszą możliwą liczbę reguł, dzięki czemu składnia jest
jednocześnie formatem serializacji (i to lżejszym od np. JSONa)

> > Nadal nie rozumiem. Jaka rzeźba z par? Jak chcesz tworzyć listę elementów a, b,
c, to piszesz po prostu (list a b c) albo '(a b c).
>
> Ładnie i wygodnie. To jak np. zamienić miejscami elementy ostatni z przedostatnim?

No np. tak (z pattern-matcherem Shinna/Wrighta):

(let (((abc ... y z) some-list))
`(,@abc ,z ,y))

> [Nothing]
> > No, dla mnie to od początku brzmiało jak ficzer, którego lepiej udawać, że nie
ma.
>
> Dlaczego? Bardzo fajny. Zwłaszcza jak się go zwraca z funkcji wywołanej w jakiejś
pętli. Nie muszę wtedy usuwać "pustych" elementów w dodatkowym kroku.
> Właśnie dlatego moja funkcja "only" była krótsza (i czytelniejsza) od Twojej w
LISPie. Stąd się biorą potem takie tabelki, jak ta z linku powyżej.

Nie powiedziałbym, żeby była czytelniejsza.
Na pewno do zrozumienia wymagała
- znajomości funkcji "map"
- wiedzy o osobliwym zachowaniu wartości "Nothing"

Łatwo jest zdefiniować "only" przy pomocy "append-map" (czy flatMap, czy concatMap,
jak zwał tak zwał)

(define (only satisfying? elements)
(append-map (lambda (element)
(if (satisfying? element)
`(,element)
'()))
elements))

Wygląda prawie tak samo, jak Twoja, tylko nie trzeba wymyślać "specjalnych elementów"
o "magicznych właściwościach" i "niejasnym statusie ontycznym".

> > > Rozumiem. Czyli do programowania w LISPie potrzeby jest Haskell
> >
> > Ale co w tym złego?
>
> Zależy, jakie masz cele w życiu. Język, który nie pozwala skupić się na problemie,
nie pomaga.

No w omawianym przypadku cel miałem raczej jasny: zaprezentowanie idei "uruchamiania
ewaluatora wstecz".
Ale inna okoliczność, przy której składnia Lispa była nieodzowna, to np. system
Boyera-Moore'a do dowodzenia twierdzeń o programach.

> > (do wartości składni Wolframa nie jestem przekonany)
>
> To ciekawe, bo mój znajomy mówi, że Wolfram mu się nie podoba, bo jest za bardzo
LISPowaty. :-)
> I ja się z nim zgadzam, że Wolfram jest LISPowaty. Tylko że on jest LISPowaty tylko
w takim stopniu, w jakim jest to użyteczne.

Najwidoczniej wynika to stąd, że różne rzeczy są dla nas ważne.
Najwidoczniej dla mnie prostota jest ważniejsza od wygody (którą Ty tutaj nazywasz
"użytecznością"), a dla Ciebie na odwrót.
Dla mnie prostota jest wartością dlatego, że te różne przygodne udogodnienia, które
Wolfram dodaje do składni Lispa, z punktu widzenia meta-programowania wcale nie są
udogodnieniami, tylko wręcz przeciwnie.

Każdy początkujący programista Lispa z łatwością doda sobie do niego różne
udogodnienia składniowe, a jeśli będzie miał nieco więcej uporu, może zaimplementuje
nawet pełną składnię Mathematiki w czytniku Lispa.

A później dostrzeże, że tego rodzaju "udogodnienia" stwarzają barierę między nim a
resztą świata, bo składnia Lispa jest dostatecznie dobra (a jeśli korzysta się z
wyspecjalizowanych narzędzi, jest nawet dużo lepsza), i jego wysiłki tylko
wprowadzają chaos komunikacyjny.

Zaprawieni programiści Lispa nazywają ten proces "rytuałem przejścia".

Być może sytuacja z Mathematiką ma się nieco inaczej, bo ona ma już wokół siebie
stosunkowo dużą społeczność.

> > > > Inna rzecz - czy pattern matching musi być podstawą w Wolframie?
> >
> > Czyli musi.
>
> Ale co w tym złego?

To samo, co w tym, że w danym języku nie da się zdefiniować swojego własnego "if"-a.
Moim zdaniem absolutnie nic, ale to Ty rozpocząłeś ten wątek, więc powiedz: co w tym
złego?

do góry

On 2019-08-02 14:10, g...@g...com wrote:
>> Ładnie i wygodnie. To jak np. zamienić miejscami elementy ostatni z przedostatnim?
>
> No np. tak (z pattern-matcherem Shinna/Wrighta):
>
> (let (((abc ... y z) some-list))
> `(,@abc ,z ,y))

O ja pieprnicze.. No rzeczywiscie "prosto"...

AK

do góry

W dniu sobota, 3 sierpnia 2019 06:52:44 UTC+2 użytkownik AK napisał:

> > No np. tak (z pattern-matcherem Shinna/Wrighta):
> >
> > (let (((abc ... y z) some-list))
> > `(,@abc ,z ,y))
>
> O ja pieprnicze.. No rzeczywiscie "prosto"...

Dla ignoranta nawet zwykłe dodawanie będzie wyglądało jak czarna magia.

Jeżeli uważasz, że umiesz prościej, to pokaż, a jeśli nie, to lepiej zachowaj takie
światłe uwagi dla siebie.

do góry

> Czasem w radiu słyszę reklamy, że producent leku przeprowadził niezależne badania,

Ale ten producent wziął dane z niezależnego serwisu (Rosetta Code). Ty też możesz te
dane stamtąd wziąć.

> Trochę też rozczarowuje brak APLa w ich rankingu

http://rosettacode.org/wiki/Category:Programming_Lan
guages

Ja myślę, że tabelka by nie była czytelna, gdyby wszystkie języki tam uwzględnić.

> pewnie wyszłoby jeszcze krócej, niż Mathematica, i by się musieli tłumaczyć.

Gorzej. W tej dyskusji to LISP wyglądałby jeszcze biedniej.

> W każdym razie "krócej" nie zawsze znaczy "lepiej".

To prawda.

> > A dlaczego akurat do meta-programowania jest najlepsza?
>
> Chyba dlatego, że ma najmniejszą możliwą liczbę reguł, dzięki czemu składnia jest
jednocześnie formatem serializacji (i to lżejszym od np. JSONa)

Dokładnie to samo można napisać o Wolframie (to jest ta "LISPowatość"). Przykładowo,
cały notebook, cokolwiek by nie miał, zapisany na dysku jest jednym legalnym
wyrażeniem.

[Nothing]
> Na pewno do zrozumienia wymagała
> - znajomości funkcji "map"

Bo akurat chciałem, żeby przykład był w stylu funkcjonalnym. Nie musiał być i nie
musiało tam być funkcji map.

> - wiedzy o osobliwym zachowaniu wartości "Nothing"

Bo właśnie to chciałem zaprezentować. Da się też bez tej wiedzy, czyli gorzej. Da się
nawet tak samo źle, jak w Twoim przykładzie. Wolfram to bardzo uniwersalny język,
może nawet udawać gorsze języki. :-)

> Łatwo jest zdefiniować "only" przy pomocy "append-map" (czy flatMap, czy concatMap,
jak zwał tak zwał)
>
> (define (only satisfying? elements)
> (append-map (lambda (element)
> (if (satisfying? element)
> `(,element)
> '()))
> elements))
>
> Wygląda prawie tak samo, jak Twoja, tylko nie trzeba wymyślać "specjalnych
elementów" o "magicznych właściwościach" i "niejasnym statusie ontycznym".

No jak nie. Ja tam widzę pustą listę gdy warunek nie jest spełniony. Skąd mam
wiedzieć, że pusta lista jest ignorowana przez append-map? Przecież mogła być też
dodana do wyniku.
A gdybym jednak chciał dodać pustą listę do wyniku?

W Wolframie pusta lista i Nothing to dwie różne sprawy.
Przykładowo:

only[condition_, list_] := Map[
Function[x,
If[condition[x], x, {}] (* tutaj jest {} zamiast Nothing *)
],
list
]

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

{{}, 2, {}, 4, {}, 6, {}}

Jest różnica, prawda? Jak tą różnicę uzyskać w Twoim przykładzie?

> Najwidoczniej dla mnie prostota jest ważniejsza od wygody (którą Ty tutaj nazywasz
"użytecznością"), a dla Ciebie na odwrót.

Zgodziłbym się, gdyby Twoje przykłady były proste. Ale nie są.

[...]
> Zaprawieni programiści Lispa nazywają ten proces "rytuałem przejścia".

Rozumiem. Wspominałeś już to określenie, ale wcześniej nie zrozumiałem. Czyli "rytuał
przejścia" to sytuacja, kiedy ktoś bez sukcesu próbuje usprawnić język i ostatecznie
rezygnuje z tego, wracając do języka bez usprawnień.

A jest jakaś fajna nazwa na sytuację, kiedy ktoś bez sukcesu próbuje usprawnić język
i ostatecznie rezygnuje z tego i zmienia język na lepszy?
Nie wiem - rytuał wyjścia? odejścia? rozejścia?
Musi być jakaś fajna nazwa.

> Być może sytuacja z Mathematiką ma się nieco inaczej, bo ona ma już wokół siebie
stosunkowo dużą społeczność.

To pewnie ludzie po rytuale wyjścia z LISPa. :-D

W porównaniu do poprzednich postów, w których próbowałeś wykazać, że nikt z tego nie
korzysta, zauważam pozytywną zmianę.

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

do góry

W dniu sobota, 3 sierpnia 2019 21:51:13 UTC+2 użytkownik Maciej Sobczak napisał:
> > Czasem w radiu słyszę reklamy, że producent leku przeprowadził niezależne
badania,
>
> Ale ten producent wziął dane z niezależnego serwisu (Rosetta Code). Ty też możesz
te dane stamtąd wziąć.

Nawet zerknąłem z ciekawości.
Tak konkretniej to zerknąłem tutaj:
https://rosettacode.org/wiki/Levenshtein_distance

Rozwiązanie w Mathematice wyglądało tak:

EditDistance["kitten","sitting"]
->3
EditDistance["rosettacode","raisethysword"]
->8

Dla porównania rozwiązanie w Haskellu:

levenshtein :: Eq a => [a] -> [a] -> Int
levenshtein s1 s2 = last $ foldl transform [0 .. length s1] s2
where
transform ns@(n:ns1) c = scanl calc (n + 1) $ zip3 s1 ns ns1
where
calc z (c1, x, y) = minimum [y + 1, z + 1, x + fromEnum (c1 /= c)]

main :: IO ()
main = print (levenshtein "kitten" "sitting")


Czyli autorzy "rozwiązania" w Mathematice nie dostarczyli implementacji odległości
Levenshteina, tylko skorzystali z wbudowanej. Wygląda zatem na to, że nawet nie
zrozumieli reguł zabawy.
Przy takiej interpretacji rzeczywiście trudno się dziwić, że w Mathematice wychodzą
najkrótsze implementacje.

> > - wiedzy o osobliwym zachowaniu wartości "Nothing"
>
> Bo właśnie to chciałem zaprezentować. Da się też bez tej wiedzy, czyli gorzej. Da
się nawet tak samo źle, jak w Twoim przykładzie. Wolfram to bardzo uniwersalny język,
może nawet udawać gorsze języki. :-)
>
> > Łatwo jest zdefiniować "only" przy pomocy "append-map" (czy flatMap, czy
concatMap, jak zwał tak zwał)
> >
> > (define (only satisfying? elements)
> > (append-map (lambda (element)
> > (if (satisfying? element)
> > `(,element)
> > '()))
> > elements))
> >
> > Wygląda prawie tak samo, jak Twoja, tylko nie trzeba wymyślać "specjalnych
elementów" o "magicznych właściwościach" i "niejasnym statusie ontycznym".
>
> No jak nie. Ja tam widzę pustą listę gdy warunek nie jest spełniony. Skąd mam
wiedzieć, że pusta lista jest ignorowana przez append-map? Przecież mogła być też
dodana do wyniku.
> A gdybym jednak chciał dodać pustą listę do wyniku?

To zamiast '() napisałbyś '(())

> > Najwidoczniej dla mnie prostota jest ważniejsza od wygody (którą Ty tutaj
nazywasz "użytecznością"), a dla Ciebie na odwrót.
>
> Zgodziłbym się, gdyby Twoje przykłady były proste. Ale nie są.

Nie do końca wiem, które przykłady masz na myśli.

> [...]
> > Zaprawieni programiści Lispa nazywają ten proces "rytuałem przejścia".
>
> Rozumiem. Wspominałeś już to określenie, ale wcześniej nie zrozumiałem. Czyli
"rytuał przejścia" to sytuacja, kiedy ktoś bez sukcesu próbuje usprawnić język i
ostatecznie rezygnuje z tego, wracając do języka bez usprawnień.

Raczej: próbuje usprawnić język, ale w międzyczasie odnajduje perspektywę, w której
okazuje się, że pozorne usprawnienia wcale nic nie usprawniają. Że zmiana kształtu
koła nie sprawia, że koło staje się lepszym kołem. Że tym, co było przeszkodą, nie
były niedoróbki języka, tylko nawyki programisty.

> A jest jakaś fajna nazwa na sytuację, kiedy ktoś bez sukcesu próbuje usprawnić
język i ostatecznie rezygnuje z tego i zmienia język na lepszy?

Zauważyłem, że często (w naszych różnych rozmowach, nie tylko teraz) posługujesz się
takimi określeniami, jak "lepszy" czy "gorszy", tak jakby one same w sobie coś
znaczyły.
Być może ma sens mówienie o tym, że coś jest lepsze dla jakiegoś danego celu niż coś
innego, albo że jest lepsze względem jakiegoś kryterium czy jakiejś miary, ale nie
wydaje mi się, żeby można było w ogóle powiedzieć, że dany język jest w jakimś
absolutnym sensie lepszy od jakiegoś innego języka.

> Nie wiem - rytuał wyjścia? odejścia? rozejścia?
> Musi być jakaś fajna nazwa.

Może "sytuacja utknięcia"?
Albo "nieprzejście rytuału przejścia"?

> > Być może sytuacja z Mathematiką ma się nieco inaczej, bo ona ma już wokół siebie
stosunkowo dużą społeczność.
>
> To pewnie ludzie po rytuale wyjścia z LISPa. :-D

Nie wiem jacy to ludzie. Pytanie jest rzeczywiście ciekawe, ale mi brak narzędzi,
żeby to ocenić. (Nie ukrywam jednak, że zdziwiłbym się, gdyby się okazało, że jakiś
znaczący odsetek użytkowników Mathematiki miał wcześniej głębszy kontakt z Lispem)

> W porównaniu do poprzednich postów, w których próbowałeś wykazać, że nikt z tego
nie korzysta, zauważam pozytywną zmianę.

Kiedy ja niby próbowałem coś takiego wykazać?

do góry

> Nawet zerknąłem z ciekawości.
> Tak konkretniej to zerknąłem tutaj:
> https://rosettacode.org/wiki/Levenshtein_distance
[...]
> Czyli autorzy "rozwiązania" w Mathematice nie dostarczyli implementacji odległości
Levenshteina, tylko skorzystali z wbudowanej. Wygląda zatem na to, że nawet nie
zrozumieli reguł zabawy.

Niekoniecznie. Bo jeśli reguły zabawy były takie, żeby nie używać istniejących
ficzerów, tylko biczować się na jak najniższym poziomie, to akurat pokazana przez
Ciebie wersja w Haskellu też tego nie spełnia. foldl, scanl, zip3, minimum, print,
itd. - naprawdę, autorzy nie zrozumieli reguł, powinni to wszystko napisać od zera.

Zaletą Wolframa jest właśnie te 5000+ funkcji, które od ręki coś robią. A ponieważ
Wolfram jest LISPowaty, to nie da się wyraźnie oddzielić funkcji "podstawowych" od
"bibliotecznych", bo wszystkie mają takie same prawa i nie ma żadnej niezbędnej.

> Przy takiej interpretacji rzeczywiście trudno się dziwić, że w Mathematice wychodzą
najkrótsze implementacje.

Problem w tym, że przy innej interpretacji mogłoby się okazać, że w wielu językach w
ogóle nie dałoby się wielu rzeczy napisać, bo większość języków bez swojej biblioteki
standardowej nie potrafi zrobić nawet Hello World.
Więc skoro reguły są takie, że bierzemy język *razem* z jego biblioteką standardową,
to niestety w Wolframie ten konkretny przykładowy problem rozwiązuje się jednym
wywołaniem odpowiedniej funkcji.

To trochę jakbyś chciał wymyślić takie reguły gry w piłkę, żeby Lewandowski nie mógł
strzelić gola i żebyś wtedy mógł z nim wygrać. Sorry, ale przy normalnych, uczciwych
regułach, Lewandowski wygrywa.

(nie żebym się znał na piłce i kto tam teraz rulez, ale mam nadzieję, że analogia
jest zrozumiała)

> > A gdybym jednak chciał dodać pustą listę do wyniku?
>
> To zamiast '() napisałbyś '(())

Ale czad. Prawie zaczynam pamiętać te wszystkie specjalne szczególiki. Bo sorry, ale
nadal tutaj jest specjalne traktowanie listy.

> (Nie ukrywam jednak, że zdziwiłbym się, gdyby się okazało, że jakiś znaczący
odsetek użytkowników Mathematiki miał wcześniej głębszy kontakt z Lispem)

Bardzo nieudolnie ukrywasz swoje poczucie wyższości nad resztą świata.

Otóż Wolfram sam twierdzi, że:

https://www.wolfram.com/language/faq/

"LISP and APL were two early influences"

https://blog.stephenwolfram.com/2013/06/there-was-a-
time-before-mathematica/

"I had a pretty broad knowledge of other computer languages of the time, both the
"ordinary" ALGOL-like procedural ones, and ones like LISP and APL."

I większy wywód tutaj, z wczesnej dokumentacji:

https://reference.wolfram.com/legacy/v1/contents/4.2
.7.pdf

Przypuszczam, że takie doświadczenia dotyczą również jakiejś części użytkowników. Ile
jest takich przypadków - nie wiem, ale biorąc pod uwagę, że w środowisku uczelnianym
LISP jest silnie reprezentowany i wiele narzędzi związanych z matematyką było swego
czasu napisanych w LISPie, to spodziewam się, że świadomość LISPa wśród użytkowników
Wolframa jest co najmniej zauważalna.

--
Maciej Sobczak

do góry

W dniu niedziela, 4 sierpnia 2019 22:57:09 UTC+2 użytkownik Maciej Sobczak napisał:
> > Nawet zerknąłem z ciekawości.
> > Tak konkretniej to zerknąłem tutaj:
> > https://rosettacode.org/wiki/Levenshtein_distance
> [...]
> > Czyli autorzy "rozwiązania" w Mathematice nie dostarczyli implementacji
odległości Levenshteina, tylko skorzystali z wbudowanej. Wygląda zatem na to, że
nawet nie zrozumieli reguł zabawy.
>
> Niekoniecznie. Bo jeśli reguły zabawy były takie, żeby nie używać istniejących
ficzerów, tylko biczować się na jak najniższym poziomie, to akurat pokazana przez
Ciebie wersja w Haskellu też tego nie spełnia. foldl, scanl, zip3, minimum, print,
itd. - naprawdę, autorzy nie zrozumieli reguł, powinni to wszystko napisać od zera.

O ile mogę się zgodzić, że problem demarkacji nie jest w tym przypadku łatwy, o tyle
nie zgodzę się z radykalnym wnioskiem.
Rozwiązanie Haskellowe, chociaż korzysta z funkcji wbudowanych, daje jednak możliwość
zozumienia tego, co się dzieje pod spodem. Rozwiązanie w Mathematice takiej
możliwości nie daje.
Prosta sprawa - zmodyfikuj rozwiązanie w Mathematice tak, żeby koszt zamiany elementu
wynosił 2 a nie 1.

> Zaletą Wolframa jest właśnie te 5000+ funkcji, które od ręki coś robią. A ponieważ
Wolfram jest LISPowaty, to nie da się wyraźnie oddzielić funkcji "podstawowych" od
"bibliotecznych", bo wszystkie mają takie same prawa i nie ma żadnej niezbędnej.

To też jest interesujące: czy algorytm Levenshteina napisany w Mathematice będzie
działał równie szybko jak ten wbudowany?
Czy może ten wbudowany został zaimplementowany w C?

> > Przy takiej interpretacji rzeczywiście trudno się dziwić, że w Mathematice
wychodzą najkrótsze implementacje.
>
> Problem w tym, że przy innej interpretacji mogłoby się okazać, że w wielu językach
w ogóle nie dałoby się wielu rzeczy napisać, bo większość języków bez swojej
biblioteki standardowej nie potrafi zrobić nawet Hello World.
> Więc skoro reguły są takie, że bierzemy język *razem* z jego biblioteką
standardową, to niestety w Wolframie ten konkretny przykładowy problem rozwiązuje się
jednym wywołaniem odpowiedniej funkcji.

W każdym razie zagadka "najkrótszego kodu" w Mathematice rozwiązana.
Każdy może wyciągnąć swoje wnioski.

> To trochę jakbyś chciał wymyślić takie reguły gry w piłkę, żeby Lewandowski nie
mógł strzelić gola i żebyś wtedy mógł z nim wygrać. Sorry, ale przy normalnych,
uczciwych regułach, Lewandowski wygrywa.
>
> (nie żebym się znał na piłce i kto tam teraz rulez, ale mam nadzieję, że analogia
jest zrozumiała)

Bardziej taka analogia, że wystawiamy w wyścigu biegaczy i motocyklistów.
Raczej nikogo nie zdziwi, że motocykliści dojadą szybciej na metę. Ale raczej nie
wnioskowałbym stąd, że kondycja motocyklistów jest lepsza.

> > > A gdybym jednak chciał dodać pustą listę do wyniku?
> >
> > To zamiast '() napisałbyś '(())
>
> Ale czad. Prawie zaczynam pamiętać te wszystkie specjalne szczególiki. Bo sorry,
ale nadal tutaj jest specjalne traktowanie listy.

Tutaj nie ma żadnego specjalnego traktowania listy.
Funkcja "append-map" wymaga, żeby przekazana do niej funkcja zwracała listę. Funkcja
tworzy listę wynikową sklejając ze sobą wyniki list cząstkowych, powstałych przez
aplikację przekazanej funkcji do każdego elementu przekazanej listy.
Nie ma tu żadnych specjalnych szczególików.

> > (Nie ukrywam jednak, że zdziwiłbym się, gdyby się okazało, że jakiś znaczący
odsetek użytkowników Mathematiki miał wcześniej głębszy kontakt z Lispem)
>
> Bardzo nieudolnie ukrywasz swoje poczucie wyższości nad resztą świata.

Zauważyłem, że niejednokrotnie w naszych dyskusjach zdarza Ci się wyjechać z jakimś
dziwnym "ad personam" w moim kierunku. A to że próbuję szpanować, a to że jestem
arogancki, a to że mam poczucie wyższości nad resztą świata.

Nie wiem, skąd się to u Ciebie bierze, ani czemu to ma służyć. Jeżeli masz jakieś
pytania na temat mojej osobowości, to lepiej zapytaj, zamiast spekulować.

W tym kontekście, jeżeli miałbym mówić o "wyższości czegoś nad czymś", to bym
powiedział, że wkład Johna McCarthy'ego w rozwój informatyki był moim zdaniem większy
od wkładu Stephena Wolframa (który być może lepiej się potrafił sprzedać). Ale to
tyle. Nie ma w tym przekonaniu absolutnie nic na mój temat.

> Otóż Wolfram sam twierdzi, że:

Że Wolfram twierdzi, to mnie nie zaskakuje. Ale mówiłem o "znaczącym odsetku
użytkowników", a nie o "odsetku znaczących użytkowników"

> Przypuszczam, że takie doświadczenia dotyczą również jakiejś części użytkowników.
Ile jest takich przypadków - nie wiem, ale biorąc pod uwagę, że w środowisku
uczelnianym LISP jest silnie reprezentowany i wiele narzędzi związanych z matematyką
było swego czasu napisanych w LISPie, to spodziewam się, że świadomość LISPa wśród
użytkowników Wolframa jest co najmniej zauważalna.

No właśnie. Ty się spodziewasz jednego, ja się spodziewam drugiego, i pewnie żaden z
nas nigdy się na ten temat nie dowie niczego.

do góry

On Mon, 5 Aug 2019 03:44:59 -0700 (PDT), g...@g...com wrote:
>>> (Nie ukrywam jednak, że zdziwiłbym się, gdyby się okazało, że jakiś znaczący
odsetek użytkowników Mathematiki miał wcześniej głębszy kontakt z Lispem)
>>
>> Bardzo nieudolnie ukrywasz swoje poczucie wyższości nad resztą świata.
>
> Zauważyłem, że niejednokrotnie w naszych dyskusjach zdarza Ci się wyjechać z jakimś
dziwnym "ad personam" w moim kierunku. A to że próbuję szpanować, a to że jestem
arogancki, a to że mam poczucie wyższości nad resztą świata.
>
> Nie wiem, skąd się to u Ciebie bierze, ani czemu to ma służyć. Jeżeli masz jakieś
pytania na temat mojej osobowości, to lepiej zapytaj, zamiast spekulować.

Raz spytałem, o ile pomnę to odpowiedzi nie było. Spytam jeszcze raz, dość
na temat, skąd ksywa "panicz"?

--
pozdrawiam
Roman Tyczka

do góry