🚀 go-pugleaf

W dniu wtorek, 17 stycznia 2017 20:36:05 UTC+1 użytkownik pawel...@gmail.com napisał:

> 
> Wiadomo że trzeba zmienić podejście w myśleniu o strukturach danych, ale czy Waszym zdaniem osoba która chce programować w takim F#, OCaml czy Haskellu powinna wziąć korki z matmy i poznać dobrze np. wspomniany rachunek lambda w matematyce?


Cześć.
Co do korków z matmy, to wydają się dziwnym pomysłem. Chyba
że byś chciał np. odświeżyć sobie pochodne funkcji, gdybyś tworzył
np. program do różniczkowania symbolicznego.
Jeżeli idzie o rachunek lambda, to jeżeli się zajmuje językiem
z perspektywy akademickiej, oczywiście warto go znać, ale w praktyce
w programowaniu w ogóle nie jest potrzebny i należy go traktować
raczej jako ciekawostkę (tzn. numerały Churcha czy kombinatory
punktu stałego uświadamiają, jak niewiele jest potrzebne do przeprowadzenia
dowolnego obliczenia, ale nie pomagają w codziennej praktyce). 

Jeśli Cię to ciekawi, to tutaj jest opracowane w dość przystępny sposób:

http://www.cl.cam.ac.uk/teaching/Lectures/funprog-jrh-1996/

Ale bez tego można programować równie dobrze, a nawet lepiej.

Co do funkcyjnego podejścia, to najlepsza książka, z jaką miałem styczność,
to "Struktura i Interpretacja Programów Komputerowych" (angielska wersja
jest dostępna tu: https://mitpress.mit.edu/sicp/full-text/book/book.html)

Osobiście sądzę, że ta książka reprezentuje najzdrowsze podejście
do programowania. Jest też np. książka Byrda i Wadlera, która jednak
w moim odczuciu jest mocno niepraktyczna (aczkolwiek przeglądałem
ją tylko pobieżnie).

Tak czy inaczej, moim zdaniem programowanie funkcyjne to jest przede
wszystkim zdrowa dyscyplina przy projektowaniu programów (nabiera
znaczenia zwłaszcza przy większych programach, gdzie niespójność
kodu utrudnia wnioskowanie i rozbudowywanie), oraz narzędzie ekspresji,
i można ją uprawiać nawet w językach niefunkcyjnych, jak C czy Python.
Najważniejsze jest to, żeby pisać programy. 

W dniu wtorek, 17 stycznia 2017 23:14:31 UTC+1 użytkownik godek....@gmail.com napisał:

> Tak czy inaczej, moim zdaniem programowanie funkcyjne to jest przede
> wszystkim zdrowa dyscyplina przy projektowaniu programów (nabiera
> znaczenia zwłaszcza przy większych programach, gdzie niespójność
> kodu utrudnia wnioskowanie i rozbudowywanie), oraz narzędzie ekspresji,
> i można ją uprawiać nawet w językach niefunkcyjnych, jak C czy Python.
> Najważniejsze jest to, żeby pisać programy.

Wielkie dzięki za szybką odpowiedź (bałem się, że grupa zupełnie umarła). Moje pytanie wynikało stąd, że nie pamiętam tych wszystkich matematycznych podstaw rachunku lambda, czy "zwijania/rozwijania" funkcji - i byłem ciekaw, czy znajomość tego od strony matematycznej, np. wyraźnie ułatwia programowanie funkcyjne czy pozwala np. szybciej rozwiązać jakiś problem przy użyciu rekurencji... 

Jeśli piszesz że matematyka nie jest tu jakoś szczególnie istotna, tylko załapanie paradygmatu to oczywiście dobra wiadomość dla mnie :) Książkę SICP zamówiłem sobie w polskiej wersji na stronie PWN (co prawda dotyczy Scheme, ale zakładam że do OCaml/F# to głównie inna składnia, silne typowanie i niuanse, które na ogólne zrozumienie nie powinny mieć wpływu).

W dniu środa, 18 stycznia 2017 10:16:01 UTC+1 użytkownik pawel...@gmail.com 
> 
> Wielkie dzięki za szybką odpowiedź (bałem się, że grupa zupełnie umarła). 

Mnie też się zdawało, że umarła -- ostatni post pochodzi sprzed 4 lat
i do dziś nie doczekał się odpowiedzi -- dlatego byłem w szoku, jak zobaczyłem,
że ktoś coś tu zapostował, i w pierwszej chwili byłem przekonany, że to spam :)

