🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.lang.funkcyjne
Article #977

Re: Języki funkcyjne (F#, Clojure, OCaml) a kwestia "wyższej" matematyki, rachunku lambda itd

#977
From: godek.maciek
Date: Sun, 22 Jan 2017 16:54
97 lines
7091 bytes
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)
Technical Details
Message-ID: <91a7051b-b153-4887-a3a4-d7dbb99c5b64@googlegroups.com>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!news.nask.pl!news.nask.org.pl!news.unit0.net!news.glorb.com!r185no1445398ita.0!news-out.google.com!78ni2479itm.0!nntp.google.com!r185no1445389ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
References: <aebb68c4-f04b-4566-8d4a-1afb7e4173a7@googlegroups.com> <49078b6d-512c-4f39-a6c1-3e6f266c5061@googlegroups.com> <dc1fa4d0-6ea8-4fcf-a794-cbb6ecfac0ea@googlegroups.com> <6b0eaacc-8422-4bc9-be80-e3a652d6c417@googlegroups.com> <bd9a4de5-a6c2-449a-9bba-ca3a89d7c5ce@googlegroups.com> <d8924739-c7b7-4511-809a-29cc1a53f5e9@googlegroups.com> <9b2f9e9d-2e67-4b17-a5e6-9624c0c847c7@googlegroups.com>

Show Full Headers
Complete Article Headers
X-Received: by 10.157.37.60 with SMTP id k57mr7439854otb.138.1485104091824;        Sun, 22 Jan 2017 08:54:51 -0800 (PST)
X-Received: by 10.157.35.89 with SMTP id k25mr2151844otd.11.1485104091783; Sun, 22 Jan 2017 08:54:51 -0800 (PST)
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!news.nask.pl!news.nask.org.pl!news.unit0.net!news.glorb.com!r185no1445398ita.0!news-out.google.com!78ni2479itm.0!nntp.google.com!r185no1445389ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: pl.comp.lang.funkcyjne
Date: Sun, 22 Jan 2017 08:54:51 -0800 (PST)
In-Reply-To: <9b2f9e9d-2e67-4b17-a5e6-9624c0c847c7@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=176.221.123.40; posting-account=f7iIKQoAAAAkDKpUafc-4IXhmRAzdB5r
NNTP-Posting-Host: 176.221.123.40
References: <aebb68c4-f04b-4566-8d4a-1afb7e4173a7@googlegroups.com> <49078b6d-512c-4f39-a6c1-3e6f266c5061@googlegroups.com> <dc1fa4d0-6ea8-4fcf-a794-cbb6ecfac0ea@googlegroups.com> <6b0eaacc-8422-4bc9-be80-e3a652d6c417@googlegroups.com> <bd9a4de5-a6c2-449a-9bba-ca3a89d7c5ce@googlegroups.com> <d8924739-c7b7-4511-809a-29cc1a53f5e9@googlegroups.com> <9b2f9e9d-2e67-4b17-a5e6-9624c0c847c7@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <91a7051b-b153-4887-a3a4-d7dbb99c5b64@googlegroups.com>
Subject: Re: Języki funkcyjne (F#, Clojure, OCaml) a kwestia
 "wyższej" matematyki, rachunku lambda itd
From: godek.maciek@gmail.com
Injection-Date: Sun, 22 Jan 2017 16:54:51 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit