Problemy lispu

1. lisp nejde rozumne kompilovat. Vychazi to ztoho ze kod se muze generovat za behu dokonce ruzne menit. Proto kompilery lispu zpocivaji v tom ze zdrojak predkousou tak aby se lepe cetl tedy aby cisla byla cisla apod. Samozdrejme ze lisp prelozit jde-stejne se nakonec provadi v assembleru ale nejde v zadnem pripade kompilovat tak optimalne jako treba cecko uz jenom proto ze + je funkce ne konstrukce kompileru tim nejde zkompilovat do instrukce add ale musi se volat nejaka rutina. Take protoze objekty nejsou jenom data ale hodne informaci kolem nejdou davat promene do registru. Proste kdyz zkompilujete lisp ve vzniklem exaci je stejne interpretr lispu a nejak predkousany zdrojak. A protoze zdrojak je tak jednoduchy a interpretace rychla neni kompilace vlastne vubec treba.
2. Je tezke urcit kdy uz objekt neni dale treba drzet v pameti. Pri kazdem eval se novy objekt vytvori. Ruseni nepotrebnych objektu se v odborne literature rika garbage collection neboli zbirani smeti. Profesori co trpe komplexy menecenosti a maji pocit ze by si je mohli studenti plect z popelari pouzivaji pojem regenerace pameti(storage regeneration) coz zni jepe ale je to to same. Algoritmu na to je nekolik. priklad: Ja ve svem interpretru si u kazdeho objektu pamatuju kolik objektu na nej ukazuje. Pokud cislo klesne na 0 objekt rusim pritom snizim cislo vsem objektum na ktere ukazuje a tam cely proces opakuju. Je to rychle a elegantni reseni ale je tezke to v interpretru odladit obcas na objekt sice zadny bezny objekt neukazuje ale pouziva ho interpretr-hlavne objekty vznikle po read a eval. Musim tedy to cislo zvetsit jako kdyby nekdo ukazoval. Take kdyz se objekt zmeni-zacne ukazovat jinam musim zapracovat. Proste neni to uplne jednoduche. Treba emacs to resi jinak. To tam objekty vesele nechava a teprve kdyz ma pocit ze pameti je malo napise garbage collecting a projde celou strukturu objektu oznaci je a neoznacene smaze. Myslim ze toto reseni je mnohem pomalejsi narocnejsi na pamet ale jednodusi na odladeni. Take je nutne si v lispovych programech hlidat promene a nastavovat jim nil aby se vymazaly z pameti kdyz uz nejsou treba. Proste uvolnovani pameti po promenych neni tak uplne automaticke a samozdrejme jako v cecku a je treba se vic hlidat.
3. Prefixova matematika je dost neprehledna a setq misto = taky prehlednosti moc neprida. Je to tim ze lisp nebyl navrzen jako drtic cisel. Proste lisp oplyva zavorakmi a v editoru ktery neukazuje co jste prave uzavreli jste ztraceni.
4. V lispu neni moc standartu-clisp je moc rozsahly aby kazdy toolkit ho implementoval. Scheme je zase moc jednoducha a lispari si na ni nechteji zvyknout. Proto kdyz z clispu prejdete na emacs musite se ucit novou knihovnu. Je to sice problem na chvili ale situaci to stezuje.
5. Presto ze interpretace lispu je rychla je tu problem z knihovnamy. Bezny programator lispu pousti jednu knihovni funkci za druhou a ty uz jsou relativne pomale protoze jsou taky interpretrovane Proto je nutne nejdulezitejsi zasti knihoven implementovat jako primitivni funkce v cecku aby se dosahlo rozumne rychlosti.
6. Velky pocet objektu z ruznymi daty navic a vsechny dynamicky alokovane celkem sezere pamet. Proto velke programy v lispu jsou narocnejsi na pamet(emacs)

Na druhou stranu lisp je skvely na psani programu u kterych presne nevite co chcete-treba toolkitu na hru kde presne nevite jake hry v nem budete delat nebo nejaky vyvoj treba umele inteligence kde potrebujete rychle a jednoduse program ladit a menit. Programy co by mely byt rozsiritelne.

Ze vsecho nejlepsi je to kombinovat-treba abuse co grafiku,zvuky a animace dela v cecku a ovladani panacka ostatnich priserek,editor levelu a podobne veci co se pri dalsi hre zmeni ma udelane v lispovi. Nebo emacs co ma v cecku opravdu jen kostru a vsechny funkce editoru - treba pro programovani: barevna syntaxe, doskakovani na zavorky, indentovani tedy vylepseni upravy zdrojaku, zpousteni kompileru a rozebirani chyboveho vystupu, interface do debuggeru,spelling chcek apod. Je napsan v lispovi je tedy ve forme knihovny co muze pouzit jak uzivatel tak programator co dela interface treba pro novy kompiler. Taky se lisp moc hodi na odzkouseni ruznych strestenych napadu jako jsou objekty, navrh noveho jazyka, vyvoj umele inteligence nebo jine zajimave vedevke projekty.

Proste lisp ma smysl umet stejne jako cecko. Jsou to dva moc dobre jazyky a kazdy se hodi na neco. Tim hodlam skolicky o lispu uzavrit a venovat se lispovym jazykum jako tcl apod.