Tcl vojny

Koncom septembra 1994 Richard Stallman zverejnil v diskusnej skupine comp.lang.tcl článok s názvom „Prečo by ste nemali používať Tcl“. Následne vypukla búrlivá diskusia, ktorá v tej či onej podobe trvala takmer mesiac. A o čom bola? Mala zmysel? Ako sformovala pohľad na skriptovacie jazyky?

Nuž, musel som sa ňou prehrýzť. Bolo to zaujímavé čítanie. V nasledujúcich riadkoch prinesiem čiastočne chronologický opis diskusie. A veru som párkrát musel pretočiť oči, lebo presne takto sa aj diskusia pretáčala 😀.

Zaujalo ma to, lebo Tcl používam, hoci sa snažím (pomaly až pomaličky) prejsť na Python.

Glenn Vanderburg

Glenn Vanderburg je softvérový vývojár, architekt a technický autor, s dlhoročnou kariérou v softvérovom inžinierstve. Pracoval s viacerými jazykmi vrátane Tcl, C, C++, Javy a Perlu a neskôr sa výrazne venoval Ruby, Rails, Clojure.

Vanderburg vtedy spravoval bibliografiu zdrojov o Tcl. Rozhodol sa zachovať zaujímavé príspevky z tejto hádky, pretože sa obával, že ak by sa uchoval iba Stallmanov pôvodný článok, čitatelia by prišli o podstatné protiargumenty a širší kontext. Snažil sa zachovať vyvážený výber, hoci priznal, že aj jeho vlastné preferencie ovplyvnili to, čo do archívu zaradil. Archivoval aj vlastné príspevky.

Vytvoril historický prameň, vďaka ktorému dnes môžeme sledovať argumenty oboch strán.

https://vanderburg.org/old_pages/Tcl/war/

O čo išlo?

Bol to ostrý spor o tom, či má byť Tcl univerzálnym skriptovacím jazykom na rozširovanie programov, alebo či je príliš obmedzený (a vtedy bol výrazne obmedzenejší ako v súčasnosti, dnes používam verziu 9.0) a mali by ho nahradiť výkonnejšie jazyky. Diskusia prebiehala na internetových diskusných skupinách od konca septembra do 18. októbra 1994 a archív obsahuje 68 správ.

Avšak nešlo iba o technickú debatu o syntaxi. Vznikol (a vnikol tam) konflikt o to, kto má rozhodovať o programovacom jazyku, ktorý budú musieť používať používatelia aplikácií.

Richard Stallman ako kritik Tcl tvrdil, že Tcl je vhodný na malé skripty, ale nie na rozsiahle programy. Kritizoval jeho dátové štruktúry, prácu s číslami a nezvyčajnú syntax.

V pôvodnom článku Stallman tvrdil, že Tcl nemá polia a neposkytuje štruktúry, z ktorých by sa dali vytvárať spájané zoznamy. To nebola pravda. Tcl malo asociatívne polia a zoznamy, v ktorých je Tcl veľmi silné (no ale nie tak ako Lisp, samozrejme 😀).

Stallman písal, že Tcl „predstiera, že má čísla“ (it fakes having numbers), a preto musí byť pomalý. To bola pravda, dodnes je Tcl beztypový jazyk, resp. základnou reprezentáciou hodnôt sú reťazce znakov. Stallman mal (zrejme) obavu z výkonovej réžie spôsobenej textovou reprezentáciou hodnôt, ale jeho tvrdenie, že to musí znamenať pomalosť, nebolo dostatočne podložené.

Ad syntax: jednoduchá pre stroj, nezvyčajná pre človeka? Stallman tvrdil, že Tcl má svojskú syntax, ktorá sa páči hackerom pre svoju jednoduchosť, ale väčšine používateľov pripadá čudná. Čo bolo, podľa mňa, odvážne tvrdenie, vzhľadom na to, že veľkú časť života programoval v Lispe (na katedre UI na MIT).

Ale pozrime sa na príklad:

set x 10
set y [expr $x * 2]
puts $y

Kde,

• set je príkaz na nastavenie premennej.
• $x znamená hodnotu premennej x.
• Hranaté zátvorky [ ] vykonajú vnorený príkaz a vrátia jeho výsledok.
• expr vyhodnotí matematický výraz.

O Tcl má root.cz niekoľko dobrých článkov, písaných, ako vždy, pánom Tišňovským. Tam opisuje jeho zvláštnu syntax. Ale zvláštna je najmä pravidlami substitúcie a vyhodnocovania výrazov. Na rozdiel od C nie je celý program jednoducho postavený na jednom jednotnom zápise výrazov. To môže pôsobiť nezvyklo, najmä ak sa očakáva, že priradenie, volanie funkcie a matematický výraz budú mať podobnú syntax.

