🚀 go-pugleaf

W dniu niedziela, 22 stycznia 2017 17:28:15 UTC+1 użytkownik markfal...@gmail.com napisał:
> Ciekawa seria filmów szkoleniowych z Common Lispa
> 
> https://www.youtube.com/channel/UCymtXMj1M7cKiV9TKLoTtEg

Na razie jestem na pierwszym, i choć oczywiście cieszy istnienie
takich zapaleńców, merytorycznie raczej nic to nie dodaje w stosunku
do tego, co można sobie poczytać w klasycznych esejach Paula Grahama.

Nie podoba mi się argument o nieczytelności Lispa, odwołujący się do tego,
że "java jest nieczytelna" oraz "wyrażenia regularne perla też są nieczytelne",
z czego niby miałoby wynikać, że "każdy język jest nieczytelny"

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

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. Stąd w Clojure wektory, przekazywanie argumentów funkcji w nawiasach kwadratowych itd. Zresztą zgrabnie ujął to w swojej prezentacji (dokładnie od 25 min):

www.infoq.com/presentations/Simple-Made-Easy

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), 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). Poza tym rozdrobnienie środowiska na kilka odmian Common Lispów (z czego najbardziej popularny CLisp jest sprzed 6 lat).

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)

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)
na trójmiejskim meetupie o programowaniu funkcyjnym

https://www.youtube.com/watch?v=wd-2CDWMetc

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ę

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

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

Myślałem sobie jeszcze trochę o tym stwierdzeniu. Jakiego masz killer-appa
dla Pythona? Albo dla Javy? (Bo rozumiem, że dla PHP to Wordpress jest
takim killer appem?)

On Wednesday, January 25, 2017 at 10:01:16 PM UTC+1, godek....@gmail.com wrote:

> Myślałem sobie jeszcze trochę o tym stwierdzeniu. Jakiego masz killer-appa
> dla Pythona? Albo dla Javy? (Bo rozumiem, że dla PHP to Wordpress jest
> takim killer appem?)

Dla Javy? :) Java to ma w swojej karierze tyle tych "killerów", że Wordpress to się może schować ;) Zresztą mi do korporacyjnej Javy najbliżej z racji pracy zawodowej, więc tak od siebie:

W Javie największym "killer rozwiązaniem", który przyciągnął tłumy jest jednak bardzo dobra multiplatformowość i znakomita skalowalność korporacyjnych rozwiązań. C# i .NET z mało dojrzałym Mono dłuugo takiej mieć nie będą. Poza tym:

- Spring i Maven (praktycznie zrewolucjonizowały sposób budowy enterprisowego oprogramowania. Nuget dla .NET miał być czymś na wzór Mavena)
- JSF/PrimeFaces do GUI
- Weblogic i IBM Websphere - zdecydowanie największe i najbardziej dopracowane serwery aplikacyjne do zastosowań krytycznych ever
- Java to w zasadzie główna platforma i język programowania na Androida 
- Eclipse i IntelliJ - te narzędzia to praktycznie potęga. Obrosły w wielki
ekosystem. To wręcz całe platformy + inteligentne IDE działające na takim
poziomie że mało co im dorównuje (refaktoring, debugowanie, automatyzacja
budowy i dystrybucji softu, integracja z wbudowanymi dockerami i masą narzędzi,
konfigurowalność, wtyczki do wszystkiego: od Junita, po całe serwery
aplikacyjne)... itd itp

Jeśli chodzi o Pythona, to moim zdaniem nie ma tu żadnej jednej extra-killer-app. Myślę (ale to tylko moje subiektywne odczucie), że przyciąga do niego fakt, że ma mnóstwo dojrzałych, non-stop rozwijanych bibliotek i jest praktycznie wszechobecny. Masz go "by default" w każdej dystrybucji Linuksa. 
Dzisiaj jako język skryptowy mocno zdetronizował Perla (wygodne biblioteki do
wszystkiego, łatwość użycia, bardzo bogata biblioteka standardowa). Jednocześnie
chcesz zrobić aplikację na Androida - masz wygodnego PhoneGAP'a, chcesz 
programować w Pythonie mikrokontrolery - proszę bardzo. Chcesz dojrzałe 
frameworki webowe - sięgasz po Django i inne. Chcesz wizualizację danych,
świetne pakiety naukowe (SciPy, NumPy), adaptery do praktycznie każdej 
istniejącej bazy danych? Są dostępne od ręki. W dodatku aktualne i wygrzane...

