Slyšel jsem, že v CADech, taky se používá v rozšířeních pro gimp a emacs.
Rád bych se tady zeptal, na co všechno se LISP používá, případně na co všechno by se dal použít?Zkusil bych odpovědět otázkou: K čemu se používá třeba takový Excel či ooCalc? Podle mne budou odpovědi hodně podobné právě kvůli univerzálnosti Lispu. Lisp je Turingův stroj postavený na stromu. Lze v něm naprogramovat téměř vše, co si lze představit.
Zkusil bych odpovědět otázkou: K čemu se používá třeba takový Excel či ooCalc? Podle mne budou odpovědi hodně podobné právě kvůli univerzálnosti Lispu. Lisp je Turingův stroj postavený na stromu. Lze v něm naprogramovat téměř vše, co si lze představit.Ano. LISP je velmi univerzalni. Dokonce jsem cetl, ze to byl prvni jazyk, ve kterem se dalo programovat stylem OOP. To me docela dostalo.
Lisp je Turingův stroj postavený na stromu.Lisp nevychází z turingova stroje. Lisp vychází z lambda kalkulu a to je jiný teoretický model než turingův stroj (ale jsou výpočetně ekvivalentní).
Ano. LISP je velmi univerzalni. Dokonce jsem cetl, ze to byl prvni jazyk, ve kterem se dalo programovat stylem OOP. To me docela dostalo.
Je tu pro lisp nějaký editor/IDE který dokáže zformátovat kód? Jsem z netbeans zvyklí nějak sprasit kód, poté zmáčknout ctrl+alt+f a kód je najednou přehledenej... existuje něco podobného pro lisp?Ten kód se dá docela dobře prasit přímo v Lispu, bez potřeby dalšího editoru. Samozřejmě je možné použít klasiku Vim nebo Emacs. Ve Vimu příkaz =%.
K bodu 5: Souhlasím s tím, že párování závorek pomůže "rozšifrovat" zdrojový text, nicméně to neznamená, že se tím program stane výrazně čitelnějším. Čitelnost znamená "kouknu se a vidím" a ne "otevřu si editor, jezdím kurzorem sem a tam a hledám".
...
Zkrátka a dobře, vždycky je to něco za něco. Obrovská flexibilita LISPu je výhoda, o tom není sporu. Problém "metajazyků" typu LISP je dvojí:
Možná bych původní otázku doplnil o svůj stop-problém (ať se taky někam dostanem :) ) -> jak normálně udělat GUI v LISPu?
Nedávno jsem si trochu hrál s programovacím jazykem LISP. Docela mě překvapilo, jak je jednoduchý a přitom univerzální.
Rád bych se tady zeptal, na co všechno se LISP používá, případně na co všechno by se dal použít?
LISP = Lost In Stupid Parenthesis, ale k tomu si musíte dojít sám, až Vás opustí to počáteční nadšení ;D
LISP = Language Intended for Smart People, ale k tomu inteligencí méně obdaření jedinci nemohou dojít nikdy ;-)
6) ma to zvrhlou obracenou syntaxi - ano, syntaxe v podobe "OPERACE OPERANDY" vypada spise jako assembler, nez jako vyssi jazyk, ale zdani klame - prave a pouze diky tato syntaxe lispu dava jeho silu.
[...]
... a ze by navic znemoznila spoustu skvelych jazykovych konstrukci.
je mi jasné že LISP je z pohľadu teórie veľmi flexibilný
6) ma to zvrhlou obracenou syntaxi - ano, syntaxe v podobe "OPERACE OPERANDY" vypada spise jako assembler, nez jako vyssi jazyk, ale zdani klame - prave a pouze diky tato syntaxe lispu dava jeho silu.
[...]
... a ze by navic znemoznila spoustu skvelych jazykovych konstrukci.
Můžu se zeptat, jak by syntaxe (!) mohla dávat jazyku sílu, popř. znemožňovat nějaké konstrukce?
Jestli prefixová notace dává LISPu sílu, tak to znamená, že postfixový Forth tu sílu nemá? Nebo v čem je teda zakopaný pes?
(nemám absolutně v úmyslu rozjíždět jakýkoli flame, otázku myslím naprosto vážně)
myslím, že tady se jedná o narážku na LISPová makra.
jde o to, že příkazy LISPu jsou syntakticky (i sémanticky) LISPové listy (seznamy) a ty je možné on-the-fly generovat a spouštět. V makrosystému daného jazyka tak máte zároveň zabudovanou i možnost pustit libovolnou funkci jazyka a z toho vyplývá označení LISPu za "programovatelný programovací jazyk". Tímto způsobem je možné v LISPu nadefinovat svoje vlastní syntaktické konstrukce (formy) bez nutnosti modifikovat kompilátor.
LISP = Language Intended for Smart People, ale k tomu inteligencí méně obdaření jedinci nemohou dojít nikdy ;-)
Dosť bolo teórie o tom aký je lisp úžasný jazyk, je mi jasné že LISP je z pohľadu teórie veľmi flexibilný, ale je lisp použiteľný aj v praxi? Mohol by sem nejaký znalec jazyka LISP napísať čo konkrétne sa dá v LISPe robiť? aké sú pre LISP frameworky knižnice, prostredia atď. či pre lisp existuje nejaký základný framework, nejaké frameworky na tvorbu GUI, MVC webové frameworky, entreprise frameworky, ORM frameworky, Frmeworky na prácu s grafikou, multimédiami, hrami atď. a či pre lisp existuje podobný archív knižníc ako napr. CPAN pre perl? Čo sa týka vývojového prostredia v akých IDE sa vyvýjajú LISPové aplikácie? Je pre lisp nejaké RAD vývojové prostredie, ktoré by umožňovalo podobne rýchly vývoj aplikácií ako NetBeans, IntelliJ IDEA, alebo Visual Studio? Keby som si vybral LISP znamenalo by to že by v tom programátori dokázali písať aplikácie rýchlejšie a za nižšiu cenu ako v .NET alebo Jave?
Druhá věc potom je, jestli tohle náhodou nebyla výhoda v jisté době a jiné jazyky ji už nedotáhly, přičemž mají jiné výhody... Jestliže např. jazyky pro CLI (.NET, mono) mají možnost on-the-fly přeložit zdroják a poté ho v rámci téhož programu spustit, nedává mi to úplně stejné možnosti i bez (sorry za to...) opruzu se závorkama?*
(znovu opakuju, že LISP neznám, takže se rád nechám přesvědčit, že umí něco, co např. ony CLI jazyky ne - ale potřeboval bych to polopaticky a pokud možno na konkrétním příkladě...)
-----
* teoretickou možnost on-the-fly pozměnit překladač tak, že místo závorek můžu psát třeba P a K je sice prima sranda, ale je to i k něčemu praktickému?
Nechci se vás nikterak dotknout, ale co vás tedy vede k polemizování o něčem, co dle svých vlastních slov neznáte?
Přeložit zdroják a pak ho spustit vám opravdu ani zdaleka nedává ty samé možnosti, jako je to v LISPu.
myslím, že tady se jedná o narážku na LISPová makra.
jde o to, že příkazy LISPu jsou syntakticky (i sémanticky) LISPové listy (seznamy) a ty je možné on-the-fly generovat a spouštět. V makrosystému daného jazyka tak máte zároveň zabudovanou i možnost pustit libovolnou funkci jazyka a z toho vyplývá označení LISPu za "programovatelný programovací jazyk". Tímto způsobem je možné v LISPu nadefinovat svoje vlastní syntaktické konstrukce (formy) bez nutnosti modifikovat kompilátor.
Ok, to beru. To ale není vlastnost syntaxe, to je věc toho, jakým způsobem pracuje interpreter/kompiler.
I když LISP neznám, docela mě bije do očí tvrzení, že síla LISPU je v syntaxi, která ale nehraje žádnou roli, protože ji jde on-the-fly změnit ;)
Druhá věc potom je, jestli tohle náhodou nebyla výhoda v jisté době a jiné jazyky ji už nedotáhly, přičemž mají jiné výhody... Jestliže např. jazyky pro CLI (.NET, mono) mají možnost on-the-fly přeložit zdroják a poté ho v rámci téhož programu spustit, nedává mi to úplně stejné možnosti i bez (sorry za to...) opruzu se závorkama?*
(znovu opakuju, že LISP neznám, takže se rád nechám přesvědčit, že umí něco, co např. ony CLI jazyky ne - ale potřeboval bych to polopaticky a pokud možno na konkrétním příkladě...)
Jaké možnosti konkrétně? (bez jinotajů typu srovnání s reálnými a komplexními čísly prosím, já jsem jednoduchý člověk :)
Pokud mám možnost vygenerovat zdroják turingovsky kompletního jazyka a spustit ho *v rámci daného procesu*, nenapadá mě moc *praktických* věcí, které bych tímto způsobem nemohl udělat...
můžete si v těch CLI jazycích nadefinovat svoji vlastní konstrukci typu "for" nebo "while"?
nemyslím teď vlastní funkci, ale konstrukci, kterou byste v programu vždy pohodlně zapsal jako (while podminka telo-cyklu) a ona se chovala jako while-cyklus, tedy podmínku vyhodnotila vždy při jejím testu znovu... a přitom by nešlo o věc zadrátovanou přímo v jazyce, ale věc, kterou jste si takto napsal sám. tak přesně tohle dovedou lispová makra, viz můj článek
http://www.root.cz/clanky/lispova-makra-aneb-programovatelny-programovaci-jazyk/
Stále si nerozumíme. LISP je jazyk určený lidem k programování, ne cvičeným opicím k lepení kódu. :D
můžete si v těch CLI jazycích nadefinovat svoji vlastní konstrukci typu "for" nebo "while"?
nemyslím teď vlastní funkci, ale konstrukci, kterou byste v programu vždy pohodlně zapsal jako (while podminka telo-cyklu) a ona se chovala jako while-cyklus, tedy podmínku vyhodnotila vždy při jejím testu znovu... a přitom by nešlo o věc zadrátovanou přímo v jazyce, ale věc, kterou jste si takto napsal sám. tak přesně tohle dovedou lispová makra, viz můj článek
http://www.root.cz/clanky/lispova-makra-aneb-programovatelny-programovaci-jazyk/
To je asi argument, který se uživateli CLI [...] asi těžko vysvětluje.
Pádnější by mohly být argumenty [...]
nemyslím teď vlastní funkci, ale konstrukci, kterou byste v programu vždy pohodlně zapsal jako (while podminka telo-cyklu) a ona se chovala jako while-cyklus, tedy podmínku vyhodnotila vždy při jejím testu znovu... a přitom by nešlo o věc zadrátovanou přímo v jazyce, ale věc, kterou jste si takto napsal sám. tak přesně tohle dovedou lispová makra, viz můj článek
http://www.root.cz/clanky/lispova-makra-aneb-programovatelny-programovaci-jazyk/
http://www.zorched.net/2009/04/26/scala-and-adding-new-syntax/
S Lispem teprve začínám, takže mi spousta souvislostí zatím uniká, ale zkusil jsem si jednoduchý tutoriál na http://lisperati.com/casting.html . Stačí, když si projdeš tím kurzem a dostaneš odpovědi na mnoho otázek.
Je velmi těžké změnit zažité paradigma programování, i když procedurálně se v Lispu dá také psát.
Příjemně mě překvapila možnost vyvíjet aplikaci bez editoru přímo v prostředí Lispu. Jakmile funkci odladím, je zakomponována v systému a mohu ji použít jako další stavební kámen aplikace. Také je možné přidat i automatizované testy, pokud je pro vývoj potřebuješ. Přirovnal bych to k Excelu, ale bez omezení daného plochou tabulky.
A ako to súvisí s otázkou? Stále sa tu len teoretizuje, ale aká je využiteľnosť jazyka v praxi? Prečo keď je LISP taký perfektný jazyk, tak sa nepožíva vo vačšej miere? Ja som si tiež lisp vyskúšal, ale nenapadlo ma načo by som ho mohol použiť. vypisovalo to do konzoly nejaké písmená. Väčšinu knižníc ktoré robia niečo užitočnejšie si ajtak musím naprogramovať v inam jazyku a v lispe ich len pozliepať, neni potom náhodou skriptovanie v lispe len lepenie kódu?Lisp svou základní syntaxí odradí hodně začátečníků. I mně se to stalo. Není vůbec jednoduché pochopit jeho možnosti a schopnosti a využít je ve svůj prospěch. Dá se v něm programovat i stylem známým z mnoha jiných jazyků, ale takové programy jsou často mnohem delší a méně efektivní, než by mohly být. Tato zkušenost odradí experimentátora od dalších pokusů a raději se vrátí k zažitým postupům.
Lisp svou základní syntaxí odradí hodně začátečníků. I mně se to stalo. [...] Programování v Lispu se jen velmi těžko popisuje [...]
Není vůbec jednoduché pochopit jeho možnosti a schopnosti a využít je ve svůj prospěch. [...] ale takové programy jsou často mnohem delší a méně efektivní, než by mohly být. Tato zkušenost odradí experimentátora od dalších pokusů a raději se vrátí k zažitým postupům.
No super, konečně něco konkrétního o nějakém prospěchu :)
No super, konečně něco konkrétního o nějakém prospěchu :) Takže v LISPu se (údajně) programuje rychleji, zdroják je kratší a výsledek efektivnější. Sice nechápu, proč by takové super vlastnosti experimentátora měly odradit, ale ok :) Pak nám tedy zůstává otázka, proč firmy, které lidem za programování platí, nechtějí, aby jejich zaměstnanci pracovali rychleji a výsledek byl efektivnější. Není to třeba špatným marketingem? ;)
Nechtěl jsem do toho zasahovat, ale to, že je ten les závorek nečitelný, to je naprostý blud.
Základní rozdíl mezi tím vaším "metajazykem" Lisp a třeba céčkovými typy jazyků je ten, že v lispu má každý řádek hutný význam, natož céčkové zdrojaky jsou roztahané, plné deklarací a podobně. Tudíž z toho plyne, že kolikrát kratičká funkce napsaná v lispu dělá to samé, jako 100 řádků v céčku a časově pro pochopení té funkce a proletění 100 řádků to vychází na stejno, ne-li pro lisp na kratší dobu. V tom je ten Váš "závorkový problém" a kolikrát mám problém s čitelností v mých programech, třeba, když se používá více cyklů v maticích a potřebuji těch matic více a z firmy mi napíší třeba po půl roce, že je to třeba upravit... (foreachem to udělat nejde a prasácky to napsané taky není)
Prefix/infix/postfix neřeším. No comment, to není problém jazyka, ale Vás, omluvte mou prostořekost.
Rozšiřitelnost a agnosticismus. No, já nevím, tento jazyk byl a zřejmě bude vždy pokusným prostředím pro konstrukty pro ostatní programovací jazyky. Razí teorii, která se mi velmi líbí a to: "Pokud máme tu možnost dát uživateli silné nástroje, tak mu je dejme." O tom svědčí samotná plná programovatelnost toho jazyka, možnost psaní maker, úprava všech částí REPLu. Vím, že určitě nastane připomínka: "A co bezpečnost jazyka?". Většina lidí, co v tom někdy něco lehce dělala o tom ani neví, takže to nemohou ani řešit nebo prostě na to nemají buňky. Zároveň takový "programátor" je cvičená opička, která se musí držet za ručičku, aby náhodou něco nepokazila.
považuji statické typy čím dál častěji za užitečnou vlastnost.
dobra poznamka, ja som s lispom prebehol nejake tutorialy a mne sa zda, ze velmi dlho trva, kym cele to "myslenie" spravne pochopite a ste schopni ho aplikovat do praxe. lisp je sice flexibilny, ale prave flexibilnost prispieva k neprehladnosti a vyvoj v tom jazyku moze trvat dlhsie ako v "konvencnom", proceduralnom, jazyku. peniaze = cas. cim ste schopni dodat funkcne riesenie rychlejsie, tym lepsie pre vas, az na specificke pripady jazyk nezohrava ulohu. ja myslim, ze programovanie v lispe, ked naozaj nieco chcete naprogramovat, je zdlhavejsie ...Tohle mi připadá velmi trefné. Kvalitní zápis programu v Lispu je sice vývojově zdlouhavější, ale výsledný kód je výrazně kratší a je efektivnější. Záleží na prioritách.
Kvalitní zápis programu v Lispu je sice vývojově zdlouhavější, ale výsledný kód je výrazně kratší a je efektivnější.
Dosť bolo teórie o tom aký je lisp úžasný jazyk, je mi jasné že LISP je z pohľadu teórie veľmi flexibilný, ale je lisp použiteľný aj v praxi? Mohol by sem nejaký znalec jazyka LISP napísať čo konkrétne sa dá v LISPe robiť? aké sú pre LISP frameworky knižnice, prostredia atď. či pre lisp existuje nejaký základný framework, nejaké frameworky na tvorbu GUI, MVC webové frameworky, entreprise frameworky, ORM frameworky, Frmeworky na prácu s grafikou, multimédiami, hrami atď. a či pre lisp existuje podobný archív knižníc ako napr. CPAN pre perl? Čo sa týka vývojového prostredia v akých IDE sa vyvýjajú LISPové aplikácie? Je pre lisp nejaké RAD vývojové prostredie, ktoré by umožňovalo podobne rýchly vývoj aplikácií ako NetBeans, IntelliJ IDEA, alebo Visual Studio? Keby som si vybral LISP znamenalo by to že by v tom programátori dokázali písať aplikácie rýchlejšie a za nižšiu cenu ako v .NET alebo Jave?
Pominu, že jsem se ptal na něco praktického - a definovat si vlastní while mi zrovna moc praktické nepřijde :)
LISP = Lost In Stupid Parenthesis, ale k tomu si musíte dojít sám, až Vás opustí to počáteční nadšení ;D
LISP = Language Intended for Smart People, ale k tomu inteligencí méně obdaření jedinci nemohou dojít nikdy ;-)
Tak jsem trochu googlil a zjistil jsem. Co rici zaverem. LISP se stava pouzivanejsim, jak je patrne z nekterych srovnavacich tabulek.
Chapu to spravne tak, ze LISP je dnes uz vlastne jen prostredek k tomu, aby se mohlo par asocialnich zivlu vymezovat a placat se po ramenou?
Tak to ukončeme. Na co se Lisp používá tu bylo řečeno.
P.S. Ty jo kluci, co je to "flame". Prelozeno z anglictiny je to "plamen". To jako znaci plamennou diskusi? Jako ze to je fakt horka diskuse? Nebo jako ze se kolem tematu rozhori velka diskuse?
To je jako by ses na srazu diskotékových DJs vyptával, co si myslej o Bachovi, jestli má smysl se jím zabývat a jestli má smysl učit se hrát na piáno. Asi takovou relevanci má diskuse o LISPu tady
To je jako by ses na srazu diskotékových DJs vyptával, co si myslej o Bachovi, jestli má smysl se jím zabývat a jestli má smysl učit se hrát na piáno. Asi takovou relevanci má diskuse o LISPu tady
Další zajímavá poetická parela do sbírky :) Skoro se mi zdá, že LISP člověka naučí hlavně tohle :)
Smím se zeptat, proč diskuse o LISPu tady nemá smysl? Je tu zjevně dost lidí, kteří o programovacích jazycích něco ví, s několika mají vlastní zkušenosti, včetně nějakých neprocedurálních, a pravděpodobně mají za sebou nějakou tu informatiku na VŠ.
V jakém už jiném prostředí by diskuse o LISPu měla smysl? V tom citovaném kroužku asociálů?
Je informatika a "informatika" a VŠ a "VŠ" - dneska se "informatika" učí na každé "VŠ", jinak by se jim tam nikdo nehlásil, protože přece informatika dneska frčí.
Nejlepší je se samozřejmě o tom pobavit a nejlépe názorně s někým, kdo se tím zabývá.
když se lidi, jako je např. Alan Kay vyjadřují o LISPu jako o [...]
Já jsem našel něco jiného: http://goo.gl/DDBnR (když si tam přidáš "C#", LISP úplně zmizí ze scény...)
Konkrétních argumentů jako šafránu, zato emotivních srovnání typu "jazyk pro programátory a ne pro cvičené opice", "reálná a komplexní čísla", "nářadí" habaděj...
Jako muzeme diskutovat konkretni aspekty. Me se treba hodne v CL libi system restartu (i kdyz jsem ho zatim nepouzil), a to je takova vec, ktera se bezne nezminuje. Co by te zajimalo? Vysvetleni konkretnich vyhod je zabavnou formou podane na http://landoflisp.com/ (http://landoflisp.com/).
No tak zase takovouhle formou to nemusím mít :)
Co by mě konkrétně zajímalo? Ta nejzákladnější otázka: proč bych měl Lisp použít? To mi to opravdu někdo neumí říct v deseti větách a přidat k tomu relevantní důkazy?
Kdybys kliknul na odkazy v tom komiksu, tak by ses mozna i neco dozvedel. Nicmene..
Nevim, co jsou "relevantni dukazy".
Ptas se jako programator, nebo kapitalista? Programator by se mel spis ptat, proc by se mel Lisp trochu naucit.
Co tak zásadně nového mě naučí lisp (především oproti prologu, haskellu a zmíněným formalismům)?
Makra.
Makra.
A co je na nich tak zásadně nového?
A co je na nich tak zásadně nového?
co je to system restartu? v skratke, nechce sa mi to hladat, (poprosim nejaky hutny vycuc :))
dakujem
Tak jsem trochu googlil a zjistil jsem. Co rici zaverem. LISP se stava pouzivanejsim, jak je patrne z nekterych srovnavacich tabulek.
Možná jsi použil špatné nástroje Googlu. Z jakých tabulek je patrné, že je Lisp stále používanější?
Take by me zajimalo nejake konkretni pouziti LISPu, jeho vyhod a prednosti. Treba v robotice. Mam tuseni, ze jsem cetl, ze je LISP selfprogramming language. Kdyby treba nekdo napsal: "Tak jsem na VS programoval robota, ktery delal to a to. Zkousel jsem ruzny veci a jazyky az jsem dosel na LISP a tam jsem to vykoumal tak, ze ten robot se uci z toho, co dela a vidi a sam si preprogramovava svuj vlastni system chodu. Takze ted dela to a to uplne jinak, chytreji a efektivneji a pritom se porad uci."
Ale mozna bych se mel podivat spise na nejake jine webove stranky, treba stranky skol nebo jine, ktere se zabyvaji umelou inteligenci, kdyz teda LISP se pouziva hlavne v teto oblasti.
Studoval jsem umelou inteligenci a robotiku a LISP se tam(podle me) pouzival proto, ze se dal bez nejakych serepeticek zapisovat rovnou algoritmus(nejake prohledavani stavoveho prostoru apod.) a vsichni studenti meli stejnou startovaci caru. Vic bych za tim nehledal.A proč ne? Copak v Lispu nejde udělat neuronová síť a k ní i proces učení?
Ale vzdyt se shodujeme.Studoval jsem umelou inteligenci a robotiku a LISP se tam(podle me) pouzival proto, ze se dal bez nejakych serepeticek zapisovat rovnou algoritmus(nejake prohledavani stavoveho prostoru apod.) a vsichni studenti meli stejnou startovaci caru. Vic bych za tim nehledal.A proč ne? Copak v Lispu nejde udělat neuronová síť a k ní i proces učení?
Zmínil bych jednu z výhod Lispu proti ostatním jazykům: Velmi rychlé prototypování. Každá funkce se dá ladit zvlášť a přímo do aplikace lze zakomponovat testování včetně automatických testů.
A důkazy? Ty jsou na http://lisperati.com , nebudu je opisovat.
Take by me zajimalo nejake konkretni pouziti LISPu, jeho vyhod a prednosti. Treba v robotice. Mam tuseni, ze jsem cetl, ze je LISP selfprogramming language. Kdyby treba nekdo napsal: "Tak jsem na VS programoval robota, ktery delal to a to. Zkousel jsem ruzny veci a jazyky az jsem dosel na LISP a tam jsem to vykoumal tak, ze ten robot se uci z toho, co dela a vidi a sam si preprogramovava svuj vlastni system chodu. Takze ted dela to a to uplne jinak, chytreji a efektivneji a pritom se porad uci."
Ale mozna bych se mel podivat spise na nejake jine webove stranky, treba stranky skol nebo jine, ktere se zabyvaji umelou inteligenci, kdyz teda LISP se pouziva hlavne v teto oblasti.
Každý... tahá pilku. (asi nekde v lese v horach) A pak si dá ... co mu přinese bernardýn v soudku na krku. ;D
(defun opposite (side)
(if (eq side left) (right) (left)))
(defun turn (direction angle)
(switch direction motor off)
(switch (opposite direction) motor on)
(delay (normalize-to-speed angle))
(switch (opposite direction) motor off))
Zkrátka nadefinuješ si funkci pro zatočení a hned si ji zkusíš. Když něco nejde, opravíš a zkusíš znova. Odladěnou funkci pak použiješ dál. [...] přímo za provozu pak můžeš měnit program, testovat nové funkce - žádná editace zdrojáku-překlad-upload do robota-zapnutí robota-vypnutí robota-a znova. [...] Reakce robota na podnět senzorů se může generovat makrem na základě předchozích zkušeností atp...
Ten kód co tvoříš je navíc dost hutný [...] Fakt je ten kus kódu tak šíleně nečitelný a nesrozumitelný, jak tu někteří tvrdí?Kód: [Vybrat](defun opposite (side)
(if (eq side left) (right) (left)))
(defun turn (direction angle)
(switch direction motor off)
(switch (opposite direction) motor on)
(delay (normalize-to-speed angle))
(switch (opposite direction) motor off))
def opposite(side):
if side==left: return right
return left
def turn(direction,angle):
switch(direction, motor, off)
switch(opposite(direction), motor, on)
delay(normalizeToSpeed(angle))
switch(opposite(direction), motor, off)
Broukoide, nic proti Tvému příspěvku jako celku, ale zejména body 5 a 6 mi přijdou trošku jako výmluvy či vytáčky.
K bodu 5: Souhlasím s tím, že párování závorek pomůže "rozšifrovat" zdrojový text, nicméně to neznamená, že se tím program stane výrazně čitelnějším. Čitelnost znamená "kouknu se a vidím" a ne "otevřu si editor, jezdím kurzorem sem a tam a hledám".
K bodu 6: Prefixová notace sice má svoje výhody, ale zrovna u aritmetických operací a podobných akcí to prostě je handicap. Výhody existují, ale například násobnou aplikaci operátoru lze v jiných jazycích vyjádřit pomocí fold/reduce. S problémem infixových funkcí si z jazyků, které jsem viděl, asi nejelegantněji poradily Haskell a Scala.
Zkrátka a dobře, vždycky je to něco za něco. Obrovská flexibilita LISPu je výhoda, o tom není sporu. Problém "metajazyků" typu LISP je dvojí:
Za ten výraz metajazyky si naliskej.
Závorky jsou bezva věc, syntaktickej orgasmus. Oproi dialektům LISPu se můžou jít vaše siiisharpy zakopat. Opět si liskni.
Prefixová notace je intuitivně i kalkulativně nad ostatními notacemi. Přece říkáme: "sečteme čísla 2 a 5 a 8" spíše než "vezmeme číslo 3, k němu příčteme 5, poté vezmem onen výsledek a k němu přičteme 8", to je tedy pěkný rozdíl v délce. Liskněte si potřetí.
Zmínil bych jednu z výhod Lispu proti ostatním jazykům: Velmi rychlé prototypování. Každá funkce se dá ladit zvlášť a přímo do aplikace lze zakomponovat testování včetně automatických testů.
Pokud třeba máte jazyk, který neumožňuje rozumně definovat přístupové metody pro atributy objektů, tak si můžete nadefinovat makro, které ty přístupové metody automaticky vytvoří. Něco jako:
(create-setters 'age 'name)
(create-getters 'age 'name 'job 'wtf)
…a to makro automaticky vytvoří metodu set-age, get-age apod.
Když tak ať nějaké víc hardcore příklady dá nějaký hardcore lispař ;-).
Docela zajímavé bylo makro, které umělo převádět rekurzivní funkce na iterativní verzi, pokud to šlo. Takže pokud bylo jednodušší napsat rekurzivní verzi než iterativní (třeba klasicky faktoriál), tak jste to mohli napsat rekurzivně a nechat to projet tím makrem.
Jo a omlouvám se, pokud všechno tohle lze běžně v jazycích dělat, já už moc přehled nemám, skončil jsem nakonec u C# a tam tyhle krávovinky fakt dělat nejdou.
A pro jistotu — hlavní rozdíl mezi makrem a klasickou funkcí je, že makro hned nevyhodnotí své atributy, to bylo vidět u toho příklad at-least-two. Proto jdou makrem zapsat věci, které by klasickou lispovou funkcí zapsat nešly.
Ty příklady jsou ale na demonstraci docela fajn.
Všechno tohle můžu v libovolném interpretovaném jazyce, který má eval... A dál?
A o co méně hutný je tenhle (Boo, Python)?Kód: [Vybrat]def opposite(side):Co z toho je srozumitelnější je samozřejmě věcí názoru, zvyku, atd., nikomu necpu svůj názor, že to první je daleko méně přehledné.
if side==left: return right
return left
def turn(direction,angle):
switch(direction, motor, off)
switch(opposite(direction), motor, on)
delay(normalizeToSpeed(angle))
switch(opposite(direction), motor, off)
Mně stále není jasné, oč ti jde.
Ptal se, jak se LISP uplatní třeba v robotice nebo obecně v embedded - dal jsem ten nejtriviálnější příklad, jaký si lze vymyslet.
Ta argumentace "ale tohle se dá udělat v XYZ taky.. a dál?" mi není moc srozumitelná. A co jako? Zmínil jsi jakýsi jazyk Boo. To se můžu mnohem smysluplněji ptát - k čemu je to dobré? Všechno, co zvládne Boo, se zvládne v LISPu taky a přinejmenším stejně jednoduše. O opačné inkluzi se dá s úspěchem pochybovat. Tak na co Boo? :D
Lispař nebude nikdy v diskusích žehrat na to, že mu v něm chybí nějaká vlastnost - tu výjimky, tu rozhraní, tu vícenásobná dědičnost, nebo když už se to tam dodá, tak že je to vymyšlené nešikovně.
(defmacro <- (fact &rest predicates)
`(lambda (variables) (when (and ,@(mapcar 'evaluate-vars predicates))
(set-variable variables
',(first fact)
(evaluate variables ',(second fact))))))
(defun evaluate-vars (pred)
`(,(first pred) (evaluate ,(second pred) variables)
(evaluate ,(third pred) variables)))
(defun evaluate (variables symbol)
(let ((value (get-variable variables symbol)))
(if value value symbol)))
(defmethod evaluate-loop ((regulator-control regulator-control))
(dolist (regulator (regulators regulator-control))
(force regulator (variables regulator-control))))
No tohle už je úplná zoufalost... Takže vlastně ostatní jazyky jsou špatné proto, že mají něco, co Lisp nemá, takže v Lispu si to člověk musí sám napsat, čímžpádem pak nenadává na to, že to někdo jinej napsal blbě.
Vraceni vice navratovych hodnot (coz z ostatnich jazyku pokud vim hezky umi jen Python), i kdyz zapis je ponekud pres ruku. Opravdu nevim (podobne jako u tech restartu) proc tak jednoduchou vec jeste nezavedly i ostatni jazyky.
Vy jste ta makra stale nepochopil.
(Kdyz jsme u toho, Viky zminil Forth - to je take jazyk, na ktery byste se mel podivat, ma k Lispu velmi blizko tim, jak je programovatelny.)
Vraceni vice navratovych hodnot (coz z ostatnich jazyku pokud vim hezky umi jen Python), i kdyz zapis je ponekud pres ruku. Opravdu nevim (podobne jako u tech restartu) proc tak jednoduchou vec jeste nezavedly i ostatni jazyky.
def f() as (string):Takže bez problému. Není to moc používané - asi to nikdo moc nepotřebuje...
return "a","b"
a,b = f()
Reader makra (a vubec cely koncept reader-printer) - v podstate vam umoznuje predelat si syntaxi totalne. Takze pokud chcete nejaky syntakticky cukr, neni problem si ho dovyrobit.
Zobecnene promenne - v podstate jde o neco podobneho jako lvalue v C, akorat si muzete definovat vlastni.
Japonština je geniální jazyk! Koukej: 器質性構音障害 - 音声器官における形態上の異状により引き起こされる発音上の障害。No není to paráda?! Kdo nevidí tu krásu, není real man, ale cvičená opice!
Vůbec to není hardcore lisp, normální 2 makra a jedna funkce.
No tak tohle konečně zní opravdu dobře a zajímavě! A to makro to umělo OBECNĚ? (jde to vůbec? Teď nějak nemám buňky nad tím přemýšlet…)Jo, obecně. Ale jde to jen u určitého typu rekurze, to jsem myslel tím "pokud to jde". Konkrétně to jde u koncové rekurze (http://en.wikipedia.org/wiki/Tail_call). Scheme to umí automaticky, Lisp pokud vím ne. Ale asi jsem dal špatný příklad, ten jednodušší zápis faktoriálu v koncové rekurzi není.
No až na ten převod na iterativní algoritmus tam všechno (nějak) dělat jde.Ono jde právě o tu eleganci, myslím si, že syntaktický cukr je hodně důležitý a Lisp umožňuje definovat prakticky jakýkoliv syntaktický cukr, jaký vás napadne, což je výhoda. I když asi i zároveň nevýhoda, když si každý Lispový programátor definuje vlastní syntaktické cukry, tak prase aby se v tom pak vyznalo :-).
No to zas taková bomba není - když už by to teda člověk tak strašlivě chtěl, stačí mu napsat něco podobného ICallable, co bude zároveň zapouzdřovat zdroják... Jasně, není to tak elegantní - no a? Copak je to něco, co používáme denně pětkrát?
Podle mě převod rekurzivní funkce na iterativní je to samé co optimalizace "tail rekurze" (což Lisp snad dělá automaticky, ne?). A C# má (podobně jako jiné jazyky) podporu pro líné vyhodnocování. Ty příklady jsou ale na demonstraci docela fajn.Jak jsem psal výše, myslím, že Lisp to nemá; Scheme ano. Co se týče podpory pro líné vyhodnocování — dá se v C# nějak napsat funkce(a+b) tak, aby se to a+b vyhodnotilo až uvnitř funkce? Nebo možná lepší příklad: mám funkci print(), která vypíše na obrazovku "ahoj". Můžu nějak napsat funkci fun tak, abych potom mohl napsat fun(print()) a na obrazovku se nevypsalo "ahoj"? Bez modifikace printu. V C# znám jen yield, ale to mi AFAIK nepomůže.
Daleko lepší mi přijde klasický koncept, kdy jazyk má přímo zabudováno 99.99% vlastností, které uspokojí 99.99% jeho uživatelů. A ti ostatní použijí nějaký jazyk vhodnější pro daný účel. No problem - nikdo netvrdí, že třeba CLI je vhodné na vše.Já bych s tímto v podstatě souhlasil, jen bych ubral procenta. On je problém, že většina programátorů se s makry nesetkala, nebo případně jen s Céčkovými makry. Těžko si řeknete, že kdybych programoval v Lispu, tak by to teď dalo krásně vyřešit makrem, když makra v Lispu vůbec neznáte. Takže jo, tenhle model mi taky přijde lepší, ale ubral bych tak na nějakých 90 %. Už jsem se i já sám přistihl, že jsem si v jiném jazyce řekl, že na tohle bych si v Lispu napsal krásné makro :-). Co to bylo už nevím.
Ok, tak co to teda dělá tak báječného? Vezme to zdroják a udělá to z něho spustitelnou funkci. A co se týče ***praktického použití***, tak se to od běžné evalu liší jak? Přijde mi, že leda tím, že to, co mi z běžného evalu vypadne, už nemůžu dál modifikovat. Tak fajn, no, to je pěkný - akorát jsem to zatím nikdy nepotřeboval. A to je teda všechno?Do evalu obvykle strkáte string, kdežto makra v Lispu jsou na úrovni syntaxe jazyka. Navíc následné použití maker je řádově jednodušší než parsovat předaný string. A pak tam bývá problém s prostředím. Když to předám jako string do evalu, tak se v Lispu (nevím jak jinde) nemůžu odkazovat na lokální proměnné, protože eval si to vyhodnotí ve svém prostředí. Nemůže napsat něco takového:
Jo, obecně. Ale jde to jen u určitého typu rekurze, to jsem myslel tím "pokud to jde". Konkrétně to jde u koncové rekurze (http://en.wikipedia.org/wiki/Tail_call). Scheme to umí automaticky, Lisp pokud vím ne. Ale asi jsem dal špatný příklad, ten jednodušší zápis faktoriálu v koncové rekurzi není.
Nebo si můžu vytvořit makro, které mi vytvoří definici celé třídy :-).
Ono jde právě o tu eleganci, myslím si, že syntaktický cukr je hodně důležitý a Lisp umožňuje definovat prakticky jakýkoliv syntaktický cukr, jaký vás napadne, což je výhoda. I když asi i zároveň nevýhoda, když si každý Lispový programátor definuje vlastní syntaktické cukry, tak prase aby se v tom pak vyznalo :-).
Co se týče toho ICallable — pokud to chápu správně, tak to mi jen pomůže v tom, že místo toho abych předal přímou hodnotu, tak ji musím předat buď jako objekt nebo jako funkci, což může být dost nepohodlné a makro je v tomto případě daleko jednodušší a elegantnější.
Těžko si řeknete, že kdybych programoval v Lispu, tak by to teď dalo krásně vyřešit makrem, když makra v Lispu vůbec neznáte.
Do evalu obvykle strkáte string, kdežto makra v Lispu jsou na úrovni syntaxe jazyka.
Navíc následné použití maker je řádově jednodušší než parsovat předaný string.
# kod ve stringu
code = """
def f(a):
print "Ahoj "+a
"""
# sem si ulozim vysledny objekt
globals={}
# prevod string -> funkce
exec code in globals
# ziskanou funkci si ulozim do lokalni promenne
f = globals['f']
# a spustim ji
f("Mirek")
# vysledek: Ahoj Mirek
A pak tam bývá problém s prostředím. Když to předám jako string do evalu, tak se v Lispu (nevím jak jinde) nemůžu odkazovat na lokální proměnné, protože eval si to vyhodnotí ve svém prostředí.
Vy jste ta makra stale nepochopil.
Z čeho tak usuzujete? Napsal jsem, že nevidím žádnou výhodu v tom, když jazyk nějakou vlastnost nemá, přestože je dostatečně flexibilní na to, aby si uživatel mohl (musel) tuto vlastnost psát sám.
Forth jsem v tom výčtu jazyků, se kterými jsem se setkal, zapomněl uvést. Ne, že bych v něm něco psal, ale trochu jsem si ho prošel. Ano, je rozhodně zajímavý - a k seznámení s ním mě vedly JASNĚ UVEDENÉ výhody oproti jiným jazykům: brutální minimalismus, jednoduchý koncept, dostatečná vyjadřovací schopnost.
Jinými slovy, milovníci Forthu mi jasně předvedli, k čemu se ten jazyk hodí víc než jiné a neotravovali mě kecy o tom, že jedině oni jsou ti správní real men, protože si pomocí nářadí vyrábí nářadí...
Jaktože nezavedly? V CLI se dá vracet pole objektů a v Boo se s tím dá pracovat úplně stejně jako v Pythonu:
To je pořád dokola. Ano, tohle je zajímavé. A dá se to využít k něčemu *praktickému*, co by se bez toho (v jiném jazyce) nedalo napsat? Pořád dokola tady slyším, jak jsou lispaři geniální, tak by snad mohli pochopit i tuto jednoduchou otázku. Ale možná jsem málo real man, abych pochopil že lapidární odpověď "makra" vyjadřuje vše...
To je pravda a tenhle argument chápu. Jenom se nějak pořád nemůžeme dobrat těch *praktických* věcí, u kterých by si to pythonista mohl říct ;)To taky nevím, protože v Pythonu jsem nenapsal ani řádku, takže nevím, co tam lze a co ne. Z těch příkladů, které jsem tady napsal, bych tipl, že nejdou napsat ty vlastní ify nebo ta logická spojka at-least-two. Ale nevím, jak moc ti to přijde praktické :-). Tady jsme asi u konce, pokud máš v Pythonu k dispozici eval, tak tím asi nějak uděláš všechno, co lze udělat makrem, akorát to bude hnusnější (viz dále) a to je možná ten důvod, proč to, narozdíl od maker v Lispu, nikdo nepoužívá.
Tomu taky rozumím a taky se mi to líbí. Ale opět tam nevidím žádnou tak zásadní přidanou hodnotu. A v tom je ten problém.Já myslím, že právě ta přidaná hodnota je obrovská. Ve chvíli, kdy člověk "programuje ve stringu", tak přichází o velkou část podpory IDE (zvýrazňování, refactoring, asi i debug…) a zároveň o třeba o syntaktickou (a případně ještě další) kontrolu kompilátorem. Navíc to vypadá hnusně.
Usuzuji z toho, jak odpovidate, ze nevite, o cem je rec, kdyz se rekne makra v Lispu. To je cele.
Samo o sobe to neni problem - ja jsem to take nevedel, a take jsem se tomu konceptu branil, nez jsem to prekonal a neco si o tom precetl. Vy byste mel take, protoze se proste pletete, kdyz mi tvrdite, ze tomu rozumite.
Makra jsou v zasade jen dalsi moznost abstrakce, podobne jako funkce. Asi byste jen tezko tvrdil, ze "nevidím žádnou výhodu v tom, když knihovna jazyka nějakou funkci nemá, přestože je dostatečně flexibilní na to, aby si uživatel mohl (musel) tuto funkci psát sám" a obhajoval tim jazyk, ktery neumoznuje uzivateli definovat vlastni funkce.
Nevim, co bych vam jeste mohl predvest. Cist odkazy se vam nechce. Tak co s vami?
Jiste, muzete vratit pole. Ale vicenasobne hodnoty se v Lispu bezne vraci na zasobniku (driv to mohlo mit i vykonnostni dopady), navic vracet pole je nesikovne, pokud nemate tuple unpacking. Uznavam, ze v nekterych dynamickych jazycich to lze pomerne snadno obejit, ale takova Java nebo C++, tam to fakt chybi.
Je mi lito, ja za vas nemuzu delat domaci ukol a vsechno vam dopodrobna popisovat, abyste pak rekl - ale me se to stejne nelibi. Proste, musite se podivat na ty veci sam. Ja vam k tomu dal dost informaci.
Z těch příkladů, které jsem tady napsal, bych tipl, že nejdou napsat ty vlastní ify nebo ta logická spojka at-least-two. Ale nevím, jak moc ti to přijde praktické :-)
Tady jsme asi u konce, pokud máš v Pythonu k dispozici eval, tak tím asi nějak uděláš všechno, co lze udělat makrem, akorát to bude hnusnější (viz dále) a to je možná ten důvod, proč to, narozdíl od maker v Lispu, nikdo nepoužívá.
Já myslím, že právě ta přidaná hodnota je obrovská. Ve chvíli, kdy člověk "programuje ve stringu", tak přichází o velkou část podpory IDE (zvýrazňování, refactoring, asi i debug…) a zároveň o třeba o syntaktickou (a případně ještě další) kontrolu kompilátorem. Navíc to vypadá hnusně.
No zatím se mi zdá, že se to principielně nijak diametrálně nelíší od evalu (resp. exec v Pythonu) - prostě se za běhu dá generovat struktura, která se dá spustit. Na tom není čemu rozumět.
Není potřeba nic dopodrobna popisovat. Stačí deseti větami ukázat příklad něčeho *praktického*, co v Lispu dá napsat, a v běžnějším jazyce by to nešlo, nebo by byl zjevný propastný rozdíl v těch dvou implementacích.
To prave dokazuje, ze to nechapete. Protoze makra nejsou eval. Makra jsou elegantni zpusob, jak generovat "boilerplate" kod (a jak treba schovat technicke detaily implementace). A proto je to neco diametralne odlisneho, nez maji bezne jazyky.
Problem je, ze vy na vsechno, co vam kdo predhodi, reknete, ze je to neprakticky priklad, a ze to svedete take. Coz je samozrejme v Turingovsky uplnych jazycich pravda. Otazka je, jak bude vypadat ten zapis.
Já si samozřejmě v jakémkoliv jazyce můžu napsat interpret jakéhokoliv jiného jazyka, ale tak o tom to není, že jo.
Aha. A pomocí evalu se nedá boilerplate kód generovat. Proto eval není makro. Hm. Tak jo.
No tak když tady někdo machruje s tím, že něco v lispu napíše na pět řádků a já mu ukážu, že v pythonu je to taky na pět řádků, tak to potom zjevně není otázka toho, jak bude vypadat kód, ale otázka toho, že někdo má prostě neutuchající potřebu machrovat...
Ja Python umim celkem slusne, byl to muj hlavni a nejoblibenejsi jazyk asi 10 let, nez jsem zacal ucit (pred 2 lety) Common Lisp.
Ja Python umim celkem slusne, byl to muj hlavni a nejoblibenejsi jazyk asi 10 let, nez jsem zacal ucit (pred 2 lety) Common Lisp.
Učíte CL a neumíte předvést aspoň tři příklady něčeho skutečně praktického (viz diskuse co je praktické výš)?
Klidek, jen tam chybi "se" (zacal ucit).
To je první potěšující zjištění tohoto tématu: že takovíhle povýšení rozumbradové na VŠ neučí...
To jste spis vy, vy se hadate o necem, co neznate. :-)
Já se o ničem nehádám. Zaslechl jsem tady, že Lisp je jazyk pro opravdové chlapy a že má obrovskou sílu, protože umí něco, co jiné jazyky ne. Když jsem se zeptal co to je, bylo mi odpovězeno "makra". Když jsem se zeptal, co umí makra, co by jiný jazyk nezvládl, bylo mi řečeno, že to se pitomcům špatně vysvětluje. Poté jsme se složitě dostali k tomu, že makra dělají principielně totéž co eval (exec), akorát se to zapisuje daleko hezčeji. A jestli nechápu, že je to narozdíl od evalu hezké a praktické, tak bych si o tom měl něco přečíst, protože jsem pitomec, který se hádá o něčem, co nezná.
A jak vam to mam ukazat? Kdyz vam ukazu kod v Lispu, nebudete mu rozumet (sam jste si stezoval, kdyz to bedna tak udelal). To bych musel vysvetlit, co co znamena, a to uz udelali jini lide prede mnou (daleko) lepe, proto odkaz na tutorialy.
Vy nerozumíte slovu "příklad"? To se slovně podá zadání a potom se ukáže řešení v jednom jazyce a v druhém, jednou větou se napíše, v čem je zásadní rozdíl a slovně se zhodnotí, které řešení je lepší v čem, např. tedy takto:
Je to asi jako snazit se vysvetlit takto OOP - nejdriv musite chapat, co je objekt.
Rozumím. Nechápu, co jsou to makra, protože jste se tak rozhodl. Na téhle rovině se nebavím. Takže definitivně HOWGH.
Proste, podobne jako OOP, neda se to vysvetlit jednoduchym prikladem
Tak když to neumíte vysvětlit jednoduše, tak si přečtěte příklad takového jednoduchého vysvětlení - třeba hned první odkaz googlu: http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html
(print (+ 1 1))No vidite. Tohle jste mohl udelat ve chvili, kdy jsem zminil slovo "makro". Ruku na srdce - kdybych vam ten link poslal, precetl byste si jej?
(defmacro my-great-and (&rest predicates)
`(and ,@predicates))
#|
(my-great-and (= x 1) (< y 3) (= (+ z 3) 4))
=> expanduje na (AND (= X 1) (< Y 3) (= (+ Z 3) 4))
|#
Kód: [Vybrat](print (+ 1 1))
To je hnus!
Se nedivím, že ani po sto příspěvcích nikdo nevěří, že je tohle ten pravý jazyk.
Jedná se o makro, které přebírá různý počet parametrů, všechny je vyhodnotí a vrátí, jestli jsou všechny pravdivé, či ne. [...] Jak by se to udělalo v Pythonu?
@Mirku: nevadi, kdyz ti budu tykat? Jednou si mi rekl, tykejte mi, ajtaci si tykaji. Uz si ani nevzpominam, jestli jsem rekl, ze tykani mi nevadi. Tak to reknu ted, nevadi mi to. Tak tedy Mirku, ze se porad tak nejak vsemu branis. Ptal ses uz tolikrat na to co jsem chtel vedet i ja a misto konkretni odpovedi, kterou potrebujes vedet, se ti dostalo jinych odpovedi, ktery ti nic nereknou. Proc se treba nezeptas jinak. Proc se na to nepodivas z jineho uhle pohledu a nepouzijes uplne jinou otazku, s jejiz pomoci byses dobral odpovedi na to, co chces vedet?
Forth jsem v tom výčtu jazyků, se kterými jsem se setkal, zapomněl uvést. Ne, že bych v něm něco psal, ale trochu jsem si ho prošel. Ano, je rozhodně zajímavý - a k seznámení s ním mě vedly JASNĚ UVEDENÉ výhody oproti jiným jazykům: brutální minimalismus, jednoduchý koncept, dostatečná vyjadřovací schopnost. Mimo to znám forthovský bootloader z FreeBSD a musím říct, že to je moc hezká věc. Jinými slovy, milovníci Forthu mi jasně předvedli, k čemu se ten jazyk hodí víc než jiné a neotravovali mě kecy o tom, že jedině oni jsou ti správní real men, protože si pomocí nářadí vyrábí nářadí...
No vida - tak tedy Forth uznáváš.
Mno, je to docela dobrá připomínka, ale já holt prostě nevím, jak jinak položit naprosto triviální otázku...Mozna bych ti mohl pomoci. Zda se, ze je jasne, ze LISP je velice univerzalni jazyk. Takze v nem lze udelat obrovske, ale obrovske mnozstvi ruznych veci. Kdyz Ti nekdo chce tenhleten fakt zduraznit, tak je velice tezke vybrat nejaky konkretni priklad, ktery by ti objasnil tu "velikost LISPu". Proto asi vetsina LISParu mluvi tak vseobecne.
To není žádný praktický příklad. (ano, skutečně trvám na tom, že není) Praktický příklad je "načti deset čísel ze souboru a najdi největší" nebo "připoj se na webservice googlu a stáhni mapu brna" nebo "vykresli GUI s obrázkem Majora Gagarina" nebo "vyřeš problém batohu, přičemž data jsou v souboru ve formátu XY".
Prakticke priklady na vyuziti makra ale nikdy nebudou mit jen par radek. To musite pochopit. Vezmete si knizku Practical Common Lisp, vyberte si tam libovolny program, a napiste/rozmyslete si program, ktery dela to same v Pythonu, pri pouziti stejne urovne knihovnich funkci (napr. je tam knihovna na parsovani binarnich souboru - zadne podvadeni se struct!). A uvidite, ze to makra zkracuji. To je asi jako chtit jednoduchy priklad, kde je OOP lepsi nez ne-OOP.
Pak uvidíme, k čemu jsme došli.
když už ostatním nadáváte, že jsou cvičené opice, tak byste aspoň mohli umět dokázat svoje silná tvrzení o svém miláčkovi...
Nikdo netvrdil, že ti, co neprogramují v Lispu, jsou cvičené opice. Za cvičenou opici jsem označil člověka, který není schopen dohlédnout ani mimo rámec vývojového nástroje, na nějž je zvyklý. Prostě jako by se někdo dotázal na možnosti použití elektromotoru a kdosi se zapojil do debaty stylem "Nejdůležitější je - kolik to má válců? A jaký mají obsah? Leje se tam benzin nebo nafta? Co se k tomu dělá za turba? Protože tohle jsou přece věci, které každého experta na pohony zajímají především."
Pak uvidíme, k čemu jsme došli.
Vsadím boty, že bysme došli k tomu, že lispaři budou tvrdit, že jejich kód je sice stejně rychlý a stejně dlouhý, ale že je elegantnější. Takové zjištění mi teda za tu námahu nestojí.
Kdyz uz se tu tak probiraji ty nekonecne moznosti Lispu, jakym zpusobem v nem lze programovat ciste funkcionalne (pokud zrovna urcitou cast kodu timto zpusobem programovat chci, nic dogmatickeho), jestlize tail rekurkze neni standardem vyzadovana? V Land of Lisp se tomu elegantne vyhli tvrzenim, ze ta a ta implementace (ci vetsina nebo jak to formulovali) to stejne podporuje.
Stejně jako Tebe mě nebaví číst vznešené řeči a alegorie, jsem technokrat a mám zájem o inženýrskou debatu. Tam samozřejmě patří metriky, příklady nástrojů, knihovny atd., ale bez nějakého umělého příkladu se asi neobejdeme.
Ovsem existuji zkratka pripady, ktere napisete v Lispu na 5 radku a v Pythonu na mnohem vic, protoze v Lispu muzete definovat makra. Proste, Lispova makra umoznuji ten kod zkratit vic nez o konstantu.
Nemůžete přece chtít, aby se v nějakém jazyce implementovaly obraty s něčím, co daný jazyk v takové podobě vůbec nemá.
(define-macro (delay x) `(lambda () x)),(define (force promise) (promise))(define-macro (delay expr)
`(let ((initialized #f)
(value #f))
(lambda ()
(if initialized value
(begin
(set! initialized #t)
(set! value ,expr)
value)))))(let ((initialized #f)
(value #f))
(lambda ()
(if initialized value
(begin
(set! initialized #t)
(set! value expr)
value))))A za třetí ta debata nemá smysl, protože každá cvičená opice ví, že co do tvrdých kritétií jsou všechny jazyky stejné, protože se v nich dá napsat ten stejný algoritmus - a potom už jenom měříme schopnost překladače optimalizovat... Takže bysme stejně jen skončili u bezobsažné debaty o tom, co je elgantní a co ne.
CitaceNemůžete přece chtít, aby se v nějakém jazyce implementovaly obraty s něčím, co daný jazyk v takové podobě vůbec nemá.
a v tom bude asi jadro pudla. silne mi to tady zacina zavadet podobenstvi o jeskyni....
Koukám, že už se to tady zvrhlo na úroveň "kdo ho má většího" :)
tak si zkusime nejaky prakticky priklad... co treba line vyhodnocovani, kod je ve schemu, ale to je jedno.
vytvorme si novy typ hodnot, tzv. prislib. do teto hodnoty si ,,schovame'' nejaky vyraz a vyhodnotime ho az kdyz bude opravdu potreba.
class delay(object):
def __init__ (self, x):
self.x = x
self.initialized = False
def __call__ (self):
if (not self.initialized):
self.value = self.x()
self.initialized = True
return self.value
for i in xrange(10):
if (i == 0):
v = delay(lambda: i + 1)
if (i > 5):
print v()
Jediné, co má smysl, je vzít PROBLÉM a jeho řešení napsat ve dvou různých jazycích takovými prostředky, které jsou v tom kterém jazyce pro řešení problému optimální.
tak si zkusime nejaky prakticky priklad... co treba line vyhodnocovani, kod je ve schemu, ale to je jedno.
vytvorme si novy typ hodnot, tzv. prislib. do teto hodnoty si ,,schovame'' nejaky vyraz a vyhodnotime ho az kdyz bude opravdu potreba.
V Pythonu třeba takto:
Kód: [Vybrat]v = delay(lambda: i + 1)
precti si neco od grahama
Ta lambda tam dost omezuje, co je mozny do toho delay schovat. Pokud by to melo byt obecne, tak bez toho execu (nebo nejake jeho rucne udelane varianty) se neobejdem.
a bez te lambdy to nejde?
Vadí to moc?
protože se tady jenom trumfujete, kdo si umí líp honit triko.
Hezky priklad je treba zamykani. Zamky se blbe vkladaji do funkci nejake knihovny, protoze je obcas potrebujete zamknout driv, nez tam vpadnete. Samozrejme, muzete si kvuli tomu bloku mezi zamkem definovat funkci, na kterou se pak zavola funkce toho zamku, ale proc tak slozite. Neni lepsi to fakt resit tim makrem?
Ja bych chapal makra proste jako funkce, ktere nemusi nutne vyhodnotit sve argumenty. V pure funkcionalnich jazycich je to pak oboji totez. Zastancem funkcionalniho purismu nejsem, pripada mi to prehnane; uz proto, ze zkratka realne pocitace jsou velmi velmi stavove. Dale je tu otazka moznosti automatickych vs. moznosti lidskych optimalizaci. Schopni lide dokazi, na urovni vyssi nez assembler, vice.
skutecne obtizny dotaz na makristy - jak implementaci CL, ktera nema podporu tail callu, pomoci maker o tuto podporu rozsirim? :-)
nebo pattern matching ala Ocaml (a patrne Haskell)?
a bude to s pomoci maker stejne rychle, jako kdyz to bude podporovat primo prekladac?
Zamykání funkce v Pythonu mohu pořešit opět dekorátorem a nic moc navíc to nestojí (režie volání není nulová, ale z hlediska programátora je to v pohodě). Java a spol. mají klíčové slovo synchronized, na konkurenční přístup k datům jsou různé strategie - počínaje STM a konče actory atd. Vhodnost a nevhodnost konkrétního přístupu si netroufám takto od boku střílet.
Však Tě nikdo nenutí, ikdyž je pravda, že jsem předpokládal, že bys zájem mít mohl. Schválně jsem ale psal o rozumné velikosti, protože několik dnů nechci a ani nemohu nad problémem strávit ani já. Podle mě je každopádně škoda, že diskuse zatím probíhá dost nasucho.
Bohuzel, krome http://page.mi.fu-berlin.de/prechelt/Biblio//jccpprtTR.pdf (http://page.mi.fu-berlin.de/prechelt/Biblio//jccpprtTR.pdf) a mozna trochu http://shootout.alioth.debian.org/ (http://shootout.alioth.debian.org/) nevim o zadne studii srovnavajici produktivitu programovacich jazyku (libovolnych - ne primo Lispu).
...
K bodu 5: Souhlasím s tím, že párování závorek pomůže "rozšifrovat" zdrojový text, nicméně to neznamená, že se tím program stane výrazně čitelnějším. Čitelnost znamená "kouknu se a vidím" a ne "otevřu si editor, jezdím kurzorem sem a tam a hledám".
char*x(char*s,int c){char*r=0;while(*(*s-c?s++:r=s++));return r;}K bodu 6: Prefixová notace sice má svoje výhody, ale zrovna u aritmetických operací a podobných akcí to prostě je handicap. Výhody existují, ale například násobnou aplikaci operátoru lze v jiných jazycích vyjádřit pomocí fold/reduce. S problémem infixových funkcí si z jazyků, které jsem viděl, asi nejelegantněji poradily Haskell a Scala.
Zkrátka a dobře, vždycky je to něco za něco. Obrovská flexibilita LISPu je výhoda, o tom není sporu. Problém "metajazyků" typu LISP je dvojí:
1. Zhoršená čitelnost kvůli jednoduché syntaxi - syntaxe LISPu je computer friendly a ne human friendly. Syntaktický cukr je z hlediska čtenáře kódu výhoda, ne že ne.
2. Rozšiřitelnost a určitý paradigmatický agnosticismus (proč je, u všech všudy, potřeba do LISPu přidávat další a další konstrukce?) tento problém ještě zvětšuje.
char*x(char*s,int c){char*r=0;while(*(*s-c?s++:r=s++));return r;}
Kouknu a vidím není vlastností jazyka, ale vlastnost konkrétního programu a programátora. Funkce x kterou uvádím pro pobavení je napsaná v jazyce C, který syntaktický cukr obsahuje, přesto není na první pohled vidět, že je ekvivalentní jedné standardní knihovní funkci.
1. Jde jen o zvyk. Když jsem přešel z Pascalu na C, tak mi přišlo { a } místo begin a end podobně nepřátelské. Dokonce jsem si myslel, že na = a == místo := a = si nikdy nezvyknu.
Příčinou zdánlivé nečitelnosti je jen nezvyk a nechuť učit se nové věci.
Benchmarků se dá najít kupa.
http://dan.corlan.net/bench.html
Java (do nativniho kodu): 25 radku kodu, 3.03s
Java (bytekod): 8.23s
Lisp: 22 radku kodu, 4.69s
Java-nativni kod o 35% rychlejší.
ad tail rekurze - pokud jsem to spravne pochopil, ten nastrel neni ciste funkcionalni (setf), coz popira puvodni duvod pro pouziti tail rekurze..
"Ano, existuji veci, ktere se i s velmi silnym makrosystemem delaji nesikovne. Je to tak prekvapive?"
ne, je to dukaz, ze jine jazyky nabizeji jine abstrakce v Lispu nedostupne a stejne efektivne neimplementovatelne; ta makra proste jen poskytuji urcity pristup a jine jazyky poskytuji jine pristupy k reseni problemu, makra nejsou nadmnozinou a vselek, jak se Lispari snazi tvrdit
Myslim, ze na to, ze je CL dynamicky jazyk, ma dost slusnou rychlost.
Největší výhodou Lispu jsou makra a možnost jednoduše zpracovávat program jako data...
To úplně není. Třeba v C si můžu udělat makro, ale v parsování C-čkového kódu mi to nepomůže.Největší výhodou Lispu jsou makra a možnost jednoduše zpracovávat program jako data...
...což je jedno a to samé :)
To úplně není. Třeba v C si můžu udělat makro, ale v parsování C-čkového kódu mi to nepomůže.
(circle x y r)nebo(rekni v "Dobry den, jmenuji se Jack")kde v je vyska tonu hlasu, nebo(moveto (map "Praha") x y)apod.
novomente: to vsechno vypada jako typicke priklady na pouziti funkce, k cemu makro?No jo, vlastne funkce a ne makro (uz jsem nejakej pretazenej, celou noc jsem skoro nespal :) )
No ale jestli to tak jde, tak to je parada.
Co presne je na tom parada? :)Parada je na tom to, Mirku, ze obcas zapremyslim nad jednim napadem, o kterem jsem se zminil v diskusi "IT inovace od neprogramatora" (neco jako programatorske LEGO). Ale prosim te, nechtej vedet o co jde, protoze o tom nechci mluvit, dokud nezjistim, jestli uz to nekdo nejak nezkousel. Presne jak jsem psal v te diskusi (IT inovace...).
Parada je na tom to, Mirku, ze obcas zapremyslim nad jednim napadem, o kterem jsem se zminil v diskusi "IT inovace od neprogramatora" (neco jako programatorske LEGO).
No a jestli to nikdo jeste nezkousel to tak resit, jak myslim, tak to pro mne bude skvela motivace, abych se ucil programovat. Ale na to je jeste cas, stale hledam.
Nicméně když srovnám Lisp jako první jazyk pro programátora třeba s Pythonem (sorry), je ta učící křivka daleko obtížnější.
* já bych nespuštěný kód nazval třeba "citát", protože pracuji jakoby nad TEXTEM (strukturou) algoritmu, nikoli nad HODNOTOU VRÁCENOU algoritmem, ani nad algoritmem jako celkem. Čili algoritmus nespouštím, ale dělám nad jeho strukturou nějaké operace. Zmínil jsem tady transparentní intenzionální logiku - ta má to samé: jednak umí rozlišit mezi "de dicto" a "de re" (což asi v programování nemá ekvivalent) [1] a navíc umí rozlišit spuštěnou a nespuštěnou konstrukci [2] (což je přesně rozdíl mezi normální funkcí a makrem).Ten první článek jsem jen tak proběhl, kdybych to celé četl a snažil se to pochopit, strávil bych nad tím hodně dlouho. Tohle mě překvapilo:
(Ovšem sluší se dodat, že TIL vznikl až po Lispu, takže s klidem můžeme lispisty poplácat po rameni, což ji zjevně dělá tak moc dobře :)
[1] http://til.phil.muni.cz/text/duzi_homonymie_dedicto_dere.php
[2] http://til.phil.muni.cz/text/tichys_fivemodes.php - viz hlavně trivializace
(P1) Karel si myslí, že papež je v nebezpečíTvrdí tam, že ty dvě věty mají různý význam. Jak to, že to má různý význam? Může snad existovat nějaká situace, kdy platí P1 a neplatí P2 nebo naopak?
(P2) Karel si o papeži myslí, že je v nebezpečí
Myslím, že to, že mám kód jako strukturu a ne jen hloupý text (ten mám u evalu), je dost podstatná výhoda.
Parsování lispu jde snadno, na to myslím má tu syntaxi co má, s protivným množstvím závorek.
Ten první článek jsem jen tak proběhl, kdybych to celé četl a snažil se to pochopit, strávil bych nad tím hodně dlouho.
(P1) Karel si myslí, že papež je v nebezpečí
(P2) Karel si o papeži myslí, že je v nebezpečí
Tvrdí tam, že ty dvě věty mají různý význam. Jak to, že to má různý význam? Může snad existovat nějaká situace, kdy platí P1 a neplatí P2 nebo naopak?
Nechci fakt ted nic probirat, protoze jak vydis z mych reakci, vsechno je to jenom zatim jen teoreticky
ad rekurze - doted jsem si myslel, ze kompilator preklada tail rekurzi jako prosty skok, ne smycku (coz v imperativnim - jakem jinem v tomto kontextu - pojeti obvykle znamena zmenu nejakeho akumulatoru nekde v pameti + skok; ostatne instrukce smycka alespon na x86 funguje presne takhle), kdo z nas dvou to nepochopil? ze mi vadi stav? nevadi, jen proste standard CL nezarucuje funkcnost ciste funkcionalniho kodu, cele me tvrzeni; pointa je, ze pokud kompilator tail rekurzi podporuje, tak se destrukce "stareho" mista a vytvareni "noveho" deje prirozene a ne tim zplostenim problemu na imperativni iteraci, jak to dela ono makro, vzdyt preci v trochu slozitejsich pripadech tohle nebude fungovatt! viz toto http://www.ats-lang.org/DOCUMENTATION/PROGINATS/HTML/x677.html
co to tedy placas ty?
Čili v podstatě dělá to samé jako eval, akorátže sympatičtějším způsobem, protože do kódu můžu "elegantněji" šahat, protože ho nemám jako string, ale jako už rozparsovanou strukturu.
Vy totiz muzete vysledek vyhodnoceni makra pak nechat zkompilovat, nemusite ho jen interpretovat. Jak to chcete provest s retezcem do eval mi tedy neni jasne.
Takže Lisp je funkcionální jazyk, ale nedá se v něm pořádně programovat čistě funkcionálně? Čtu to tady a nevím, co si o tom mám myslet, zatím mě to taky moc nezaujalo. Třeba stránky o Haskellu se jeho hlavním výhodám oproti jiným jazykům (lenost, žádné vedlejší efekty, silný statický typový systém atd.) věnují hodně.
Největší výhodou Lispu jsou makra a možnost jednoduše zpracovávat program jako data... je to tak? Taky myslím, že něco takového je prakticky použitelné hlavně pro programování věcí, kde se pracuje s lispovým kódem (např. IDE pro Lisp). Generovat kód za běhu a spouštět ho (exec, eval) se považuje za nebezpečné, ale v Lispu se tak programuje normálně. Není to špatný a nebezpečný způsob programování? Dívám se na to nějak špatně?
Vy totiz muzete vysledek vyhodnoceni makra pak nechat zkompilovat, nemusite ho jen interpretovat. Jak to chcete provest s retezcem do eval mi tedy neni jasne.A co vám na tom není jasné?
Zrejme jste prehledl ono "zkompilovat". To co pisete je interpret.
#!/bin/sh
while true; do
vim makro.c
gcc -o makro makro.c
./makro
read
done
ta diskuze je jeste zoufalejsi nez vcera... ale neposled neco zkusim.
makra v lispu vic nez nejakemu evalu jsou podobne preprocesoru, ktery je treba v cecku. stejne jako v cecku se nejdriv vyresi veci tykajici se podmineho prekladu a provede se expanze maker a az pak se preda kod prekladaci. tak stejne to funguje i v LISPu. ***nejdriv se provede expanze maker a pak se kod zkompiluje pripadne interpretuje***.
JS: zase ta rekurze :-)
proc? protoze pro nektere problemy je to prirozeny zpusob (v tve reci tedy elegantni), napr. ono traverzovani stromu; bez tail rekurze to nebude obecne
Shodou okolností jsem tenhle aha-zážitek právě teď udělal při čtení čehosi... Takže ok, přiznávám se, že jsem to vůbec nepochopil.
Tak to je škoda, myslel jsem, že ty makra jsou zajímavější...
V tom případě teda musím upravit tvrzení, že eval je stejně silný nástroj, jen trochu neohrabanější na tvrzení "eval je daleko silnější nástroj, i když trochu neohrabaný" - všechno, co se dá udělat makrem, se dá udělat evalem, ale ne naopak - a jediný rozdíl makra od evalu je v tom, že makro se spustí těsně před překladem, zatímco eval se spustí až v době běhu.Já bych řekl že zásadní chyba je v pocitu že je tu eval NEBO makra - to je absurdní, eval je tam vždy, bez něj se v LISPu nic neprovádí. Zda se překládá nebo interpretuje není moc relevantní a je to spíš matoucí.
Tak to je škoda, myslel jsem, že ty makra jsou zajímavější...
Kdybys přece jenom chtěl něco konzultovat, tak se na mě můžeš obrátit - klidně i s nějakou tou "mezimotivací" - na m.prymek na gmailu. Nic Ti ale nemůžu slíbit :)Beru na vedomi :)
No konecne. Jenom skoda, ze jste pri tom stihl urazit vsechny okolo, jak jsou arogantni, pritom se vas jen snazili upozornit na fakt, ze to nechapete.
def KlidneNejakaStatickaInicializace():
pass
def GenerateFlexibleClass(name,classhosting):
classCode = """class %s: # bez problemu pouzijeme lokalni kontext
def __init__():
KlidneNejakaStatickaInicializace() # bez problemu volame normalni funkce
"""%(name,)
classCode+=NactiKodZeSite(classhosting) # bez problemu nacteme kod odkud chceme, nejsme omezeni jenom na samotny zdrojak...
globals = {}
exec classCode in globals
return globals[name]
# tomuhle taky muzu rikat "upravil jsem si syntaxi jazyka" a "vytvoril jsem DSL"?
myFlexibleGeneratedClass = GenerateFlexibleClass("SuperClass","classfactory.testing.cz")
We can create macros for our to-do list items that will get called by lisp compiler and will transform the to-do list into code. Now our to-do list will be treated as code and will be executed. Suppose all we want to do is print it to standard output for the user to read:
(defmacro item (priority note)
'(block
(print stdout tab "Priority: "
~(head (tail priority)) endl)
(print stdout tab "Note: " ~note endl endl)))
Mirek vám tu přece netvrdí, že LISP je špatný jazyk. Jen nesouhlasí (nebo řekněme chce se dozvědět, proč by to byla pravda), že je to super - uber - ultra - mega krutopřísný jazyk hodící se na vše a vždy a ostatní jazyky jsou pro pitomce.
(zde záleží na náročnosti na propojení s ostatními jazyky, což si samozřejmě musím nastudovat sám).
A co tomu tady chybí? Příklad. Vždyť to nemusí být ani ukázka kódu. Reálný příklad z praxe složitého problému, popsaný slovy. Nástin implementace (opět, bez ukázky kódu) v lispu.
Tahle diskuse by byla mnohem věcnější, kdyby si tu pár fanatiků hned na začátku nezačalo honit triko. Co si k takové komunitě totiž říct? "Hm... jazyk je to jiný (záměrně nepíši těžký), nějaká literatura k tomu je, ale co když něco nepoberu a budu se chtít zeptat? Dozvím se, že jsem cvičená opice s lepidlem?" Neměla by komunita, obzvláště pak komunita malá, vítat každého případného nováčka, člověka, co se chce něco dozvědět? Nač to elitářství? Není to kontraproduktivní (a také bezdůvodné)?
The enlightenment came instantaneously. One moment I understood nothing, and the next moment everything clicked into place. I've achieved nirvana. Dozens of times I heard Eric Raymond's statement quoted by different people: "Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot." I never understood this statement. I never believed it could be true. And finally, after all the pain, it made sense! There was more truth to it than I ever could have imagined. I've achieved an almost divine state of mind, an instantaneous enlightenment experience that turned my view of computer science on its head in less than a single second.
That very second I became a member of the Lisp cult. I felt something a ninjitsu master must feel: I had to spread my newfound knowledge to at least ten lost souls in the course of my lifetime. I took the usual path. I was rehashing the same arguments that were given to me for years (only now they actually made sense!), hoping to convert unsuspecting bystanders. It didn't work. My persistence sparked a few people's interest but their curiosity dwindled at the mere sight of sample Lisp code. Perhaps years of advocacy would forge a few new Lispers, but I wasn't satisfied. There had to be a better way.
Neměla by komunita, obzvláště pak komunita malá, vítat každého případného nováčka, člověka, co se chce něco dozvědět? Nač to elitářství? Není to kontraproduktivní (a také bezdůvodné)?
JS:
Common Lisp neznam, cili z toho kodu nejsem nijak zvlast moudry a tudiz otazka: *current-tail-marker* mi nebude branit v tom traverzovat 2 stromy paralelne zaroven (= paralelne spustit 2 nesouvisejici tail rekurze zaroven; na me urovni uvazovani a na urovni syntaxe makra, o jehoz vnitrnosti se "nemusim" zajimat, to jsou preci 2 naprosto nesouvisejici cinnosti), ze ne?
Z takové "komunity" se mi dělá špatně a představa, že bych se takových lidí měl na něco ptát, mě upřímně děsí...
Jestlize dosahnete osviceni, proste dosahnete osviceni, co s tim kdo nadela?
Ono totiž právě to je největší umění - dokázat něco netriviálního vystihnout několika slovy tak, aby to pochopil každý - a pokud to tu někteří neustále požadují, nejspíš si ani sami neuvědomují, jak náročný požadavek ve skutečnosti mají.
<todo name="housework">
<item priority="high">Clean the house.</item>
<item priority="medium">Wash the dishes.</item>
<item priority="medium">Buy more soap.</item>
</todo>
(todo "housework"
(item (priority high) "Clean the house.")
(item (priority medium) "Wash the dishes.")
(item (priority medium) "Buy more soap."))
(defmacro item (priority note)
'(block
(print stdout tab "Priority: "
~(head (tail priority)) endl)
(print stdout tab "Note: " ~note endl endl)))
To bylo opravdu tak těžké takovýhle příklad uvést a ušetřit si tři dny plácání? A myslíte si, že vám někdo uvěří, jakého osvícení jste s lispem dosáhli, když o takhle jednoduchém úkolu (stručně vystihnout povahu maker) napíšete "jak *náročný požadavek* ve skutečnosti mají"?
Ano, bylo to tezke, protoze jste nam tu tvrdil, ze makrum rozumite.
To bylo opravdu tak těžké takovýhle příklad uvést a ušetřit si tři dny plácání? A myslíte si, že vám někdo uvěří, jakého osvícení jste s lispem dosáhli, když o takhle jednoduchém úkolu (stručně vystihnout povahu maker) napíšete "jak *náročný požadavek* ve skutečnosti mají"?
A zákadnímu principu jsem skutečně rozuměl, jen jsem si myslel, že je trochu mocnější než jenom normální preprocesor.
Nikde tu nikdo z nás netvrdil, že jsme pedagogové.
...rika clovek, co si mysli, ze funkce eval je lepsi vynalez :-]]
V tom případě teda musím upravit tvrzení, že eval je stejně silný nástroj, jen trochu neohrabanější na tvrzení "eval je daleko silnější nástroj, i když trochu neohrabaný" - všechno, co se dá udělat makrem, se dá udělat evalem, ale ne naopak
ehm...CitaceV tom případě teda musím upravit tvrzení, že eval je stejně silný nástroj, jen trochu neohrabanější na tvrzení "eval je daleko silnější nástroj, i když trochu neohrabaný" - všechno, co se dá udělat makrem, se dá udělat evalem, ale ne naopak
tak to ještě neznamená, že dokáže stručně a srozumitelně vysvětlit triviální věc ;)
jak s tim asi zahybe nejaka jina rekurze spustena ve stejnou dobu?
Zaverem bych se jeste zeptal, jestli nekdo nema nejaky tip na dalsi stranky, jako jsou root nebo abclinuxu, o programovani, kam chodeji zkuseny programatori diskutovat?
Nic ve zlem, ale mne se to spamovani anketou moc nelibi.Nemyslel jsem to jako spam. Myslel jsem, ze by to mohlo tady nekoho zajimat (zejmena ty cisla u Lispu). Ale budiz, priste si dam na ty odkazy vetsi pozor.
Zaverem bych se jeste zeptal, jestli nekdo nema nejaky tip na dalsi stranky, jako jsou root nebo abclinuxu, o programovani, kam chodeji zkuseny programatori diskutovat?
root a abclinuxu nie sú stránky o programovaní, ale o linuxe a open source. o programovaní sa tu veľa nedozvieš(max o programovaní v linuxe), nechodia sem totiž programátori, ale správcovia serverov.
Říkal jsem, že se domnívám, že základnímu principu rozumím - a nerozumím tomu, co je na něm tak kulervoucího - a proto bych tu kulervoucnost chtěl vidět na nějakém konkrétním příkladě.
Muzes jeste zkusit http://stackoverflow.com/questions/267862/what-makes-lisp-macros-so-special (http://stackoverflow.com/questions/267862/what-makes-lisp-macros-so-special).
A Lisp macro is not handed a string, but a preparsed piece of source code in the form of a list, because the source of a Lisp program is not a string; it is a list.
What is really happening here is that "setf" is a macro. **At compile time**, it examines its arguments, [...] And it quietly **rewrites the code** in place to:
Muzes jeste zkusit http://stackoverflow.com/questions/267862/what-makes-lisp-macros-so-special (http://stackoverflow.com/questions/267862/what-makes-lisp-macros-so-special).
No konečně odkaz na někoho, kdo mluví o lispu a nemastí si při tom ego. Hned ta první zvýrazněná věta pěkně a věcně vyjadřuje podstatu:CitaceA Lisp macro is not handed a string, but a preparsed piece of source code in the form of a list, because the source of a Lisp program is not a string; it is a list.
Souhlasím, v tomhle je lispová koncepce skutečně zajímavá, však jsem to tady taky několikrát psal.
Žádné plky o "vytváření vlastního jazyka", ale stručný a jasný popis reality. Palec nahoru, klobouk dolů!
...a autor pokračuje ve stejném stylu:CitaceWhat is really happening here is that "setf" is a macro. **At compile time**, it examines its arguments, [...] And it quietly **rewrites the code** in place to:
Opět žádné nesmysly o cvičených opicích, lepidlech, žádná komixová pohádka o lispu, který zachraňuje planetu před zhroucením. Žádné vznešenosti o rozšiřování překladače a osvícení. Jen jednoduchá a strohá pravda: "přepisuje zdroják".
Díky! Jen škoda, že to nepřišlo dřív...
Ty jsi tedy opravdu případ... Vždyť tohle ti tu bylo řečeno asi dvacet krát! Ale jak praví klasik, "to už říkal starej hostinskej Rampa na Vinohradech, když mu chtěl někdo zůstat dlužen, že přijde někdy na člověka takovej moment, že je ke všemu hluchej jako pařez."
No právě že nebylo. Minimálně ne takhle stručně a jasně. Kdyby někdo na otázku "A co je na lispu tak zajímavého?" odpověděl "Docela zajímavá jsou makra - je to použití samotného lispu v preprocesoru k potenciálně složitému přepisování zdrojáku před jeho překladem, s čímž se pak dají dělat zajímavá kouzla", tak jsme si všichni mohli ušetřit dost času a nervů...Souhlasím.
...páč bysme to asi během chvilky zhodnotili tak, že to je zajímavé, ale těžko to může vyvážit praktické nevýhody reálného nasazení lispu...Jak to můžeš vědět?
Jak to můžeš vědět?
..Takove veci samozrejme existuji, ale nejsou zadarmo (LispWorks, Allegro CL). Co se tyce OSS knihoven, quicklisp.org. V podstate oboji uz tu padlo, co takhle precist si nejdriv poradne diskusi?
Jinak pokud budete mit dobre programatory, bude to rychleji a za nizsi cenu. Pokud budete mit lepice, vyjde to nastejno.
No právě že nebylo. Minimálně ne takhle stručně a jasně. Kdyby někdo na otázku "A co je na lispu tak zajímavého?" odpověděl "Docela zajímavá jsou makra - je to použití samotného lispu v preprocesoru k potenciálně složitému přepisování zdrojáku před jeho překladem, s čímž se pak dají dělat zajímavá kouzla", tak jsme si všichni mohli ušetřit dost času a nervů...
vyhodou je, ze makrojazyk v LISPu je taky LISP takze jde vyuzit v plne mire jeho vyjadrovacich schopnosti a funkci (to v C nejde) a ... makra v takovem pripade slouzi k rozsireni vyjadrovacich schopnosti jazyka. to umoznuje uzpusobit si jazyk potrebam dane situace a tudiz zefektivnit psani.
Dobrý programátor je lepič kódu. Práca kvalitného vývojára je založená na kooperácii a deľbe práce. nebude znovu onbjavovať koleso keď ho už objavil niekto pred ním a vyladil ho k dokonalosti, dobrý programátor sa sústredí len na riešenie problému. Väčšinu času venuje štúdiu, knižníc, frameworkov a návrhových vzorov. Je lacný rýchly a efektívny.
CitaceNo právě že nebylo. Minimálně ne takhle stručně a jasně.
vazne? kdosi, kdysi tu napsal...Citacevyhodou je, ze makrojazyk v LISPu je taky LISP takze jde vyuzit v plne mire jeho vyjadrovacich schopnosti a funkci (to v C nejde) a ... makra v takovem pripade slouzi k rozsireni vyjadrovacich schopnosti jazyka. to umoznuje uzpusobit si jazyk potrebam dane situace a tudiz zefektivnit psani.
a uvedomujes si, ze podle tve logiky autori tech knihoven, frameworku a navrhovych vzoru jsou prave ti spatni programatori? :-]]
CitaceDobrý programátor je lepič kódu. Práca kvalitného vývojára je založená na kooperácii a deľbe práce. nebude znovu onbjavovať koleso keď ho už objavil niekto pred ním a vyladil ho k dokonalosti, dobrý programátor sa sústredí len na riešenie problému. Väčšinu času venuje štúdiu, knižníc, frameworkov a návrhových vzorov. Je lacný rýchly a efektívny.
a uvedomujes si, ze podle tve logiky autori tech knihoven, frameworku a navrhovych vzoru jsou prave ti spatni programatori? :-]]
Asi si to nepochopil, zaujímavý článok na túto tému je: http://vbnet.cz/blog-clanek--131-dva_programatorske_pristupy.aspx
Na Matfyzu nám říkali, že programování je hlavně o teorii a algoritmech, že jazyk nebo technologii se už naučíme za týden. S tím bych si dovolil polemizovat, základy .NET frameworku se za týden pochytit dají, pokud člověk má obecné programátorské znalosti, ale aby člověk programoval pořádně a elegantně, musí mít s touto technologií alespoň půl roku zkušeností.
Asi si to nepochopil, zaujímavý článok na túto tému je: http://vbnet.cz/blog-clanek--131-dva_programatorske_pristupy.aspx
...
CitaceDobrý programátor je lepič kódu. Práca kvalitného vývojára je založená na kooperácii a deľbe práce. nebude znovu onbjavovať koleso keď ho už objavil niekto pred ním a vyladil ho k dokonalosti, dobrý programátor sa sústredí len na riešenie problému. Väčšinu času venuje štúdiu, knižníc, frameworkov a návrhových vzorov. Je lacný rýchly a efektívny.
a uvedomujes si, ze podle tve logiky autori tech knihoven, frameworku a navrhovych vzoru jsou prave ti spatni programatori? :-]]
Jediné dva praktické příklady, které jsem tu viděl [...] Podle mě vesměs nic, co by nešlo v jiných jazycích udělat také za srovnatelných obtíží.
defmacro MyHandler (name)
{
class ${name}: XYZHandler {
...
}
}
MyHandler(JabberMessageHandler)
MyHandler(ConsoleMessageHandler)
MyHandler(TcpMessageHandler)
handler = JabberMessageHandler()
Kromě toho tady zaznělo, že pomocí maker by se daly stručně napsat třeba definice spousty tříd, které mají dostatečný společný základ.
Něco jako (pseudokód)Kód: [Vybrat]defmacro MyHandler (name)
{
class ${name}: XYZHandler {
...
}
}
MyHandler(JabberMessageHandler)
MyHandler(ConsoleMessageHandler)
MyHandler(TcpMessageHandler)
handler = JabberMessageHandler()
Jako jo, no... v hodně divokých snech si dovedu představit, že by se to k něčemu mohlo hodit...
Mně to přijde jako typická násobná dědičnost, snad dokonce pouhý mixin (trait v terminologii Scaly). Ano, pár znaků se při vytvoření každé nové třídy ušetřit dá, ale...
# cat test.py
#!/usr/bin/python
def defmacro(name,code):
# pomocna funkce
def macrodef(params,code):
exec code%params in globals()
globals()[name]=lambda params: macrodef(params,code)
# ukazeme, ze muzeme v klidu dedit z normalniho kodu
class XYZHandler(object):
def test(self):
print "XYZHandler.test()"
print " self=%s"%(self,)
# timhle nadefinujeme FUNKCI MyHandler, jejimz spustenim
# nadefinujeme konkretni (parametrizovanou) tridu
defmacro("MyHandler","""
class %(className)s(%(superClass)s):
def test(self):
super(%(className)s,self).test()
print "%(className)s.test()"
print " self="+str(self)
""")
# nadefinujeme tridu JabberMessageHandler
MyHandler({'className':'JabberMessageHandler','superClass':'XYZHandler'})
# nadefinujeme tridu SuperJabberMessageHandler, ktera dedi z predchozi
MyHandler({'className':'SuperJabberMessageHandler','superClass':'JabberMessageHandler'})
handler1 = JabberMessageHandler()
print "=====> Testuju handler1"
handler1.test()
handler2 = SuperJabberMessageHandler()
print "\n=====> Testuju handler2"
handler2.test()
# ./test.py
=====> Testuju handler1
XYZHandler.test()
self=<__main__.JabberMessageHandler object at 0x1004cc890>
JabberMessageHandler.test()
self=<__main__.JabberMessageHandler object at 0x1004cc890>
=====> Testuju handler2
XYZHandler.test()
self=<__main__.SuperJabberMessageHandler object at 0x1004cc8d0>
JabberMessageHandler.test()
self=<__main__.SuperJabberMessageHandler object at 0x1004cc8d0>
SuperJabberMessageHandler.test()
self=<__main__.SuperJabberMessageHandler object at 0x1004cc8d0>
Schválně, jestli si uděláš představu o přínosnosti ZDRBUGU pro tvoje auto:
Nebudeš mít potřebu ze mě vytáhnout, v čem je kurnik teda ten ZDRBUG tak dokonalý a jedinečný?
U jazyků to vidím podobně. Pokud je majoritní jazyk (třeba Java) použitelný a máme k dispozici vyspělou platformu a lidi, kteří jazyk ovládají, zůstaňme u ní.
simulace LINQ pomocí Lispu
@deda.jabko: je to furt dokola, nemám potřebu v tom pokračovat po 101ní
No vidis, a pritom by stacilo, aby jsi uznal, ze s tim LINQ ma deda.jabko uplnou pravdu.
http://www.root.cz/clanky/lispova-makra-aneb-programovatelny-programovaci-jazyk/nazory/153290/
Pridani nove syntakticke kategorie je tedy velmi jednoduche, protoze vlastne samotna syntaxe zustava nezmenena (treba smycky v LISPu neni nic jineho nez specialni forma)
CitaceU jazyků to vidím podobně. Pokud je majoritní jazyk (třeba Java) použitelný a máme k dispozici vyspělou platformu a lidi, kteří jazyk ovládají, zůstaňme u ní.
...s takovym pristupem dodnes piseme kod v assembleru :-]]
Citacesimulace LINQ pomocí Lispu
LINQ je hezky priklad. Aby sel pridat LINQ do C#, tak bylo potreba udelat zasadni zasahy do specifikace jazyka, kterou navic musel udelat microsoft... a ty to zmeny tam budou trcet navzdy, kvuli zpetne kompatibilite. V LISPu by to byla jen knihovna maker, kterou by pouzivali jen ti co ji chcou/potrebuji a technicky by sis ji mohl napsat ty sam.
Jasne, vsichni mate pravdu. Kdyz jste osviceni, tak co holt mate delat
CitacePridani nove syntakticke kategorie je tedy velmi jednoduche, protoze vlastne samotna syntaxe zustava nezmenena (treba smycky v LISPu neni nic jineho nez specialni forma)
http://www.root.cz/clanky/lispova-makra-aneb-programovatelny-programovaci-jazyk/nazory/153290/
jinak syntaxe jako takova v LISPu rozsirit opravdu jde, protoze v LISPu jde preprogramovat i reader, ktery se stara o nacteni jednotlivych vyrazu. imho, by me zajimalo, kolik dalsich jazyku jeste neco takoveho umi. :-]]
jinak syntaxe jako takova v LISPu rozsirit opravdu jde, protoze v LISPu jde preprogramovat i reader, ktery se stara o nacteni jednotlivych vyrazu. imho, by me zajimalo, kolik dalsich jazyku jeste neco takoveho umi. :-]]
No, není jich asi tolik, ale něco podobného lze dělat v jiných jazycích (různým způsobem): http://nemerle.org/wiki/index.php?title=Features (http://nemerle.org/wiki/index.php?title=Features), http://www.cs.utah.edu/flux/papers/pldi02-maya-base.html (http://www.cs.utah.edu/flux/papers/pldi02-maya-base.html) a koneckonců i http://lampsvn.epfl.ch/trac/scala/browser/compiler-plugins (http://lampsvn.epfl.ch/trac/scala/browser/compiler-plugins). Jasně že tam chybí tradice a zřejmě i vyzrálost Lispu, ale pracuje se na tom. Ve světě Pythonu bych čekal, že se něco podobného brzy objeví kolem projektu PyPy (pokud to už neexistuje).
http://boo.codehaus.org/Syntactic+Macros
V Lispu je to ale samozřejmě daleko osvíceněji udělaný...
Tak na tomto se shodneme. :-)
A to už je vážně konec? :(
Runtime code generation is a useful technique but most really interesting metaprogramming opportunities manifest themselves at compile time through one of the extension points provided by boo: attributes, macros, metafunctions and the compilation pipeline which shall all be covered next.
Myslím, že Boo je s ohledem na rozšířenost horší volba než LISP. LISP je sice i přes dlouhou historii málo používaný, ale Boo je na tom ještě hůř - nikdo ho nezná.
Můj názor je jednoduchý. Úžasných jazyků, "řešících všechny problémy lidstva" je mnoho a možná mezi ně patří i Lisp. Až ale komunita jeho uživatelů dosáhne toho, že bude obecně akceptovaný (sw) průmyslem, pak teprve bude mít "vyhráno".
Abych doplnil tuto debatu o relevantní názor... Schválně jsem tento dotaz (k čemu je dobrý LISP) poslal uznávané osobě na Katedře informatiky Fakulty aplikovaných věd na Západočeské univerzitě v Plzni.
http://bamboo.github.com/2010/07/11/boo-meta-programming-facilities-I-the-ast.html
Ano, kdyz se na to podiva clovek, co zna Lisp, je mu jasne, cim se inspirovali. :-) (Maly hint: [| je ` a $ je ,@ .)
No a? Pan učitel prostě taky ještě není spasen a osvícen...Jak se říká v GTA2:
Můj názor je jednoduchý. Úžasných jazyků, "řešících všechny problémy lidstva" je mnoho a možná mezi ně patří i Lisp. Až ale komunita jeho uživatelů dosáhne toho, že bude obecně akceptovaný (sw) průmyslem, pak teprve bude mít "vyhráno".
Hele, oni přiznali, že LISP je v současností mrtvý :-D
Hele, oni přiznali, že LISP je v současností mrtvý :-D
CitaceMůj názor je jednoduchý. Úžasných jazyků, "řešících všechny problémy lidstva" je mnoho a možná mezi ně patří i Lisp. Až ale komunita jeho uživatelů dosáhne toho, že bude obecně akceptovaný (sw) průmyslem, pak teprve bude mít "vyhráno".
Kdyz pominu, ze "akceptace SW prumyslem" je ponekud slaboduche kriterium (podle nej by mel byt COBOL lepsim jazykem nez puvodni Lisp, nebo VB lepsim jazykem nez Python), tak to neni historicky celkem pravda, ze by Common Lisp nebyl akceptovany prumyslem. Ale zabila ho, jako radu veci, AI zima, mikropocitacova revoluce a fragmentace komercnich implementaci.
Abych doplnil tuto debatu o relevantní názor... Schválně jsem tento dotaz (k čemu je dobrý LISP) poslal uznávané osobě na Katedře informatiky Fakulty aplikovaných věd na Západočeské univerzitě v Plzni.
Jinymi slovy... zabil ho pokrok
Common Lisp se stale dost pouziva, ale vetsina zajimavych (a komercnich) projektu v Lispu vznikla v 70.-90. letech.
Mno a vracíme se k původní otázce. O síle LISPu třeba já osobně nepochybuji, ale jaký je důvod se ho učit (a teď míním do hloubky, ne základy) dnes? Pomineme-li onen jiný přístup k řešení problémů (ano, rozhodně je dobré si tímto směrem rozhledy rozšířit). Ale co ta praxe?
deda.jabko: Nechce se mi psát další email s žádostí o svolení k uvedení jména. Ostatně, ty a mnoho dalších tu taky nevystupujete pod svým jménem.
Tech veci, ktere jsem drive neznal nebo ne zcela chapal, byla cela rada - lexikalni vs. dynamicke promenne, uzavery, makra, restarty, genericke funkce, REPL, vice navratovych hodnot, anaforicka makra, kontinuace, ... Proste kamkoli se do Common Lispu podivate, vidite nejake elegantni reseni.
Ano, ale on se neohani tim, jaka je autorita. Pokud uz se nekdo chce stavet za svoji autoritu, asi by to bylo vhodnejsi. Jinak to opravdu neni nic jineho, nez nazor jako kazdy jiny.
Nikdo to tu nevydává za pravdu. Mimochodem, stejnou odpověď mi dal i vedoucí architekt našeho týmu - jazyk to může být sebesilnější, ale bez knihoven, podpory a dostatku vývojářů v něm těžko můžeš začít něco pořádného dělat.
A když bych chtěl "diskutovat" jako někteří zde, tak mohu říct, že se deda.jabko staví za svou božskou autoritu LISPaře.
Otázka nezněla zda má cenu LISP studovat, na tom se myslím většina z nás shodne, že není co řešit. LISP do takové skupiny patří, stejně jako milion dalších věcí. Otázka zněla Na co všechno je dobrý LISP? Jak já to chápu - pro jaký případný projekt / část projektu se LISP hodí výrazně více než alternativy?
Jak já to chápu - pro jaký případný projekt / část projektu se LISP hodí výrazně více než alternativy?
Mimochodem, tahle otazka je zavadejici - alternativy se necemu rika proto, ze to muzete pouzit take. Kdyby se to pouzit nedalo, nejde o alternativu.
Ne, on mluvi jako nekdo, kdo Lisp (pokud vim) zna a patrne pouziva. O tom jake ma autority nelze nic rict.
Co teda konkrétně *mně* může lisp přinést pro **můj konkrétní projekt**? (osvícení, prozření a cvičení mozku prosím nechme stranou, to už jsme si dostatečně vyjasnili...)
Treba vcera jsem (ciste nahodou pri brouzdani knihoven na quicklisp.org) narazil na commandline prehravac mp3 v Common Lispu http://vintage-digital.com/hefner/software/shuffletron/ (http://vintage-digital.com/hefner/software/shuffletron/). Apropos, koukal jsem do zdrojaku a i kdyz pouzivaji makra, jsou docela prehledne (i kdyz to neni zadny zazrak).
Já proti lispu nic nemám, až bude víc času, chci se do něj hlouběji zabrat, protože mi přijde zajímavý.
Mě by ale skutečně zajímal nějaký větší projekt, kde se LISP ve velké míře používá.
Lisp at ITA Software
What does ITA use Lisp for? In a sense, this is the wrong question. Lisp is a programmable programming language, and one of the few languages that can be used for a wide range of applications. At ITA we have projects with vastly different focus, and it's precisely Lisp's versatility that makes it so useful to us.
Our QPX search engine is engineered for speeds that must not be lower than using C and where huge amounts of data must not be bigger than packing them in C structs. Still, QPX is very complicated, and driven by individuals who write large bodies of code. Lisp allows us to define a wide variety of abstractions to manage the complexity, and at the same time we get the speed we want - and our customers demand. Once QPX is compiled, one cannot easily tell the machine code from the machine code compiled from C.
In other projects we manage even larger collections of coded industry knowledge, and there we use all of Lisp's dynamic features to give us the maximum productivity. This allows us to re-implement airline codebases for use outside of their original scope (mainframes) for the first time.
Fakt je to tak slozite?
the Yahoo! Store web-commerce site, which originally involved Paul Graham and was later rewritten in C++ and Perl
O rozhrani mezi CL a CLR nic nevim, ale stacilo to zadat do Google a vypadlo
Myslím, že je celkem legitimní od lidí, kteří daný jazyk používají a účastní se diskuse o něm, očekávat nějaký *rozumný* shrnující komentář typu "no hele, jak bych ti to řekl - no lisp je super, protože v něm můžeš elegantně a rychle udělat třeba tohle [...] - ale na druhou stranu při praktickém nasazení narazíš zase problémy s [...]. To už musíš zvážit sám, co bude pro tebe v tom projektu důležitější... Ale podle toho, co píšeš, bych ti doporučil [...] - má sice trochu omezenější možnosti než [...], ale na tohle použití by měl stačit."
Sorry, ale odpověď typu "přečti si On Lisp" myslím každého leda odradí, nehledě na nadávání do cvičených opic a lepičů kódu - a konzolový přehrávač mp3 nabytý dojem fakt nemůže zachránit...
Pokud mas tym, co umi Lisp, napis to v Lispu.
Když mi na jedné straně někdo tvrdí, jak je lisp nepřekonatelný, neuvěřítelný a nejgeniálnější jazyk s kulervoucí produktivitou což dokládá kniha od Paula Grahama - a na druhé straně dá velký projekt Grahamovi košem a odejde k hrůzám typu C++ a Perl, tak co si o tom mám myslet?
Jeste muzete zkusit:
http://postabon.posterous.com/why-i-chose-common-lisp-over-python-ruby-and (http://postabon.posterous.com/why-i-chose-common-lisp-over-python-ruby-and)
more obscure libraries like Thrift and OpenID support may be an issue in the future. The lack of libraries is, without a doubt, the biggest disadvantage of CL and one of the reasons Clojure is so appealing to me. I can usually just write my own foreign function interface into a C library – but that’s really time consuming compared to downloading an egg/gem/jar.
Inu - svět prostě na starý kolena blbne.
Ještě že existují lidi jako ty, kteří jsou normální, když už se všichni ostatní zbláznili :)
Ostatně - když po Chuckovi Moorovi v NRAO přebírali jeho výtvory ve Forthu, tak první befehl taky zněl "vše přepsat do Fortranu." A v CERNu se teď zase o 106 přepisují letité knihovny z Fortranu do C++. Inu - svět prostě na starý kolena blbne.
Mě by zajímalo, jestli byste se taky hádali, jestli je lepší kladivo, nebo štípačky, jen proto, že jedni umíte zatloukat hřebíky a druzí štípat dráty...
Problém je v tom, že lispisti tady vehementně tvrdí, že štípačky jsou jedinečný nástroj na cokoli včetně utírání si [...] a kdokoli si utírá [...] čímkoli jiným, je cvičená opice.
Problém je v tom, že lispisti tady vehementně tvrdí, že štípačky jsou jedinečný nástroj na cokoli včetně utírání si [...] a kdokoli si utírá [...] čímkoli jiným, je cvičená opice.
Joo? A to tu řekl kdy kdo?
...
Stále si nerozumíme. LISP je jazyk určený lidem k programování, ne cvičeným opicím k lepení kódu. :D
No tak co se tyka hadky, tak tohleto je asi nejdelsi hadka na soucasnym rootu, protoze je nase "diskuse" uz na prvnim miste s nejvetsim mnozstvim "odpovedi". Takze tohleto vitezstvi si uz muzeme pripnout na triko. Mozna by me zajimalo, jestli take netriumfujeme i v tom, ze je tu nejvetsi mnozstvi odpovedi, ktere neodpovidaji na otazky takovym zpusobem, jak by si zde mnozi prali. Ale tyhlety nazory ted necham stranou a budu se venovat tomu, cemu jsem se venovat chtel a to je zjistit, kde se LISP uplatni lepe, nez jine programovaci jazyky.
V tomto clanku: http://www.flownet.com/gat/jpl-lisp.html (http://www.flownet.com/gat/jpl-lisp.html) (ktery tu byl zminen) jsem se napriklad dozvedel, ze LISP byl uspesne pouzit v robotice, ktera uspesne plnila sve ukoly ve vesmiru. Ale kdyz to vztahnu na nas, tak je tam napsano, ze LISP je velmi dobre pouzitelny (krome jineho) s malymi mikroprocesory a dokonce s mikrokontrolery s malou RAM/ROM v radu nekolika kilobyte - napr. 8kB). Ale s tim, ze s tak malou pameti se zas az tak toho moc napsat neda.
Ale vypada to, ze se konecne vracime k puvodni otazce, ktera znela jako: "Kde se LISP uplatni lepe, nez jine jazyky?".
Strucnych odpovedi je cela rada, tak bych si vybral konkretnejsi otazku a zeptal se...
LISP a GIMP. V GIMPu je LISP pouzit ve script-fu pluginech. A me by zajimalo, jak to v tom GIMPu funguje, jakym zpusobem je LISP implementovany a jak spolupracuje s jazykem, ve kterem je GIMP napsany. Jestli to nekdo vi, nebo ma nekdo odkazy, kde se to lze dozvedet, tak je uvedte. A pripadne jestli nekdo pise script-fu pluginy, tak jak se pisou, a neco kolem nich (nejaky kratky povidani, nebo odkazy).
http://postabon.posterous.com/why-i-chose-common-lisp-over-python-ruby-and (http://postabon.posterous.com/why-i-chose-common-lisp-over-python-ruby-and)
map(lambda each: if each.isManager: each.salary = 2000, employees)LISP a GIMP. V GIMPu je LISP pouzit ve script-fu pluginech. A me by zajimalo, jak to v tom GIMPu funguje, jakym zpusobem je LISP implementovany a jak spolupracuje s jazykem, ve kterem je GIMP napsany. Jestli to nekdo vi, nebo ma nekdo odkazy, kde se to lze dozvedet, tak je uvedte. A pripadne jestli nekdo pise script-fu pluginy, tak jak se pisou, a neco kolem nich (nejaky kratky povidani, nebo odkazy).
LISP a GIMP. V GIMPu je LISP pouzit ve script-fu pluginech. A me by zajimalo, jak to v tom GIMPu funguje, jakym zpusobem je LISP implementovany a jak spolupracuje s jazykem, ve kterem je GIMP napsany. Jestli to nekdo vi, nebo ma nekdo odkazy, kde se to lze dozvedet, tak je uvedte. A pripadne jestli nekdo pise script-fu pluginy, tak jak se pisou, a neco kolem nich (nejaky kratky povidani, nebo odkazy).
Problém je v tom, že lispisti tady vehementně tvrdí, že štípačky jsou jedinečný nástroj na cokoli včetně utírání si [...] a kdokoli si utírá [...] čímkoli jiným, je cvičená opice.
Joo? A to tu řekl kdy kdo?
nedávno si napísal že:...
Stále si nerozumíme. LISP je jazyk určený lidem k programování, ne cvičeným opicím k lepení kódu. :D
1. programovanie je synonymum lepenia kódu.
2. 99% vývojárov neprogramuje v LISPe, sú teda cvičené opice?
Přesně tohle jsme tu zmiňovali hned na začátku - robotiku a důvod, že je to taky poměrně minimalistický jazyk, podobně jako Forth, i když ne tak extrémně.
Pokud jde o ty roboty, tak tam se asi nejvíc uplatňují přednosti snadného prototypování, interaktivního vývoje a nenáročnosti LISPu.
Problém je v tom, že jste nevyargumentovali, PROČ se v té robotice používá.Jedním z pádných důvodů může být např. modifikace programu za provozu. Nemusím robota zastavovat jenom kvůli změně programu.
script-fu není LISP, ale Scheme (ale ono je to do značné míry jedno). Jinak nehledejte v LISPu něco tak diametrálně odlišného a pokud je LISP (Scheme) jako skriptovací jazyk nějakého programu, tak v tom jazyku máte prostě jen zpřístupněné proměnné, popř. nějaké funkce toho programu. Prostředky jazyka to jen přenastavujete a spouštíte (třeba máte obrázek a forem zvýšíte hodnotu jedné barevné složky každého pixelu)...
Jedním z pádných důvodů může být např. modifikace programu za provozu. Nemusím robota zastavovat jenom kvůli změně programu.
Ale vypada to, ze se konecne vracime k puvodni otazce, ktera znela jako: "Kde se LISP uplatni lepe, nez jine jazyky?".
V jiných jazycích to jde? Pokud vím, umí to například Erlang.Jedním z pádných důvodů může být např. modifikace programu za provozu. Nemusím robota zastavovat jenom kvůli změně programu.
Tak na to já už nemám nervy...
Jestli tomu dobře rozumím, tak prakticky jediná výtka proti Pythonu, která zůstala, je Guido nemá rád FP. Když tedy zdvořile opomenu to, že v jednom odstavci autor tvrdí,
V jiných jazycích to jde? Pokud vím, umí to například Erlang.
Diky. Presne to jsem chtel vedet. :) a v programech typu CAD je to to same, nebo tam je to jinak?
Pokud vím, tak LISP používal AutoCAD a osobně jsem v tom nedělal, ale čekal bych stejný princip. Jazyk je jenom nástroj. Co jsem teď zběžně našel:http://www.jtbworld.com/lisp.htm (http://www.jtbworld.com/lisp.htm)
JJ, to API v AutoLispu bylo v zásadě ekvivalentní API v C (ADS library). Pro zajímavost, někdo udělal podobnou podporu skriptování v Pythonu: http://pyacad.sourceforge.net/ (http://pyacad.sourceforge.net/)
Jestli tomu dobře rozumím, tak prakticky jediná výtka proti Pythonu, která zůstala, je Guido nemá rád FP. Když tedy zdvořile opomenu to, že v jednom odstavci autor tvrdí,
Nemuzu diskutovat za autora, akorat si myslim, ze je to zajimavy odkaz (predevsim diskuse u nej) - proto jsem to sem take vlozil.
Už jsi zkusil vyměnit funkci běžícímu programu? Každý interpretr to nepřekousne. Kromě toho tuto funkci zvládá Lisp atomicky - je možné tuto funkci změnit i v okamžiku, kdy je v ní proces.V jiných jazycích to jde? Pokud vím, umí to například Erlang.
To snad umí jakýkoli intepretovaný jazyk, ne?
Tak to je hodně zlé, když programátoři dnes už mají potíže i s formální logikou...
Kromě toho tuto funkci zvládá Lisp atomicky - je možné tuto funkci změnit i v okamžiku, kdy je v ní proces.
factorial(N) when N > 0 ->
N * factorial(N - 1);
factorial(0) -> 1.
Tak to je hodně zlé, když programátoři dnes už mají potíže i s formální logikou...
To teda je. Ale v tvojich plkoch by som logiku nehľadal.
Už jsi zkusil vyměnit funkci běžícímu programu? Každý interpretr to nepřekousne. Kromě toho tuto funkci zvládá Lisp atomicky - je možné tuto funkci změnit i v okamžiku, kdy je v ní proces.
ad patter matchin
hledal jsem knihovnu, která by mi umožňovala psát funkce podobně jako v erlang, nic uspokojivého jsem nenasel...Kód: [Vybrat]factorial(N) when N > 0 ->
N * factorial(N - 1);
factorial(0) -> 1.
Tenhle příklad je ještě v pohodě, to by zvládnul i cond. Hlavní sílu pattern matchingu vidím ve svazování hodnot se jmény (x:xs) pro seznam v Haskellu apod., @ patternech atd. Lisp naštěstí nemá algebraické typy, takže odpadají argumenty typu tahání vnitřků z ADT apod. Tohle je věc, která mi u Lispu chybí docela dost.
Myslis neco jako destructuring-bind? Jinak v knizce On Lisp jsou popsane ruzne typy pattern matchingu a destrukturovani, jestli je to silne jako Haskell netusim.
Jo, destructuring-bind dělá něco takového. Ale poradí si třeba s něčím takovým (předpokládám, že ten kód je poměrně pochopitelný)?Kód: [Vybrat]matchTest = matchTest' [1, 2, 3, 4, 5]
where
matchTest' [] = 0
matchTest' [x] = x
matchTest' s@(x:xs) = x * (length s) * matchTest' xs
Haskell? Jsem rád, že tu je někdo, kdo my poradí lamerskými dotazy až se začnu učit haskell... ;D
Erlang mě přivedl k funkcionálnímu programování, ale jednak není čistě funkcionální, a jednak na desktopové aplikace se zrovna moc nehodí...
Jestli tomu dobře rozumím, tak prakticky jediná výtka proti Pythonu, která zůstala, je Guido nemá rád FP.
Já osobně tyhle "funkcionální" prvky v pythonu nepoužívám vlastně vůbec.
Jo, destructuring-bind dělá něco takového. Ale poradí si třeba s něčím takovým (předpokládám, že ten kód je poměrně pochopitelný)?
asi před rokem kolega s úspěchem nasadil do GUI kódu "currying" (tu pythonní obdobu) pro předzpracování zobrazených dat.
asi před rokem kolega s úspěchem nasadil do GUI kódu "currying" (tu pythonní obdobu) pro předzpracování zobrazených dat.
Chápu to správně, že místo f(data1) -> data2; g(data2) -> data3 pouzil f(data1) -> g; g() -> data3? Má to nějaké významné výhody, převažující nevýhodu, že sa na data2 nemůžu kouknout?
def __init__(nazev, transformace):
def transformujVek(radek):
return (str(radek[klic]), radek[klic])
Sloupec(
JMENO,
transformuj('jmeno', lambda x: x.capitalize(), lambda x: x)
),
Sloupec(
VEK,
transformuj('vek',lambda x: x, lambda x: x)
)def transformujVek(radek):
return (radek['vek'], radek['vek'])
@Inkvizitor: Takže šlo vlastně jenom o to, aby byl kód pěkný a přehledný?
Tak nějak. Podle mě to ale není málo.
Tak teď se musím ozvat. Čitelnost kódu je vždy na 1. místě. I špatný a neefektivní kód, když není zprasený, může někdo programátorsky zdatnější dát dohromady. Nečitelný kód nikdy. Tvrzení, že čitelnost a přehlednost kódu není důležitá, je jako tvrzení, že při programování není potřeba mozek, však to stejně píší ruce, ne?
O tom ale vůbec není řeč. Šlo o to, že buď mám kód napsaný normálně hezky a čitelně "procedurálně", nebo normálně hezky a čitelně "funkcionálně".
Myslim, ze z kontextu je jasne, ze ten problem elegantneji proceduralne zapsat neslo
Funkcionální přístup (konkrétně třeba i ty pipelines, které zmiňuje JS) má i další výhody. Konkrétně doporučuji prostudovat si tuto kapitolku (http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies_23.html). Procedurální kód je obecně špatně paralelizovatelný, zatímco čistě funkcionální přístup je přirozeně přístupný paralelizaci.
Elegance kódu je subjektivní záležitost.
Vidim, ze jsem po tydnu pozapomnel, jak je s vami tezka domluva.
Samozrejme, mozna ze by to Prymek napsal Inkvizitorovi lepe
Nevím, co je tak provokativního na konstatování zjevného faktu, že někomu se víc líbí řešení A, někomu
řešení B - a dokonce i když řešení bude stejné, někomu se vícd líbí napsat ho stylem X, někomu stylem Y.
No, co je na tom provokativniho - ze by me opravdu ten elegantni zapis Unixovych pipes proceduralne zajimal, bude se hodit, az budu zase pouzivat modul subprocess. Ja elegantnejsi zapis neznam [...] Takze bud takovy zapis znate, a pak se ho rad dozvim, a nebo takovy zapis neznate, a pak mate priklad k vasemu tvrzeni, ze jde vzdy o subjektivni zalezitost.
Napište mi přesnou definici, jaké řešení je "funkcionální" a jaké "procedurální" a můžeme se o tom pobavit. (i když popravdě řečeno nevidím důvod takového rozhovoru...)
Když třeba v céčku napíšu int x = f(g(y)), tak to je "funkcionální", protože "definuji novou funkci jako slozeni existujicich pomoci aplikace funkce"?
V tomhle pripade se "funkcionalni" tyka moznosti mit funkce, ktere pracuji s funkcemi.
V tomhle pripade se "funkcionalni" tyka moznosti mit funkce, ktere pracuji s funkcemi.
A roura pracuje s funkcemi?
Nezlobte se, ale je naprosto zbytečné se překřikovat, když Vám (jak jste sám uvedl) není jasné, co znamená funkcionální programování. Zkuste se podívat na lambda kalkul, třeba Haskell (který se snaží být striktně funkcionální) atp. Nevykřikujte jen proto, že něčemu nerozumíte...
result = reduce(lambda x, y: x+" "+y, ["a", "b", "c", "d", "e"])
l = ["a", "b", "c", "d", "e"]
result = ""
for s in l[:-1]:
result += s+" "
result += l[-1]
(ošetření zvláštních případů pro stručnost vypouštím)V tomhle pripade se "funkcionalni" tyka moznosti mit funkce, ktere pracuji s funkcemi.
A roura pracuje s funkcemi?
Da se to tak chapat.
Jak uz tady nekdo naznacoval, neskodilo by vam podivat se na lambda kalkul.
3. do téměř jakéhokoli jazyka můžu zavést "funkcionální prvky", které funkcionální programování nějakým způsobem *připomínají*. I do céčka můžu zavést funkci map, která bude fungovat s callbacky. Takovou věc pak můžu používat tak, že to někomu bude *připomínat* funkcionální programování, zatímco někdo jiný řekne, že to žádné funkcionální programování není. Jak mám vědět, co JS bude považovat za dostatečně *podobné* funkcionálnímu programování, bavíme-li se *procedurálním* jazyku? (s Inkvizitorem byla řeč o pythonu)
Takze, v jazyce jako C, jak takovou operaci, vyuzivajici "|", elegantne zapises?
Neda sa nahodou funkcionalna paradigma ovela lahsie paralelizovat ,,pod kapotou", zatial co napr. for-cyklus nie?
Nemám zájem "diskutovat" s někým, kdo mi neustále dává najevo, že jsem idiot. Takže si to užijte s někým jiným. S chutí vám nechávám poslední slovo.
Přesně proto jsem se Inkvizitora ptal, co ho k používání těch jakože-funkcionálních prvků vede, když mu nepřináší to ovoce skutečně funkcionálního jazyka (např. právě ta optimalizace). Inkvizitor to narozdíl od JS pochopil a odepsal, že to dělá kvůli tomu, že se mu jakože-funkcionální zápis *líbí*.
Lenze keby niekto preimplementoval funkciu map() / reduce() v Pythone na nieco efektivnejsie, programy pobezia automaticky rychlejsie, zatialco klasicke for-cykly nie.
Napr. v Jave cakam na closures (funkcie ako objekty) ako na spasenie, lebo to dramaticky zefektivni zapis. Skolske priklady su ,,prelez zoznam a s kazdym prvkom urob nejaku transformaciu", pripadne ,,odfiltruj zo zoznamu dane prvky", pricom transforimacia / podmienka filtracie sa specifikuje, ci meni za behu sa pisu nasobne lahsie. (O obsluhe udalosti v GUI ani nehovorim, to, co C# sekaju delegatmi, v Jave este stale nie je).
No ale to pořád bude klasická javovská funkce, akorát bude nepojmenovaná. Syntakticky to možná bude *připomínat* nějakou funkcionální konstrukci, ale vnitřně to bude furt ta stará známá funkce...
Nemuzu vedet, co vite a co ne.
Nemuzu ani vedet, zda vubec vite, co je currying.
Pokud se hodlate urazet pokazde, kdyz si nekdo mysli, ze neco nevite, asi bude dost tezke s vami vyjit... (a naopak - neni to tak dlouho, co jste se tu naopak rozciloval, ze predpokladam, ze neco vite)
Me pripada analogie mezi curryingem a pipelinou zrejma, vam asi ne.
Ano. A pak jste tu zacal tvrdit, ze je to subjektivni nazor, a ze elegance funkcionalniho zapisu nad proceduralnim je subjektivni. Coz bych prave rad kontroval prikladem elegance zapisu rour v shellu; pokud by mela byt subjektivni, rad bych videl lepsi (alespon subjektivne) proceduralni zapis.
Myslim, ze uzaver (closure) je neco jineho, nez co si vy myslite, ze to je. Znovu nezbyva nez doporucit [...]
Já jsem ale mluvil o něčem úplně jiném: jestliže v *procedurálním jazyce* můžu nějakou věc napsat "jakože-funkcionálně" nebo "normálně-procedurálně", potom je imho věcí vkusu, který ze zápisu použiju, protože s pravděpodobností hraničící s jistotou překladač oba zápisy přeloží úplně stejně.
ale ještě ze mě při tom děláte vola
To se mozna prelozi stejne, ale ten funkcionalni bude v nekterych pripadech kratsi a citelnejsi.
Jenže ono to na "něco efektivnějšího" implementovat afaik nejde, protože ten jazyk prostě funkcionální *není* a *nikdy nebude*.
http://forum.root.cz/index.php?topic=1978.msg15951#msg15951
Blik?
Mimochodem, to, ze se smycka da zapsat jako funkce nazyva Doug Hoyte v Let Over Lambda pripadem "syntakticke duality", a tvrdi, ze tyto duality jsou hlavni duvod, proc je Lisp tak dobry jazyk (a proc programatori snaseji ty zavorky).
Například můžu napsat "funkcionálně":Kód: [Vybrat]result = reduce(lambda x, y: x+" "+y, ["a", "b", "c", "d", "e"])
nebo "procedurálně" něco ve stylu:Kód: [Vybrat]l = ["a", "b", "c", "d", "e"](ošetření zvláštních případů pro stručnost vypouštím)
result = ""
for s in l[:-1]:
result += s+" "
result += l[-1]
...přičemž oboje s velkou pravděpodobností překladač přeloží na úplně stejný nebo aspoň hodně podobný výsledný kód.
" ".join(["a", "b", "c", "d", "e"])Obě řešení navíc obsahují chybu (to není kritika, chápu, že jde o rychlý příklad), neboť na rozdíl od joinu si nedokáží poradit s prázdným vstupním seznamem. V takovém případě bych asi stejně nasadil funkci, samozřejmě s tím rizikem, že v Pythonu je volání funkce poměrně drahé. Jinak by tam musel ještě přibýt if a došli bychom k tomu, co nemám rád - procedurální/imperativní kód bobtná a stává se méně a méně přehledným. Tu funkcionální verzi lze zkrátit ve stylul = ["a", "b", "c", "d", "e"]
result = reduce(lambda x, y: x+" "+y, l) if l else ''ikdyž samozřejmě zůstává otázkou, co je nakonec čitelnější. Já hlasuji pro one-liner.
No vida a zrovna na tohle je ideální funkcionální konstrukceKód: [Vybrat]" ".join(["a", "b", "c", "d", "e"])
Obě řešení navíc obsahují chybu (to není kritika, chápu, že jde o rychlý příklad),Jasně. V tom druhém případě jsem to tam i napsal.
Jinak by tam musel ještě přibýt if a došli bychom k tomu, co nemám rád - procedurální/imperativní kód bobtná a stává se méně a méně přehledným. Tu funkcionální verzi lze zkrátit ve styluKód: [Vybrat]l = ["a", "b", "c", "d", "e"]ikdyž samozřejmě zůstává otázkou, co je nakonec čitelnější. Já hlasuji pro one-liner.
result = reduce(lambda x, y: x+" "+y, l) if l else ''
P.S. dáme závod o nejnečitelnější "funkcionální" oneliner? ;)
http://www.root.cz/clanky/perlicky-uvod-do-referenci/nazory/187499/
Já už jsem jeden docela drsný kdysi napsal:Kód: [Vybrat]http://www.root.cz/clanky/perlicky-uvod-do-referenci/nazory/187499/
No vida a zrovna na tohle je ideální funkcionální konstrukceKód: [Vybrat]" ".join(["a", "b", "c", "d", "e"])
Tak teď teda už vůbec nechápu, co se slovem "funkcionální" míní, pokud volání metody objektu je "funkcionální konstrukce" :)
join :: String -> [String] -> String
join s [] = ""
join s [x] = x
join s (x:xs) = x ++ s ++ (join s xs)
main = print $ " " `join` ["a", "b", "c", "d", "e"]
dostali bychom se k podobné syntaxi a v zásadě i sémantice. A volání metody, která má jenom jeden parametr, lze ve Scale napsat ve stylu infixové funkce. Kdyby třída String měla metodu join(), bylo by možné psát normálně" " join List("a", "b", "c", "d", "e")
Mimochodem, to, ze se smycka da zapsat jako funkce nazyva Doug Hoyte v Let Over Lambda pripadem "syntakticke duality", a tvrdi, ze tyto duality jsou hlavni duvod, proc je Lisp tak dobry jazyk (a proc programatori snaseji ty zavorky).
Kde přesně to je?
Promiň, ale jestli budeme za "funkcionální obrat" považovat všechno, co nám *nějak* (v tomhle případě jenom pořadím "objektů") připomíná něco z nějakého funkcionálního jazyka, tak to už jsme ten pojem definitivně vyprázdnili a pro mě osobně ztrácí smysl ho vůbec používat...
Kvuli tomu tu knizku nema cenu cist..
Kvuli tomu tu knizku nema cenu cist..
Já chci jenom vědět, kde to v té knížce je.
http://letoverlambda.com/index.cl/guest/chap3.html#sec_7 (http://letoverlambda.com/index.cl/guest/chap3.html#sec_7)
No tohle jsem právě četl a nikde tam nevidím "to, ze se smycka da zapsat jako funkce". Takže je to v té 7mé kapitole? Kde přesně?
(loop for i from 1 to 10 do (print i))je to v té 7mé kapitole? Kde přesně?
Tak protoze ta smycka je vlastne volani funkce (nebo spis makra), neni problem pozdeji tu smycku zmenit a napsat tam my-loop misto loop, kde to my-loop muze treba tu smycku paralelizovat.
A tady je IMO jasná demonstrace, že Lisp (Scheme) se jako jazyk pro skriptování Gimpu moc neosvědčil a jeho volba byla dána pravděpodobně dobovým kontextem: http://forum.root.cz/index.php?topic=1884.0 (http://forum.root.cz/index.php?topic=1884.0) Zlatý Python, zlatá Lua...
LISP a GIMP. V GIMPu je LISP pouzit ve script-fu pluginech. A me by zajimalo, jak to v tom GIMPu funguje, jakym zpusobem je LISP implementovany a jak spolupracuje s jazykem, ve kterem je GIMP napsany. Jestli to nekdo vi, nebo ma nekdo odkazy, kde se to lze dozvedet, tak je uvedte. A pripadne jestli nekdo pise script-fu pluginy, tak jak se pisou, a neco kolem nich (nejaky kratky povidani, nebo odkazy).
(if (not (= shadow 0))
(begin
(gimp-image-add-layer img shadow-layer -1)
(gimp-edit-clear shadow-layer)))
(gimp-context-set-background '(0 0 0))
Promiň, ale jestli budeme za "funkcionální obrat" považovat všechno, co nám *nějak* (v tomhle případě jenom pořadím "objektů") připomíná něco z nějakého funkcionálního jazyka, tak to už jsme ten pojem definitivně vyprázdnili a pro mě osobně ztrácí smysl ho vůbec používat...
(nic ve zlým, to není kritika, jenom takový povzdech)
Doufám, že jsem svůj postoj dostatečně vysvětlil.
Nicméně je pro mě důležité, abych mohl program psát (alespoň na nejvyšší úrovni) tak, že specifikuji co je třeba vypočítat a ne jak to má program/počítač udělat.
Nicméně je pro mě důležité, abych mohl program psát (alespoň na nejvyšší úrovni) tak, že specifikuji co je třeba vypočítat a ne jak to má program/počítač udělat.
Me prijde, ze tohle je obecny duvod, proc zavadime nejake jazyky (a nechavame optimalizovat kompilator). Pokud uz bych to musel nejak nazvat, tak spis deklarativnim programovanim nez funkcionalnim. To same by slo rict o OOP, ze nemusime rucne kodovat tabulky virtualnich metod. Nebo o Prologu - je funkcionalni? V podstate kazda abstrakce, kterou nam jazyk dava (a Lisp nam dava moznost tvorit nove) je krokem k tomu "co misto jak", protoze to jak schovava nekam pod kapotu.
Mně přijde, že OOP jde jiným směrem a řeší jiné problémy než FP a přestože je daný jazyk založený na OO paradigmatu, pořád v něm lze používat konstrukce, které bych nazval funkcionálními.
Pokud bysme byli poctiví, musíme zákonitě nakonec přijít na to, že ve všech používaných jazycích se dají zhruba stejně dobře řešit všechny praktické problémy (jinak by ty jazyky nikdo nepoužíval) - s tím, že na některé specialitky je trochu lepší jeden, na druhé jiný, ale celkově mají ve finále všechny stejné možnosti.
Klidne si to mysli, ale je dost lidi, chytrejsich nez ty, kteri si to nemysli.
A co z toho plyne? Ze si to musim myslet taky?
Mluvi o tom, ze kazdy programovaci jazyk dokaze svym osobitym zpusobem resit zakladni problemy (jake to presne jsou sice nrekl, ale budiz). Dale rekl, ze urcite speciality dokaze jeden jazyk resit lepe nez ten druhy (opet nerekl, o jake speciality jde, ale opet budiz).
A tim, podle mne, priznal, ze i LISP dokaze resit zakladni problemy svym osobitym zpusobem stejne, jako jine jazyky.
Jak uz jsem psal, plyne z toho, ze to neni "zakonite" a ze si to nemusime myslet, i kdybychom "chteli byt poctivi". (To co je v uvozovkach jsi napsal vyse.)
Pokud bysme byli poctiví, musíme zákonitě [...]
A odkud beres tu jistotu, ze vsichni lidi, kteri jsou chytrejsi nez ja, jsou POCTIVI? Nebo jak vis, ze vsichni ti z nich, kteri jsou poctivi, si nemysli to, co jsem rekl?
Ja myslim, ze to co jsi napsal, jsem pochopil jasne. Tedy, ze "kazdy rozumny clovek musi prijmout, ze vsechny jazyky maji stejnou vyjadrovaci silu".
Mozna jsi to pochopil dle sveho nazoru jasne, ale dle meho nazoru spatne.
Jak mam tedy chapat vetu "Pokud bysme byli poctiví, musíme zákonitě nakonec přijít na to, že ve všech používaných jazycích se dají zhruba stejně dobře řešit všechny praktické problémy (jinak by ty jazyky nikdo nepoužíval)"?
Snad se v tom nechces stourat?
Ty jsi tvrdil, ze jsem te pochopil spatne, tak chci vedet, v cem?
Jen pridam (znovu) odkaz na toho Grahama: http://www.paulgraham.com/avg.html (http://www.paulgraham.com/avg.html) (kde zcela jasne polemizuje s moji interpretaci tvoji vety)
Nedávno jsem si trochu hrál s programovacím jazykem LISP. Docela mě překvapilo, jak je jednoduchý a přitom univerzální.
Rád bych se tady zeptal, na co všechno se LISP používá, případně na co všechno by se dal použít?