Ešteže človek už dnes nič neočakáva. 😀

Stallman chcel ponúknuť dva jazyky: jeden s Lispovskou syntaxou pre programátorov (teda napríklad Scheme alebo Lisp) a druhý s tradičnejšou algebraickou syntaxou pre ostatných.

John Ousterhout, autor Tcl, tvrdil, že Tcl treba posudzovať podľa účelu, na ktorý vznikol. A vznikol ako interpretovaný jazyk, ktorý slúži ako „lepidlo“ medzi viacerými jazykmi. Ja som robil programy, kde prepájal C a bash a riešil veci, ktoré v C či bashi sú dosť nemotorné (napr. prácu s reťazcami).

Ostatní účastníci — programátori rozoberali konkrétne otázky: či Tcl skutočne nemá polia a zoznamy, či je jeho syntax problémom pre bežných používateľov, či by bol lepší Python alebo Scheme a či je rozumné nútiť všetkých vývojárov používať jediný jazyk.

Diskusia v skratke

Najprv Stallman vyhlásil, že Tcl nie je vhodný ako univerzálny rozširujúci jazyk. Samozrejme, svojim vlastným konfrontačným prístupom. Diskutujúci spochybňujú jeho argumenty a upozorňujú, že Tcl/Tk je praktický a prenosný. Ousterhout vysvetľuje, že Tcl má dopĺňať C či C++, nie ich nahrádzať.

Diskusia sa presúva ku konkrétnym vlastnostiam jazyka. Má polia? Dajú sa vytvárať spájané zoznamy? Je syntax skutočne horšia než syntax Lispu alebo shellu?

Potom vznikne debata, či by nebolo lepšie použiť Scheme alebo Python, pretože majú (údajne) lepšie dátové štruktúry.

Barry Merriman uznáva, že Tcl nie je plnohodnotný jazyk a má zvláštnu syntax, ale pýta sa, či alternatíva dokáže byť súčasne jednoduchá, prenosná, vložiteľná do aplikácií a vhodná aj na väčšie programy. Kritizuje myšlienku dvoch rovnocenných jazykov od GNU a navrhuje zvážiť Python.

Potom dostane Stallman „sprchu“ za to, že nedoceňuje Tcl dostatočne. A že by sa nemal snažiť „spraviť Emacs z každého programu“.

A vôbec — musí celý GNU ekosystém používať jeden jazyk? (Teraz vieme, že nemusí.)

Niektorí (Grunwald, DeLine) navrhujú Scheme (t.j. minimalistický dialekt Lispu, ktorý kladie dôraz na jednoduchosť, funkcionálne programovanie a rekurziu). Pretože ak má Tcl niekoľko tisíc riadkov, dá sa obtiažne udržiavať. Ale zase — Tk (grafický toolkit) je výborný.

Zase a znovu sa rozoberá, najmä Ousterhoutom, že veľký systém môže používať C/C++ na zložité dátové štruktúry a Tcl na jednoduché skripty. Od skriptov chce najmä ľahké učenie a pohodlné prepájanie, nie schopnosť riešiť všetky algoritmické úlohy.

Neskôr sa dopracujeme k tomu (Throop), že triedy, procedúry a rozdelenie menných priestorov (namespaces) umožňujú vytvárať veľké systémy aj v jazykoch pôvodne určených na skriptovanie.

Zaujímavé je, ako Eduardo Pelegri-Llopart odpovedá Ousterhoutovi, že skriptovací jazyk nemusí zostať oddelený od hlavnej aplikácie. Skúsenosť s Emacsom podľa neho ukazuje, že hranice medzi hlavným kódom a rozšíreniami sa v praxi menia a veľká časť funkcionality sa časom presúva do rozširujúceho jazyka. Len na okraj, na tomto je Emacs postavený: rýchle jadro v C, rozšírenie v deriváte Lispu.

Krátka debata o popularite ako ukazovateľovi kvality. Programátori si už v tom čase vyberali jazyk podľa existujúcich knižníc, nástrojov a skúseností a nie podľa jeho technickej výnimočnosti.

Neskôr Adam Sah tvrdí, že Tcl má slabiny, ale odmieta paušálne odsúdenie. Rozoberá sémantiku, výkon a porovnanie so Scheme. (Zase a znova) zdôrazňuje, že správna otázka nie je, ktorý jazyk je absolútne najlepší, ale na aké úlohy sa ten-ktorý hodí.