W dniu środa, 25 stycznia 2017 23:02:45 UTC+1 użytkownik markfal...@gmail.com napisał:
> On Wednesday, January 25, 2017 at 10:01:16 PM UTC+1, godek....@gmail.com wrote:
> 
> > Myślałem sobie jeszcze trochę o tym stwierdzeniu. Jakiego masz killer-appa
> > dla Pythona? Albo dla Javy? (Bo rozumiem, że dla PHP to Wordpress jest
> > takim killer appem?)
> 
> Dla Javy? :) Java to ma w swojej karierze tyle tych "killerów", że Wordpress to się może schować ;) Zresztą mi do korporacyjnej Javy najbliżej z racji pracy zawodowej, więc tak od siebie:

A jednak Wordpress wciąż wystaje i uparcie nie chce się schować :O
Próbowałem odgadnąć, co masz na myśli, pisząc o killer-appach, stąd
ten wordpress. Tak samo ma się rzecz z C i UNIXem

> W Javie największym "killer rozwiązaniem", który przyciągnął tłumy jest jednak bardzo dobra multiplatformowość i znakomita skalowalność korporacyjnych rozwiązań. C# i .NET z mało dojrzałym Mono dłuugo takiej mieć nie będą. Poza tym:
> 
> - Spring i Maven (praktycznie zrewolucjonizowały sposób budowy enterprisowego oprogramowania. Nuget dla .NET miał być czymś na wzór Mavena)
> - JSF/PrimeFaces do GUI
> - Weblogic i IBM Websphere - zdecydowanie największe i najbardziej dopracowane serwery aplikacyjne do zastosowań krytycznych ever
> - Java to w zasadzie główna platforma i język programowania na Androida 
> - Eclipse i IntelliJ - te narzędzia to praktycznie potęga. Obrosły w wielki
> ekosystem. To wręcz całe platformy + inteligentne IDE działające na takim
> poziomie że mało co im dorównuje (refaktoring, debugowanie, automatyzacja
> budowy i dystrybucji softu, integracja z wbudowanymi dockerami i masą narzędzi,
> konfigurowalność, wtyczki do wszystkiego: od Junita, po całe serwery
> aplikacyjne)... itd itp

Dla mnie brzmi to raczej jak frameworki i narzędzia, niż killer-appy,
i w większości przypadków stanowią uzasadnienie dla ekosystemu w sensie
maszyny wirtualnej, niż dla samego języka (który nota bene staje się
coraz mniej popularny; może własnie owo oddzielenie języka od środowiska
swiadczy w największym stopniu o sukcesie tego projektu).

> Jeśli chodzi o Pythona, to moim zdaniem nie ma tu żadnej jednej extra-killer-app. Myślę (ale to tylko moje subiektywne odczucie), że przyciąga do niego fakt, że ma mnóstwo dojrzałych, non-stop rozwijanych bibliotek i jest praktycznie wszechobecny. Masz go "by default" w każdej dystrybucji Linuksa. 
> Dzisiaj jako język skryptowy mocno zdetronizował Perla (wygodne biblioteki do
> wszystkiego, łatwość użycia, bardzo bogata biblioteka standardowa). 

Moim zdaniem popularność Pythona bierze się przede wszystkim stąd,
że "na powierzchni" wygląda bardzo przystępnie (tak że jest zrozumiały
również dla osób, które wcześniej nie programowały), zaś semantykę
ma wzorowaną na Dylanie (czyli niehomoikonicznym dialekcie Scheme'a
z obiektami). Do tego dochodzą również kwestie etyczno-kulturowe, tzn.
istnienie pewnego kodeksu regulującego, jak należy programować, dzięki
czemu autor programu nie jest jedyną osobą, która potrafi go zrozumieć

Jednocześnie
> chcesz zrobić aplikację na Androida - masz wygodnego PhoneGAP'a, chcesz 
> programować w Pythonie mikrokontrolery - proszę bardzo. Chcesz dojrzałe 
> frameworki webowe - sięgasz po Django i inne. Chcesz wizualizację danych,
> świetne pakiety naukowe (SciPy, NumPy), adaptery do praktycznie każdej 
> istniejącej bazy danych? Są dostępne od ręki. W dodatku aktualne i wygrzane...

Przypomina mi się cytat, który znalazłem na Quorze:

"…Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, Electronic Design Automation/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical Computer Aided Design (CAD), Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list."

—Kent Pitman