No, ale kto wie, może właśnie ożyła

> Moje pytanie wynikało stąd, że nie pamiętam tych wszystkich matematycznych podstaw rachunku lambda, czy "zwijania/rozwijania" funkcji - i byłem ciekaw, czy znajomość tego od strony matematycznej, np. wyraźnie ułatwia programowanie funkcyjne czy pozwala np. szybciej rozwiązać jakiś problem przy użyciu rekurencji... 

Tzn. jeżeli idzie o folda i unfolda, to przyznam, że bardzo długo ich
unikałem, bo zawsze najważniejsza była czytelność/łatwość zrozumienia kodu.
Sytuację zmieniło to, jak uświadomiłem sobie, że (nieco upraszczając)

  fold(*, [a1, a2, ..., aN])

to po prostu

  a1 * a2 * ... * aN


> Jeśli piszesz że matematyka nie jest tu jakoś szczególnie istotna, tylko załapanie paradygmatu to oczywiście dobra wiadomość dla mnie :) Książkę SICP zamówiłem sobie w polskiej wersji na stronie PWN (co prawda dotyczy Scheme, ale zakładam że do OCaml/F# to głównie inna składnia, silne typowanie i niuanse, które na ogólne zrozumienie nie powinny mieć wpływu).

Jeżeli idzie o użycie Scheme'u w SICP, to ta decyzja była
swego czasu krytykowana przez Wadlera

https://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf

ale w moim odczuciu po prostu nie załapał :)

W każdym razie Scheme to bardzo prosty język, i jest w SICP
wytłumaczony bardzo dobrze (choć książka jest raczej wymagająca).
Oczywiście nic nie stoi na przeszkodzie, żeby zadania rozwiązywać
w Swoim Ulubionym Języku (przynajmniej dopóki system typów
nie wchodzi w paradę)

W dniu środa, 18 stycznia 2017 13:37:16 UTC+1 użytkownik godek....@gmail.com 
> W każdym razie Scheme to bardzo prosty język, i jest w SICP
> wytłumaczony bardzo dobrze (choć książka jest raczej wymagająca).
> Oczywiście nic nie stoi na przeszkodzie, żeby zadania rozwiązywać
> w Swoim Ulubionym Języku (przynajmniej dopóki system typów
> nie wchodzi w paradę)

A tak z ciekawości, Ty używasz Racket Scheme właśnie? Z tego co widziałem, to środowisko jest bardzo miłe, wychodzą nowe wersje (racket-lang.org), tyle że sami twórcy przyznają, że środowisko jest stworzone z myślą o "początkujących studentach". Czy do bardziej poważnych, produkcyjnych rzeczy "schemowcy" używają raczej Lispa, czy również jakiegoś środowiska Scheme? Wiesz.. pytam pod kątem tego, że gdybym potrzebował np. za jakiś czas zrobić klienta, który pobierze mi dane z usługi REST, w wygodny sposób przetworzy jsona itp, to żeby nie trafić na ścianę pt "kompletny brak bibliotek".

W dniu czwartek, 19 stycznia 2017 09:53:14 UTC+1 użytkownik pawel...@gmail.com napisał:
> W dniu środa, 18 stycznia 2017 13:37:16 UTC+1 użytkownik godek....@gmail.com 
> > W każdym razie Scheme to bardzo prosty język, i jest w SICP
> > wytłumaczony bardzo dobrze (choć książka jest raczej wymagająca).
> > Oczywiście nic nie stoi na przeszkodzie, żeby zadania rozwiązywać
> > w Swoim Ulubionym Języku (przynajmniej dopóki system typów
> > nie wchodzi w paradę)
> 
> A tak z ciekawości, Ty używasz Racket Scheme właśnie?

