LISP vs. XML

Dobry den,
tento komentar je pekny a velmi ho ocenuji, i kdyz se povazuji za clena skupiny "Lisp rulez". Vy rozhodne patrite do te druhe skupiny ("Lisp znají"), a obvineni z nizkych motivu ve vasem pripade beru zpet.

Jedina vyhrada, ponekud se mi nelibi oznacovani naseho Lisp anarchistickeho krouzku za "fundamentalisty". Lidi ktere kolem Lispu znam jsou velmi chytri programatori s teoretickym rozhledem. Pravda, tito lide maji silne nazory a neboji se je vyjadrit, ale jak jste mohl videt v diskusi tak jsou mnohdy podepreny konkretnimi teoretickymi znalostmi.

Na druhou stranu, silne reakce z druhe strany ("Lisp na smetisko dejin") mi trosku ukazuji ze Lisp je necim jako cernym svedomim XML, kdyz je potreba ho takhle potlacovat.

Mozna je to vzajemne, XML je take cernym svedomim Lispu. Lispova komunita si muze rikat ze kdyby netravila roky nad obrovskou normou a misto toho psala knihovny a parsery a resila nudne ale dulezite prakticke problemy jako je kodovani a prenositelnost dat, tak bych dneska nemusel silhat do pekelnych XSLT sablon ale do elegantniho DSL jazyka v Lispu ktery bych si sam napsal nebo stahnul od Paula Grahama.

Dlouhy prispevek, ale tohle je moje oblibene tema.

Perfektní text, takhle si představuju blog na Rootu. Možná bych to hodil i jako článek na titulní stranu. Ostudu by si tím, na rozdíl od některých uveřejněných ptákovin, Root rozhodně neudělal.

re: student MFF

"velmi chytri programatori s teoretickym rozhledem", "jsou mnohdy podepreny konkretnimi teoretickymi znalostmi".
Najdete v techto dvou kusech textu dve stejna slova a vysledek uz mluvi sam za sebe...

Ona nějaká ta konkrétní teoretická znalost může být teoreticky v praxi velmi užitečná. :-D

Ciernym svedomim XML je LISP. A preco? Lebo znaky () sa velmi podobaju <>. Tam cela podobnost zacina a aj konci.

Bóže můj, už zase kdosi exhumuje zombie. Kvůli tomu, že neexistuje náhrada za tuhle příšernost, nepoužívám Emacs ani script-fu v GIMPu. Učit se jakousi vykopávku, připomínající jazyk prvních programovatelných kalkulaček, ke které navíc za ta léta nikdo nedokázal napsat použitelný manuál, se mi opravdu nechce.

Nevzdelany burane, odejdi ze svitu slunce Lispu pod matne blikajici zarivku xml. Howgh.

LISP je až moc spartánský, takže podle mě nemá šanci. Rozhodně si fakt nedokážu představit psaní v LISPu jako dokumentů.

LISP podle mě je sice neuvěřitelně univerzálním jazykem, neuvěřitelně homopgenním a skvělým, ale IMHO už překročil tu hranici, kdy jednoduchost konceptu je až na škodu. Lépe je něco složitější, byť třeba méně univerzálního, ale dá se v tom psát a lze se v tom dobře orientovat.

Problém LISPu je jeho teoretičnost a akademičnost. Jaksi se zapomnělo na praxi.

Ptám se teď jakožto neznalec. Kolik aplikací v LISPu znáte? Dá se v tom napsat a píšou informační systémy? Dá se v tom nějak neproblematicky napsat databázový grafický klient. Atd.. Já vím, že to jde, ale existují na to knihovny a vývojová prostředí?

Naproti tomu existují jazyky, které moc skvělé nejsou, ale ženou se do praxe a proto jedou.

LISP podle mě nikdy do praxe moc nepůjde . Daleko více mě mrzí Smalltalk, který byl daleko šikovnější po praktické stránce, ale prohrál to po stránce licence a také po stránce prostředí.

Mě by zajímalo, jak se v Lispu dá programovat, když nemá typy? Mnohokrát se mi stalo, že jsem do funkce v C omylem dal pointer na jinou strukturu než jsem měl --- kompilátor vydal warning. Kdyby se takhle do funkce v Lispu dal pointer na jiný seznam než má, kompilátor na to nepřijde a chyba se bude velmi těžko hledat.

Mikuláši, to si děláš legraci, viď že jo... Já programuju převážně v Pythonu, to zčásti je taky trochu Lisp (akorát těch závorek tam je míň ;-), ale ještě se mi nestalo, že bych poslal něco jiného než jsem chtěl a včas se na to nepřišlo. Na to máme dokumentaci, rozumné názvy proměnných, unit testy apod. S těma pointerama bych se nebál, Lisp takové prasárny nemá. ;-)

