Vlákno názorů k článku LISPová makra aneb programovatelný programovací jazyk od anonym - Je pravda že programátoři kteří dělají v Lispu...

No, myslím, že pokud taková firma skutečně existuje (možné to samozřejmě je, i když si nemyslím, že by to bylo příliš pravděpodobné), nevypovídá to nic o programovacím jazyku jako takovém, ale spíš o programátorech, který daný problém řešili...

Čím je problém komplikovanější a řešení rozsáhlejší, tím víc se stírají rozdíly (v kategorii množství kódu) mezi jednotlivými programovacími jazyky. Stejně jako cokoliv jiného, ani tohle tvrzení určitě neplatí pro zcela všechny programovací jazyky, ale pro většinu by myslím bylo možné je i exaktně dokázat. Stojí za ním totiž úvaha, že i když nějaký jazyk sám o sobě nabízí nějaké podstatné výhody, je většinou možné si vytvořit jejich kopii v jiném programovacím jazyku... Pro malá řešení bude taková kopie samozřejmě podstatnou částí řešení... ale čím je řešení rozsáhlejší, tím se ona kopie stává méně a méně podstatnou a zbylý kód je rozsahem velmi podobný...

Pokud je to možné, můžete prosím uvést konkrétní jméno firmy?

ITA Software. A vůbec to není nepravděpodobné, oni neprogramovali žádné účto.

"Čím je problém komplikovanější a řešení rozsáhlejší, tím víc se stírají rozdíly (v kategorii množství kódu) mezi jednotlivými programovacími jazyky."

Legrační. Copak by na to řekli jejich zaměstnanci?

Díky za odkaz. Máte s tou společností nějaké bližší kontakty nebo čerpáte čistě z jejich webu? Používají zajímavou kombinaci jazyků, ale protože vím, jak se vytvářejí podobné PR prohlášení či webové stránky, neviděl bych za tím snahu o efektivitu. Já vím, jsem pochybovač, ale asi to bude tím, že prostě mám dlouhodobější kontakt s realitou. Ovšem, je možné, že na společnost máte nějaký užší kontakt a oni na svých stránkach skutečně nemají běžné reklamní cancy, ale pravdu (je to tak řídký jev, že se blíží zázraku, ale nemožné to není).

Společnost, kde nyní pracuji by mohla mít podobné stránky (zkracuji):

používáme různé technologie:
RPG - protože nám dává maximální kontrolu nad systémem AS/400
Visual Basic - pro rychou tvorbu aplikací a maximální uživatelskou přívětivost
C++ - pro maximální výkon
Java - pro vysoký výkon a snadou přenositelnost serverových aplikací

Skutečnost je ovšem taková - používáme tyhle technologie z historických/pragmatických důvodů. RPG používáme, protože se historicky v ničem jiném pořádně na AS/400 pracovat nedalo. Visual Basic - prostě jsme potřebovali řešit problém a byl k dispozici programátor se znalostí dané domény, který pracoval v VB. Céčkové programátory má skoro každá společnost.
Téměř veškeré nové věci ovšem děláme v Javě (jedna věta ze stránek oné společnosti mě utvrzuje v tom, že oni na tom budou podobně: We began our project with a mix of Perl, Lisp and Java, but have since migrated to a pure Java codebase.)

Když máte velkou bázi kódu např. v RPG, nezačnete ho z ničeho nic přepisovat do Javy. Protože to nikdo nezaplatí... Zákazníky v podstatě nezajímá, v čem je daný produkt vytvořený (až na módu okolo J2EE v posledních letech), ale jak funguje, jak je spolehlivý, rychlý a jak je drahý...

Co se týče poslední věty... zkuste se skutečně zamyslet nad oním tvrzením... zkuste ho třeba rozporovat (může z toho být zajímavá debata :-) )... "Legrační" není přeci argument...

"Téměř veškeré nové věci ovšem děláme v Javě (jedna věta ze stránek oné společnosti mě utvrzuje v tom, že oni na tom budou podobně: We began our project with a mix of Perl, Lisp and Java, but have since migrated to a pure Java codebase.)"

Jistě jste si také všiml, že tahle věta se týká jakéhosi "Dataspace Browseru", což je jen jeden z mnoha jejich projektů, a že v Javě dělají web, protože na to jsou frameworky. Myslím, že přepisovat jádro search enginu by je v životě nenapadlo, protože na to žádné frameworky nejsou a nebudou, natožpak v Javě (se stále ještě nedostatečným JITem a s nepříliš pohodlným rozhraním k nativnímu kódu).

