Jsem zvedavy,s cim se pan autor vycajchnuje. Jinak par poznamek k tomu textu a kodu v lispu. 1) skutecni muzi pouzivaji iterate, 2) ten kod je napsany jako od prasete, mam pocit, ze to je snada udelat si z LISPu pascal, coz zrovna neni ten spravny postup, ale budiz. :-D Jinak ohledne lidi, co maji problemy se zavorkama, na to je jednoducha odpoved, mate pozuivat poradny editor – EMACS, ktery to se zavorkama umi zatracene dobre. Jo a jinak v Zlispu nebo Maclispu (ted nevim v kterem) existoval pojem ,,superzavorka'', ktery uzaviral vsechny leve zavorky, … taky dobra feature, ale hodi se spis do prikazove radky nez pro psani programu v editoru.
Otázka zvyku… Když na nás v prváku na VŠ vybalili cosi jako zkrácené psaní součtů a produktů, Kroneckerův a Levi-Civitův symbol, Einsteinovo sumační pravidlo a pravidla o indexech s tím vším spojená, taky to pro většinu z nás bylo zpočátku „prostě méně čitelné“. Ale později se ukázalo, že pro řešení komplikovanějších problémů je to opravdu mnohem pohodlnější, přehlednější a rychlejší. A ti, kteří k tomuto závěru nedospěli, nejsou ty komplikovanější problémy schopni elegantně řešit dodnes. :-)
Nebyl bych tak drsný. Určitě LISP a podobné jazyky (třeba PROLOG) mají své místo v řešení speciálních úloh. Ale na úroveň obecných programovacích jazyků bych je nestavěl. LISP jsme se učili na FELu. Dokud to bylo jen teoretické cvičení nad souborem speciálních úloh, tak to bylo efektivní. Jakmile jsme se dostali do fáze, kdy se začaly popisovat běžné operace, jako vstup a výstup, volání funkcí OS, nebo nedej bože něco, co připomíná OOP, tak jsem pochopil, že na tohle se LISP fakt nehodí. Nevím, jestli je efektivnější psát UI v LISPu nebo třeba v Javě (případně v jiném vyšším UI jazyce).
Tím neříkám, že by to v LISPu nešlo… ale tak nějak mi to přijde, jako drbání ucha přes hlavu.
Ona je to asi otázka zvyku, ale syntaxe Lispu je pro normální lidi dost nepřekročitelná bariéra. Já jsem si třeba před pár měsíci zkoušel udělat stejný primitivní prográmek v několika jazycích běžících nad JVM. Java – zívačka, Jython – v klidu, JRuby – pohoda, Scala – nádhera. Pak jsem šel na stránky Clojure (dialekt Lispu běžící nad JVM) a podíval se na tamní Hello world a s křikem jsem utekl. Po čase jsem zjistil, že ten příklad byl napsaný pitomě a zbytečně složitě, ale ta syntaxe se mi zdá strašná dosud. Podle mě je (Common) Lisp mocná zbraň díky makrům a dá se v něm udělat všechno, ale svoji šanci už promarnil a dnešní moderní jazyky už ho v mnohých ohledech překonaly.
S jazykem Lua jako takovým nemám žádné zkušenosti, dnes jsem si LuaJ stáhnul a koukal jsem na příklady – není to tak zlé. Přijde mi, že ta kostra aplikace (luajava.newInstance, luaJava.bindClass + dvojtečková notace na jedné straně a LuaState + LPrototype + LClosure na straně druhé) se dá obsáhnout docela snadno), přesto bych řekl, že Jython je oproti LuaJ prakticky bezešvý. Třídy jdou mezi Jythonem a Javou normálně dědit (ikdyž násobnou dědičnost si člověk bude muset v některých případech odpustit) atd.
Z jazyků pro JVM mě ale nejvíc oslovila Scala. Má propracovanější objektový model (Kovariance a kontravariance apod.), obsahuje spoustu funkcionálních vlastností a docela originálně spojuje oba světy (case classes a jejich použití v pattern matchingu, samostatné funkce, strukturální typy apod.). Scala byla prvním staticky typovaným jazykem, který mě, jakožto uživatele dynamicky typovaného jazyka přesvědčil, že typy nemusí zbytečně bolet. Předtím jsem koketoval s OCaml, ale tam je inferenční mechanismus dost svazující (nemožnost přetěžování stejných operátorů pro jiné typy, nemluvím o kontroverzním přetěžování jako >> v C++, ale třeba o třeba sčítání čísel jiných typů – zkušení javisti mi jistě rozumějí). S nástupem moderních staticky typovaných jazyků podle mě spousta výhod dynamických jazyků typu Jython a JRuby prostě odpadá. Něco málo v tomto směru ušla i Java (a C# na té „zlé“ straně je ještě o kousek dál) – autoboxing, generika, for/each, ale tam to ještě nějak pořád není ono.
jj, ta dvojtečková vs. tečková konvence postihuje rozdíl mezi voláním metody s this a bez něj.
S tím autoboxingem, generikama a for-each v Javě máš pravdu, to skutečně ten jazyk hodně posunulo dopředu, i když například autoboxing je někdy problematický – zdánlivě sjednocuje primitivní datové typy a jejich objektové ekvivalenty, což ne vždy funguje a může to vést k těžko odhalitelným chybám, viz například == vs. equals().
Dost důležitá je také změna na úrovni bajtkódu, která vlastně umožňuje snadnou implementaci dynamických jazyků nad JVM.
Řekl bych, že řešíte celkem malichernost. Proti tomu bych postavil otázku, co je univerzálnější. Z hlediska čitelnosti se oba příklady liší opravdu jen kosmeticky, z hlediska sémantiky se liší naprosto diametrálně, ovšem s tím, že ten první zápis je z tohoto hlediska mnohem silnější. Připravovat se o spoustu vlastností a spoustu jiných věcí si zkomplikovat jen proto, že jsem debil a nedokážu mentálně vstřebat zápis, který se nepatrně odlišuje od toho, který jsem se učil na obecné škole, mi připadá jako dost chabý důvod.
Na fakultě nás často deprimovali tím, že „když vám dělá problémy to pochopit a zvyknout si na to – nebylo by lepší orientovat se jiným směrem? Třeba na nějakou manuální práci?“ :-)
Já jsem dlouho přemýšlel, jakou ukázku LISPu tam dát, jestli nějakou „klasiku“ – žádné smyčky, jen rekurze, nebo CL specialitky (makra) popř. imperative-like kód a nakonec jsem zvolil třetí možnost, aby se lidi moc nepolekali :) To je právě jedna z výhod LISPu, když už chci psát imperativní kód, dají se nasekat makra pro podmínky, smyčky a potom vesele používat (no a trošku závorkovat :-)