Názory k článku
Programovací jazyky používané na mainframech

V perexu má být čárka mezi „Java“ a „a v mnoha …“. Takhle to vypadá, jako by LISP byl založený na ALGOLu, což mě, přiznávám se, trochu vykolejilo.

Díky za upozornění, opravíme.

Tak jsem to samozřejmě nemyslel :), i když je ale zajímavé, že McCarthy se okolo ALGOLu taky pohyboval, tuším že byl i na té známé schůzce v Paříži, na níž vznikl návrh ALGOLu.

Posledním programovacím jazykem, u němž se dnes (prozatím jen krátce) zmíníme, je jazyk LISP.

Je tam toho více… Např. „zevrubně popíšeme“ – zevrubně = velmi podrobně; neřekl bych, že předkládaný popis je velmi podrobný. A samozřejmě tradiční chybné použití vztažného zájmena „jenž“.

http://cs.wiktionary.org/wiki/jenž

zevrubně != zevrubně

Jsem se kdesi dočetl, že někteří a výkladový slovník chápou zevrubně jako detailně. Já pořád žiju v tom, že zevrubně je povrchně, ne detailně. A zdá se, že to nemá ani geografický původ.

Presne, ty zavorky :D Bez IDE to byl nadlidsky ukol. Musel jsem prebehnout k eclipse, jelikoz netbeans LISP stale ignoruji …

Lost In Stupid Parenthesis

Tak ted jsi na to kapnul. LISP ma takovou syntaxi, aby to nezvladl kazdy :D

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, ..

Lispove jazyky nemaji dobre knihovny. To je problem. A dalsi vec je, ze me treba Common Lisp (ac jsem jeho velky priznivec) pripada dost ukecany.

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).

Já vás spíš podezřívám z toho, že vy zase nerozumíte LISPu, když můžete napsat toto. XML je opravdu v jazyku, jako je LISP, naprostá zbytečnost. Asi jako přidělávat k turbomotory poháněnému letadlu ještě benzínový čtyřválec.

Precenovanie. XML nie je nativny jazyk ani Javy ani .Net-u ani C++. Mysite s nim pracovat a aparat naokolo je hotovy a je taky aky je. To ako keby ste napisali ze Jave je XML na nic lebo samotna Java je silnejsia ako XML. Proste blbost.

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).

Ale XML nie je jazyk. To ze mate alternativny zapis XML struktur v LISPe este z LISPu nerobi skvely jazyk.

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.

Ano, pouziva se jak jazyk symbolickych instrukci, tak i adres (JSI, JSA), i kdyz bych rekl, ze dneska kazdy z oboru dnes proste rekne assembler :-)

Jasně, tak tomu bylo i dřevních dobách. Vždy jsme používali termín assembler nikoliv JSA a taky router místo směrovač atd. :-).

Nas nutili na škole říkat JSI/JSA :-(

A taky „posuvná měrka“ místo „šuplera“, za „šupleru“ jsem jednou v dílnách dostal pětku :-)

„A computer without COBOL and FORTRAN is like a piece of chocolate cake without ketchup or mustard.“

Souhlasím, ale do článku se mi to nějak nehodí :)

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!!!

A co PL/1 ?

Bude jak RPG (ruzne verze), tak i PL/1 (a k tomu PL/M).

OK :) Mimochodem, ty AS400 davam pryc, uroven bordelu uz prekrocila vsechny meze. Fotky ale jeste udelam a poslu, pokud bys potreboval do budouciho clanku.

Bezva, fotky posli, budu se tesit. Ale rekl bych, ze je to skoda vyhazovat, zkus to prodat na eBayi nebo tak, lidi (s volnou garazi/sklepem napriklad :-) by to urcite koupili.

ok, mozna to testnu

Je to skoda, ale ak tak velmi prekaza, miesto by som nasiel…

Jsou toho 2 euro-palety! 2× AS400 (jedna funkcni, jedna s lehkou zavadou), 7× twinax terminal, tiskarna, hromada kazet a kabelu

hm tak to do auta fakt nedam… ako velmi ponahlate s tym upratovanim?

Zadny extremni spech neni. Asi jeste zkusim ebay.

Neviem ci sa RPG pouzivalo aj na mainframoch (teraz zSeries) – myslim, ze v sucasnej dobe je uz len na iSeries (AS/400). Mimochodom je to doteraz asi jediny jazyk, ktory som nebol schopny pochopit z manualu ale isiel som radsej na skolenie :-)

Jenom male upresneni
V clanku je veta „prvni prekladac vytvoreny Grace Hopperem“, coz by na nekoho mohlo pusobit, ze se jedna o muze.
Grace Hopper byla zena a ta opravdu vytvorila prvni prekladac :-)