Jejich hlavní produkt ("IDOS pro celosvětové letecké spoje") začal vznikat jako nový (!) lispový projekt někdy kolem roku 2000 s cílem nahradit levnějším (Lintel clustery) a lepším (algoritmy) softwarem původní mainframové vyhledávače, které tyhle věci dělají někdy od sedmdesátých let.

Spousta zajímavých informací pochází z interního emailu a myslím, že ještě později se objevily nějaké zajímavé informace ze zákulisí, ale narychlo to nedohladám. Když se to začalo před lety vynořovat, tak jsem to sledoval.

RPG je na svou oblast použití zřejmě dost použitelný jazyk, stejně jako asi i Java, pokud jde o psaní pro konkrétní aplikační platformu. S J2EE jsem naštěstí do styku nepřišel a ani o to nestojím, musel bych si pro slušný vývoj asi dokoupit do desktopu další giga paměti a na to jsem moc líný. :-)

Apropos kompaktnost a rychlost vývoje...kdysi na to vznikla zajímavá studie, ale možná by stálo za to ji zopakovat. Každopádně C++ a Lisp se od té doby moc nepohnuly, takže jejich vztah ve výsledku by neměl být tolik ovlivněn, ale tohle je hloupé hádat, že. Java snad od té doby na ten plyn aspoň trošku přišlápla.

uz davno som nevidel takyto ukazkovy priklad srackoveho vyberu technologii ktory isto spravil nejaky kravatkovy manazersky blbecek.

V Lispe, data su kod, a kod su data. To pre teba ale neznamena nic lebo vies trt barani o skutocnom programovani.

Az Oracle bude krome Pro*C, Pro*C++, Pro*COBOLu, ODBC, JDBC, DBI, ... driveru dodavat i nejaky Pro*LISP, tak o tom zacnu uvazovat.

Vzhledem k tomu, kde pracuji, pro me rozmezi mezi hrackou a nastrojem je, zda v tom napisu aplikaci bezici proti Oracle databazi. YMMV.

Wow! :-D To by člověk nečekal, co? ;-)

Jenže počet řádků kódu není jediné kritérium. Kolik například stáli ti vývojáři? Co se stane, když všichni zahynou? Dokáže to po nich ještě někdo přečíst? Nemohu si pomoci, ale mně Lisp moc čitelný nepřijde. Kdyby to naprasili v Perlu, tak by těch řádek taky mohlo být málo, ikdyž je mi jasné, že Lisp není zdaleka takové zvěrstvo. Psaní vlastních jazyků mi z hlediska flexibility týmu přijde jako dost velké riziko - proč se mám učit nějaký nový jazyk, ve kterém se rochní Pepa od vedlejšího stolu a jinak ho nikdo nezná a proč by se měl Pepa namáhat s jazykem, který jsem si vymyslel já sám?

Možná by se při bližším pohledu zjistilo, že by bylo výhodnější to napsat v Javě nebo C# (dnešní IDE se snaží ruční psaní minimalizovat) nebo, pokud se někomu nechce psát moc řádek, třeba v Pythonu nebo Ruby. A i v tom C++ se dá docela kouzlit.

Takže se mlčky předpokládá, že se deset průměrných vývojářů (== schopných ušmudlat něco v Javě), vyrovná jedinému člověku, který k využití svého potenciálu potřebuje lepší nástroj, případně si musí vyvinout vlastní, aby svůj nápad mohl zrealizovat? Já nevím, ale ve vědě a inženýrství rovnostářství nikdy tak nějak nefungovalo. Tohle "hraní na jistotu" mi nějak nejde dohromady s tím, že cestu k dnes masami využívaným vědomostem a výdobytkům někdo prokopat musel - a nebyl to žádný "Pepa od vedlejšího stolu", ani omylem. Ale jo, při smolení kódu pro webovky to může fungovat - je pravda, že tam se schopný lisper nepohrne. Ten půjde řešit jiné věci.

Mlčky se nepředpokládá nic, jenom se ptám, resp. si dovoluji tu bohorovnost zpochybnit. Že ten jediný člověk je schopný udělat práci za 10 průměrných vývojářů, je dost dobře možné. Že ale nějaký génius bude k dispozici vždycky, to už není jisté. Pokud ten program ale napíše geniální (a disciplinovaný) javista, bude firma v poněkud lepší pozici, dle mého názoru.

