Vlákno názorů k článku
Programovací jazyky používané (nejen) v SSSR (část 3 – LISP)

Se zpusobem, jakym se v tomto clanku (a mnoha jinych) podava Lisp, totiz ve stylu „Lisp jsou v podstate seznamy, ktere se skladaji z cons bunek“, zasadne nesouhlasim, protoze si myslim, ze to Lispu jako jazyku prokazuje medvedi sluzbu. Sice jsem ponekud ovlivneny Common Lispem, a chapu historickou perspektivu, ale mam pocit, ze Lisp je prece jen o necem jinem.

Mluvim z vlastni zkusenosti – dlouho jsem nechapal, v cem jsou vyhody Lispu – vzdyt je to proste prace se seznamy. Ale prednaska a pak knizka Practical Common Lisp (a jeste pozdeji On Lisp) mi otevrela oci – v (Common) Lispu je spousta mnohem zajimavejsich konceptu, nez cons bunky. V te prednasce Practical Common Lisp zminuje autor 3 veci – multimetody, signaly a makra, ktere v beznych jazycich chybi (naopak Common Lisp umi temer vsechno, co ostatni jazyky). Ja bych jeste pridal dynamicke promenne.

Takze rikat, ze jsou to seznamy, jenom posiluje povrchni dojem, ze je to jen spousta zavorek a nic z toho. Pravdou je pritom naprosty opak!

P.S. Jinak, abych jen nekritizoval, clanky jsou skvele. Diky!

Dnesni dil byl jen takovy „rozjezd“, v dalsi casti urcite budou zmineny lambda vyrazy, program jako rekurzivni seznam (bez toho by neslo treba rozumne udelat makra), funkce typu mapcar, apply, reduce atd. (imho hodne zajimave – u mnohych „modernich“ jazyku se prave toto prezentuje jako uzasna novinka) a snad se stihnou take Common Lispovska makra.

A samozrejme mate pravdu v tom, ze Practical Common Lisp a nezapominal bych take na SICP je hoodne dobra literatura, dokonce bych rekl, ze jedna z nejlepsich o programovani vu­bec.

Ale vždyť LISP jsou v podstatě consy a seznamy… To že v „odvozených“ implementacích jsou další featchury, je věc jiná.

Mě spíše vadí opačná tendence, kdy se z původně funkcionálního jazyku dělá čím dál víc procedurální, čemuž všechny tyhle fičurky směřují…

A on byl Lisp nekdy funkcionalni ve smyslu, v jakem to chapeme dnes (v jakem je treba Haskell funkcionalni)? Ja osobne si myslim, ze ne, protoze treba takove rplacd a rplaca tam bylo odjakziva. Podle me je nazyvan funkcionalnim proto, ze byl odvozen z lambda kalkulu a jako prvni jazyk implementoval funkce jako skutecne funkce a ne procedury, a take jako samostatny typ (i kdyz je tady ta Lisp-1 a Lisp-2 zalezitost).

Common Lisp je multi-paradigm. To je proste fakt. A v tom je jeho sila. Scheme, ktera je vice funkcionalni, vznikla az pozdeji. Povazovat Lisp za ciste funkcionalni je IMHO spatny vyklad historie.

No, tak u haskelu se tyhle myšlenky akorát přivedly k dokonalosti. Ale dle mě měl být LISP funkcionální, jen se možná nevěřilo, že to programátorům bude stačit, proto jsou tam procedurální berličky. Ale to je jedno, mě šlo jen o to, že základem LISPu (jak ho tedy chápu já) jsou funkce a seznamy (a tím pádem i consy), ten jazyk je na tom prostě postavený. Všechno ostatní jsou jenom vylepšovátka, která se hodí popisovat, když chcete udělat LISPu reklamu, né ho vysvětlit…

<trolling>
Zcela ciste funkcionalni pristup neni mozny v prakticky zadnem realne pouzitelnem programovacim jazyce, protoze funkce s vedlejsimi efekty jsou prakticky nutnosti. Krome evidentnich pripadu (zmena stavu pocitace, treba otevreni souboru, poslani znaku na konzoli) je napriklad „nefunkcionalni“ i forma (setq x 42) i kdyz jako kazda spravna funkce neco vraci (konretne hodnotu 42), tak mnohem dulezitejsi je ten jeji vedlejsi efekt, tj. prirazeni teto hodnoty do x (popr. vytvoreni tohoto objektu).
</trolling>

No, i kdyz nejsem fanousek funkcionalniho programovani, tak striktni vyhnuti se vedlejsim efektum (jako to dela Haskell) ma velke vyhody, protoze to dovoluje kompilatoru staticky analyzovat kod velice hluboko, a optimalizovat kod zpusobem, jakym to zadny clovek nedokaze (nebo o to nestoji, kvuli citelnosti).

Pokud ovsem funkcionalni programovani zustane na nizsi urovni nez teto, pak snazit se o ciste funkcionalni programovani (napr. nepouzivat iteraci misto rekurze) je podle me zcela zbytecne.

Navic, jsem pragmatik, a myslim si, ze optimalizace, ktere dokaze Haskell pomoci staticke analyzy, by bylo mozne v nefunkcionalnim programu dosahnout pomoci analyzy dynamicke.

Já bych řekl, že těch výhod je víc, třeba snadnější porozumění chování programu než u obecného imperativního kódu nebo poměrně přirozená paralelizace programů.

Na Haskellu se mi líbí, že je na první pohled (podle typu funkce) jasné, jestli je „čistá“ nebo ne. Ve většině ostatních jazyků nelze u žádné funkce, která není triviální (tedy volá alespoň jednu funkci/procedu­ru/metodu) nikdy říci, co přesně její volání provede, aniž by bylo nutné znát poměrně široký kontext; u dynamických jazyků to platí obzvlášť.

Trolling je trochu silné slovo, ale ako disclaimer je to vystihujúce :)

Referenčná transparentnosť je lákavá, ale iba s ňou si nevystačíme. To je prostý fakt. Som rád, že si to dovolil povedať niekto ako vy.