Názory k článku
Programovací jazyky používané (nejen) v SSSR (část 3 – LISP)

Taky jsem se na to dřív díval tak, že LISP je jen hromada závorek.

Ve skutečnosti jde o to, že je to jazyk bez syntaxe. Člověk přímo zapisuje ten strom, který u „obyčejných“ jazyků dělá parser. No a tahleta fíčura má svoje výhody, třeba že program a data jsou zde opravdu jedno a to samé.

Chytré hlavy pro to používají slovo „homoikonický“.

Jazyk bez syntaxe? To snad ne. I když pravda, pokud by se to zapisovalo všechno consama, tak by to byl téměř syntaktický strom, o kterém mluvíte, ale i to jen téměř.

Já v tom kódu ten syntaktický strom vidím. Každopádně je to syntaxe na tak primitivní úrovni, že parser nacvaká i malé děcko na čelním panelu počítače.

Jo, souhlas. Syntaxe LISPu je podobná syntaktickému stromu a udělat syntaktický analyzátor LISPu by mělo být snadné (tohle je řekl bych jeho největší výhoda), ale neřekl bych, že je to jazyk bez syntaxe. Možná jde jen o subjektivní výklad pojmu…

Není to spíš nevýhoda? Míchání kódu a dat se nepovažuje za bezpečné.

Mozna je to povazovano za nebezpecne, ale v jinych kontextech. Treba z hlediska bezpecnosti datovych souboru prenasenych po siti. Nebo z hlediska ulozeni v pameti.

V Lispu to znamena zas neco trosku jineho, a totiz, ze muzete programem manipulovat jako daty, a tedy snadno generovat programy. Makra v Lispu toho velmi vyuzivaji. Umoznuje to psat daleko mocnejsi (a zaroven bezpecnejsi) makra nez treba C preprocesor.

Je to standard.

Děkuji za dobrý článek, poznámku bych měl jen k přepisu „tečka-dvojice“. Zní to podivně nečesky, u nás na škole používáme tečkové páry, IMHO to zní lépe :-).

Ano, to je pravda. Zde se projevuje jedna z genialnich vlastnosti anglictiny – z kazdeho podstatneho jmena jde udelat sloveso nebo pridavne jmeno. Zde je to zrovna tento priklad – dot (tecka) uzit ve funkci pridavneho jmena. Podobny problem je treba s prekladem zapisu IP adresy v IPv4, coz je v originale „dotted quad“. Kazdopadne zadny preklad mi neprijde dost rozumny – ty „teckove pary“ navozuji predstavu, ze tam nekde bude par tecek, coz neni :-). Mozna bych pro to navrhl specialni nove slovo „teckapar“, „teckapary“ :-).
Zdravi Pavel

My jsme zase pouzivali (FIT VUTBR) prave ty „tecka-dvojice“, takze cesky preklad asi bude dost nejednotny. V pristi casti si nejsem jisty, zda pouzivat termin „forma“ nebo „vyraz“, nejaky hint? V zahranicni literature vetsinou skalni LISPari pouzivaji termin „forms“ u odpadliku, kteri zkusili i jiny jazyk :-) zase prevazuje „expression“…

Shltnul jsem to jedním dechem.

Zrovna u LISPu je problem v tom, jestli nejdriv vysvetlovat, jak je uvnitr implementovany (a tim padem ctenarum po nejakou dobu zamlcet, proc to tak tvurci udelali – potom si 90% lidi rekne, ze je to nanic a tvurci proste jen meli radi zavorky:-) nebo pouze rict „jo, vsechno jsou seznamy a lambda transformace“ a pritom se nezminit, ze vlastne interne o seznamy vubec nejde, protoze v pameti se ukladaji binarni stromy a prave proto mohly vzniknout velmi efektivni funkce CAR a CDR (+ jejich pribuzni).

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.

Nevycházel tenhle serial v úterý? Já se těšil na grafiku osmibitů.

Je to posunute, protoze jsem minuly tyden byl na horach (bez internetu i signalu :-), takze ve ctvrtek clanek nevysel, az toto utery. „Grafika“ tam prozatim byla zminena jen velmi okrajove, pokud se za ni daji povazovat carecky na sedmisegmentovem LED :-) Priste to uz bude lepsi, natipal jsem obrazky z PMD-85, Flappy, Hlipu a spol.

Proč je pravá větev nesymetrická k levé?

Protoze musite nejak rozlisit vnitrni ukazatele v tom stromu a data. Oboji mohou byt slozene z cons bunek.

Vynikajuca vec, precital som naozaj na jeden dych a tesim sa na dalsi diel!

splecneho se SSSR?

v nadpisu mas „(nejen)“, takze spolecneho nemusi mit nic :-)

Cekal jsem ze tam bude historie LISPu v CCCP, kdo ho a ja implementoval, na cem, kde ho pripadne ukradl, k cemu se pouzival, jake byly problemy. Jako v predchozich clancich o hw. Ne syntaxi LISP.

K tomu se jeste dostaneme, sice ne primo k tomu, kdo Lisp v CCCP implementoval, ale k HW ktery se na to pouzival urcite.