Myslim ze na to pozerate trochu zle...

Vytvorenie "noveho jazyka" je len prostriedok, nie ciel. Prostriedok ako dosiahnut vyzsiu citatelnost jazyka.

Urcite viete, ze jazyky sa od seba delia aj urovnou abstrakcie, ktoru poskytuju. Bezne jazyky maju datovu (a pripadne riadiacu abstrakciu - teraz si niesom isty tymito nazvami, ale o to nejde). V takom Cecku Pepa implementuje udajovu strukturu stromu, alebo prioritnej fronty. Niekam do dokumentacie napise ako s nou narabat - a hotovo... mame datovu abstrakciu. Vy pouzivate funkcie ako add_node a pod. a vobec vas nezaujima ako to Pepa vnutri naimplementoval. Ak Pepa odide, nic sa nedeje (ak je jeho implementacia korektna, samozrejme...).

Toto vsetko ma aj Lisp, plus ma nieco, co vami menovane jazyky nemaju, a to syntakticku abstrakciu. Tato abstrakcia vam umoznuje nie len vymysliet a implementovat datove struktury, ktore ostatnym ulahcia pracu, ale aj vytvorit "jazyk" na pohodlnu manipulaciu s nimi. A mnoho dalsieho...

Myslim ze je najdolezitejsie pochopit "krasu a silu" toho, ked nieje rozdiel medzi datami a programom. Ja by som uz Lisp nemenil za iny jazyk (len sa trosku bojim, ze budem musiet... drviva vacsina IT firiem v cechach a na slovensku zial nevie co je Lisp... kopaci kanalov s "modernymi" krompacmi ako Java, C# a pod...)

Pardon, oprava:
Vytvorenie "noveho jazyka" je len prostriedok, nie ciel. Prostriedok ako dosiahnut vyzsiu citatelnost kodu (programu).


Aha a toto, niektore z toho stoji za precitanie:
http://norvig.com/

Samozřejmě je možné, že se takový jazyk čas od času hodí. Ale to se dá zvládnout třeba pomocí Lexu+Yaccu nebo ANTLR. S pomocí nich podobných prostředků lze vytvořit spec. jazyk prakticky pro libovolný programovací jazyk, ikdyž chápu, že v Lispu je ta integrace se zbytkem aplikace z principu přirozenější. Na druhou stranu, např. v C++ je pomocí přetížení operátorů dosáhnout podobného efektu a dokonce i v C s pomocí preprocesoru si člověk podobné úlohy často může usnadnit i bez externích nástrojů.

Jazyk ako Lisp sa hodi podla mna vzdy (az na specialne pripady, ako driver alebo nejaka RealTime aplikacia - teda nieco blizke HW).

V Lispe nepotrebujete ziaden externy nastroj, to robi ten jazyk tym cim je... ale aspon ste uznali, ze je to uzitocne :)... ved preto sa o nieco podobne snazia aj ine jazyky. Skuste si ale predstavit to, ze nieje ziaden preprocesor, ziadne "pretazovanie" operatorov a pod... Ze mate jazyk, v ktorom mozete pisat kod, ktory generuje kod - a to bez obmedzenia nejakym inym jazykom preprocesora, ale presne takym istym jazykom do akeho kod generujete.

Meta-programovanie je mocna zbran, a "brana" do pre vas netusenych moznosti, ako vyjadrit svoje myslienky. Lisp je jazyk, ktory vam nehadze polena pod nohy. Vyberiete si paradigmu (proceduralnu, objektovu - CLOS, funkcionalnu... pripadne ich kombinaciu), ktora sa vam najviac pre dany problem hodi, upravite si jazyk tak, aby sa vam to co najlepsie, najrychlejsie a najcitatelnejsie pisalo...

Pretazovanie operatorov... ach jaj... keby ste len vedeli co vsetko mozete v lispe... :) Skusali ste niekedy implementovat v C++ matice a na pracu s nimi pouzit pretazene operatory? Ak nie skuste... hadajte kolko-krat sa skopiruje matica (objekt) pre napr: A = B + C; ... :)

btw CLOS: http://en.wikipedia.org/wiki/Common_Lisp_Object_System

