Mně připadá tak jednoduchá, že ji musí okamžitě chápat každý blb (narozdíl od syntaxe jiných jazyků, jako extrém třeba C++). Když je někdo schopen špekulovat nad syntaxí LISPu, která je vlastně veškerá žádná – „(co s-čím s-čím s-čím atd)“ – tak už vážně nevím, jaký typ problémů je takový člověk schopen řešit a vyřešit.
Nechápu, že tolik lidí dokážou nejvíc vykolejit právě jazyky, které neobtěžují (a neomezují) svou syntaxí (jako LISP, Forth, Smalltalk apod.), ale umožňují soustředit se na řešený problém.
Trochu to připomíná obchodníky na burze – ti si taky tak zvykli na tu svou obskurní terminologii používanou v technické analýze, že jim ta normální, používaná v matematické analýze, připadá jak z Marsu.
Ja tady snad spekuluju nad jeho syntaxi? Me je jasna a programovat v tom dokazu. A LISP prave svou syntaxi dost obtezuje. Uz jsi nekdy musel zkoumat cizi kod v LISPu? I kdyz to mas hezky sparovane a odsazene, tak je to proste neprehledne. Clovek nema v hlave syntakticky analyzator a neudrzi proste v pracovni pameti obsah dvaceti zavorek. Oproti tomu u modernich jazyku muzes cist kod(pokud je slusne napsany) jako clanek v novinach a mas jasno.
Paradox LISPu je, ze je sice syntakticky velmi jednoduchy, ale napisat v nom nejaky komplikovanejsi program je ovela zlozitejsie ako v inych syntakticky zlozitejsich jazykoch.
Lisp resp. Scheme ma sice vzdy fascinovali a viackrat som sa pokusal pouzit Clisp resp. MzScheme ako skriptovaci jazyk, ale vzdy sa mi to ukazalo menej produktivne ako ked pouzijem Perl, Python, Ruby alebo REXX.
Moja skusenost je, ze aj ked je napriklad Perl ovela syntakticky zlozitejsi, clovek sa ho nauci pouzivat prakticky v kratsej dobe a produktivnesjie ako Lisp resp. Scheme – nemyslim teraz nejake teoreticke ulohy na rekurziu ale prakticke veci, napriklad spracovanie textovych suborov, regex, ..
Ja by som k tomu ze LISP je nedoceneny dodal iba tolko ze castokrat je aj precenovany. A povedat ze zapis v LISP-e je to iste ako zapis v XML a preto ho LISP nepotrebuje tak nerozumie okolitemu aparatu okolo XML ako je XSD, type safety, name safety a kompatibilita medzi systemami.
Inac dajuem za pekny clanok, trocha opakovania z vysokej nikdy nezaskodi.
XML a LISP samozrejme neni to stejne, jedna se o dost odlisny pristup k jednomu problemu. Rekl bych, ze XSD, XML transformace atd. docela znam a chapu, ze v jinych jazycich (hlavne kompilovanych) tyto technologie maji smysl, ale pri pouziti LISPu je to kanon na vrabce, k tomu mene „mocny“ nez samotny LISP (i co se tyka napriklad typovych kontrol).
Je to presne jak rika Biktop – vy nevite, co to Lisp je.
Videl jsem aplikaci s XML jen par, ale u tech, ktere jsem videl, by se to Lispem dalo poresit daleko lepe, vcetne parsovani. Treba jen takove promenne – fakt, ze nemuzete v XML definovat nejaky atribut a dal to pak pouzivat silne omezuje jeho moznosti jako konfiguracniho jazyka. Ale nejvetsi problem XML je asi dichotomie mezi atributy a entitami (ktera ma vyznam pro puvodni pouziti XML jako markup jazyka, ale pro cokoli jineho jde o nadbytecnou komplikaci, ktera jenom ukazuje, jak se XML spatne pouziva).
XML je predevsim naprosto nevhodne na cokoli jineho nez markup textu (a i tam je ta vhodnost sporna), tj. 90% vsech aplikaci XML. A ja tvrdim, ze na tyto aplikace by byl vyhodnejsi Lispovy zapis (a zpracovani).
Co se tyce Lispu, skvely jazyk z nej delaji makra, a pro ty je bohuzel tento zapis docela podstatny.
Pokud si pamatuji, tak se assembly language v době kdy jsem ho používal (to už je hodně dávno :-) překladal jako „jazyk symbolických adres“. Na netu jsem našel i zde uváděný termín „jazyk symbolických instrukcí“, ale ten je zřejmě pozdějšího data.
Jinak gratuluji k velmi zajímavému seriálu. člověk si vzpomene na doby, kdy si musel počítač sám postavit.
asi uz jsem hodne stary, kdyz si toto pamatuji a naopak mi to v clanku sedi a vyvolalo to vzpominky na dobu, kdy jsem s pocitaci zacinal. To jsou tezko sdelitelne zkusenosti, muselo by se vysvetlovat historicke pozadi „zjeveni“ citatu apod. Za cas take nikdo nebude rozumet rivalite Windows x Linux. Dekuji za vyborny serial.
Ve výčtu mi chybí RPG (http://en.wikipedia.org/wiki/IBM_RPG), pokud to nebude součástí nějakého dalšího výkladu o AS400/iSeries. Jinak moc pěkný seriál – díky!!!
Ano bola to zena, ktora to dotiahla na hodnost admiral, participovala na vytvoreni COBOLu a od nej sa vraj traduje aj slovo „bug“ pre oznacenie chyby: http://en.wikipedia.org/…Grace_Hopper
jsem z rocniku husakovych deti a vzpominam si, kdyz jsem mel asi 12 let, tak
jsem vyhrabal rodicum z knihovny knihu Algol – Fortran – Cobol a byl jsem tim
uplne fascinovan ackoliv jsem nicemu nerozumel a osmibitovy pocitac se ke me
dostal az za par let. to je takova pravzpominka.
No, jak se to vezme. Ma to neco do sebe. Kdyz neco potrebuji, najdu si nejake sve starsi JCL, a mam tam vsechno po kupe – jake soubory jsem pouzival, jake optiony jsem zadaval; a to i po letech.
Kdezto kdyz neco udelam v Linuxu v radce, tak jsem rad, kdyz to najdu v .bash_history.
Tohle je jedna z nedocenenych vlastnosti JCL.
Dneska ke me prisel manazer a pta se „programoval bys rad v Jave?“ a ja: „Ne“. Tak rika „to se ale budes muset naucit“ a ja: „a proc? je potreba neco udelat?“ a on: „ne ale abys byl pripraven“
Pak rikal neco o tom ze bude mozna potreba udelat neco pro nejake zakazniky v Jave nebo v C++ proste aby to bylo objektovy. Nakonec z nej vypadlo ze programovani nerozumi, protoze neni programator.
Delalo to na me dojem, ze nekde cetl v nejakem pocitacovem modnim casopisu nejake buzzwordy nebo je slysel na mitingu a
ted citil tlak a chtelo to z nej ven. Citil jsem se tim celym buzerovan. Rek jsem mu ze podle me je cely objektovy programovani overrated.
Stary dobry casy kdy se psalo ve strojaku, assembleru nebo C.
Něco podobného jsem taky zažil. A ještě jako „argument“ bylo použito tvrzení, že kolega XY v tom taky programuje. Reagoval jsem asi v tomto duchu a zatím je pokoj:
Podívejte se, na softwarové (nejen) úkoly mně svěřené si musím vystačit sám, neboť nejsem součástí žádného týmu. Chcete-li po mně kvalitní výsledky, nechte na mně, jaké prostředky k jejich dosažení použiji. Trváte-li na svém, musím vás upozornit, že s největší pravděpodobností dojde k citelnému snížení produktivity a kvality mé práce, v krajním případě k odchodu jinam.
Ten, co přijde po mně, to sice z počátku asi nebude mít moc lehké, ale bude-li ovládat řemeslo, nemělo by to představovat vážnější překážky. Ostatně – já jsem se taky musel naučit Fortran, abych mohl pokračovat v údržbě staršího softwaru. Trvalo to asi týden čistého času. Legrační na tom je, že další dva kolegové dostali za úkol přepsat to celé do C++, na čemž pracují už zhruba rok, aniž by jejich větev byla prakticky použitelná. Když to srovnám s tím svým týdnem studia nového (nebo spíš „nového“) jazyka, silně pochybuji o smyslu takovéhoto počínání.
Java je business standard, je v tom mraky penez uz za ty leta :) A prolezle je to vsude, kde jsou integratori a velke business podniky, a tak.. Cela komercni IT sfera imho jede na Jave.. velke veci, velke zodpovednosti, velke penize, statni sektory, bankovnictvi, telco markety, zdravotnictvi, vsude je to..
Je to perspektivni se to naucit, mozna bys mel byt rad, ze ti to sef navrhl :)
Taky mam radeji jine veci..
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 :-)
Těším se na popis APL, tento jazyk, stejně jako jeho následovníci J, K, patří k jazykům, které zřejmě nebudu nikdy používat, ale účastním se Projektu Euler a řešení v této množině jazyků mě dost fascinují.
Ten Grahamův bonmot, pokud by měl být brán jenom z 10% vážně, by si zasloužil asi vysvětlení. Podle mě se v průběhu vývoje dá najít spousta mechanismů, které z Fortranu ani z Lispu nevycházejí.
Mně šlo třeba o řízení přístupu a dědičnost v OOP, typové systémy ala Hindley-Milner, věci jako monády a šípy v jazycích typu Haskell, pattern matching atd.
Ale nechtěl jsem nějak rýpat, spíš mi šlo o získání lepšího vhledu. Samozřejmě mám určitou představu (funkce vyššího řádu, rekurze a proudové zpracování dat oproti klasickým imperativním výpočtům atd.) a uznávám, že nějaký smysl to dává.