Clanek docela v pohode, i kdyz musim rict, ze trochu pokulhava s fakty. Predne, v Emacsu je elisp a nikoliv scheme, jakkoliv muze byt v mnoha ohledech podobny spise schemu nez common lispu. Jinak, bylo by dobre vyvarovat se portretovani lispu jako nejakeho drsne ,,funkcionalniho jazyka'' (zadny Haskell to neni, nastesti). Spis bych jej oznacil za jazyk multiparadigmovy, protoze v nem muzete programovat, jak chcete (i kdyz je preferovany zpusob funkcionalni s minimem vedlejsich efektu, stejne dobre se v nem da delat ciste imperativne, i kdyz to trochu potira jeho vyznam). Jeste k cyklum, v LISPu je ITERATE, ne primo v CL, ale jako knihovna, ale kdo jednou zkusil, uz nikdy nechce jinak! Let Over Lambda Forever!

Ja jsem nekde psal, ze v Emacsu je Scheme nebo pouzil spojeni „funkcionalni jazyk“? :-)

btw, i ve Scheme je jedna forma vzdalene podobna smyckam – „do“, ale to je jen zakukleny tail-cail :-) Me osobne se take nelibi jen ciste funkcionalni pristup (ten stejne neni z praktickeho hlediska mozny), nekdy smycky reseny problem vyjadruji lepe nez rekurze (i kdyz to je ve vysledku ekvivalentni, tak citelnost a primost algoritmu je dulezitejsi).

No ono to mohlo vyznít z násl. věty 3. bodu článku:

<cite>Právě z těchto důvodů se Scheme využívá či využívalo jak při výuce programování, tak i v mnoha open-source projektech, například v textovém editoru Emacs či v grafickém editoru GIMP jako jeden z podporovaných skriptovacích jazyků.</cite>

Asi nikdo nezpochybňuje, že čistě funkcionální přístup sám o sobě nestačí na řešení reálných problémů, ale na rozdíl od jiných taky-funkcionálních jazyků si s tím asi nejlépe poradil právě Haskell. Nevydal se cestou míchání s imperativním přístupem, kdy funkcionální vlastnosti tak nevyniknou, ale striktně je oddělil a tu „imperativní část“ zabalil funkcionálně (monády).
Výše uvedené spolu se silným typovým systémem umožňuje eliminovat většinu chyb už při kompilaci (potřeba debugování je raritní záležitost) a zároveň umožnit kompilátoru vysoký stupeň optimalizace (kód z GHC se může rovnat výstupu kompilátorů C)

Mnoho příladů reálných opensource aplikací je k dispozici na http://hackage.haskell.org/packages/archive/pkg-list.html . Hodně lidí určitě zná i verzovací systém Darcs http://darcs.net

Aha, to se omlouvam, ta veta je napsana skutecne nestastne. Ja jsem myslel tu druhou zminku o Emacsu, tam je to dobre. Nechapejte to prosim tak, ze jsem si jako Vimar rypl do Emacsaku, tak to nebylo mysleno ;-)

Ano, Haskell se vydal trosicku jinou cestou, treba zavadi i staticke typovani a dalsi napady, coz je logicke – ovsem Haskell je stary „pouze“ 20 let, dedecek LISP ma uz 52 let, takze vyvoj urcite musi byt videt.

Osobne si myslim, ze tento pristup bude v budoucnu jeste vice prosazovan – vykon ALU a radicu moc neroste, spise se zvysuje pocet vypocetnich jader, takze snaha o paralelizaci kodu povede k vetsi orientaci na ty programovaci jazyky, ve kterych se daji BEZPECNE psat multithreadove aplikace.

Erlang ide o krok ďalej a podporuje distribuovateľné riešenie, nielen multithreadové. Sú aj pokusy takýto prístup preniesť do Scheme/Common Lis­pu.

Ve skole nas ucili Rebol. Tohle je tomu trochu podobny. O vikendu si to snad prectu cele v klidu a poradne.

Skutecne, Rebol z LISPu castecne vychazi, takze podobnost neni ciste nahodna :-) Muzu se zeptat, na jake skole se uci Rebol?

Technicka univerzita v Liberci, Fakulta mechatroniky, cca rok 2002, pan Mecir, tenkrat tam asi tak nejak doktorandoval a pro Rebol mel zrejme slabost.

Zrovna včera jsem pařil s jedním kolegou, co se podílel na procesorové jednotce.
Strašně jsme si zavzpomínali na ony Bulharské disky, bubnové paměti a co všechno se muselo vyřešit, by to fungovalo. Jak se u SSSR klonů AT/XT řešila vodovzdornost, neb to muselo šlapat i pod vodou.
A pak už jsme si pokecali o nových SSD a shodli jsme se na tom, že to je dnes přeci jen supr, a ty zážitky z těch průkopnických dob nám nikdo nevezme.

Jo jo, to byly časy. (y) :D. Zdarec.

Nebely by byt ty teckove pary (nebranim se tomuto terminu:)) tvaru (1 . 2) a ne (1.2)? Druhe zminovane je totiz desetinne cislo v seznamu. Ale clanek pekny, Lisp je nej.