Este jedna vec k syntaxi. Ak ju raz clovek pochopi, zisti ze vlastne nemoze byt moc ina... a co je dolezitejsie, so spravnymi editormi (parent-matching a automaticke odsadzovanie) sa stane velmi mocnou zbranou. Len z tvaru funkcie sa da zistit, ci je pisana funkcionalne alebo proceduralne :)... ale to len tak btw...

Nebojte sa Lispu, na vysokych skolach je znasilnovany k uceniu funkcionalneho programovania... verte mi... ja som Lisp na skole nenavidel, ked nas ho "ucili"... nastastie som nezanevrel a isiel na neho uplne inak... a nelutujem...

Co se týče toho C++, tak tam se kopírování těch matic dít vůbec nemusí, pokud operátor pracuje s referencemi. ;-)

Například v Pythonu taky poznám hned, kdy se používá funkcionální, kdy procedurální a kdy objektové paradigma. ;-)

Já jsem na VŠ absolvoval kurs Lispu, dokonce je mi ten jazyk i v mnohém sympatický a lákají mě i další jazyky, ale to neznamená, že v těch jazycích budu chtít automaticky dělat věci, které mě živí. Chtěl jsem vyvolat zajímavou polemiku o některých otázkách spíše z pragmatického pohledu. Já netvrdím, že se v Lispu nedá nic pořádného udělat, akorát bych rád slyšel nějaké pádné argumenty, proč a kdy je dobré nasadit Lisp. Že Paul Graham programuje v Lispu, je asi jasné, ale pro mě z toho nic moc nevyplývá. Že nějaká firma X použila pro projekt Y jazyk Z a pochvaluje si to, také automaticky neznamená, že by to s jazykem W nezvládla lépe.

K tym maticiam este :)...

Asi som to trochu zle napisal... referencie pouzit ide, pretazi sa + aj =, a kopiruje sa ta nova matica, teda napr...

A = (B + C) + D;

B + C - jedna matica X

X + D - druha matica Y

A = Y

funguje to takto niejako, nie?... lenze B + C aj X + D musia tu maticu (X, resp. Y) vytvorit pomocou operatora new, to znamena v heape, nie na zasobniku (aby po ukonceni funkcie/operatora + stale existovala)... povedzte mi ako ju potom upracem, zmazem????

Ak je nieco zle na tom, co som tu pisal, tak mi povedzte, rad sa poucim (vazne, nemyslim to ironicky, je kludne mozne ze sa mylim) :)

Tohle se da vsechno obejit pres expression templates. Zhruba receno to znamena, ze treba operator+ nedela zadnou praci, ale vrati nejakou strukturu popisujici vypocet souctu dvou matric.

To je něco jako lazy evaluation svépomocí? ;-)

Pokud

Matice &A = B + C;

pak nikoliv. Samozřejmě ale předpokládám, že operator+ vytvoří novou matici, ale je možné změnit jednu z původních "in place" a vrátit referenci na ni. Každopádně si nemyslím, že by se tohle dalo vyřešit v nějakém jazyce výrazně lépe.

Abych řekl pravdu, na programování třeba expertních systémů mi více sedí jazyky typu Prolog, ale uznávám, že flexibilita Lispu by mohla v podobných případech pomoci. Podobně jako tng vidím ale největší brzdu v nedostatku vhodných knihoven (rychlý GUI prototyp udělám třeba v PyQt nebo PyGtk, v CL to asi tak snadné nebude a podobně v dalších oblastech - zkrátka CL nemá "batteries included" jako některé jiné jazyky), je ale třeba možné uvažovat o použití Lispu nad JRE, což by ten handicap poněkud snížilo. A vývojářů ochotních používat Lisp asi taky bude o něco méně, jak výše jmenovaný předřečník taky zmiňoval.

Takze k nasim maticiam :) V lispe by nebolo problem spravit makro, ktore by zobralo matematicky vyraz s maticami (kludne aj v infixe), a cele spocitavanie matic by sa rozlozilo na kod, ktory modifikuje jednu jedinu maticu... Napr.: (toto je len cisto hypoteticky priklad, ak sa nastvem tak vam to mozno aj nakodim ;)

(with-matrix (A B C D)
  (setf A (+ (+ B C) D)))

Staci napisat funkciu na scitanie dvoch matic, ktore modifikuju tretiu:

(defun matrix+ (dest-matrix source-matrix-1 source-matrix-2)
  "nejaky kod co nasetuje dest-matrix")

