Názory k článku
Programovací jazyk LISP (druhá část)

Tecky v consech (tak rikam tem teckovym parum) by mely byt z obou stran oddelene mezerou. Jsem rad za kazdy clanek o Lispu, diky :-).

Plne souhlasim! Z hlediska prehlednosti a jednoznactosti by se mel teckovany par zapisovat jako PRVEK . PRVEK Jinak moc diky za vynikajici clanek.

Nevím proč se mi po přečtení tohoto příspěvku asociovalo ono staré známé
„Lost In Stupid Parentheses“ :-D

S Lispem nemam zadne prakticke zkusenosti. Proc ale musi byt zavedeny specialni formy? Pocitove mi tam nesedi. Neslo by specialni formu (IF PODMINKA fceTRUE fceFALSE) ji nahradit (IF PODMINKA '(fceTRUE fceFALSE)).
Proste by se fci IF predaly jako parametry vyhodnocena podminka a nevyhodnoceny seznam a az fce IF by z nej vyhodnotila prvni ci druhy prvek.

Aby to nemuselo byt v tom seznamu, musi to byt specialni forma (tudiz makro). Pokud by if byla takova funkce, jak navrhujete, musela by v tele obsahovat nejaky eval, takze by se problem jen dost neelegantne obesel. Lisp neni funkcionalni jazyk (a vyhodnocovaci proces neni liny), a proto se bez maker, ktere resi co se bude/nebude vyhodnocovat, neobejde.

Pochopil jsem to tak, ze specialni formy jsou tedy v lispu kvuli zjednoduseni zapisu. Dalo by se bez nich obejit, pokud by hlavnim kriteriem byla cistota jazyka.

No ona je i (quote) alias ' (apostrof) specialni forma, takze obejit se bez ni IMHO neda, resp. bez nejakeho mechanismu, ktery by urcoval, zda se ma neco vyhodnotit ihned nebo az na pozadani. To stejne (setq), taky specialni forma.

Ono to zacina uz lambdou, ktera je taky spec. forma :-).

Pravda, jak jsem mohl na lambdu zapomenout :-), kdyz je dokonce v perexu clanku

Makro != speciální forma; popravdě řečeno to, že ve větě

3. seznamy jsou vyhodnocovány tak, že se první prvek seznamu chápe jako jméno funkce (či speciální formy), které je předán zbytek seznamu jako parametry této funkce (formy)

není zmínka o makrech mne docela překvapilo. Ale beru to tak, že mluví o již makroexpandovaném kódu a že o expanzi maker bude řeč jindy.