Proč bych si měl dělat legraci?

Udělat unit test, který ti otestuje všechny větve (každý zfailovaný malloc, každou chybu při čtení souboru...) je dost složité, takže kontrola kompilátorem přecejen přijde vhod.

V Lispu je všecko buď pointer nebo atom, a pokud předáš pointer s něčím jiným někam, tak se ti to bude chovat divně (C by v takovém případě poškodilo náhodná data nebo spadlo). Neříkej, že se ti to nikdy nestalo.

Ale jistě, že se mi to stalo. Jenže když pomineme skutečně beztypové jazyky, tak existuje dost mechanismů, jak to zkontrolovat, když je třeba. V Pythonu můžeš napsat na začátek funkce / metody assert(isinstan­ce(parameter, MyClass)) nebo si pro testovací účely pomoci nějakým dekorátorem. V CL by jistě bylo možné použít nějaké makro nebo si ohackovat reader, případně snad s použitím CLOS použít podobnou techniku jako v tom Pythonu.

Zfailovaný malloc() podle mě v současné době není problém programátora, ale OOM killeru a dalších mrch a v Lispu se jaksi přímo ani malloc() v programu nevolá, že ano. Nevydařené otevření souboru NIJAK nesouvisí s problémem detekce nesprávného typu ve fázi kompilace.

A co hůř, kontrola při kompilaci dává leda falešný pocit bezpečí. Pokud zavolám setWindowSize(x, y) a prohodím parametry, kompilátor neřekne ani popel, protože posílám 2 inty, jak očekává. Když je těch parametrů 10 a všechny stejného typu, tak se z toho opupínkuješ, zvlášť, když tam kolega přidá volitelný parametr a neupdatuje to všude v kódu. Python i Lisp na to mají keyword parametry, které jsou podle mě ve spojení s rozumnými názvy tou nejlepší primární kontrolou.

createFamily(
father = 'Josef',
mother = 'Ivana',
child = 'Pepíček')

Pokud v Lispu všude posíláš data v jednom parametru typu ("Josef" "Ivana" ("Pepíček" "Andulka") ("Alík" "Micinka") ('Audi 'Porsche) ("Politických vězňů 131" "Praha 1" "11000" ("0609363600" "0800123456"))), riziko se zvyšuje a čitelnost snižuje, ale nikdo Tě k tomu nenutí.

Nejdřív uvedu na pravou míru ty fundamentalisty. Formulace z konce článku není povedená. Rozhodně jsem neměl a nemám za fundamentalisty všechny příznivce LISPu. Označení, navíc přiznaně nadsazené, se týká jen početně malé ale dost viditelné skupiny těch, kteří mají neustálou potřebu dokazovat svou morální převahu nad ostatními.

Pokusel jsem se vyjádřit, že disputace o tom, zda je lepší to nebo ono, nemá smysl. To i ono má své místo, svou historii a své příznivce. Myslím, že "podoba" LISPu a XML je nápadnější při pohledu z lispového tábora (i když mám pocit, že tento pohled hodně přeceňuje možnosti a význam "programovacích jazyků" v XML). Člověka, který např. píše webovou aplikaci s využitím nativní XML DB a XQuery, spíš napadají úplně jiná srovnání.

„V Pythonu můžeš napsat na začátek funkce / metody assert(isinstan­ce(parameter, MyClass)) nebo si pro testovací účely pomoci nějakým dekorátorem. V CL by jistě bylo možné použít nějaké makro nebo si ohackovat reader, případně snad s použitím CLOS použít podobnou techniku jako v tom Pythonu.“

To je ale nejspíš pracnější než statická typová kontrola? Statické typové kontrole se navíc dá mnohem hůř vyhnout (= feature).

„A co hůř, kontrola při kompilaci dává leda falešný pocit bezpečí.“

To přeci nemůžeš myslet vážně…

„Pokud zavolám setWindowSize(x, y) a prohodím parametry, kompilátor neřekne ani popel, protože posílám 2 inty, jak očekává.“

Nikdo neříká, že statická typová kontrola řeší všechno. Když najdeš jeden protipříklad, neznamená to přeci, že je statická kontrola typů k ničemu.

„Když je těch parametrů 10 a všechny stejného typu, tak se z toho opupínkuješ“

Nevím jak v C, ale v Javě většina těch parametrů nebývá primitivního typu (int, char, …), takže když člověk něco přehodí, přijde se na to. Krom toho se v Javě většinou předávají vyšší typy, takže těch parametrů ani zdaleka není tolik.

„Python i Lisp na to mají keyword parametry, které jsou podle mě ve spojení s rozumnými názvy tou nejlepší primární kontrolou.“

