🚀 go-pugleaf

W dniu czwartek, 26 stycznia 2017 19:55:13 UTC+1 użytkownik markfal...@gmail.com napisał:
> No właśnie. Żeby nie robić z tamtego wątku tasiemca zupełnie off topic...
> 
> Czy na prawdę Lisperzy na pytanie jakie zadał bigos na comp.lang.lisp:
> 
> https://groups.google.com/forum/#!topic/comp.lang.lisp/2XyHXlVpTiw
> 
> Mają tylko odpowiedź w stylu "The abstraction tools used at the micro level can also be used at the macro level"?
> 
> Przecież każdy architekt dużych systemów, które mają się dobrze skalować, wie
> że to tak nie działa :) Obsługa 10 różnych usług sieciowych w aplikacji 
> z której korzysta w tym samym czasie 300 osób, a obsługa np. 300 tysięcy różnych usług, o różnej wolumetrii danych, w rozproszonym systemie, z wymaganiami HA, przy ostrych wymaganiach na wydajność - to zupełnie nie to samo i sam DSL
> mi tego nie zapewni...

Ja myślę o tych kwestiach w zupełnie inny sposób, tzn. mam świadomość,
że korzystając z jakiegoś języka programowania niebędącego lispem, coś
odrzucam. Mówiąc konkretniej, odrzucam elastyczność powodowaną tym, że
składnia lispa, wraz z operatorem quote pozwala tworzyć dowolne obiekty
drzewiaste. Dlatego kiedy się np. mieliśmy na uniwerku zajęcia z parsowania
i gramatyk, to zamiast korzystać z jakichś bardzo skomplikowanych
narzędzi typu Bison, mogłem zapisywać gramatyki po prostu za pomocą
s-wyrażeń, np.

  '((<S> => <A> <B>)
    (<S> => <B>)
    (<A> => a <A>)
    (<A> => x)
    (<B> => b <B>)
    (<B> => x))

Napisanie rekurencyjnego programu pozwalającego przetwarzać takie
gramatyki nie zajęło wiele miejsca -- niewiele więcej, niż ekran kodu,
zaledwie 4 funkcje, z czego dwie rekurencyjne.

Gdybym chciał to samo osiągnąć w jakimś nie-lispie, musiałbym
się babrać z tworzeniem parserów. Tutaj mam to za darmo. Kod może nie
był czysto funkcyjny, bo używałem w nim wyjątków, ale ponieważ
intefejs był funkcyjny, mogłem go łatwo testować, np.

((recursive-descent-parser '((A => a A b)
                             (A => c)))
 '(a a a c b b b))
;; => (A a (A a (A a (A c) b) b) b

podczas gdy pan, który prowadził kurs na uniwerku, napisał chyba z 5
ekranów kodu odpowiedzialnych za samo wyświetlanie drzew parsowania.

I oczywiście, kiedy tworzysz jakiś konkretny projekt na jakieś konkretne
potrzeby, wówczas faktycznie kluczowe znaczenie ma ekosystem oraz
grono odbiorców.

Zdaje się, że w projektach Javovych typowym formatem strukturyzowania
danych jest XML. Programiści Scheme'u wymyślili sobie coś takiego,
jak SXML, czyli konwersję XML do postaci s-wyrażeń, dzięki czemu
mogą uniknąć tego bezsensownego narzutu redundantnych znaczników.

Trochę się swego czasu rozpisywałem na ten temat na quorze:
https://www.quora.com/Which-programming-language-is-the-most-suitable-in-building-a-humanoid-robot/answer/Panicz-Godek

W dniu czwartek, 26 stycznia 2017 23:56:05 UTC+1 użytkownik godek....@gmail.com napisał:

> Ja myślę o tych kwestiach w zupełnie inny sposób, tzn. mam świadomość,
> że korzystając z jakiegoś języka programowania niebędącego lispem, coś
> odrzucam. [...]

uświadomiłem sobie, że chyba niedociągnąłem wątku.
Chodzi mi zasadniczo o to, że być może istnieją języki, które mają
lepsze ekosystemy, niż Common Lisp albo Scheme (przynajmniej
do partykularnych potrzeb), jednak to jest kwestia przygodna
-- ekosystem jest czymś, co ewoluuje. Co do pewnych własności
istotowych, to Common Lisp i Scheme będą zawsze je posiadały
-- homoikoniczność jest realną przewagą Lispów nad nie-lispami.

Składnia Javy może się podobać albo nie, tak jak składnia
Pythona albo Ruby'ego. Być może za popularnością Pythona
stoją względy estetyczno-kulturowe, bardziej niż cokolwiek innego.

W przypadku Lispa -- w przeciwieństwie do Javy czy Pythona
-- składnia nie jest kwestią fanaberii. Kluczową kwestią jest
zrozumienie, że to jest składnia uniwersalna, tzn. taka, w której
można wyrazić (w sposób jednorodny) każdą strukturę wyrażalną
w każdej innej składni.
To nie jest kwestia estetyki (w każdym razie wizualnej), tylko zrozumienia.
To jest składnia obiektywnie prostsza -- co mogdybym chciał
stworzyć podobną strukturę w C albo Javieżna stwierdzić,
porównując BNF dla Lispa np. z BNF dla C
http://cui.unige.ch/db-research/Enseignement/analyseinfo/LISP/BNFlisp.html
http://www.cs.man.ac.uk/~pjj/bnf/c_syntax.bnf
(jest prostsza do wyrażenia, a zatem prosta w nauce, bo przewidywalna,
i prosta do przetworzenia). Co prawda analogony operatora quote
istnieją w takich językach, jak Julia czy Elixir, a makra można tworzyć
nawet w Scali, ale w każdym z tych przypadków jest to nieporównywalnie
trudniejsze i idiosynkratyczne.

Wracając do przykładu z gramatykami bezkontekstowymi, gdybym chciał
stworzyć podobną strukturę w C albo w Javie, napotkałbym na wiele przeszkód.
W Pythonie albo Javascripcie mógłbym co prawda korzystać z tablic
albo stringów, ale nawet wówczas składnia jest nieprzezroczysta, tzn.
musiałbym pisać
['<S>', '=>', '<A>', '<B>']
itd., co jest upierdliwe nawet przy wpisywaniu, oraz istotowo różne
od kodu w Pythonie/JavaScipcie.