Ha, ty ženy! První programovací jazyk, žena, první překladač, žena. ;-)

No ono dokonce totiz i „prvni clovek, zena“. ;-)

A ja porad, kdo za to vsechno muze!

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.

My si doma s bratrem hrali s dernou paskou, do knizek misto zalozek davame dodnes derne stitky a z mikulaskych veselic pro deti v Agrodatu sme si odnesli obrazky tistene „ascii artem“ na traktorovem papiru :-)

Tiez pouzivame dierne stitky ako zalozky do knihy.

Alebo ako papier na poznamky :-)

CLIST a REXX.

JCL, CL

tak me napadlo, bude taky nejake to povidani o zOS ? AFAIK to je mainframovy OS od IBM

Pokud si dobře vzpomínám, byly na děrných štítcích svislé čáry před některými sloupci. Nebylo to kvůli snadnější kontrole programů ve FORTRANu?

Co ja vim tak se kod psal az od urcite pozice a do urcite pozice – zacatek byl vyhrazen pro navesti (???). Kdysi mi ucili fortran na FELu – no uz je to dost dlouho a nepamatuju si nic :)

Ano, pred zavedenim volneho zapisu programu se vlastni kod psal od 6 sloupce, v prvnim se nachazely spec. znaky (zacatek komentaru apod.), popr. mezi 1–5 sloupcem navesti.

To jako že se mainframy bály příchodu Windows 2000? Nebo měly spíš strach z kocoviny na Nový rok 2000 – Y2K?

Pěknej šotek :-) díky za upozornění. IMHO zrovna wokna mainframy moc neohrozila, to je uplně jiná liga (když už firmy do mainframů investovaly), pro nové projekty je to asi něco jiného.

Doufam, ze v pokracovani nebude chybet JCL – to je na mainframe asi nejdulezitejsi. Jinak, neni ten odhad ohledne milionu vyyvojaru v COBOLU trochu prehnany? Myslim, ze tolik neni ani vyvojaru pro mainframe dohromady.

JCL je zlo

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..

Ještě bych doplnil – velké průsery.
Kde se točí velké peníze a je třeba velká spolehlivost, tam nikdo zodpovědný nic takového nepustí.

:) celej z tebe ted horim ! ale nebudu tady flamovat, opravdu ne…

zeptej se vsech velkejch firem jako IBM, Oracle, Sun atd. proc vyrabeji middleware a enterprise solutions na jave…

Však říkám – velký průsery.
Ty se zase zeptej, proč se tím neříděj atomový elektrárny nebo kosmický rakety.

já jsem o atomových elektrárnách ani kosmických raketách netvrdil, že jedou na Jave :) Jenom jsem říkal, kde se všude Java používá a kde má své místo :) Tak nedělej chytrýho, všichni jsme viděli matrix :)

Logika tvé reakce mi uniká. Resp. – žádná není.

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.

Já jsem se učil, že 1 + 2 = 3

Sorry no, prostě tento zápis

( = ( + 1 2 ) 3 )

… je pro mne prostě méně čitelný

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.

Zkousel jsi i luaj (Lua reimplementovana v Jave)? Je to neco na zpusob Jythonu ale s mensim overheadem.

http://sourceforge.net/projects/luaj/

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.newIn­stance, 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.

Promin, ze si rypnu, ale ten prvni radek, ten je z jakeho programovaciho jazyka? Nejaka definice axiomu:-)?

Ale treba takova Java, tim, ze odmita pretezovani operatoru, takovou syntaxi v urcitych pripadech vynucuje take. A to se pak tvrdi, ze je to kvuli citelnosti. Tak si pak vyberte.

To je otázka. Co je čitelnější?

(fn a b c)

vs

fn(a,b,c)

Jinak samozřejmě nepřetěžování operátorů v Javě mi také vadí. v C++ je to jen na půli cesty, ideální by bylo umět přetěžovat libovolné operátory včetně volby priority.

Ř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?“ :-)

V LISPu se dá poměrně snadno implementovat i infixová matematika (a dokonce i „bezzávorkový LISP“), ale nějak se to v praxi neujalo, když už si lidi zvyknou na prefixový zápis, tak ho používají i pro aritmetické a logické výrazy.

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í.

Ano, treba pristup Forthu apod. Nebo 4GL jazyky, ale ty asi Paul Graham nepocita mezi universalni jazyky (i kdyz mnohe jsou Turingovsky uplne :-)

U ostatnich 3GL jazyku me ta hlaska prijde vcelku trefna, i kdyz samozrejme, jako kazde zobecneni nepresna.

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á.

PL/1 byl taky skvely. Budete o nem mluvit?

Ano, bude minimalne jedna cast o PL/1 i PL/M.