spyked bricks in the wall

interacțiunea om-mașină ca act de comunicare

Citind [i] un articol care face încercarea de a lega mediul UNIX de literatură, m-a lovit în crestetul capului ideea că eu nu m-am gândit până acum să leg iadul abstractizării de interacțiunea om-calculator. Cum a reușit creierul meu să omită această legătură foarte importantă n-am de unde să știu, însă consider că trebuie remediată problema cât mai repede cu putință, deci voi purcede imediat la a trata subiectul.

Putem cădea de acord, conform The Elements Of Style, că există două paradigme mari și late care se disting în interacțiunea om-mașină și în particular în interacțiunea om-sistem de operare. Prima presupune tipărirea explicită de comenzi care fac mașina să execute chestii, deci este în principiu proactivă, în timp de a doua constă în interacțiunea cu elemente grafice în măsura în care acestea sunt disponibile pe ecran, deci este în mare parte reactivă. De fapt firește că adevărul e undeva la mijloc, motiv pentru care nici nu are rost să fim snobi și să înfierăm GUI-ul drept o prostie [ii] și să catalogăm interfața textuală drept Α și Ω.

Ar fi ok totuși să afirmăm că interacțiunea prin text este mult mai apropiată de ideea de comunicare lingvistică, în timp ce interfețele grafice se aseamănă mai mult cu manipularea unui mediu abstract virtual. Cea dintâi paradigmă e evident mai complicată decât cea de-a doua, dat fiind faptul că orice copil învață să ia obiecte și să le bage în gură în primele luni din viață, pe când stăpânirea limbajului necesită un antrenament îndelungat ajutat de educație formală și așa mai departe. Sigur, la nivelul cel mai de jos se întâmplă că și limbajul corpului e un act de comunicare important, însă noi dorim să discutăm cu calculatorul idei, nu semnale de împerechere, motiv pentru care îmi permit să reduc domeniul comunicării, referindu-mă strict la limbaj atunci când vorbesc despre aceasta.

Dacă mai privim și sistemul de operare ca pe un hardware extins și ne gândim că hardware-ul calculatoristic există în general pentru a fi programat, putem ajunge să ne uităm la ansamblul de utilitare [iii] dintr-un sistem UNIX (și nu numai) ca la un soi de primitive ale unui limbaj de programare. Terminologia e și aici „loose”, pentru că una e programarea și alta e scripting-ul, însă aspectele astea sunt cât se poate de irelevante pentru discuția noastră.

Este relevant însă să ne întrebăm în ce paradigmă se încadrează limbajul de programare asociat utilizării de zi cu zi, pentru că putem apoi să stabilim un model de calcul și mai ales tipare lingvistice conform cărora vom ști ce proprietăți posedă unealta cu care operăm. Pot să bag mâna în foc că majoritatea hackerilor din lumea *nix habar nu au de acest aspect și nici nu sunt interesați. Recunosc că nici eu nu știam până recent care-i paradigma în care se încadrează shell scripting-ul UNIX, dar acum știu și vă pot împărtăși că este cea a programării concatenative, care se bazează de fapt pe modelul mașinii cu stivă, același cu cel folosit de inginerii HP pentru a proiecta calculatoare aritmetice acum 30-40 de ani.

Programarea concatenativă pură se aseamănă foarte mult cu modelul categorial cu care m-am mai jucat pe aici. Avem de-a face așadar cu morfisme văzute ca fluxuri de informație cu o intrare și o ieșire (deci între două obiecte), pe care noi nu avem altceva de făcut decât să le compunem și răscompunem, obținând în final ceva util nouă. În cadrul sistemelor de operare obiectele statice sunt fișierele, fluxurile sunt de fapt procesele (programele) care rulează iar operatorul de compunere, adică pipe-ul, nu face decât să lege programe între ele.

Dacă notăm operatorul de compunere cu | ca în Unix, putem astfel construi idiomuri de genul:

spyked@tuvok:~$ ls | grep "do"
docs
downloads

Prin disecția comenzii vom afla că pipe-ul ia ieșirea lui ls și o trimite către grep "do", care acționează la fel ca filter din programarea funcțională, afișând doar acele șiruri care conțin subșirul „do” – în cazul acesta eu am în directorul ~ două fișiere care respectă condiția, „docs” și „downloads”. Stilul ăsta ne duce cu gândul exact la modelul comunicației definit de Shannon, ăla cu sursa, codificatorul, canalul și așa mai departe. Cu alte cuvinte interacțiunea aici nu e numai un act de comunicare între om și calculator, ci și o manipulare a programelor cu rezultatul de a le face capabile să comunice între dânsele.

Abordarea scalează la rețele de calculatoare ajungând evident până la nivelul Internet-ului, unde funcționarea proceselor de calcul e de așa natură încât acestea comunică cu mai multe alte procese simultan, de multe ori fără să fie conștiente de asta. Acest lucru se reflectă și în programarea concurentă, astfel că prin analogie în shell-urile UNIX putem de obicei să pornim un program în background și să executăm alte procese în paralel, acest stil fiind dus la un cu totul alt nivel de către utilitare precum Screen.

Există deci aspecte care fac lucrul cu o interfață grafică mult mai complicat față de un mediu bazat complet pe text. Chiar și așa e discutabilă utilitatea liniei de comandă pentru utilizatorul mediu, având în vedere că o secretară nu se va apuca niciodată să editeze documente în LaTeX, la fel cum eu prefer să îmi generez toate graficele cu Gnuplot față de Excel. Articolul lui Scoville rămâne însă în continuare la fel de valabil în sensul în care Windows abia acum învață [iv] să ofere utilizatorilor diversitatea pe care mediile GNU/Linux și în general cele Unix o oferă în acest domeniu încă de la începuturi.

1. Via Google+, care apropo, în cazul ăsta a reușit să-mi dea un plus de utilitate considerabil. [↩]
2. Ba dimpotrivă, oamenii de la Xerox care au inventat tipul ăsta de interfață au fost geniali. Pe deasupra au mai fost și sănătoși la cap, deci nu i-au dat în judecată pe Apple și Microsoft după ce le-au „furat” ideile, că doar asta au făcut, nu? [↩]
3. Prin „utilitare” înțeleg shell-ul și toate celelalte unelte de bază oferite atât direct de nucleu cât și de alte programe din sistem. Apropo, știți că în Linux există un utilitar numit [? [↩]
4. PowerShell e o unealtă cinstită de scripting în Windows, venind cu un sistem de pipeline foarte puternic. [↩]