🚀 go-pugleaf

W dniu piątek, 27 stycznia 2017 11:55:09 UTC+1 użytkownik pawel...@gmail.com napisał:
> Maciek Godek w którymś z wątków stwierdził, że nie przepada za Common Lispem (i że już lepszym wyborem pewnie byłoby Clojure dzisiaj), bo pewne rzeczy niewygodnie w CL implementować.

Gwoli ścisłości, stwierdziłem, że nie przepadam za Common Lispem
(jako językiem). Nie twierdzę, że jest niewygodny; może nawet być
bardzo wygodny, ale nie podoba mi się jego stopień komplikacji.

> Trochę się macam z podstawiami Clojure właśnie i mam w związku z tym pytanie.
> Poza oczywiście zaletą, że Clojure działa na JVM, ma dobre mechanizmy wspierające skalowalność, to nie jest też tak że jednak trochę utrudnia programiście?
> CL daje swobodę i jest raczej multiparadygmatowy, a Clojure mimo wszystko wymusza programowanie funkcyjne, wszystkie struktury danych domyślnie są immutable, brakuje jakiegoś modelu obiektowego jak CLOS itd.

Tak, Common Lisp daje programiście nieograniczone możliwości.
Dlatego też Paul Graham nazywa go "programowalnym językiem programowania".
Wadą tej wolności jest to, że każdy programista może wytworzyć swój
"prywatny język", i mimo że programiści Common Lispa w pojedynkę potrafią
być bardzo efektywni, w wielu przypadkach współpraca między nimi
może graniczyć z niemożliwością. Myślę, że to owa kodyfikacja sposobu
pisania programów, tzw "one way to do it", jest głównym źródłem sukcesu
Pythona, i że owa "ograniczoność" Clojure to dobra rzecz. Tym bardziej,
że programy funkcyjne, choć mogą być trudniejsze do napisana, z reguły
okazują się prostsze w analizie (pomijając nawet kwestię skalowalności)

> A druga sprawa, czy w związku z tym, że w Clojure jednak składnia
> lekko odbiega od CL'a (poza listami są wektory i wszelkie [], {})
> to nadal na wyższym poziomie zachowana jest ta homoikoniczność
> i elastyka?

Owa różnorodność składniowa, poza tym, że komplikuje język, a koncepcyjnie
nie wnosi zupełnie nic, raczej nie zaburza homoikoniczności.


Od razu odpowiem na ewentualny zarzut: to, że mamy osobną składnię
do tworzenia tablic haszujących, wektorów i zbiorów, jest pewną optymalizacją,
bo nie umiemy robić niektórych rzeczy lepiej. Koncepcyjnie nie ma różnicy,
czy zapiszę słownik jako {:a 1 :b 2} czy jako '((a 1) (b 2)) -- w obu
przypadkach zawartość informacyjna jest ta sama. Różnica jest taka, że
w pierwszym przypadku podpowiadam kompilatorowi, jakiej struktury danych
powinien użyć. Podobnie, nie ma znaczenia, czy zapiszę zbiór jako #{1 2 3}
czy jako '(1 2 3) -- to, że owo coś jest zbiorem, wynika z operacji,
które będę na tym przeprowadzał. Hickey popełnia błąd koncepcyjny, mieszając
struktury danych z ich reprezentacjami (i z tej perspektywy atakuje Scheme'a,
za to, że "używa archaicznych łączonych list", ale ten atak raczej nie ma
sensu, z tego powodu, że McCarthy zdefiniował tylko interfejs do list, tj.
cons, car i cdr, i chociaż implementacja, którą podał, faktycznie opierała
się na listach łączonych, nie narzucił na nikogo obowiązku stosowania tej
właśnie, a nie innej struktury danych)