Ja głównie używam Guile Scheme z poziomu Emacsa.
Jeśli jesteś ciekaw, możesz zerknąć na mój ("Panicz Godek") wpis
w serwisie Quora:
https://www.quora.com/Which-LISP-implementation-will-be-useful-for-run-of-the-mill-problems

> Z tego co widziałem, to środowisko jest bardzo miłe,
> wychodzą nowe wersje (racket-lang.org), tyle że sami twórcy
> przyznają, że środowisko jest stworzone z myślą o "początkujących
> studentach".

Jak czasem zdarza mi się uczyć różne osoby Scheme'u, to rzeczywiście
używam dra Racketa, bo Emacs sam w sobie nie jest zbyt przyjazny dla
początkujących. Ale osobiście raczej bym nie zdzierżył używania tego
środowiska do celów produkcyjnych (co innego sam język/implementacja
-- tutaj raczej nie mam zastrzeżeń). Kiedyś korzystałem z Racketowego
steppera makr, żeby lepiej ogarnąć, jak działa system makr syntax-case.

> Czy do bardziej poważnych, produkcyjnych rzeczy
> "schemowcy" używają raczej Lispa, czy również jakiegoś środowiska
> Scheme?

Ostatnio doszło do pewnego przełomu, bo Kent Dybvig upublicznił źródła
swojego kompilatora Chez, którego wydajność jest chyba na poziomie
najlepszych Common Lispów (i w niektórych benczmarakach rzeczywiście
uzyskiwałem przyspieszenie rzędu 10x w porównaniu do Guile 2.0, którego
jednak główną zaletą nie jest wydajność, ale wygoda użycia i dokumentacja)

> Wiesz.. pytam pod kątem tego, że gdybym potrzebował np.
> za jakiś czas zrobić klienta, który pobierze mi dane z usługi REST,
> w wygodny sposób przetworzy jsona itp, to żeby nie trafić na ścianę
> pt "kompletny brak bibliotek".

Jakiś rozwiązania na pewno znajdziesz. Z takich praktycznych, to Racket
może rzeczywiście być dobrą opcją, bo tam nawet na stronie kiedyś mieli
jakieś jednolinijkowe serwery. Zresztą jeżeli idzie o samą naukę, to sądzę,
że pod względem jakości materiałów edukacyjnych Racket nie ma sobie
równych (jak choćby książka http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html albo kurs "Introduction to Systematic Program Design", kiedyś
na Courserze, a teraz zdaje się w edX), ale co do praktycznej interakcji
ze Schemem, to raczej polecam Emacsa, bo to jest zupełnie inna jakość
programowania (Clojure miał kiedyś edytor LightTable podobny w duchu,
ale chyba już nierozwijany)

Tak czy siak, nauka podstaw Scheme'u to najwyżej kilka godzin (Abelson
i Sussman porównują to do nauki ruchów szachowych, ale tak naprawdę ruchy
w szachach są dużo bardziej skomplikowane)

Gdybyś chciał sobie zerknąć, to napisałem na zaliczenie projektu na studiach
książeczkę o tzw. "inteligencji obliczeniowej" w języku Scheme:

http://panicz.github.io/pamphlet/

W dniu czwartek, 19 stycznia 2017 14:17:16 UTC+1 użytkownik godek....@gmail.com napisał:
> Gdybyś chciał sobie zerknąć, to napisałem na zaliczenie projektu na studiach
> książeczkę o tzw. "inteligencji obliczeniowej" w języku Scheme:
> 
> http://panicz.github.io/pamphlet/

Dzięki :) Poczytałem, zapoznałem się. Poczytałem również trochę o F#, o Clojure, o Common Lisp i teraz to mam dopiero mętlik ;)

Z jednej strony F# wydaje się ciekawy bo ma bardzo prostą, "czystą" i przejrzystą składnię wzorowaną na OCaml, z pewnymi najciekawszymi rozwiązaniami z Haskella. Mam silne typowanie, mam dostęp do ekosystemu .Net i Mono (całośc jest open source), do dziesiątków frameworków generujących JavaScript, wizualizujących dane itp itd. Nie ma różnych zaciemniających makr itd, jest potężne wsparcie Microsoftu i społeczności open source.

Z drugiej strony fajna i "hipsterska" jest składnia lispowa, a taki Clojure z kolei ma dostęp do nie mniej potężnego ekosystemu Javy :) Społeczność też prężna. Tyle że tutaj dochodzi właśnie sporo zagadnień, które pewnie mogą być dużym utrudnieniem w nauce (makra, transduktory (odmiana funkcji redukujących), poężna retrospektywność języka)...

Ponieważ masz duże doświadczenie w Scheme (a w końcu to pewna odmiana/podzbiór Lispa) i pewnie masz styczność ze środowiskiem "lispowatych" języków, to pozwolę sobie jeszcze dopytać o dwie kwestie:

1. Zakładając że wybrałbym Common Lispa lub Clojure (CL dla Javy), to czy faktycznie jest tak, jak się o Lispach mówi, że "w F# człowiek "rozwiązuje problem", a w rodzinie lispów "pisze się kod, który wygeneruje program, który rozwiąże problem"? Czyli dochodzi kolejna warstwa abstrakcji, która uwzględniając jeszcze makra i różne "meta-programowanie" mocno utrudnia naukę?

2. O co chodzi z tym twierdzeniem zwolenników Common Lispa, że nauka Scheme "utrudnia naukę Lispa" i generalnie z tą małą "świętą wojenką"? Jak tak czytam, to Scheme wygląda mi po prostu na uproszczonego Lispa. Czy w CL jest jakieś inne podejście/niuanse/wyraźne różnice, że tak się "odgradzają" od Scheme? Pytam z czystej ciekawości, bo zakładam że nie jestem świadomy wielu kwestii. Byłbym ogromnie wdzięczny za jakieś wyjaśnienie, bo pewnie i dla "potomnych newbies" się przyda ;)

pozdrawiam

W dniu niedziela, 22 stycznia 2017 14:07:16 UTC+1 użytkownik pawel...@gmail.com napisał:

> > Gdybyś chciał sobie zerknąć, to napisałem na zaliczenie projektu na studiach
> > książeczkę o tzw. "inteligencji obliczeniowej" w języku Scheme:
> > 
> > http://panicz.github.io/pamphlet/
> 
> Dzięki :) Poczytałem, zapoznałem się. Poczytałem również trochę o F#, o Clojure, o Common Lisp i teraz to mam dopiero mętlik ;)

Zupełnie niepotrzebnie ;]

> Z jednej strony F# wydaje się ciekawy bo ma bardzo prostą,
> "czystą" i przejrzystą składnię wzorowaną na OCaml, z pewnymi
> najciekawszymi rozwiązaniami z Haskella. Mam silne typowanie,
> mam dostęp do ekosystemu .Net i Mono (całośc jest open source),
> do dziesiątków frameworków generujących JavaScript, wizualizujących
> dane itp itd. Nie ma różnych zaciemniających makr itd, jest
> potężne wsparcie Microsoftu i społeczności open source.

W F# podoba mi się feature zwany "Type Providers". Ogólnie wygląda tak,
że wsparcie dla F# w Visual Studio jest bardzo fajne, i bardzo dużo
ułatwia. [Że jednak ja sam mam ze współpracą z oprogramowaniem
Microsoftu raczej umiarkowane doświadczenie, to nie mogę służyć
żadnymi wskazówkami. Wiem tylko, że na Lambda Days było parę ciekawych
prezentacji -- możesz wyszukać na youtubie "Evelina Gabasova" albo
"Tomas Petricek", bo z tego co pamiętam, oni sporo o tym opowiadali]

> Z drugiej strony fajna i "hipsterska" jest składnia lispowa,
> a taki Clojure z kolei ma dostęp do nie mniej potężnego
> ekosystemu Javy :) Społeczność też prężna. Tyle że tutaj
> dochodzi właśnie sporo zagadnień, które pewnie mogą być
> dużym utrudnieniem w nauce (makra, transduktory (odmiana
> funkcji redukujących), poężna retrospektywność języka)...