No, to konečně zní jako odpověď. Jenže dost často přichází v úvahu několik různých podob téhož parametru, takže i když se pojmenované parametry postarají o správnost pořadí, typově to ještě pořád nemusí klapnout, ne?

Já neříkám, že jsou jazyky bez statické typové kontroly k ničemu (mám moc rád Perl :), ale rozhodně bych netvrdil, že statická typová kontrola dává „leda falešný pocit bezpečí˝. A taky by mě zajímalo, jestli [a proč] s tím v Lispu u větších projektů nejsou problémy.

Jo a mimochodem jsme docela offtopic, takže bychom toho možná měli nechat dřív, než zcela zruinujeme diskusi na původní téma? :)

No ja bych se ptal jestli si veta "konkretni teoreticke znalosti" tak trochu neprotireci, bud mam konkretni a nebo teoreticke znalosti:D

To Miroslav Ponkrac: s tematem Lisp/XML to sice nesouvisi, ale kdyz uz se ptate: Lisp je pouzit napriklad v AutoCADu a jsou v nem udelany i docela rozsahle nadstavby, treba z oblasti geodezie, prehradnich nadrzi, neco z protipozarni bezpecnosti atd.

Sam jsem se AutoLISPu v minulosti venoval a dokonce jsem v nem udelal svuj rekord cena/delka_kodu :-) Jednalo se asi o dvacetiradkovy program, ktery byl opravdu jednoduchy, ale praci s AutoCADem lidem ve firme dost zjednodusil a urychlil.

Do novych AutoCADu pridali i Visual Basic, ale jaksi to neni ono, LISP je na zpracovani vektorovych dat mnohem lepsi (jeste bych tam docela rad videl Python, neni sice tak mocny jako LISP, zato je o dost citelnejsi, i kdyz na LISP se da taky zvyknout).

To Pavel T.: Co se týče Pythonu a AutoCADu, tak v zásadě existují dvě možnosti použití: pyacad a win32 extensions / rozhraní ActiveX. Ale co si budeme povídat, AutoLisp, ActiveX rozhraní ani VBA nejsou zdaleka tak mocné jako ObjectARX (C++).

Zoule, otázkou je, jestli to vadí autorovi, protože k původnímu článku a) není moc co dodat a b) diskuse vázne (i díky tomu a)). Jinak jenom krátce: Napsat

@cP(int, str, int, dict)
def myFunc(i, s, j, d):

(ty názvy parametrů nejsou košer, to vím) je samozřejmě o něco pracnější, ale ne zase o moc. Hlavní můj argument byl ten, který jsem napsal o těch kw parametrech a názvech proměnných. Můj názor je takový, že statické typování je výhodné pro strojové zpracování (kontrola typů apod., automatická refaktorizace, optimalizace na rychlost), zatímco důležitější je čitelnost člověkem a udržovatelnost kódu. A v době, kdy ve spoustě projektů (zvláště v C, což je, předpokládám oblíbený jazyk MP) se čitelnost a udržovatelnost blíží nule a vývojáři nejsou schopní ani odstranit warningy na každém 5. řádku, natož aby používali lint nebo něco takového, přijdou mi ty výhody statické kontroly jako docela málo významné.

Ohledně C se v podstatě shodneme (viz [1] – „my conclusion is that type checking, as practiced by C and Pascal, is a failure” :)

[1] http://perl.plover.com/yak/typing/notes.html

A chtěl jsem to napsat už do svého prvního příspěvku, mně se staticky typované jazyky i hezky čtou. Když vidím něco jako

private BufferedImage buffer = …,

tak mám větší představu, než když tam bude něco jako

my $buffered_image = …

Nicméně nic doopravdy velkého jsem nikdy nepsal, takže jsou to jen takové osobní dojmy. Těším se na Perl 6, tam si člověk bude moct vybrat :)

Díky za odkaz, ten slajd 11 má pravdu (ta automatická konverze z floatu na int mi ale přijde relativně košer, s tím unionem to je pravda, ale ne moc fér). C++ část těch problémů řeší, ale marná sláva, pointery jsou (někdy nutné) zlo. Hlavně mě ale zajímá ta část věnovaná ML, protože jsem si už dávno chtěl pohrát s OCAML, ale ty tutoriály mi přišly docela špatné. Tenhle textík vypadá srozumitelně, aspoň vím, jak mezi sebou konvertovat typy. ;-)

Mezi Lispem a XML je stejný rozdíl jako v programování pro Linux a pro Windows. Lisp a Linux klade vyšší požadavky na inteligenci programátora, takže ho používají ti chytřejší. Windows a XML má spoustu reklamy a různé "nástroje", takže ti méně vzdělaní se na to chytí.
A to je pravda...
(tak, která potrefená husa zagagá první?)

Přesně. Navíc se v některých průzkumech ukázalo, že uživatelé XML mají v průměru menší penisy. <rimshot/>