On Thursday, January 26, 2017 at 12:36:31 PM UTC+1, godek....@gmail.com wrote:
>
> Dla mnie brzmi to raczej jak frameworki i narzędzia, niż killer-appy,
> i w większości przypadków stanowią uzasadnienie dla ekosystemu w sensie
> maszyny wirtualnej, niż dla samego języka (który nota bene staje się
> coraz mniej popularny; 

Wordpress, czy wspomniane wcześniej Railsy, to przecież również
narzędzia/frameworki. Przez określenie "killer app" rozumiem takie
rozwiązanie/narzędzie - które spowoduje że dana grupa programistów/projektantów
(czy też osoby odpowiedzialne za wybór technologii w której będzie
implementowane jakieś rozwiązanie w firmie X) będą CHCIELI użyć tego, a nie
innego języka czy platformy. A programiści/projektanci patrzą właśnie na
narzędzia i frameworki. Przecież Angular to też narzędzie/framework, a to
właśnie Angular (obok Node.js) powoduje, że masowo deweloperzy uczą się
JS'a, a JavaScript przeżywa reinkarmację.

Piszesz, że wspomaniane przeze mnie "narzędzia" stanowią nie tyle uzasadnienie
dla Javy, co dla maszyny wirtualnej. Otóż moim zdaniem tak nie jest.
Przykładowo bardzo dopracowane, napisane w Javie, potężne serwery aplikacyjne o
których wspomniałem (Weblogic Oracle'a czy Websphere IBM'a) są stworzone dla
rozwiązań stricte implementowanych w Java EE i bazują na architekturze opartej
o Enterprise JavaBeans, JTA, javową obsługę kolejek itd itp. To że masz 
Clojure na JVM'a i możesz korzystać z bibliotek Javy, nie oznacza - że
napiszesz korporacyjny soft w architekturze EJB i zepniesz go z Webogikiem,
który załatwia za programistę masę rzeczy. A mimo że różne startupy i mniejsze
projekty śmigają na różnych JavaScript czy PHP, to z moich obserwacji 
np. polskiego i brytyjskiego rynku wynika - że WIELKIE systemy bankowe,
systemy administracji publicznej itd - nadal są tworzone w Java Enterprise.
M.in właśnie dlatego, że nikt jeszcze nie napisał odpowiednika Oracle Weblogic
dla Common Lispa, czy Pythona ;)


> Przypomina mi się cytat, który znalazłem na Quorze:
> 
> "…Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, Electronic Design Automation/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical Computer Aided Design (CAD), Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list."
> 

Ok. Tylko zauważ, że Pythona SERIO używają DUŻE firmy do Data Miningu
(Python Pandas stosowany przez Goldman Sachs, Merill lynch, CitiBank) 
serio używają go do programowania mikrokontrolerów itp itd, a na temat 
tychże zastosowań Pythona (i innych wymienionych) można kupić książki 
na Amazonie wydane w zeszłym roku czy planowane na 2017. 
Nie jest to więc tylko jakiś "pusty slogan". Tymczasem pokaż mi książkę
z ostatniego 10-lecia, która opisywałaby zastosowanie Common Lispa w
działce Data Minig/GIS/tworzenie gier/cokolwiek...

Żeby było ciekawiej to mnie ciągnie do tego, żeby popisać 
co nieco w Common Lispie (jakoś Scheme wydaje mi się przy implementacjach
CL nieco uboższe), tylko ciągle szukam powodu (poza samym faktem nauki
nowego paradygmatu i języka) DLACZEGO warto inwestować swój czas w Common Lisp.
Co ma takiego ten język, co spowoduje, że zrobię w nim coś lepiej/szybciej
niż w Javie/Pythonie lub F#...

