Na co všechno je dobrý LISP?

[deda.jabko]

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í.

a to si myslis, ze jde nacpat do diskuze? a do diskuze, kde jeden o tom druhemu jazyku nic nevi?

hele, pokud chces nejake reci od lidi, co lisp pouzivaji a maji k tomu duvod a vydelali na tom miliony. precti si neco od grahama http://www.paulgraham.com/avg.html  http://www.paulgraham.com/progbot.html http://www.paulgraham.com/carl.html

[Reklama]

[Mirek Prýmek]

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:

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.

(samozrejme Lisp se bez neho taky neobejde, ale to si jaksi nikdo nechce priznat - ze totiz ty pismenka se zazracne v nuly a jednicky nepromeni samy - a je uplne jedno, jestli je exec-uju skryte na pozadi, nebo zjevne v kodu...)

[deda.jabko]

Kód: [Vybrat]

v = delay(lambda: i + 1)

a bez te lambdy to nejde?

[Mirek Prýmek]

precti si neco od grahama

To je nejaka lisperská nemoc, tohle*? Je to nakazlive?


* neschopnost neco strucne vysvetlit, napr. popsat pomocí pár vět implementaci algoritmu

[Inkvizitor]

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.

Vzhledem k zadání (výraz) mi to přišlo dostatečné. Vzhledem ale k tomu, že delay je normální dekorátor, dá se to aplikovat i na obecnou funkci.

a bez te lambdy to nejde?

Momentálně mě řešení bez lambdy nenapadá. Vadí to moc?

[Reklama]

[Mirek Prýmek]

Vadí to moc?

Až někdo přijde s příkladem, kdy je to nutné nebo alespoň mimořádně vhodné použít k řešení nějakého problému, tak to vadit bude. Do té doby je to úplně bezpředmětné, protože se tady jenom trumfujete, kdo si umí líp honit triko.

[Inkvizitor]

protože se tady jenom trumfujete, kdo si umí líp honit triko.

Ale kdepak. Já se jenom z lispařů snažím vymáčknout co nejlepší argumenty.

[JS]

[quote author=Inkvizitor link=topic=1978.msg15265#msg15265 date=1301510500
Tohle bych prosil vysvětlit. "Víc než o konstantu" podle mě zkracují kód i poměrně standardní funkce vyšších řádů (jejichž obdobu podporuje koneckonců i C) nebo hloupé GOSUB. Co znamená zkrácení o konstantu a kdy jde o asymptoticky lepší optimalizaci?
[/quote]

Teoreticky ano, ale kdo to pak bude cist?

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.

[Inkvizitor]

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.

Já mám s makry (pokud chápu správně směr příspěvku a tady by se mi líbil příklad) docela problém v případě, že se snaží něco dělat skrytě. Coby (neortodoxní) pythonista ctím zásadu, že explicitní je lepší než implicitní. 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.

Co se týče línosti a funkcionálního purismu, to bych se bál spojovat jenom proto, že nejznámější líný jazyk je shodou okolností Haskell.

Fakt by se hodily konkrétní příklady, já si to přád mám problém živě představit.

[koroptev]

Inkvizitor:
jeste k te tail rekurzi; to je to, co me bije do oci: zastanci CL casto uvadi jako vyhodu standardizovanou podobu jazyka (coz je obvykly protiargument proc ne dejme tomu neco jako Racket) + netrvani na jednom paradigmatu; pokud ovsem budu chtit psat ciste funkcionalni kod (jedno z nabidky tech paradigmat), pak to nebude ten kod, jehoz funkcnost mi standard zarucuje

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?

[JS]

skutecne obtizny dotaz na makristy - jak implementaci CL, ktera nema podporu tail callu, pomoci maker o tuto podporu rozsirim? :-)

Nevim. Trochu jsem googlil a tady je takovy nastrel, ktery pouziva CPS transformaci http://www.rhinocerus.net/forum/lang-lisp/46642-cl-implementations-tail-call-elimination.html. Ale moc bych se tim netrapil, vsechny bezne implementace ji v nejake forme maji.

nebo pattern matching ala Ocaml (a patrne Haskell)?
a bude to s pomoci maker stejne rychle, jako kdyz to bude podporovat primo prekladac?

Pattern matching popisuje Paul Graham v On Lisp (nevim, jestli je to stejne jako Ocaml nebo Haskell, neznam je). Teoreticky by to mohlo byt stejne rychle.

Stejne tak Graham ukazuje implementaci call/cc, a zminuje CPS (continuation passing style) transformaci, i kdyz ji neimplementuje. Tam je i diskuse o tail callech.

Ano, existuji veci, ktere se i s velmi silnym makrosystemem delaji nesikovne. Je to tak prekvapive?

[JS]

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.

Ja myslel spis situace, kdy synchronized nestaci a je potreba zamek udelat mimo funkci nejakeho API (na konkretni situaci si nevzpominam, ale nejak to souviselo s condition variable). Treba pthreads vyzaduji, aby volajici pred vstupem do cond_wait() zamkl souvisejici mutex. Se zamky jsou problemy - jedna malickost vam muze totalne zmenit dukaz korektnosti celeho zamykani. Proto IMHO neni dobre davat je dovnitr funkci, byt pres dekoratory.

Samozrejme, teoreticky lze vsechno poresit pres synchronized nebo jine pristupy k synchronizaci, ale realny svet casto neni tak jednoduchy (to je ostatne to, co mi vadi na pure functional jazycich - vyzaduji cistotu v podstate vsude).

V CL jsem paralelne neprogramoval, ale dokazu si predstavit situace v C, kdy by se mi Lispova makra velmi hodila.

[JS]

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 a mozna trochu http://shootout.alioth.debian.org/ nevim o zadne studii srovnavajici produktivitu programovacich jazyku (libovolnych - ne primo Lispu). Urcite by se hodily, ale nikdo o to nema zajem (financne lepsi je, kdyz nikdo nevi, jak to je, nez aby nejaka mocna firma prohrala). Ja za sebe muzu rict, ze kdybych v necem takovem participoval, tak jedine anonymne. :-)

Takze opravdu, jedine, o co se muzeme oprit, jsou anekdoty lidi, kteri zkusili vic jazyku, a muzou to porovnavat. Je to asi skoda, na druhou stranu, je z pochopitelnych duvodu obtizne sehnat lidi (a pripadne finance) pro takove studie.

[Mirek Prýmek]

Bohuzel, krome http://page.mi.fu-berlin.de/prechelt/Biblio//jccpprtTR.pdf a mozna trochu http://shootout.alioth.debian.org/ nevim o zadne studii srovnavajici produktivitu programovacich jazyku (libovolnych - ne primo Lispu).

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ší.

A z toho tvyho odkazu:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=sbcl&lang2=java

Lisp 2x (median) pomalejší než bytecode java.

[koroptev]

JS:
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