Pod mým nedávným článkem o jazyku XML Pipeline proběhla pozoruhodná diskuze. Bohužel ani trochu nesouvisela s tématem. Několik příznivců LISPu mělo potřebu světu sdělit, že „LISP rulez!“ a XML je jen jeho značně nedokonalou napodobeninou, uměle protlačovanou nevzdělanými rádobyexperty, kteří si z tohoto podvodu udělali dobrou živnost. Můj mírně ironický tón naznačuje, že s tímhle názorem tak docela nesouhlasím. Pokusím se vysvětlit, co mě k tomu vede.
LISP a XML mají některé společné charakteristiky, ale každá z těchto technologíí vznikla v jiné době, v jiném kontextu a má jiné cíle. LISP je starší, ale představa, že místo XML bylo možné prostě „sáhnout po LISPu“, když mají tolik společného, nerespektuje souvislosti. XML nevzniklo ze dne na den, tak že by někdo zabalil kus LISPu do jiné syntaxe a začal tím oblbovat lidi. Bylo tady GML a SGML určené primárně pro práci s textem. LISP nikdy nebyl dvakrát vhodný pro práci s textem. Dokument můžete přepsat do S-expressions, ale umíte si v tomto formátu představit rozsáhlý manuál nebo knihu? Já bych nic takového editovat nechtěl. Nechce se do toho ani lidem z lispové komunity – většina dokumentů o LISPu je v LaTeXu. V syntaxi LISPu má zvláštní význam řada znaků běžně používaných v textu, tudíž je obtížnější okem rozeznat text a značky, a musí se častěji escapovat. LISP není na rozdíl od *ML určen ke psaní dokumetů.
Důležitou, možná hlavní motivací vzniku XML bylo nahrazení špatně automaticky zpracovatelného HTML něčím podobným, ale pravidelnějším. Měli tehdy autoři XML místo definování profilu SGML a následného přeformulování HTML4 na XHTML prostě sáhnout po LISPu? Jak by na to asi reagovali výrobci prohlížečů a miliony autorů webových stránek? Jistě s pochopením. Nebo se chyba stala už dřív, když Tim Berners-Lee, místo aby prostě sáhl po LISPU, začal vymýšlet HTML? Obávám se, že kdyby tehdy TBL web založil na LISPu, zůstal by dodnes akademickou záležitostí.
To, co je XML často vyčítáno – upovídaná syntaxe a zdánlivě nadbytečné koncové značky – se do XML nedostalo náhodou. Umožňují dobrou čitelnost formátu lidským okem a lepší detekci chyb. Když v S-expression chybí uzavírací závorka, zjistí to parser až na konci. Když v XML chybí pojmenovaný koncový tag, pozná to většinou hned, jak narazí na jiný koncový tag. Dokument XML dokáže deklarovat své kódování. XML je neutrální datový formát podporovaný všemi relevantními programovacími jazyky, včetně LISPu. Pro tyto vlastnosti je XML vhodný formát pro přenos dat mezi různými systémy a platformami.
Lidé stojící u zrodu XML nebyli žádní nedouci. LISP dobře znali, rozhodně ne hůř než mladí rozlobení mužové požadující, aby LISP vládl všemu a všem. Jeden z „otců“ XML, James Clark, se dlouho zabýval DSSSL a napsal vynikající lispový modul pro Emacs (nXML). Přesto mu stálo za to vymýšlet XSLT a Relax NG, a napsat neuvěřitelné množství open-source implementací XML standardů. Kam patří on a jemu podobní? Mezi ty, kdo „prostě nemají na to aby Lisp pochopili“, nebo mezi padouchy, kteří „Lisp znají, ale radši o něm nemluví, aby se neprozradilo že toho zas tak moc nevymysleli, to co znaji přepíšou do "ex em el“ a nechají si to dobře zaplatit."
Pokud někteří příznivci LISPu vnímají XML jako prázdný „enterprise“ buzzword, je to bohužel jejich chyba. Měli by přestat chodit na jalové firemní prezentace s plkajícími kravaťáky, a radši si přečíst sborník z Extreme Markup Languages nebo sledovat list xml-dev.
LISP je velmi starý jazyk a obsahuje hromadu vynikajících principů. Během času mnohé jiné jazyky a formáty některé z těchto principů přejímají a mění ke svému obrazu. Znamená to, že všichni jsou plagiátoři a nárok na existenci má jen LISP? Před patnácti lety byl ortodoxním LIPSistům trnem v oku Unix a C. Tedy kombinace, bez které by nevznikl Free Software, Linux ani dnešní open-source boom. Z tohoto pohledu by nepřízeň této fundamentalistické komunity měla být pro XML dobrým znamením.
Psáno s mírnou nadsázkou a hlubokým respektem k LISPu.
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.
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.
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(isinstance(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(isinstance(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.
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).
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í?)
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{"premenna"}{"nepremenna"} je strasne nachylne k preklepom (oproti C++). To iste IMHO plati pre rozdiel otvaracich/uzatvaracich 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.
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.
Přečteno 11 971×
Přečteno 8 483×
Přečteno 8 353×
Přečteno 8 304×
Přečteno 8 015×
ČLÁNKY DO MAILU