W dniu czwartek, 26 stycznia 2017 19:32:48 UTC+1 użytkownik markfal...@gmail.com napisał:
> On Thursday, January 26, 2017 at 12:36:31 PM UTC+1, godek....@gmail.com wrote:
> >
> > Dla mnie brzmi to raczej jak frameworki i narzędzia, niż killer-appy,
> > i w większości przypadków stanowią uzasadnienie dla ekosystemu w sensie
> > maszyny wirtualnej, niż dla samego języka (który nota bene staje się
> > coraz mniej popularny; 
> 
> Wordpress, czy wspomniane wcześniej Railsy, to przecież również
> narzędzia/frameworki.

Na Railsach się nie znam, ale co do Wordpressa, to rozumiem,
że jego zaleta jest taka, że potrafią go postawić nawet osoby
nieprogramujące. W tym sensie rozumiem to raczej jako aplikację,
niż framework, mimo że można go oczywiście rozszerzyć o różne
pluginy. (Nie wiem, bo się nie zajmuję takimi rzeczami)

> Piszesz, że wspomaniane przeze mnie "narzędzia" stanowią nie tyle uzasadnienie
> dla Javy, co dla maszyny wirtualnej. Otóż moim zdaniem tak nie jest.
> Przykładowo bardzo dopracowane, napisane w Javie, potężne serwery aplikacyjne o
> których wspomniałem (Weblogic Oracle'a czy Websphere IBM'a) są stworzone dla
> rozwiązań stricte implementowanych w Java EE i bazują na architekturze opartej
> o Enterprise JavaBeans, JTA, javową obsługę kolejek itd itp. To że masz 
> Clojure na JVM'a i możesz korzystać z bibliotek Javy, nie oznacza - że
> napiszesz korporacyjny soft w architekturze EJB i zepniesz go z Webogikiem,
> który załatwia za programistę masę rzeczy. A mimo że różne startupy i mniejsze
> projekty śmigają na różnych JavaScript czy PHP, to z moich obserwacji 
> np. polskiego i brytyjskiego rynku wynika - że WIELKIE systemy bankowe,
> systemy administracji publicznej itd - nadal są tworzone w Java Enterprise.
> M.in właśnie dlatego, że nikt jeszcze nie napisał odpowiednika Oracle Weblogic
> dla Common Lispa, czy Pythona ;)

No, pewnie masz rację. Ja zawodowo siedzę ostatnio raczej w niskopoziomowym
C, gdzie jak chcę coś mieć, to zazwyczaj sam to sobie piszę (a hobbistycznie
w wysokopoziomowym Schemie, w którym też zazwyczaj wszystko sam sobie
piszę ;] No, czasem korzystam z scmutils)

> > Przypomina mi się cytat, który znalazłem na Quorze:
> > 
> > "…Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, Electronic Design Automation/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical Computer Aided Design (CAD), Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list."
> > 
> 
> Ok. Tylko zauważ, że Pythona SERIO używają DUŻE firmy do Data Miningu
> (Python Pandas stosowany przez Goldman Sachs, Merill lynch, CitiBank) 
> serio używają go do programowania mikrokontrolerów itp itd, a na temat 
> tychże zastosowań Pythona (i innych wymienionych) można kupić książki 
> na Amazonie wydane w zeszłym roku czy planowane na 2017. 
> Nie jest to więc tylko jakiś "pusty slogan". Tymczasem pokaż mi książkę
> z ostatniego 10-lecia, która opisywałaby zastosowanie Common Lispa w
> działce Data Minig/GIS/tworzenie gier/cokolwiek...

Co do tworzenia gier, jest Land of Lisp http://landoflisp.com/
Jeżeli idzie o data mining, to Ross Ihaka, twórca pakietu R,
pisze uzasadnienie, dlaczego lepiej byłoby oprzeć przyszłe
wersje na Common Lispie
https://www.stat.auckland.ac.nz/%7Eihaka/downloads/Compstat-2008.pdf
(2008 to jeszcze się łapie na ostatnie 10-lecie, choć nikt nie wie,
co stało się z tym projektem, więc raczej nie zawładnął światem)

> Żeby było ciekawiej to mnie ciągnie do tego, żeby popisać 
> co nieco w Common Lispie (jakoś Scheme wydaje mi się przy implementacjach
> CL nieco uboższe), tylko ciągle szukam powodu (poza samym faktem nauki
> nowego paradygmatu i języka) DLACZEGO warto inwestować swój czas w Common Lisp.
> Co ma takiego ten język, co spowoduje, że zrobię w nim coś lepiej/szybciej
> niż w Javie/Pythonie lub F#...

Ja osobiście raczej nie zachęcam do Common Lispa, bo za nim
nie przepadam. Nawet Clojure wydaje się zdecydowanie lepszym wyborem,
ze względu na rezygnację z tych rzeczy, które utrudniają skalowalność.

Dla mnie Scheme służy po 1. do badań dotyczących transformacji
programów, a po 2. do robienia wykonywalnych notatek. (no i po 3.
do programowania gier)

Jeszcze jeżeli idzie o podcasty na temat Common Lispa, polecam prezentację
Richarda Gabriela z European Lisp Symposium 2014

http://medias.ircam.fr/x03b42f

(może pozwoli lepiej uświadomić, co mam na myśli, mówiąc, że "Common Lisp
nie jest dla owiec"). Oprócz tego na stronie można znaleźć też inne nagrania
z tamtego eventu.

Nagrania z ubiegłego roku można już znaleźć na youtubie:
https://www.youtube.com/channel/UC55S8D_44ge2cV10aQmxNVQ/feed