Mnie trochę drażni niejednorodna składnia Clojure, ale poza
tym czerpie bardzo dużo zarówno ze Scheme'u, jak i Common Lispa.

Co do transduktorów, to one się w głównej mierze opierają
na foldzie. Leniwa ewaluacja opiera się zaś bezpośrednio
tym, co zostało wyłożone w 3-cim rozdziale SICP ("strumienie").

> Ponieważ masz duże doświadczenie w Scheme (a w końcu to pewna
> odmiana/podzbiór Lispa) i pewnie masz styczność ze środowiskiem
> "lispowatych" języków, to pozwolę sobie jeszcze dopytać o dwie kwestie:
> 
> 1. Zakładając że wybrałbym Common Lispa lub Clojure (CL dla Javy),
> to czy faktycznie jest tak, jak się o Lispach mówi, że
> "w F# człowiek "rozwiązuje problem", a w rodzinie lispów
> "pisze się kod, który wygeneruje program, który rozwiąże problem"?
> Czyli dochodzi kolejna warstwa abstrakcji, która uwzględniając
> jeszcze makra i różne "meta-programowanie" mocno utrudnia naukę?

Nie wiem. Dla mnie raczej ułatwia, niż utrudnia. Zazwyczaj
najpierw staram się opisać problem, który chcę rozwiązać,
a później "wyjaśnić" ewaluatorowi Lispa terminy użyte w opisie
problemu.
Jeżeli idzie o makra, to używam ich bardzo rzadko. Zazwyczaj wtedy,
kiedy chcę dodać jakąś ogólną konstrukcję do języka, bo mi jej brakuje.

Z pewnością dużo wygodniej operuje się na lispowych językach,
jak się ma odpowiedni edytor. Wówczas wszystko, co ma inną składnię,
wydaje się strasznie archaiczne i toporne. (Z drugiej strony,
do bazgrania na tablicy albo w zeszycie składnia Haskella wydaje się
nie mieć sobie równych. Powiedziałbym, że Lisp jest minimalistyczny
składniowo, a Haskell jest minimalistyczny notacyjnie)

Na pewno Lisp daje na programowanie taką perspektywę, że zaczynasz
widzieć wszystko inne jako "nieudolne nakładki składniowe na Lispa"

Ciekawą rzecz też powiedział David Nolen, że nauka SICP nauczyła
go patrzeć na języki programowania nie jak coś danego z góry,
ale coś, co można tworzyć i zmieniać samemu.

> 2. O co chodzi z tym twierdzeniem zwolenników Common Lispa,
> że nauka Scheme "utrudnia naukę Lispa" i generalnie z tą małą
> "świętą wojenką"? Jak tak czytam, to Scheme wygląda mi po prostu
> na uproszczonego Lispa. Czy w CL jest jakieś inne
> podejście/niuanse/wyraźne różnice, że tak się "odgradzają"
> od Scheme? Pytam z czystej ciekawości, bo zakładam że nie 
> jestem świadomy wielu kwestii. Byłbym ogromnie wdzięczny
> za jakieś wyjaśnienie, bo pewnie i dla "potomnych newbies" się przyda ;)

Co do "świętych wojenek", to staram się raczej trzymać od nich
z daleka. Na pewno między Common Lispem a Schemem są spore różnice
kulturowe (pomimo że oba języki mają "tego samego tatusia").
W moim odczuciu kultura Scheme'u raczej promuje programowanie funkcyjne, zaś
kultura Common Lispa ma do programowania funkcyjnego raczej ambiwalentny
stosunek. Kultura Common Lispa wysoko stawia efektywność pojedynczego
programisty, zaś kultura Scheme'u raczej akcentuje zrozumiałość kodu
i komunikowanie idei. Z tego powodu programiści Common Lispa (oraz Clojure)
chętniej szafują makrami na lewo i prawo.
Na pewno istotną różnicą między Common Lispem a Schemem jest CLOS.
Niektóre implementacje Scheme'u dostarczają jakieś swoje różne zamienniki,
ale CLOS jest ustandaryzowany.

Ja jednak nie przepadam za CLOS. (Już zdecydowanie bardziej podobają
mi się protokoły w Clojure)