Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #32762 > unrolled thread

"Najbardziej imponujący kod, jaki widziałem"

Back to article view | Back to pl.comp.programming

Contents

  "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-07-30 06:58 -0700
    Re: "Najbardziej imponujący kod, jaki widziałem" dantes <dantes@qmail.com> - 2019-07-31 11:34 +0200
      Re: "Najbardziej imponujący kod, jaki widziałem" Roman Tyczka <noemail@because.no> - 2019-07-31 12:32 +0200
        Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-07-31 13:54 +0200
        Re: "Najbardziej imponujący kod, jaki widziałem" Bischoop <Bischoop@vimart.net> - 2021-09-23 23:11 +0000
    Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-07-31 05:59 -0700
      Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-07-31 16:18 +0200
        Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-07-31 16:36 +0200
        Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-01 04:47 -0700
      Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-07-31 10:03 -0700
        Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-01 05:26 -0700
          Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-01 07:29 -0700
            Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-02 01:32 -0700
              Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-02 05:10 -0700
                Re: "Najbardziej imponujący kod, jaki widziałem" AK <nobody@nowhere.net> - 2019-08-03 06:52 +0200
                  Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-03 00:55 -0700
                    Re: "Najbardziej imponujący kod, jaki widziałem" AK <nobody@nowhere.net> - 2019-08-08 00:44 +0200
                      Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-08 00:06 -0700
                        Re: "Najbardziej imponujący kod, jaki widziałem" AK <nobody@nowhere.net> - 2019-08-08 17:44 +0200
                          Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-08 13:04 -0700
                Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-03 12:51 -0700
                  Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-03 15:37 -0700
                    Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-04 13:57 -0700
                      Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-05 03:44 -0700
                        Re: "Najbardziej imponujący kod, jaki widziałem" Roman Tyczka <noemail@because.no> - 2019-08-05 14:35 +0200
                          Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-05 05:58 -0700
                        Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-05 13:29 -0700
                          Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-06 01:55 -0700
                            Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-06 13:57 -0700
                              Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-07 00:39 -0700
                                Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-07 01:09 -0700
                                  Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-07 02:10 -0700
                                    Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-07 05:02 -0700
                                      Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-07 07:43 -0700
                                        Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-07 13:32 -0700
    Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-08-06 15:31 +0200
      Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-06 06:45 -0700
        Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-08-06 16:32 +0200
          Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-06 07:39 -0700
            Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-08-06 16:57 +0200
              Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-06 08:20 -0700
            Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-08-06 17:01 +0200

Page 1 of 3  [1] 2 3  Next page →

#32762 — "Najbardziej imponujący kod, jaki widziałem"

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

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

[toc] | [next] | [standalone]

#32763

Dnia Tue, 30 Jul 2019 06:58:03 -0700 (PDT), godek.maciek@gmail.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-Godek
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#32764

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

> Dnia Tue, 30 Jul 2019 06:58:03 -0700 (PDT), godek.maciek@gmail.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-Godek
>> 
>> 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

[toc] | [prev] | [next] | [standalone]

#32765

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,

[toc] | [prev] | [next] | [standalone]

#34749

On 2019-07-31, Roman Tyczka <noemail@because.no> wrote:
>> 
>> 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 :-)
>

stare maszynki fajne byly. Teraz tak przypomnialem sobie te dema jakie
mozna bylo pozapuszczac. Grafa nie powalala ale dzwieki robily zajebisty
klimat.
U mnie nie Amiga ale Atari ST hulalo.
Czasy super, bajtki PCWorldy i tak jak piszesz, cokolwiek wyslac to
Poczta Polska, czasy przed internetowe :-)

--
Thank You
Bischoop

[toc] | [prev] | [next] | [standalone]

#32766

> https://www.quora.com/Can-you-explain-to-non-coders-the-most-impressive-code-youve-seen/answer/Panicz-Godek
> 
> 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

[toc] | [prev] | [next] | [standalone]

#32767

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

[toc] | [prev] | [next] | [standalone]

#32768

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"

[toc] | [prev] | [next] | [standalone]

#32775

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-autocompleter-deep-tabnine-ai-deep-learning-smart-compose

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

[toc] | [prev] | [next] | [standalone]

#32772

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

[toc] | [prev] | [next] | [standalone]

#32776

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

[toc] | [prev] | [next] | [standalone]

#32778

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

[toc] | [prev] | [next] | [standalone]

#32781

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

[toc] | [prev] | [next] | [standalone]

#32782

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

[toc] | [prev] | [next] | [standalone]

#32783

On 2019-08-02 14:10, godek.maciek@gmail.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

[toc] | [prev] | [next] | [standalone]

#32784

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.

[toc] | [prev] | [next] | [standalone]

#32815

On 2019-08-03 09:55, godek.maciek@gmail.com wrote:
> 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. 

vec[-2], vec[-1] = vec[-1], vec[-2]

Tak sie to robi w _normalnym_ jezyku programowania, a nie jakies szmuje
buje z kompletnie nieczytelnym pattern matchingiem do tak prostackiej 
wrecz operacji.