Pokud chcete peníze, učte se XML.
Pokud chcete opravdu rozumět programování, učte se Lisp a Scheme.
A to je pravda.

Pod pojmem "praktické problémy" které by údajně měly programovací jazyky řešit se většinou skrývají nudné a otravné úkoly typu vyplň formulář, ulož to do databáze, sečti a zobraz v html. Na takovýchto "praktických problémech" jsou zajímavé jenom prachy které za to dostanete a bavit to může jenom někoho kdo nezná nic lepšího.
Klidně si ty praktické problémy v ex em el a v jávě řešte až do roztrhání těla a přeplnění peněženky. My se v Lispu budeme zabývat opravdu podstatnými záležitostmi - umělou inteligencí, programováním inteligentních robotů, hledáním suboptimálních cest ve velikých množinách dat. To je stokrát zajímavější než webové formuláře na sto způsobů (mnohdy) za státní peníze.

A nenapíšu že je to pravda, i když je to pravda :-)

Pavel T.: O autolispu vím, stejně tak jako o GIMPu, emacs a dalších (i když tam možná není úplný lisp, ale já v tom nedělám, takže detaily neřeším).

Jenže mě zajímají plnohodnotné aplikace, ne skriptování. Proto se ptám na databázového klienta, na informační systém, na ...

Pan pravda: Mezi Lispem a XML je stejný rozdíl jako v programování pro Linux a pro Windows. Lisp a Linux klade vyšší požadavky na inteligenci programátora, takže ho používají ti chytřejší. Windows a XML má spoustu reklamy a různé "nástroje", takže ti méně vzdělaní se na to chytí.

Já jsem tedy za svou dvacetiletou kariéru programoval asi pro deset operačních systémů, mimo jiné i pro Unixy, stejně jako pro Linux i Windows a jaksi v tom nevidím principiální rozdíl. Asi mi něco uniká, nebo mi lhali, ale já zatím nepoznal zásadnější rozdíl mezi programováním pro Linux a Windows.

Jinak mám pocit, že XML a LISP nelze srovnávat. XML je vstupně výstupní formát, LISP je programovací jazyk. XML je pravda trochu nadužíván, protože je in a velmi často se používá tam, kde nemá být.

Pan Pravda: Klidně si ty praktické problémy v ex em el a v jávě řešte až do roztrhání těla a přeplnění peněženky. My se v Lispu budeme zabývat opravdu podstatnými záležitostmi - umělou inteligencí, programováním inteligentních robotů, hledáním suboptimálních cest ve velikých množinách dat. To je stokrát zajímavější než webové formuláře na sto způsobů (mnohdy) za státní peníze.

Výborně bádejte :-) Já jsem se umělou inteligencí zabýval, mám mimo jiné po krk špatně navrženého Prologu a nyní klidně vydělám peníze na xml a budu obcovat s krásnými ženami, které na peníze ulovím. Tyto zážitky se ženami klidně vyměním za ztracené příležitosti pro hledání suboptimálních cest, které přenechám s radostí vám :-)

No priznam sa, ze som uz mierne zmateny z tych komentarov, ale moje postrehy:

1. v Perle je mozne tiez pisat napr. ('a', ['b', 'c', 'd'], 'f', ['g', ['g']]) a v kontexte hashmapy to je ('a' => ['b', 'c', 'd'], 'f' => {'g' => ['g']})

Pointa: kym to generuje program a cita program (a nie clovek), je to IMHO jedno, ale clovek spravi zbytocne vela chyb, keby to zapisoval v 'array' kontexte.

2. Perl mam sice rad, ale pisat struktury stylom $struct{"premen­na"}{"nepremen­na"} je strasne nachylne k preklepom (oproti C++). To iste IMHO plati pre rozdiel otvaracich/uzat­varacich tagov <tag> a </tag> oproti () - jak uz bolo v povodnom blogu pisane (aby bolo jasne - nesnazim sa tvrdit, ze LISP je lepsi nez XML ani naopak ;-))

3. @M. Ponkrac [http://pcimprich.blog.root.cz/0610/lisp-vs-xml#komentar-156]: co mate na mysli "spatne navrzeny Prolog", celkom by ma to zaujimalo.

[26]:
Hezká odpověď, pobavila velmi.
Myslím že tuhle zásadní volbu řeší v životě každý.

[26]:
Jenom doufám že vám ve víru milostných dobrodružství zbyde i čas na čtení Roota :-)

27> Jestli Ti vadí, že se v Perlu můžeš ve výrazech typu $moo{'index'} uklepnout ve jménu indexu a nastavit něco úplně jiného, než jsi chtěl, můžeš použít takzvané omezené heše (restricted hashes), viz http://perldoc.perl.org/Hash/Util.html.