Makro with-matrix by sa rozlozilo na nieco taketo (jeho kod by myslim nebol zlozity, nejaka ta rekurzia):

(progn
  (matrix+ A (matrix+ A B C) D)
  A)

Toto je samozrejme len nacrt, nechce sa mi to teraz kodit :)... len som chcel demonstrovat, co vsetko je mozne s lisp makrami... a sak o tom je aj tento clanok, nie?

Btw: toto len pre toho koho to zaujima... myslim ze vo forme (seft A ..bla bla..), v tom ...bla bla.. by sa v tomto pripade nemohlo pouzit samotne A, lebo funkcia matrix+ robi na A side-effect...

Pre niekoho kto by nechapal o co mi islo... to makro by mohlo vyzerat kludne aj takto:

(with-matrix (A B C D)
  (A = ((B + C) + D)))

A este k tym GUI... no hej, existuje ich par:

http://www.cliki.net/Graphics%20Toolkit

Ale pravda je, ze o klavite a rychlosti niektorych z nich by sa dalo polemizovat... ja pouzivam vyhradne REPL ked pracujem so svojimy programami... ked som potreboval nieco jednoduche vykreslit, pouzil som LTK (Tcl/Tk binding, mnou trosku upraveny... uznavam ze to nieje nic moc...). Inak kniznic do CL je hromada a na vselico, doporucujem popozerat spomenute www.cliki.net

V C++ řešit práce s maticemi pomocí overloaded operátorů není dobré řešení, ale budiž, někomu se na to může hezky koukat.

Jen reference nevyřeší vše. Ještě přidám jeden způsob "kopírování" matic. Při overloaded operatoru+ se nevrátí class "matice" ale jiná (třeba zděděná) struktura, kterou nazveme třeba "generovana_matice". A tím dáme v compile-time najevo, že do takovéto matice se dá "hrabat", není const, můžeme do ní zapisovat následující výsledek a že smíme její data ukrást pro cíl.

Technicky, předpokládám, že class "matice" neobsahuje vlastní data, ale jen odkaz na alokovanou strukturu, plus nějaké info o rozměrech. V copy constructrou se pak nemusí udělat new a memcpy, stačí zkopírovat pointer (z generované matice).

A kdybych to chtěl dotáhnout fakt až do konce, tak i info o rozměrech přesunu do onoho alokovaného prostoru a class matice i generovana_matice je jen pointer na data. Proč to? Protože pokud mám dobrý kompilátor (umí to i borland 5.0 z před 12 lety) a pointer má stejný sizeof jako int, tak kompilátor dokáže divy - při return matice nealokuje žádné extra místo na stacku, celý class (4 bytes) vrátí via (E}AX;

Potom např. deklarace "matice A=B+C;" provede _jediný_ construktor, kterým je právě jeden copy constructor. A bude-li to z "generovane_matice" tak copy constructor sestává z překopírování ukazatele. Vše. Přičemž overloaded operator+ provede new pro cílová data B+C.

Obdobně, "matice A=B+C+D;" provede nejprve B+C, vrátí generovanou matici. Pak se provede (jiný) overloaded operator+ (generovaná_matice&, const matice& D) který přímo do generované (tedy už bez new) přičte D. Nakonec se obdobně jako v předchozím odstavci copy constructorem vyplní A (opět jen kopie pointerů, ne dat).

Pokud bychom nepoužili sčítání při dekladaci A, ale až později přiřazení:
matice A;
... něco...
A=B+C+D;

tak přibude navíc volání default constructoru A (při deklaraci) ... pravděpodobně vyplnění 0 do pointeru na data. Následně pak overloaded operator= (přiřazení do A) by se nejprve pokusil smazat stará data (zde pointer 0, delete neproběhne, ale kontrola tam být musí pro jiné případy) a pak do toho pointeru se dal hodnotu pointeru z generovana_matice. Tedy opět žádné new a kopie dat matice.
---
Všechny příklady předpokládají, že po přesunu pointeru z generované matice se její pointer nuluje. Ale i tak se při destrukci generované matice musí jistotu kontrolovat a při nenulovém delete data. To jen pro případ, kdybychom jen tak napsali "B+C+D;" bez přiřazení. Nejsem si totiž jist, zda při takovém šíleném overloadování se dá v comile-time jednoznačně určit, že jde o nonvolatile operace a že si kompilátor může dovolit celý výraz nevykonat.