If opravdu jde lze udělat jako funkci a i bez evalu, volanou (if-fn cond #'true-branch #'false-branch)  – ale všech forem se takto asi zbavit nelze, a tady zrovna přivolání vyleze function-value.

Mimochodem, historicky byl jako speciální funkce spíš
cond a if jako nadstavba, i když to CL nyní definuje obráceně – ale s „An implementation is free to implement a Common Lisp special operator as a macro. An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided.“

A fungovalo by v tom ifu i toto?

(let ((a 10))
  (if 1 ‘((lambda() a) 2))

Pokud se to ifu předá jako nevyhodnocený seznam, tak se nevytvoří closure a pak se „a” nevyhodnotí na 10.

Ve Scheme se na rozdil od LISPu T a nil pro vyjadreni booleovskych hodnot uz nepouziva, namisto toho jsou tam atomy #t a #f, coz me pripadne jako skoda (ta LISPovska konvence byla vice minimalisticka). Nevi nekdo nahodou, proc to ma Scheme vyresene jinak?

Mozna, ze to trochu skoda je, ale z hlediska „cistoty“ jazyka: nil neni to same co nepravda. Otazka je, co znamene ciste — melo by (if '() 1 2) vracet 1 nebo 2 (scheme: 1, lisp: 2)? Zkuseny lispovy programator dokaze s onoho minimalismu tezit, zacatecnik musi byt obezretny.

ve schemu se sice pouziva #t a #f… ale pro vyjadreni pravdy se da pouzit jakykoliv jiny objekt nez #f. jinymi slovy funguje: (if 1 2 3) ⇒ 2 (anologicky commonlispu, kde kazdy vyraz krome NIL odpovida ,,true'')

o duvod vic si myslet, ze to #t a #f je zbytecne, resp. dela to problemy pri prechodech mezi LISPem a Scheme, viz ukazku kodu, ktery o nazor vice prezentoval kolega.

http://abstractnonsense.com/schemix/

Ta funkce infix->prefix je jednou v clanku zapsana jako infix-<prefix. Alespon me nenapada zadny duvod, proc by to melo takhle zapsane byt spravne.

To je moje chyba, jak jsem demonstracni priklady prepisoval do HTML, tak jsem omylem namisto &gt; zapsal &lt;

Bude to opraveno, diky za upozorneni.

Nechci moc vyvolat flame, ale chtel bych se zeptat, jestli se jako docela skalni LISPar :-) mam vic podivat „na zoubky“ Haskellu. Vsude je na ten jazyk slyset chvala, jen mi moc nesedi to staticke typovani, precejen je LISP v nekterych ohledech hodne volny a makra, to je taky posusnanicko (kdyz to clovek moc neprasi, potom nevi, co se v runtimu bude vlastne dit :-). Tedy abych to shrnul – ma cenu aby LISPar prechazel na Haskell nebo je to spis jazyk, ktery chytne treba byvale Ceckare?

možno ti toto pomôže rozhodnúť sa:

http://www.alsonkemp.com/haskell/reflections-on-leaving-haskell/

Ja ho mám tiež na zozname, ale asi tam aj ďalších pár rokov ostane…

Další z obskurních jazyků?

ale no tak… pokud je pojmem „obskurni“ myslen jazyk, ve kterem dokazu byt tak 5× vykonnejsi nez v dnesnich mainstreamovych jazycich, tak ano, je dobre se vzdelavat. Mimochodem je zajimave, ze prave v minulosti ty „nej“ jazyky jsou dnes chapany jako obskurnosti nejvetsiho kalibru, napriklad COBOL. Za par let se stejne budeme divat treba na C++ a ptat se proc v tom proboha nekdo programoval a potom musel resit „malickosti“ typu stack overflow, memory management, vicevlaknovost atd…

(nez zacnete resit vykonnost vysledneho kodu „C++ je nejlepsi“, mrknete se prosim na vysledky, ktere davaji nektere Lispovske prekladace nebo prave Haskell)

No dobře. Mě jde spíš o ten zápis. Mě asi nejlépe vyhovuje Python-Jython. Potom Java. C++ mi připadá jako záludný kolos. Ještě jsem se chtěl učit C#, ale mám pocit, že se z něj stává podobný kolos jako C++.

obavam sa ze pred ludskou hlupostou vas nezachrani ziaden prekladac ani Haskel ani Lisp ani Ruby na kolejch ci bez nich…

Tohle jsem nedávno četl a moc jsem to nepochopil. Čekal bych, že ten člověk bude hledat štěstí v nějakém jazyce, který vychází z ML, třeba právě ve Scale, když chce dělat nad JVM. Docela by mě zajímalo (a teď nic nepředjímám), co bude psát za rok nebo za dva.

On niekoľko rokov používal Haskell. OCaml a spol. sa podobajú Haskellu, ale nie sú pure. Clojure má immutable dátové typy.

http://clojure.org/data_structures

Immutable datové typu jsou fajn. Haskell se ale (pokud se nemýlím) liší od Clojure třeba tím, že:

1. Tím, že je implicitně líný
2. Má typovou inferenci
3. Má algebraické datové typy
4. Na rozdíl od Clojure, kde autor radí být „pure“ co nejvíce, lze v Haskellu říci docela snadno, která funkce je „pure“ a která ne (pokud nepočítáme FFI)
5. Nemá makra
6. Funkce lze používat v infixu i prefixu
7. Má „literate“ variantu
8. Nepotřebuje (ani nepodporuje) JVM
9. Má „návodnější“ syntaxi
10. Bez znalostí nějaké té teorie je v něm těžké udělat něco složitějšího. Feedy o Haskellu jsou plné článků typu „Isomorfické monoidy versus aplikativní functory“ a každý druhý začátečník v Haskellu píše vlastní tutoriál k monádám.

Těch rozdílů je docela hodně. Třeba Standard ML, OCaml nebo Scala mi přijdou jako přijatelný kompromis, pokud tedy Haskell člověku ± seděl.

Veď celý ten článok je o tom, že mu Haskell nesedel a tak hľadá funkcionálny jazyk, ktorý by tie problémy riešil lepšie. Prečo by mal hľadať kópiu Haskellu?

Jde o to, že pokud to dobře chápu, autor se Haskellem prokousal poměrně daleko a implementoval v něm nějakou svoji verzi Ruby On Rails. Podle mých zkušeností je Haskell natolik těžký a exotický jazyk, že v něm vytrvá jenom ten, komu tento jazyk hodně dá. V Pythonu nebo Javě může začít programovat kdejaký trouba bez větších překážek, v Lispu o trochu menší trouba, který dokáže pochopit funkce typu map, car a cdr. Žádný jazyk, který jsem zkoušel, snad kromě Prologu, nehází začátečníkům takové klacky pod nohy jako Haskell.

Ja si viem celkom dobre predstaviť, že tie IO a monády človeka časom omrzia. On píše, že v ňom písal 5 rokov a dokonca by chcel aby JVM mal nejaký dialekt.

Tá diskusia je tiež celkom zaujímavá, vyjadruje sa tam aj ku Scale.

Samozrejme sú to jeho subjektívne dôvody, ale ja tiež píšem vždy v jazyku, ktorý mi dá najviac výhod. Referenčná transparentnosť (alebo rýchlosť, ďalšia preceňovaná vlastnosť) nemusí byť všetko.

OK, pragmatismus nade vše, zvlášť pokud má projekt člověka živit, o tom žádná. Já jsem skoro přesvědčen o tom, že bych byl ve Scale produktivnější než v Clojure, autor to má jinak – možná.

Mimochodem, pro zajímavost jeden odkaz, kde je stejná věc implementovaná v Haskellu a Scale. Zajímala by mě i ta verze v Clojure, ale mně ten kód přijde hodně podobný (v rámci možností):

http://blogtrader.net/blog/FunctionalAbilityScalaComparingHaskell

Nejsem sice lispař, ale třeba Ti moje reakce taky něco dá. Už poměrně dost let se zabývám skoro výhradně Pythonem – projekty, na kterých jsem pracoval, mají skutečně velký rozsah. Na Python jsem přecházel z C a C++ jako mých hlavních jazyků a přišlo mi to tenkrát jako obrovský skok dopředu a podle mě v mnoha ohledech i byl. Byl jsem velkým fanouškem dynamických jazyků, nicméně protože mě jazyky zajímají, koukal jsem i jinam.

Ze školy jsem trochu znal Common Lisp a Prolog a když bylo třeba, vrtal jsem se v AutoLispu, takže jiná paradigmata mi úplně cizí nebyla. Z důvodu, že v OCaml bylo možné psát moduly do Pythonu, začal jsem se trochu zajímat o tento jazyk a objevil jsem výhody typové inference. Šel jsem dál, zajímal jsem se o Concurrent Clean a Haskell, později o Scalu. Dopodrobna to tady líčit nebudu, napíšu jenom stručný závěr:

Zjistil jsem, že na Pythonu pro mě není nejdůležitější dynamičnost, ale úsporný kód (žádné zbytečné závorky (lispaři prominou) a středníky), absence nutnosti psát ZBYTEČNÉ anotace typů, slušné standardní knihovny, dobré vyjadřovací schopnosti a podobné věci. Pak taky REPL, tedy možnost zkoušet kód v interaktivním prostředí. To všechno mi přinesl Python a velkou část z toho umějí i některé statické jazyky s typovou inferencí, jejich výhoda ale je, že u funkcí víc než v Pythonu vím, na čem jsem a že tu anotaci typu můžu v případě potřeby napsat (umí i Common Lisp, já vím).

Na žádný jazyk jsem nepřešel, Python je pro mě z některých důvodů pořád #1, ale studuju jiné jazyky dál, zkouším řešit úkoly v Projektu Euler, nějaké menší svoje věci zkouším taky řešit v Haskellu a Scale a myslím, že mi to rozšiřuje obzory a pomáhá získat lepší vhled i do programů v Pythonu, C++, Javě apod. Chystám se o podobných věcech napsat už nějakou chvíli článek na blog, kterým by se koneckonců možná dala nakopnout zajímavá diskuse. ;-)

A čo Ruby? Python mi pripadá škaredý a nekonzistentný.

Ruby dopláca na to, že je o niečo pomalší a nemá toľko používateľov (a teda aj knižníc). Inak keď si porovnám kvalitu takého Gtk+ bindingu, tak je to neporovnateľne elegantnejšie.

Upřímně řečeno, na Ruby se mi něco líbí víc než na Pythonu a něco naopak vůbec ne. Podle mě má Matz pravdu, když říká, že tyhle jazyky jsou v mnohém podobné a programátoři v Ruby a v Pythonu jsou jako milovníci psů a milovníci koček – je to spíš věc vkusu. Osobně si myslím, že Ruby (nakolik znám jeho základy) mi nic moc nového nabídnout nemůže, ale pokud bych musel, klidně bych v něm dělal.

Haskell nebo třeba Prolog oproti Ruby nabízí pythonistovi rozšíření obzorů neskutečně větší.

Haskell je příliš hardcore, aby chytil někoho, kdo byl někdy céčkař. Je to sice krásně čistý jazyk, ale je to velká změna úplně ve všem – vždyť to nemá cykly ani proměnné. To spíš Ruby.

Před napsání tohoto názoru jsem měl dlouho auru 0, teď mám 91. Tak teď fakt netuším – takhle to má fungovat?
Už jsem si říkal, že se přestanu logovat, protože se tím automaticky nechávám ‚zašednout‘, což mi připadá vedle sousty neregistrovaných jako velký handicap.

Takovej dotaz začátečníka…

Kdybych se mel začít učit něco jako lisp, měl bych se učit Lisp nebo scheme?

Scheme je řekl bych takový čistší, než Lisp. Asi jako je Pascal čistší, než C. ;-) Ale Common Lisp je určitě používanější, než Scheme, což má pro hackera některé obligátně známé příjemné důsledky. Ono je podle mého názoru dobré se nejdřív zamyslet, co ti na stávajícím jazyku, který používáš, vadí, co ti chybí atp. To, jestli nějaký jazyk někomu sedne lépe nebo méně, záleží i na tom, jakým způsobem myslí a jakým způsobem se mu lépe vyjadřuje to, co má na mysli. A to je samozřejmě odlišné člověk od člověka – ale dají se vystopovat shodné rysy u určitých typů lidí – trochu jinak myslí matematik, trochu jinak fyzik, trochu jinak (elektro)technik, trochu jinak strojař, architekt, ekonom… Takže co sedne matematikovi, nemusí sednout architektovi – prostě protože myslí každý trochu jinak.

Pravda je ze zatím, žádný jazyk nemám, ale líbí se mi myšlenka, něco napsat v lispu a pak to „zkompilovat“ do C. Navíc už delší dobu plánuji že se naučím něco jiného, než mě budou učit ve škole… Jak je to s rychlostí jazyka? Čet jsem o sbcl pro lisp, ale nemělo by být scheme teoreticky rychlejší? A je ve scheme něco jako clos? Mě by se asi vice zamlouvalo scheme, zdá se na první pohled jednodušší…

Mě se na první pohled zamlouvá scheme, přijde mi jednodušší. Jak je to s rychlostí, nemělo by být scheme teoreticky rychlejší? Je ve scheme něco jako clos?

Pascal je cistsi nez C? :-) To je spis naopak ne? Cecko ma pomerne primocarou syntaxi i semantiku bez omezeni, ktere ma Pascal. Nehlede na to, ze Pascal zavadi uplne zbytecne konstrukce, napriklad „program blabla“ na zacatku, „end.“ na konci, write/writeln jako uplne specialni kategorie, parametry funkci/procedur bez jasne vyjadreneho zpusobu jejich predavani (hodnotou/odkazem), typova neflexibilnost atd., ktere v cecku proste nemusi byt.

Jinak se vsim dalsim v prispevku souhlas – neni jediny jazyk universalne nejlepsi pro vsechny, stejne jako neexistuje jeden typ auta, ktery by vsechny uspokojil :-)

Pokud se na to díváš takto, tak nejčistším jazykem by byl Forth. :-)