spyked bricks in the wall

rolul semanticii statice în comunicare

Putem afirma că orice act de comunicare este compus din două contexte: un context static și unul dinamic. De fapt mie personal afirmația asta mi se pare una cât se poate de cinstită și nu văd de ce nu ar putea fi folosită drept bază pentru a înțelege mai bine care e utilitatea distincției între „semantică statică” și „semantică dinamică”.

Semantica pe care eu o numesc statică se referă în principiu la un set de concepte prestabilite, existente indiferent de felul în care decurge comunicarea propriu-zisă. De exemplu o sferă este o sferă și nu poate fi un cub în nici o discuție – cu excepția cazului în care este demonstrat contrariul, ceea ce ne duce la gândul că în viața reală nu prea există concepte statice cu adevărat „strong”, dar asta e o cu totul altă discuție.

Un exemplu de context static în actul de comunicării de zi cu zi este cel al protocoalelor. Comunicarea verbală e începută (conform protocoalelor stabilite apriori de societate) printr-o formă de salut, continuată pe un subiect – eventual după reguli de nivel mai înalt – și apoi e încheiată prin alte gesturi și/sau acte de vorbire. Ideea asta e la fel de valabilă și în protocoalele din rețelele de calculatoare etc.

Dacă privim actul comunicării ca pe un caz particular de calcul, putem observa că și în acest context se aplică exact aceleași reguli. Limitările operării/programării unui calculator sunt (inclusiv) statice, iar programele pe calculator sunt la rândul lor formate din contexte statice și dinamice.

Practic aici se află un punct sensibil al lumii calculatoarelor, cel constituit de lingvistica computațională. Limbajele de programare sunt o idee absolut genială și sunt ceea ce fac din oameni ca Chomsky sau McCarthy [i] titani nu numai ai lingvisticii sau ai matematicii, ci și ai calculatoarelor. Pe scurt, folosirea limbajului, cu toată structura sa de jos până sus și înapoi, este ceea ce a permis crearea unor sisteme software de o complexitate mare [ii], fapt ce a dus apoi la așa-zisa inginerie software.

Limbajele de programare au și ele un context semantic static dat de obicei de tipurile și variabilele ale căror semnificație, respectiv stare sunt cunoscute în momentul compilării. Dar bine, îmi veți spune, anumite limbaje nu sunt în general compilate. N-o să stea nimeni să compileze script-uri Bash sau programe în Python, Ruby sau Javascript. Și e adevărat, limbajele astea nu au o componentă statică puternică, ceea ce le face din multe puncte de vedere mult mai flexibile decât echivalentele lor scrise în C de exemplu. Un avantaj clar îi este adus programatorului, care poate scrie programe pe care le va testa imediat, fără să mai treacă prin compilare – proces care poate dura destul de mult, mai ales în cazul unor proiecte așa-zis „complexe”.

Ba chiar și unele limbaje în general compilate vin în general cu o semantică destul de laxă, limbajul de asamblare fiind o extremă în acest caz. Nici C-ul [iii] nu e foarte departe, dat fiind faptul că pointerii pot fi convertiți dintr-o parte în alta și se ajunge la cazuri în care operațiile executate asupra structurilor de date sunt de-a dreptul necurate [iv].

Un limbaj cu o semantică statică destul de bună este Java [v]. Mai ales în versiunile mai noi anumite măgării pur și simplu nu sunt permise de către compilator. Exemplul meu preferat este totuși Haskell, care se bazează pe un sistem de tipuri extrem de bine formalizat, plecând de la programarea funcțională și împrumutând câteva concepte cheie din teoria categoriilor.

Care este totuși argumentul în favoarea limbajelor cu o semantică statică puternică? La fel ca în viața reală, rigiditatea staticului e compensată de avantajul eficienței și poate mai important de robustețe. Nu cred că e de preferat să scrieți un prototip software în Javascript, unde bug-urile pot ajunge să vă scape printre degete imediat – noroc că interpretoarele, adică browserele, au măsuri de securitate care să prevină unele calamități. De asemenea nu cred că doriți să scrieți un software critic din punctul de vedere al securității și/sau al corectitudinii într-un limbaj dinamic. Pur și simplu nu se face asta, deoarece proprietățile menționate anterior trebuie asigurate cu mult înainte ca programul să ajungă să ruleze [vi].

Într-un mod oarecum similar, în limbajul natural literatura ca ansamblu – care e un mijloc de comunicare preponderent static, cel puțin până în momentul în care un agent ajunge să încerce să îl înțeleagă – are rolul de a stabili înțelesul limbii în care este publicată, motiv pentru care o limbă fără literatură relevantă se formează pe baza vulgului, ajungând să aibă o semantică foarte volatilă, fapt care până la urmă decurge în mod evident din comunicarea strict orală.

Din fericire civilizația în toată diversitatea ei a evoluat destul de mult încât să poată dezvolta un context având componente atât statice cât și dinamice puternice. Mă refer bineînțeles la arhiva de informație a rasei umane™, care-i un organism suficient de complex încât să poată susțină toată informația, chit că nu-i suficient de matur încât să se autosusțină; încă.

1. Mă refer la John McCarthy, matematician și om de știință al calculatoarelor, dezvoltatorul limbajului LISP. [↩]
2. Cum ar fi de exemplu un compilator, adică gcc, sau un nucleu al unui sistem de operare, adică Linux. Apropo, Windows nu intră în discuție pentru că nu poate fi studiat, iar Minix are doar valoare academică și nimic mai mult. [↩]
3. Care e până la urmă un fel de wrapper frumos peste limbajele de asamblare, nimic mai mult. De fapt tocmai asta îl și face un limbaj așa de puternic. [↩]
4. Mai grav e că practicile astea sunt binecunoscute în ingineria software și reprezintă în general un compromis bun între performanță și corectitudine. Sigur, teoretic nu ar trebui să fie nevoie de așa ceva, dar practic povestea stă cu totul altfel. [↩]
5. L-am dat ca exemplu pentru că la C++ nu mă pricep așa de bine, iar C++ e tatăl lor. Citiți – în cazul în care n-ați făcut-o deja – câteva din cărțile lui Andrei Alexandrescu și vă veți lămuri. [↩]
6. Ca fapt divers niște indivizi de la NICTA dezvoltă un nucleu de sistem de operare care-i dovedit formal a fi „sound” din punctul de vedere al securității. Căutați seL4 și OKL4 dacă sunteți interesați. [↩]