A honem honem se opravím - upřesním.
... deklarace "matice A=B+C;" provede _jediný_ construktor ...
Má být jediný (copy) constructor _pro A_. Předtím se musí ještě vykonat constructor generované matice.

Tedy, že "matice A=B+C;" kompilátor přeloží jako "matice A(B+C);" a ne "matice A; A=B+C;"

Toť otázka.

1) Pro A=B+C; se vždy a ve všech prog. jazycích musí číst dvě matice {B,C) a uložit do alokované třetí (A). Pokud to nechci, tak použít třeba B+=C;

2) "new / malloc" bývá celkem optimalizované na rychlost. A to je jediné, čim se B+C liší od B+=C. Vždy se musí pushnout double z konkrétního místa C, pushnout double z konkrétního místa B, add, pop na konkrétní místo (B nebo A). FP operace se pokud vím stále nedokáží provádět přímo na cílovém místě v paměti - pokud se mýlím a umí to, tak se omlouvám (už to nějaký ten pátek nesleduji tak podrobně).

A teď co je rychlejší. FP add, sub, ..., nebo memory read & write. V dnešní době L1, L2, ... si netroufám odhadovat. Pravda, možná tady by se projevila výhoda "+=" oproti samotnému "+".

Prošel jsem několika programovacími jazyky, ovšem posledních 16 let programuji v C-like jazycích (jednoznačně převažuje C++).
V LISPu jsem napsal jenom několik velmi drobných studijích příkladů na vysoké škole.

On LISP, stejně jako jiné akademické projekty, není nezajímavý... je jen pro řešení většiny reálných problémů nepraktický... a myslím, že to velmi dobře odráží "mohutnost" skupiny jeho uživatelů...

Mohu se zeptat, jaké že "reálné problémy" to máš na mysli?

Pod pojmem reálný problém jsem měl na mysli požadavek z reálného světa (nikoliv akademický příklad) jako např.
- nejrůznější webové aplikace, např. eShopy, přímé bankovnictví, redakční systémy, zákaznické webové aplikace
- jakákoliv desktopová aplikace, browser, ftp klient, grafický editor, CAD aplikace, přehrávač multimédií, atd. atd. atd.
- výkonné serverové aplikace, databáze, webové servery, indexování obsahu, simulace proudění kapalin atd...

Ano, Autodesk kdysi zvolil pro svůj AutoCAD LISP coby interfacový jazyk (nevyplývá z toho ovšem ani v nejmenším, že by byl AutoCAD v LISPu napsán). Fakt, že takové Vámi popisované aplikace existují, je dle mého názoru daný tím, že AutoCAD se postupem času stal defacto standardem ve svém oboru a jiný interface nenabízel... Když není alternativa, je výběr jednoznačný ;-).... ovšem v jiných oblastech (kde alternativy jsou) LISP téměr nenajdete.

Pokud je mi známo (a to se můžu skutečně velmi mýlit, protože jde o oblast mi relativně vzdálenou), sám Autodesk od AutoLISPu upustil a už léta ho nerozvíjí (nemůže ho ovšem odstranit, když jak sám píšete existuje velká spousta aplikací, které ho využívají).

CAD software přinejmenším zčásti založený na Lispu nabízí ještě Fractal Concept, Design Power, Dassault... Spousta věcí v tomhle oboru ostatně vznikla na Lisp Machines...

Pokud se něco za posledních pár let nezměnilo, nesahá AutoLisp v možnostech tvorby aplikací pro Autocad C++ ani po kotníky (ObjectARX + OMF dovoluje "malinko" něco víc).

http://en.wikipedia.org/wiki/Viaweb

Podle me neprakticnost Lispu je zpusobena miniaturni komunitou, ktera nema silu napsat hromady knihoven a kvalitni multiplatformni implementace, dale samozrejme je asi skoro nemozne sehnat programatory ktere ho ovladaji. Sam o sobe mi ten jazyk ale neprakticky fakt neprijde ... Obavam se, ze clovek ktery napsal v Lispu par skolnich prikladu typu "vymaz zadany symbol ze zadaneho listu" apod. opravdu neni schopen ten jazyk rozumne posoudit. Z meho pohledu je Lisp jazyk ktery mi umoznuje se vyjadrovat na vysoke urovni abstrakce a tim psat strucny a vystizny kod ktery je blizky pseudokodu. V Lispu ma clovek moznost vyznamne zuzit propast mezi myslenkami a kodem.