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

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.