Post by Maciej SobczakPost by g***@gmail.comhttps://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ł.
"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.
Post by Maciej SobczakCzytanie 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.
Post by Maciej SobczakZwł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.
Post by Maciej Sobczak"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.
Post by Maciej SobczakA 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ć.
Post by Maciej SobczakCzy 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.
Post by Maciej SobczakZaletą 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:
Post by Maciej SobczakSam artykuł oczywiście, jak zwykle, zniechęca do LISPa.
Powiedz coś więcej na ten temat. W jaki sposób zniechęca?
Post by Maciej SobczakJak 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.
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?
Post by Maciej Sobczakonly[condition_, list_] := Map[
Function[x,
If[condition[x], x, Nothing]
],
list
]
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?
Post by Maciej SobczakOczywiś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?
Post by Maciej SobczakI 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.
Post by Maciej SobczakmyIf[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.