🚀 go-pugleaf

W dniu środa, 25 stycznia 2017 13:24:24 UTC+1 użytkownik markfal...@gmail.com napisał:
> On Wednesday, January 25, 2017 at 11:55:45 AM UTC+1, godek....@gmail.com wrote:
> 
> > 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.
> 
> Ale wówczas może łatwiej dostrzec pewne elementy w gęstym kodzie, które
> normalnie (szczególnie jak kod jest kiepsko sformatowany i ktoś nie używa paredit i i innych wspomagaczy) mogą się ...zlewać? :)

Mnie ten argument nie przekonuje. Jeżeli idzie o wcięcia, to Emacs
zrobi je jednym skrótem klawiszowym w ułamku sekundy, podobnie wszystkie
pretty-printery. Oczywiście, ktoś może oczekiwać, że będzie się dało
pracować z Lispem "bez pomocy dodatkowych narzędzi", tyle że samo
wyświetlenie pliku wymaga już jakichś narzędzi. Ktoś mógłby argumentować,
że jednak narzędzia, które pozwalają na komfortową pracę w Pythonie
są dużo prostsze -- bo wystarczy np. notatnik. Jednak prawda jest taka,
że dla Lispa po prostu dużo łatwiej zaprojektować dużo lepsze narzędzia,
niż dla jakiegokolwiek języka.

Poza tym wydaje mi się, że ten gąszcz nawiasów uczy, jak lepiej
modularyzować oprogramowanie.

> A składnia i tak pozostaje minimalistyczna w stosunku do takiego
> chociażby Ruby.

Tylko tutaj nie chodzi o "minimalizm w stosunku do języka X",
a o pewną koncepcyjną prostotę, którą Clojure lekkomyślnie odrzuca
(nie żeby efekt był tragiczny. Z Clojure da się pracować, a niektóre
rzeczy są naprawdę super, choć ogólnie wydaje mi się, że to jest
język rozsądnego kompromisu w stosunku do czasów, w których powstawał)

> > 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)
> 
> Ale z drugiej strony bałagan w języku w dużej mierze wynikał z pewnej otwartości i popularności Pythona. Może gdyby Guido nie wykonał tego posunięcia, Python stałby się drugim, "bałaganiarskim" Perlem. A co dwóch gałęzi, to chyba też nie jest aż taki problem. W zasadzie 99% najważniejszych bibliotek jest już sportowana na wersję 3:
> 
> https://python3wos.appspot.com/

No dobrze, tylko jak wytłumaczyć tę zmianę najbardziej fanaberyjną,
tzn. że zamiast print x trzeba pisać print(x)? Rozumiem, że to było
motywowane spójnością, bo nie ma potrzeby wyróżniać wypisywania tekstu
jako szczególnego elementu składniowego języka. Ale przecież wystarczyłoby
dopuścić, żeby każdą funkcję można było wywołać bez nawiasów (tak jak
bez nawiasów można robić przypisania do krotek/list), i problemu by nie było.


> > 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.
> 
> Nie ma mody bo właśnie nie ma "killer apps". Wiesz, tu nie chodzi o hipsterską modę, czy "owce", tylko o parę tak dobrych rozwiązań, które spowodują, że ludzie (również świetni projektanci i programiści) zechcą używać Common Lispa, rozwijać jego możliwości i tworzyć ciekawe biblioteki/frameworki itp. Chodzi o porządny rozruch środowiska, który spowoduje że ludzie zechcą tego używać w szerszej skali, co się później przełoży na decyzje projektowe dużych firm, dostawców oprogramowania itd. Bez tego niestety język jest skazany na niszę, a w efekcie powolne obumieranie lub "tkwienie w miejscu" (na jedno wychodzi).

Oczywiście, język nie jest celem sam w sobie.
Jeżeli małe startupy mogą osiągnąć przewagę dzięki jakiejś technologii,
to pewnie prędzej czy później tak się stanie. Wydaje mi się, że w tej
akurat kwestii Clojure robi naprawdę dużo dobrego (tym bardziej, że
pozwala robić dobry użytek z wieloprocesowości)

> > 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.
> 
> No dobra, ale przy tym bogactwie gotowych bibliotek do Pythona, pisanie wielu rzeczy w Common Lispie nie byłoby zwykłym "przepisywaniem" tylko implementowaniem często bardzo złożonych rozwiązań. Przykładowo moja firma używa mocno zaawansowanych bibliotek Pythona do data miningu (m.in w takich bazach jak Sybase czy obiektowy GemStone) i do wizualizacji danych, generowania raportów. Inna zaprzyjaźniona firma, z której "napłynęli" do nas programiści Pythona, używa z kolei tego języka do dosyć złożonych zabaw z Geoserwerem (i generalnie do GIS'a). Gdybyś chciał teraz użyć do tych rzeczy Common Lispa, musiałbyś takie biblioteki praktycznie napisać, wygrzać, ustabilizować itd. 

Zgodzone

> > Takie samo rozdrobnienie środowiska masz w Pythonie (bo różne wersje)
> > i w JavaScripcie (bo różne przeglądarki)
> 
> No jednak nie do końca, bo nad portowaniem rozwiązań i wspieraniem obu wersji Pythona czuwa jeden podmiot i jedno środowisko, a nie kilka. W kontekście JavaScript, dostawca jQuery, Angulara, czy Node.js'a martwi się o to, żeby grało to na różnych przeglądarkach, dostarcza transpilatory dla różnych standardów Ecma itp. A w Common Lisp? Czy Franz który rozwija swoją komercyjną wersję, daje jakieś biblioteki lub rozwiązania, z których może skorzystać użytkownik CLispa lub SBCL? 

Pewnie w dużej mierze masz rację. Ja tam w Common Lispie napisałem
tylko najwyżej kilka programów, i stwierdzam, że zdecydowanie bardziej
przepadam za Schemem (w przypadku którego dużą ilość implementacji
-- nawet bardzo ze sobą niezgodnych -- postrzegam mimo wszystko jako
zaletę)