Wayne Throop sa vracia k pravidlám substitúcie v Tcl. To, že sa Tcl správa inak než shell, nemusí byť (resp. nie je) chyba. Poznáme to aj sami — časť problémov či odporu vzniká tým, že používatelia očakávajú správanie iného jazyka. Neskôr otvára spor, či má Tcl lexikálny alebo dynamický rozsah premenných. Throop tvrdí, že lokálne premenné Tcl sú izolované spôsobom, ktorý môže byť bezpečnejší než niektoré konkurenčné prístupy. Ide o konkrétnu technickú polemiku, nie všeobecnú obhajobu všetkých vlastností Tcl. Len dodám, že Tcl je hybridný: premenné v procedúre sú lokálne, no príkazy ako upvar umožňujú siahnuť do prostredia volajúcej procedúry, čo pripomína dynamický rozsah. Preto sa nedá jednoducho označiť za čisto lexikálny ani dynamický jazyk.

George M. Sipe zabŕdne do inej problematiky — prenosnosti, licencie a komunite Tcl. Má obavy, či licenčné podmienky GNU GPL môžu ovplyvniť ochotu komerčných vývojárov používať nové riešenie.

Tom Lord vysvetľuje dôležitý terminologický spor: Tcl má asociatívne polia, ale nie klasické polia typu C, teda vektory s priamym indexovaním. Stallmanovo tvrdenie preto nebolo nezmyselné, ale bolo zavádzajúce (zámerne?). Asociatívne polia totiž nenahrádzajú efektívne vektory vo všetkých situáciách.

Pre zaujímavosť:

1. Klasické pole v jazyku C

int vek[5] = {25, 31, 19, 42, 28};
printf("%d\n", vek[2]);  // vypíše "19"

Pri klasickom poli sú prvky rovnakého typu uložené v súvislom bloku pamäte. Preto sa k prvku podľa indexu dá pristupovať veľmi efektívne: jeho adresa sa vypočíta z adresy začiatku poľa a indexu. A preto máme radi pointery 😀.

V bežnom prípade je prístup k nemu operácia s konštantnou časovou zložitosťou O(1). Teda nezáleží, ku ktorému prvku pristupujeme, stále je to „rovnako rýchlo“.

2. Asociatívne pole v Tcl

V Tcl to vyzerá takto:

set vek(Richard) 47
set vek(Mirec) 42  ;# asi 😀
set vek(Gandalf) 1500
puts $vek(Mirec)   ;# vypíše "42"

Tu nie je indexom číslo označujúce pozíciu, ale kľúč — v tomto prípade meno človeka. Výhodou je, že netreba vedieť poradie.

3. Prečo Stallman frfľal?

Napríklad chceme uložiť z nášho zariadenia na riadenie klímy 100000 hodnôt, napr.

teplota[0] = 21.4
teplota[1] = 21.7
teplota[2] = 21.5
...
teplota[99999] = 19.8

Je to kompaktné, predvídateľné a umožňuje efektívne prechádzať všetky prvky.

V asociatívnom poli by to šlo spraviť tiež, ale práca by dozaista bola ťažkopádnejšia (napr. prevádzať poradie na kľúče a pod.)

Keď Stallman kritizoval Tcl za chýbajúce polia, vznikol terminologický problém. On myslel nielen array, t.j. klasické pole s priamym číselným indexovaním, jeho výhrada mala konkrétny technický obsah, ale súčasne aj akúkoľvek sústavu hodnôt prístupných cez index a/alebo kľúč, a tam tvrdil, že Tcl tieto asociatívne polia nemá.

Ešte detail — v neskorších verziách Tcl pribudli aj zoznamy, ktoré umožňujú uchovávať usporiadanú postupnosť hodnôt:

set vek {25 31 19 42 28}
puts [lindex $vek 3]   ;# vypíše "42"

Sharon Hopkins vtipkuje o tom, či je Lisp vizuálne príťažlivý, a objaví sa ukážka programátorskej poézie v Perle.

Niektorí, ako Ian Moor, zbytočne odbočujú k používateľským aplikáciám a Emacsu. Spochybňuje ideu, že integrácia mnohých funkcií do jedného prostredia je vždy výhodná.

Neskôr Ousterhout pridáva porovnanie výkonu pri práci so zoznamami. Upozorňuje, že niekto použil neefektívny spôsob pridávania prvkov do Tcl zoznamu a ignoroval optimalizovaný príkaz lappend. Takže sa ukazuje, že kritizovať niekto niečo by mal len vtedy, ak ozaj dotyčný má hlbšie znalosti. Ale aj dnes vidíme, že to nie je nutnou podmienkou 😀.

