🚀 go-pugleaf

W dniu środa, 25 stycznia 2017 07:36:54 UTC+1 użytkownik markfal...@gmail.com napisał:
> On Tuesday, January 24, 2017 at 1:08:30 PM UTC+1, godek....@gmail.com wrote:
> 
> > Non sequitur, tym bardziej, że są języki (takie jak np. Python
> > albo w pewnej mierze Haskell), które są raczej czytelne nawet dla osób,
> > które nigdy wcześniej nie programowały
> 
> Dokładnie. Na temat nieczytelności nawiasów Common Lispie
> w pewnych sytuacjach, wypowiadał się nawet twórca Clojure.

Z Hickeyem nie zgadzam się pod wieloma względami.
Moim zdaniem czyteność języka wcale się nie poprawia,
jak się wprowadza do języka wiele nawiasów, które w różnych
kontenstach oznaczają różne rzeczy. To wymaga tylko więcej
zapamiętywania i jest frustrujące.

Raczej sytuację mógłby uratować dobry edytor typografizujący,
żeby każdy programista mógł wyświetlać kod stosownie do swoich
upodobań.

> Stąd w Clojure wektory, przekazywanie argumentów funkcji
> w nawiasach kwadratowych itd.

Z tego co wiem (a coś tam kiedyś w Clojure pisałem), aplikacja
funkcji jest w nawiasach okrągłych, tzn. piszesz (f x y ...)
-- tak jak we wszystkich lispach.

Przy definiowaniu funkcji używa się nawiasów kwadratowych, tzn.
pisze się (defn f [x y] ...) (w najprostszym wariancie)

W Common lispie pisze się
(defun f (x y) ...), co wydaje się równie dziwaczne, zważywszy
na asymetrię między definicję a użyciem. Moim zdaniem tylko Scheme
robi to dobrze, tzn. jeżeli napiszesz (define (f x) cośtam/x), to
(f x) rzeczywiście oznacza cośtam/x.
Tak czy inaczej, nie widzę, w jaki sposób rozwiązanie w Clojure
miałoby być lepsze niż w Common Lispie.

Tak samo, jeżeli idzie o formę let. O ile zgadzam się, że domyślne
zachowanie let powinno być sekwencyjne (czyli jak let* w CL/Scheme),
to nie widzę, dlaczego pisanie (let [a 5 b 10] ...) miałoby być
czytelniejsze niż (let ((a 5) (b 10)) ...).

> Jak dla mnie bolączką Common Lispa jest przede wszystkim uboga
> biblioteka standardowa, uboga ilość bibliotek w porównaniu
> z Pythonem, Ruby, Javą, a nawet Perlem (coś jak Pypi, CPAN, RubyGems),

Dla mnie największe bolączki Pythona to nadmiar wersji, oraz genialny
pomysł Guido, żeby rozbić kompatybilność pomiędzy pythonem 2 i 3
(najbardziej idiotyczna fanaberia w dziejach współczesnej informatyki)
-- a szkoda, bo istnieją naprawdę fajne projekty, jak choćby Enaml
(którego postawienie jest jednak groteskowo trudne np. na OS X)

Co do pakietów to niby jest Quicklisp; ja tam zresztą nie wiem
-- i tak zazwyczaj sam rozwijam swoje biblioteki (no ale to w Schemie).

Zresztą chyba Garret Smith żartował, że menadżerem pakietów Erlanga
jest Github.

> brak tzw "killer apps", które spowodują, że dużo ludzi po prostu będzie
> chciało przesiąść się na Lispa i rozwijać jego klocki, bo nie zrobi
> "czegoś" tak wygodnie i fajnie jak w Common Lispie (czyli np. boom
> jaki był z Railsami w pewnym czasie, albo dzisiaj jest z Node.js
> i Angularem dla JS'a).

Tzn. chodzi o to, że nie ma na Common Lispa głupiej mody. Zgoda, 
pewnie nigdy nie będzie, Common Lisp nie jest dla owiec.
Z drugiej strony, jeżeli warto to robić, przepisanie
aplikacji z Pythona na Common Lisp jest raczej łatwe, a zysk
wydajności potrafi być nawet o kilka rzędów wielkości.

> Poza tym rozdrobnienie środowiska na kilka
> odmian Common Lispów (z czego najbardziej popularny CLisp jest sprzed 6 lat).

Takie samo rozdrobnienie środowiska masz w Pythonie (bo różne wersje)
i w JavaScripcie (bo różne przeglądarki)