Vlákno názorů k článku Editory pro TeX: který je nejlepší? od A. S. Pergill - byl DOSovský CSED, proto ho taky CSTUG hromadně...

Reverzní polská anotace: Nedokážu si představit, jak v tom udělat nějaký vzoreček, složitější než naprosté triviality, které bývají v nadšených článcích (třeba výpočet Gaussovy křivky). Přinejmenším by to znamenalo se léta učit úplně odlišnou matematiku. Většinou je v tom dost složité zpracovávat texty nebo binární data. Je to prostě hračka pro exkluzívní skupinu, která má na hračky čas.

Určitě máte na mysli reverzní polskou notaci. :-) Ta ale nemá nic společného s Lispem, a vůbec nechápu, proč by se kvůli tomu měl člověk učit jinou matematiku. Asi si pletete algebru s matematikou, ale to dělá víc lidí, takže se to dá chápat. Nicméně významné procento inženýrů používá RPN kalkulátory (aspoň v místech, ve kterých se daly historicky normálně sehnat, jako je třeba USA) a nemají s tím sebemenší problémy. Když jsem měl RPN kalkulátor, přišel mi zcela bezproblémový na používání, ba dokonce ještě přirozenější (počítá to tak, jak bych počítal já). Ale možná máte pravdu v tom, že pro inženýra je takový kalkulátor i hezká hračka, stejně jako třeba počítač nebo multimetr.

Věta "Většinou je v tom dost složité zpracovávat texty nebo binární data" je trošku mimo mísu, nemyslíte? Násobení a dělení při zpracování textů přeci nepoužíváte a funkce jako read(jaky_soubor, kolik_bajtu) nebo subst(retezec, regularni_vyraz, nahrada) a podobně určitě nejsou infixové. Nanejvýš v jazycích s message passingem můžete dostat název za objekt, kterému zasíláte zprávu (s tím, že další argumenty jsou, na rozdíl od Lispu a Dylanu, diskriminovány a pak se vymýšlejí "návrhové vzory" typu návštěvník, protože jazyk nemá dostatečné vyjadřovací schopnosti).

"Výkonem" jsem myslel paměť a rychlost procesoru, kdy není nutno složitými hacky bojovat o každý bit paměti a každý cyklus. Tyhle jazyky mají prostě význam na nevýkonných počítačích s malou pamětí ("inteligentní toustovač"), kam se nic rozumného implementovat nedá a úkol je současně moc složitý na assembler nebo strojový kód.

Tak v téhle kategorii AFAIK vede právě Common Lisp. :-) Rozhodně je na tom líp, než třeba Python nebo Java. Osobně se přiznám, že k němu mám ambivalentní postoj, protože ve své dově bohužel vznikl jen jako prostředek ke sjednocení divergujících dialektů jazyka. A sám bych byl rád za něco lepšího, ale ono moc na výběr není. CL ale má sílu v tom, že tu prostě je, jako jazyk s dvěma silnými komerčními implementacemi (byť proprietárními, ale jedna z nich má takový user support, že by si o něm leckterá firma mohla nechat zdát :-)) a několika svobodnými, z nichž aspoň dvě rozhodně nelze označit za pomalé. Na rozdíl od C++ (asi hlavní konkurent) nabízí ovšem žádoucí interaktivitu à la Python. Vy se můžete domnívat, že na velkých strojích nemají význam, ale jsou firmy, co na Lisp na serverech vsadily krk. ;-)

Nicméně tohle je mimo zase z mojí strany. Původní vaše rýpnutí, které mě, jak vidno, dost popudilo, se totiž týkalo toho, že v Emacsu se údajně "makra programují v nějakém obskurním jazyce, pamatujícím kuličková počítadla". To rozhodně není pravda, Elisp byl navržen v první polovině 80. let pouze kvůli napsání textového editoru a k jeho následnému rozšiřování. Tedy má funkce a prostředky přímo k psaní textových editorů. :-) Klidně by v něm mohl být napsaný třeba Vi, nejspíš o dost snáze, než v Cčku. Je to jiný jazyk než LISP 1.5 z roku 1962 "pamatující kuličková počítadla", a jiný jazyk než Common Lisp (tentokrát už jen s prvním písmenem velkým, bacha na to), jehož implementace čistě za tímhle účelem by nebyla tak jednoduchá a navíc v té době teprve vznikal. Pokud se Vám zdá divný zápis funkcí (f x y) (což je asi jediná věc, kterou má Elisp společného s "jazykem pamatujícím kuličková počítadla", společně s minimálním funkcionálním jádrem) tak s tím musíte jít za matematiky, ti to totiž píší přesně takhle (nanejvýš vynechávají závorky, pokud není třeba zapisovat prioritu, stačí se podívat třeba na http://en.wikipedia.org/wiki/Lambda_calculus). Koneckonců to jeden z nich vymyslel.

Pan Knuth napsal jazyk web pro TeX a Metafont, Metapost je syntakticky téměř shodný s Metafontem, obsahuje pouze rozšíření pro barvy a vkládání písmen (fontů) do obrázků a má menší omezení velikosti výsledného obrázku, Metafont má zase navíc ve spouštěcích příkazech generování bitmapy o konkrétním rozlišení a velikosti, zatímco Metapost má jako výsledek postskriptový formát (vektor).

Já jsem měl na mysli samotný TeX. Nikomu neberu Metapost, ale většina lidí, co používají TeX, píše v makrojazyku TeXu - no, dobře, většina z nich asi používá hotová makra v LaTeXu. ;-) Ale ti, co používají plain, v něčem píší svá makra, a ten jazyk není ani web, ani metapost. Osobně mi to přišlo jako vylepšený Troff, má to zhruba podobný model. Problém je, že když se v tom člověk pokusí dělat složité věci, začne to být zajímavé. V TeXu člověk nemá jinou možnost, na rozdíl třeba od Troffu, kde se dají makra expandovat filtrem psaným v jakémkoli jazyku. Je to Unix, používá to pajpu. ;-)

Osobně svůj "ideální nástroj" co do výstupu a sazby stále hledám. V jednu chvíli jsem uvažoval o TeXu, ale víc než vstupní jazyk mě odradily jiné zlotřilosti. Syntaxe TeXu jako vstupního jazyka pro text je téměř dokonalá, jako prostředek k zápisu maker se mi líbí již mnohem méně. Taky by bylo bezva, kdyby se člověk nemusel potýkat s věcmi, jako je kódování, písma a podobně. Třeba jedna firma, ve které jsem pracoval, přešla z TeXu na XSL:FO kvůli problémům TeXu s exotickými jazyky. Já sice uznávám CM jako nádherné písmo na spoustu (především technických) aplikací, ale bylo by pěkné, kdyby se třeba OpenType písma dala v TeXu používat tak snadno, jako v dnes již stařičkém Troffu (viz ukázka: http://heirloom.sourceforge.net/doctools/troffdemo.pdf). Možná to ještě zkusím, přiznávám, že se mi moc líbí ConTeXt, ale zatím váhám.