Potom Tom Christiansen porovnáva syntax Tcl, Perlu a Scheme na jednoduchom príklade vytvárania grafických prvkov. Tvrdí, že Perl nemusí byť taký neprehľadný, ako sa hovorí. Tým vznikne zbytočná diskusia o Perle 😀.

Potom nastúpi kritika Stallmanovho spôsobu komunikácie. Technická debata sa čiastočne mení na spor o zodpovednosti Stallmana ako verejne známej osoby.

Kathi Fisler predstavuje Schemepkg, ktoré umožňuje spúšťať Scheme priamo z Tcl skriptov. Toto sa zdá ako praktické spojenie výhod oboch jazykov namiesto nahradenia jedného druhým. Ale viac sa o tom nedebatuje.

Zase sa točíme v kruhu a diskutuje sa o tom, že Tcl má byť zámerne jednoduchou vrstvou, pričom dátové abstrakcie má poskytovať aplikácia, do ktorej je vložený.

Akoby toho nebolo málo, tak sa opäť spochybňuje prenášanie skúseností z Emacsu na všetky aplikácie. Je pravdou, že Emacs prerástol do programovateľného prostredia, no to neznamená, že je to jediný správny prístup.

A znovu sa rozoberá syntax, jej čitateľnosť, a hlavne to, že ako je oná čitateľnosť subjektívna. Programátovi v TeX-u by vedeli rozprávať. Pokračuje v obhajobe jednoduchého skriptovania a v otázke, či sa oplatí zavádzať zložitejší jazyk tam, kde stačí jednoduchá vrstva príkazov.

Mark Harrison nastolí ďalšiu otázku z hľadiska praktickosti, a to, či sa jeho obmedzenia dajú prekonať vhodnými knižnicami a organizačnými mechanizmami.

Otvorí sa filozofia Unixu: možnosť kombinovať nezávislé programy. Nie je to dôkaz univerzálnej nadradenosti Tcl, ale vysvetlenie jeho praktickej hodnoty.

Znovu sa otvoria už zodpovedané otázky o organizácii kódu pri veľkých projektoch, vyhodnocovaniu príkazov,… a zase tá syntax! A zase to „lepidlo“.

Ak by sa zdalo, že sa ešte nepovedalo všetko: tak znovu tá syntax. A porovnávanie Tcl vs Perl.

Pôvodná výmena názorov sa blíži ku koncu bez jednoznačného technického víťaza.

A aký je záver?

Debata sa často točí v kruhoch a to najmä, či sa dajú veľké programy v Tcl udržiavať, a ku konkrétnym dátovým štruktúram.

Nikto jednoznačne nezvíťazí.

Ak zhodnotíme diskusiu, zistíme to, čo sme asi aj tušili, že:

• Tcl sa hodí na jednoduché úlohy a prepájanie programov. Je pomerne ľahké ho používať, funguje na rôznych systémoch a dobre spolupracuje s programami napísanými v C a C++.
• Pri veľkých programoch sa však ukážu jeho obmedzenia.
• Dva odlišné pohľady na to, aký má byť jazyk. Ousterhout vnímal Tcl ako jednoduchý nástroj, ktorý dopĺňa iné programovacie jazyky. Stallman chcel univerzálnejší jazyk, v ktorom by sa dali vytvárať aj veľké rozšírenia bez potreby prejsť na C.
• Diskusia pomohla určiť, čo by mala ponúknuť alternatíva pre GNU. Z toho sa neskôr rozvinul samostatný projekt s názvom GNU Extension Language, známy ako Guile.

A aká je hlavná myšlienka? Asi, že najlepší jazyk na rýchle prepájanie hotových komponentov nemusí byť najlepším jazykom na budovanie veľkého softvérového systému.

A spor z roku 1994 je zaujímavý práve tým, že obe strany mali v tomto bode čiastočne pravdu. A nebol iba o tom, či má Tcl dosť dátových štruktúr. Išlo aj o to, či má byť rozširujúci jazyk ľahkou vrstvou na prepájanie hotových častí, alebo plnohodnotným jazykom, v ktorom môžu používatelia postupne písať čoraz väčšiu časť aplikácie — a kto o tejto voľbe rozhoduje.

Kto si to chce prečítať v origináli, mal by si na to vyhradiť dlhší večer. Preto som to zhrnul, aby bola možnosť zorientovať sa v jej hlavných argumentoch a pochopiť, o čo v spore vlastne išlo, a to za podstatne kratší čas.

Ak niekoho téma zaujme, pôvodné príspevky sú dostupné — stačí si vybrať a ponoriť sa hlbšie. História internetu (a IT vôbec) si zaslúži viac než len zabudnutý odkaz v archíve.