Lisp je o něco rozšířenější, nicméně v Scheme se IMHO programuje pohodlněji a vlastní i cizí kód se líp čte.
Scheme má taky špičkové kompilátory/interpretry jako Gambit, Chicken nebo Gauche. Např. z Gambit-C leze efektivnější kód než ze SBCL co do rychlosti běhu a paměťových nároků.
Problémem Scheme oproti Common Lispu a jiným „velkým“ jazykům jsou samozřejmě základní knihovny, resp. oblasti praktického programování kterou pokrývají.
asi nejvetsi rozdil mezi nekterymi Lispy a Scheme je prave v dynamickem vs lexikalnim scopingu, par minoritnich rozdilu tam navic je taky, ale nejsou tak velke (dvoji vs jeden namespace, zminovany rozdil v chapani prazdnich seznamu). Pokud mate rad minimalisticky navrzene jazyky, je Scheme celkem jasna volba, pokud naopak hledate neco pro vyvoj vetsich aplikaci, mozna bych sel do CL.
Pro Scheme není pořádné GUI? A DrScheme (resp. PLT Scheme) je co? www.plt-scheme.org
jj ale je to pouze pro plt-scheme, a plt-scheme se nekompiluje do nativního kódu…
Ale na druhou stranu tu mám gtk-server… a zakomponovat tcl/tk – wish by také nemuselo být obtížné… to podporuje např chicken…
Ale stejně, lisp je na tom lépe.
Ps: Nevíte o knihovně umožnující v lispu prototype-based programování?
Ide to. Na kontinuacie pouzijes kniznicu (napr. http://common-lisp.net/project/cl-cont/ ) a potom spravis code walker, ktory si uklada pri prechadzani kodu lexikalne bindingy. Pokial najdes takuto premennu v na zaciatku zoznamu (ked nie je quotovany) strcis tam ‚funcall‘ a mas scheme :)
nevim jestli to odpovida tomu, co se aktualne uci na UPOL. nicmene, upravenou variantu toho zasobnikoveho modelu pouzivame v schemiku (implicitne paralelnim dialektu schemu). pokud byste mel zajem o podrobnosti, napiste mi na email (je naspodku tech stranek)
Našel jsem nějaké poznámky a zdrojové kódy: http://krupka.inf.upol.cz/2009Z/PP3.html
Teorie: http://krupka.inf.upol.cz/2009Z/09.pdf
Zdroják: http://krupka.inf.upol.cz/2009Z/code/stack-scheme.lisp (+ nějaké pokračování http://krupka.inf.upol.cz/2009Z/code/continuations.lisp)
A případně ještě na http://phoenix.inf.upol.cz/esf/materialy.htm skripta Paradigmata programování 2, díl A/B od dua Vychodil/Konečný.
Ja jsem sel do Common Lispu, da se to celkem vydrzet, ale Scheme moc neznam. Z toho co pisi ostatni me prijde, ze Common Lisp ma pragmatictejsi pohled na svet nez Scheme, na ukor elegance (a to je vec, ktera mi velmi vyhovuje treba na Pythonu).
Kdyz ale srovnam Common Lisp s Pythonem, vadi mi na nem oproti Pythonu par veci:
- nedostatek standardnich knihoven (treba co mi dost chybi jsou i takove zakladni veci jako string.split a podobne), ale to muze byt moje neznalost (docela bych uvital stranku ekvivalentu CL a Pythonich knihoven); a tech par co jsem videl, mely dost horsi API oproti Pythonu (coz muze souviset s dalsimi body)
- neobjektovost, z cehoz vyplyva treba dichotomie mezi eql, equal, equalp, nebo spatna podpora hash tabulek a vlastnich struktur ve smyckach
- nema iteratory a generatory, vim ze na to existuji nejaka makra, ale zase, neni to tolik integralni soucast jazyka jako v Pythonu
Pokud vim, nic z toho Scheme moc neresi.
I kdyz s CL koketuji jiz pomerne dlouho, stale se mi prakticke veci lepe pisi v Pythonu.
string.split → http://www.cliki.net/SPLIT-SEQUENCE
– neobjektovost, z cehoz vyplyva treba dichotomie mezi eql, equal, equalp, nebo spatna podpora hash tabulek a vlastnich struktur ve smyckach
eq, eql, equal, equalp a pod nesuvisi s „objektovostou“ ale s identitou.
eq porovnava ci su 2 objekty jeden a ten isty – btw. v Lispe je VSETKO objekt, vcetne cisiel
eql porovnava cisla
equal porovnava zoznamy
equalp porovnava stromy (tzn – zoznamy/vektory, ale vnoruje sa rekurzivne dovnutra prvkov – je to strukturalna ekvivalencia)
spatna podpora hash tabulek – neviem kde je problem, mozno ti vadi ze Lisp nema „specialnu“ syntax ala table[key]?
Loop → doporucujem nahradit s http://common-lisp.net/project/iterate/
Tiez, http://common-lisp.net/project/alexandria/ by nemala chybat v kazdom Lisp projekte.
Dobra vec je aj http://github.com/ks/X.LET-STAR
Ha, diky. I kdyz stejne mi to pripada trochu rozstristene.
Co se tyce tech eql a tak, proste mi vadi, ze to nejsou genericke funkce. Totez plati i o rade dalsich veci, treba elt atd. Zkratka, ackoliv je v CL vsechno objekt, stale mi prijde, ze OO je tam jenom tam ex-post nasroubovane (narozdil od Pythonu, kde treba len() nebo == nebo + jsou genericke funkce). Ale mozna jsem jen neco nepochopil. A nebo je mozna nejaky snadny zpusob, jak ty funkce rozsirit.
Co se tyce hash tabulek, vadi mi prave tohle – ze na ne nefunguje vetsina funkci pracujicich s posloupnostmi. Ale to asi resi to ITERATE.
Kazdopadne, diky za odkazy, krome tech utilit jsem je neznal, a uzitecnost tech utilit jsem asi pri prvnim cteni podcenil.
K lispu jsem nedávno narazil na CLPython.
CLPython is an open-source implementation of Python written in Common Lisp. With CLPython you can run Python programs in a Lisp environment. Libraries written in Lisp are available to Python code, and Python libraries can be accessed by Lisp code.
Pane Tisnovsky, mel byste to zabalit. Vase serialy o HW mi pripadaly zajimave, ale to bylo asi tim, ze HW nerozumim. Pokud v nich bylo tolik zavadejicich nesmyslu, jako v tomhle clanku, tak to pekne dekuju. Zvlast s tema rozsahama platnosti jste to teda napsal tak, ze je z toho citit, ze tomu moc nerozumite. Mel byste se radsi drzet svych oblibenych temat a nepsat o vecech, kterym nerozumite.
Podstatnější (i když na první pohled možná méně viditelný) rozdíl než #f vs. nil mi přijde lisp 2 vs. lisp 1 (např. http://www.nhplace.com/kent/Papers/Technical-Issues.html)
Mas na mysli jeden vs dva jmenne prostory. Abych se priznal, tak jsem nikdy moc nechapal vyhodu dvou jmennych prostoru. Kdysi se to hodne resilo pri vyvoji LOGA (byly i nejake flamewars mezi vazenymi pany profesory :-), ale proc mit vlastne dva namespacy, jen to mate v pripade, ze prasici programator ma dva ruzne objekty pojmenovany stejne :-)
zatímco se v LISPu oblast platnosti proměnných stanovuje dynamicky v čase běhu programu, ve Scheme a v některých implementacích LISPu je oblast platnosti proměnné určena na základě toho, v jakém bloku se proměnná nachází (tato vlastnost jazyka se označuje lexical scope)
Zatiaľ čo toto môže byť pravda pre Elisp, tak Common Lisp používa dynamic scoping iba pre defvar/defparameter a podľa konvencie názov týchto premenných začína a končí hviezdičkou.
Seznam literatury a odkazů je snad delší než článek, ale chybí v něm dvě kvalitní knížky dostupné v plném znění na webu (z jedné je přitom použit obrázek):
Structure and Interpretation of Computer Programs http://mitpress.mit.edu/sicp/full-text/book/book.html
a
How to Design Programs http://www.htdp.org/