AK

[toc] | [prev] | [next] | [standalone]

#32816

> vec[-2], vec[-1] = vec[-1], vec[-2]
> 
> Tak sie to robi w _normalnym_ jezyku programowania

W Wolframie jest nieco dłużej:

{vec[[-2]], vec[[-1]]} = {vec[[-1]], vec[[-2]]}

ale idea jest zachowana. Tak czy inaczej chodzi o fundament: lista musi być strukturą liniową z dostępem swobodnym a nie jakąś rekurencyjną matrioszką.

Niektóre języki odróżniają listy od tablic pod względem tego swobodnego dostępu, ale to jest rozróżnienie niskopoziomowe, przydatne powiedzmy w C/C++ lub w Adzie, ale kompletnie nieużyteczne w takich językach jak Python czy Wolfram.

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

[toc] | [prev] | [next] | [standalone]

#32821

On 2019-08-08 09:06, Maciej Sobczak wrote:
>> vec[-2], vec[-1] = vec[-1], vec[-2]
>>
>> Tak sie to robi w _normalnym_ jezyku programowania
> 
> W Wolframie jest nieco dłużej:
> 
> {vec[[-2]], vec[[-1]]} = {vec[[-1]], vec[[-2]]}

Dopuszczalnie. Nie ma o co kopii kruszyc (choc Wolframa nie lubie
bo zbyt Lispowaty i malo obiektowy - ale dobrze - j.w. - ze nie
"dogmatycznie" Lispowaty). Jest czytelne.

> ale idea jest zachowana. Tak czy inaczej chodzi o fundament: lista musi być strukturą liniową z dostępem swobodnym a nie jakąś rekurencyjną matrioszką.

Janiej/trafniej juz nie mozna :)

> 
> Niektóre języki odróżniają listy od tablic pod względem tego swobodnego dostępu, ale to jest rozróżnienie niskopoziomowe, przydatne powiedzmy w C/C++ lub w Adzie, ale kompletnie nieużyteczne w takich językach jak Python czy Wolfram.

No niekoniecznie. Tzn "metodycznie" masz racje, ale wydajnosciowo
juz mniej. W Pythonie istnieje standardowa struktura typu tablice
- array() - o okreslonym i i stalym (w przeciwienstwie do list) -
typie danych, czyli zdecydowanie wydajniejsza ok (linked)list,
Oczywiscie obluga obu jest taka sama/bardzo podobna.

PS: Nalezy tez wspomniec o numpy arays.

AK

[toc] | [prev] | [next] | [standalone]

#32822

> No niekoniecznie. Tzn "metodycznie" masz racje, ale wydajnosciowo
> juz mniej. W Pythonie istnieje standardowa struktura typu tablice
> - array() - o okreslonym i i stalym (w przeciwienstwie do list) -
> typie danych, czyli zdecydowanie wydajniejsza ok (linked)list,
> Oczywiscie obluga obu jest taka sama/bardzo podobna.

OK. Dla porównania, Wolfram oferuje tablice przeznaczone do pracy z typami numerycznymi:

https://reference.wolfram.com/language/ref/NumericArray.html

oraz ByteArray.
Służą do optymalizacji czasu obliczeń, zajętości pamięci (są zawsze spakowane) i do komunikacji z modułami napisanymi w C. Te tablice to naprawdę tablice, takie jak w C, żadnych dekoracji. Ale zestaw dostępnych typów jest z góry ograniczony.

To są jednak niskopoziomowe narzędzia, chociaż ich interfejs jest taki sam jak normalnej listy.

W Wolframie chodzi jednak o coś szerszego - lista to nie tylko {a,b,c}. Wszystko ma wewnętrznie taką samą postać, więc skoro {a,b,c} to w rzeczywistości List[a,b,c], to podobnie np. a+b+c to w rzeczywistości Plus[a,b,c]. I taki Plus ma te same mechanizmy dostępu co List, bo z punktu widzenia indeksowania to jest taka sama struktura danych. Czyli np.:

{a, b, c}[[2]]

b

(a + b + c)[[2]]

b

whatever[a, b, c][[2]]

b

Ciekawostka - indeksowanie tych struktur jest od 1, natomiast 0 jest indeksem specjalnym, który oznacza "głowę" całej konstrukcji:

{a, b, c}[[0]]

List

(a + b + c)[[0]]

Plus

whatever[a, b, c][[0]]

whatever

Wszystko działa tak samo i to jest ta "nieortodoksyjna LISPowatość" Wolframa, która ułatwia metaprogramowanie i przetwarzanie symboliczne. Nie ma natomiast żadnych gwarancji co do wewnętrznej implementacji tych struktur. Czy to są tablice, czy listy z dodatkowym indeksem czy jeszcze jakieś inne hashmapy - nie wiemy.

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | pl.comp.programming

csiph-web