🚀 go-pugleaf

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ć? :)
A składnia i tak pozostaje minimalistyczna w stosunku do takiego chociażby Ruby.


> 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/


> 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).

> 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. 


> 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? 

> W ogóle jeżeli ktoś jest zainteresowany, to w wakacje prowadziłem
> małą prelekcję na temat Scheme'a (choć wyszła może dość nudnawo)

Dzięki za linka. Z przyjemnością obejrzę