Motto 0: Cine nu citeşte istoria este condamnat s-o retrăiască.
Motto 1: Those who do not understand Lisp are doomed to reinvent it, poorly.

Istoria recentă a Europei este împărţită de obicei în trei faze de relativă civilizaţie: antichitatea greco-romană, evul mediu şi epoca modernă, ultima precedată de o perioadă de `renaştere'.

Barbarie şi renaştere

De fapt, această secvenţă descrie relaţia triburilor care au populat continentul pana recent faţă de o invenţie aparuta acum doar 25 de secole: statul laic, adică o anumită combinaţie funcţională între o justiţie laică şi o structură militară. Statul laic a facut posibilă dezvoltarea unei lumi civile şi a unei culturi creative, laicitatea lui separând aspectele culturale de activitatea statală.

Cele trei faze despre care vorbim au constat în dezvoltarea şi afirmarea acestei invenţii (antichitatea), recunoaşterea şi adoptarea ei pe scară largă de către populaţiile gentilice barbare care au luat contact cu ea, adoptare făcută iniţial doar în formă şi motivată de prestigiul conferit de această formă (evul mediu---o îmbinare de stat religios şi gintă), şi descoperirea în generaţii progresive a fondului invenţiei, asimilarea lui în cultura şi apoi în structura societăţii (renaşterea) apoi adaptarea şi dezvoltarea lui.

Aici plecăm de la premiza că această schemă descrie impactul multor invenţii epocale în societate şi că li se aplică împărţirea în astfel de faze, de descoperire şi recunoaştere, de adoptare formală, de redescoperire a fondului şi de aplicare generalizată.

Invenţia care ne interesează aici este, desigur, calculul digital şi aplicaţiile sale. Considerăm că acesta a trecut printr-o fază `antică,' axată pe maşini mainframe (şi apoi mini) în jurul cărora s-a dezvoltat o întreagă cultură a aplicaţiei numerice; o fază medievală de generalizare la o populaţie admirativă dar inocentă, care a adoptat mai ales formele (de exemplu a confundat calculatorul personal cu un fel de maşină de scris şi l-a adoptat în principal în această formă) şi care a început cu microcomputerele personale în anii '80; iar acum ne aflăm în plină renaştere care a început izolat cu proiectul GNU (iminenţa renaşterii), a explodat cu fenomenul Linux/OSS (recunoaşterea renaşterii) şi intră acum într-o fază de căutare şi redescoperire sistematică a `clasicilor', după care ar urma, logic, o fază de dezvoltare a rezultatelor lor, de data aceasta pe o scară mult mai largă.

Din perspectiva `civilizatului' evurile medii par dezagreabile: din toată splendoarea culturii originale se ia o faţadă greşit înţeleasă cu care `barbarii' se împăunează ridicol, şi această mascaradă ajunge să înlocuiască însăşi cultura. De fapt, privite de la distanţă, evurile medii sunt fenomene îmbucurătoare, în care invenţia cu pricina se generalizează în sfârşit. Rareori martorii `invaziilor' pot însă să se detaşeze şi să nu deplângă sfârşitul splendidei lor izolări, sau promotorii renaşterii să nu se dezică dispreţuitori de `evul întunecat'.

De fapt, nici în societatea europeană, şi nici în lumea calculatoarelor, structurile arhaice n-au dispărut pe parcursul evului mediu, ci chiar au evoluat lent, sub forma statului bizantin şi a celui abasid în primul caz şi a unor proiecte de dezvoltare în cazul calculatoarelor---proiecte despre care vom vorbi mai jos.

Această dezvoltare pare să încetinească însă progresiv, şi într-un caz şi în celălalt, dar tocmai când pare să se fi oprit complet, se amorsează renaşterea şi revalorizarea---fenomen pe care nu ni-l putem explica. Poate renunţarea formală la orice pretenţie de proeminenţă îngăduie în sfârşit preluarea soluţiei cu pricina de către o nouă generaţie dornică de afirmare, fără ca aceasta să mai aibă sentimentul că ar participa de pe o poziţie inferioară într-un sistem de prestigiu existent.

Mecanismele renaşterii

Preluarea parţială a unei structuri culturale stabile într-o alta cultură nu duce la un rezultat stabil. Mai devreme sau mai târziu apar aceleaşi probleme care s-au întâlnit şi în cultura originală şi trebuie sa li se dea o rezolvare de regulă similară. Îndeobşte, prima soluţie adoptată este chiar cea `antică' dar deseori reîmpachetată sub o altă denumire şi prezentată ca o mare descoperire a momentului.

În Sfântul Imperiu Roman de Origine Germană nu s-a putut promite de către împărat o pace civilă poporului fără separarea acestuia de biserică şi nu s-a putut face asta fără separarea dreptului general de cel canonic---adică fără apariţia dreptului general---şi de aici a prezumţiei de nevinovăţie, a obligativităţii apărării, a încurajării opiniilor contrare şi cântăririi lor şi a întregii metode de explorare juridică din jurul codului iustinian. Generalizând, adoptarea formei: un împărat care promite populaţiei o stare civilă a deschis întreaga problemă a justiţiei, de aici a educaţiei şi ştiinţei de carte, etc.

Tot aşa, adoptarea unor aplicaţii minimale, single user, pe maşini PC, fără mari consideraţii de fiabilitate sau eficienţă, a dus la utilizarea lor extensivă, de aici la utilizarea în întreprinderi şi de aici la nevoia de fiabilitate şi eficienţă, la nevoia de a concentra aspectele mai dificile de administrare de sistem pe mai puţine maşini şi la apariţia configuraţiilor client-server, a reţelelor locale şi la generalizarea Internet-ului.

Când s-a produs acest fenomen, tot mai mulţi au redescoperit că simplitatea şi generalitatea design-ului sistemului de operare, eleganţa modelului de multiprocesare, disponibilitatea şi claritatea surselor programelor de sistem, continuitatea cu ce se predă în facultăţile de calculatoare, respectarea standardelor, eficienţa implementării, nu sunt nişte simple mofturi ale unor savanţi frustraţi ci calităţi subtile dar de fapt indispensabile, care se traduc direct în scăderea costurilor şi riscurilor. Şi că aceste probleme n-au apărut în istoria omenirii în 1990 ci prin anii '60, iar după multe căutări (gen multics sau gcos) s-au rezolvat mulţumitor prin inventarea sistemului de operare Unix. Cu această (re)descoperire s-a propagat şi adoptarea sistemului de operare Linux şi a unora din instrumentele şi aplicaţiile cu surse deschise.

Direcţii emergente ale renaşterii

Aceleaşi trăsături se pot identifica şi pentru tehnologii dezvoltate până în anii '80, cunoscute doar în cercuri restrânse, uneori chiar ridiculizate în cercuri semidocte, ceva mai largi, care rezolvă de fapt diverse probleme ce apar doar când devin evidente cerinţele de eficienţă, fiabilitate, portabilitate sau chiar estetică, sau alte cerinţe atât de subtile încât nu au un nume în vocabularul general. Unele din aceste tehnologii au devenit între timp populare, sau sunt evident în curs de expansiune, odată ce creşte în rândul consultanţilor densitatea celor care ajung să perceapă respectivele necesităţi subtile. Deseori, la probleme percepute ca noi (deşi, de fapt, cunoscute şi rezolvate de mult) se aşteaptă soluţii noi---şi atunci se `reîmpachetează' tehnologia mai veche sub o etichetă nouă pentru a accelera adoptarea ei.

Mai jos încercăm să enumerăm câteva dintre ele, începând cu cele mai larg adoptate deja. Toate tehnologiile prezentate au atins stadiul maturităţii depline şi al standardizării de cel puţin 10 ani şi au fost şi mai sunt folosite în aplicaţii masive, uneori gigantice, unele fiind la un moment dat, sau chiar actualmente, soluţiile unice sau cel puţin majore ale unor clase întregi de probleme. Toate sunt accesibile oricărui programator interesat cu costuri şi eforturi simbolice, de regulă liber, pe Internet. Dar, din nişte motive misterioase, în multe din facultăţile noastre de profil nici nu se pomeneşte de ele. Unele sisteme descrise mai jos sunt componente standard ale oricărei distribuţii de Linux şi mulţi utilizatori s-ar putea să le aibă de fapt deja instalate pe propriile PC-uri.

SGML

O problemă clasică a fost descrierea conţinutului şi structurii logice a documentelor, separat de elementele grafice ale aşezării în pagină, în scopul stocării şi regăsirii automate a documentelor în organizaţii mari cum este administraţia Statelor Unite. În acest scop au fost inventate o serie de limbaje de marcare care au culminat cu formularea SGML (standard generalised markup language) de către IBM, care s-a maturizat suficient pentru a fi adoptat de ISO în 1986. Acest limbaj este de o complexitate, generalitate şi impenetrabilitate legendară, dar nici măcar această legendă n-a depăşit nici astăzi lumea utilizatorilor tehnici din câteva guverne şi câteva edituri. Limbajul SGML rezolva însă, practic definitiv, problema standardizării reprezentării documentelor. [1]

Nici unul din `procesoarele de texte' larg folosite începând din anii '80 n-a adoptat măcar în parte soluţia definitivă menţionată, fiecare (WordStar, WordPerfect, Word for DOS, nenumaratele versiuni de Word for Windows, Ventura Publisher, Adobe Pagemaker, framemaker şi multe altele) implementând propriul ad-hoc, de regulă (şi poate intenţionat uneori) incompatibil cu toate celelalte. Utilizatorii, în cvasitotalitatea lor amatori, proaspeţi fani ai noilor pc-uri, au luat dificultăţile de interoperare ca naturale şi s-au descurcat cum au putut (de regulă, jalnic).

Problema interoperării a luat proporţii cu extinderea reţelei Internet, pentru că transmiterea de documente electronice s-a accelerat. O soluţie incipientă a fost formatul HTML, o aplicaţie de SGML. Separarea formei de conţinut nu a fost respectată riguros până la versiuni mai tardive de HTML şi introducerea limbajului CSS (pentru descrierea stilurilor). SGML-ul în (aproape) toată generalitatea lui a atins reala popularitate sub numele de XML abia prin anul 2000, iar ralierea procesoarelor de texte la standard nu s-a făcut nici în ziua de azi. Dar un standard pentru reprezentarea documentelor produse manual în SGML tocmai a fost totuşi finalizat (ODF). Unul dintre sistemele Office (OpenOffice) este în plină ofensivă pentru segmentul de piaţă tocmai pe baza acestei standardizări, a cărei raţiune începe în sfârşit să fie înţeleasă larg.

Documentaţia de linux este întreţinută cu un SGML numit docbook, iar instrumentele şi documentătiile necesare sunt componente standard ale oricărei distribuţii de linux.

Maşini virtuale, mainframe

Nevoia de a rula mai multe programe în paralel pe acelaşi procesor, sau mai multe fire (thread-uri) de execuţie în acelaşi program este o parte a nevoii de a partaja resursele aceluiaşi sistem între mai mulţi utilizatori sau între mai multe configuraţii (incluzând instanţe ale unor sisteme de operare potenţial diferite şi imagini diferite asupra perifericelor accesibile) pe acelaşi hardware.

Această partajare face ca o resursă ale cărei costuri şi accesibilitate (iniţiale sau de întreţinere) sunt mari să îşi poată găsi mai multe aplicaţii simultan. Pe acest drum, de la o maşină izolată cu un singur utilizator care lansează un singur program până la un sistem în care tot mai mulţi utilizatori să aibă impresia că dispun de maşini separate (în sensuri tot mai largi) a fost început cu primele calculatoare şi a continuat într-o istorie neîntreruptă a evoluţiei calculatoarelor mainframe şi continuă şi astăzi.

Aceeaşi evoluţie se întâlneşte şi la calculatoarele personale, de la maşini cu un procesor şi fără management de memorie până, astăzi, la noua modă cu maşinile virtuale (vmware, xen) şi cu server-ele de Linux virtuale închiriabile (vserver).

O problemă conexă, a cărei rezolvare pe scară largă este impusă de nevoile server-elor de reţea, este partajarea fiabilităţii unei instalaţii de server. La ce evenimente trebuie ne-am dori să reziste un server de reţea, fără nici o întrerupere? La o pană de curent de 1 secundă, de 1 oră sau de 1 săptămână, la defectarea unui ventilator, a unui harddisk, a unui procesor, la distrugerea printr-o catastrofă naturală a clădirii în care se află server-ul, la reconfigurarea unor utilitare, la upgrade-ul lor, la upgrade-ul sistemului de operare, la upgrade-ul hardware-ului? Toate aceste probleme s-au rezolvat de mult. Dar, din ce cerem o fiabilitate mai mare, din aceea costă mai mult şi devine tot mai necesar ca aceste costuri să se distribuie între mai multe aplicaţii ale aceleiaşi resurse, iar soluţia tehnică este maşina virtuală.

Tehnologia M (MUMPS, GT.M, VistA)

M este un sistem de gestiune a bazelor de date de string-uri şi un limbaj de programare specializat în prelucrarea acestor baze de date. A fost dezvoltat la MIT şi Massachusetts General Hospital în anii '60 pentru gestiunea datelor clinice ale pacienţilor şi a fost aplicat pe scară largă în reţeaua de spital `Veteranş Administration'. La un moment dat s-a decis administrativ înlocuirea sa prin alt sistem, dar schimbarea s-a dovedit imposibilă. Actualmente multe eforturi naţionale de standardizare a datelor despre pacienţi se bazează pe M.

O altă clasă largă de aplicaţii o constituie baze de date ale unor instituţii financiare (ING, Lloyd's). Aplicaţiile medicale ale Linux-ului par a fi aproape sinonime cu noua încarnare, open-source, a sistemului, numită VistA (vezi de exemplu [3])

`Calitatea sa subtilă' pare a fi potrivirea între modelul de reprezentare a datelor şi problema de rezolvat, dar ar putea avea şi alte calităţi care ţin de fiabilitate şi eficienţă.

Autorul, deşi medic, nu ştie foarte multe despre acest sistem, iar sintaxa sa îi cam displace; motivul pentru care este inclus aici este observaţia că VistA este adoptată tot mai larg la nivel global şi că este o tehnologie foarte veche, standardizată ISO de mult, şi care, pe undeva, a renăscut de două ori.

TeX

Spre deosebire de toate celelalte exemple, care au fost create în câteva decenii fiecare, una din `calităţile subtile' ale acestui sistem s-a distilat în experimente care au durat câteva secole: regulile de estetică ale textului tipărit. Forma tipografică trebuie, ideal, să fie un martor perfect din punct de vedere estetic, care să încânte percepţia subconştientă, dar tăcut, care să nu interfere în nici un fel cu conştientul cititorului pentru a nu-l abate de la firul lecturii.

Această calitate este în mod special dificil de obţinut în tipărirea formulelor matematice, chimice, a partiturilor şi altor reprezentări de specialitate.

Regulile esteticii tipografice făceau obiectul unor lucrări voluminoase şi puteau fi asimilate doar după o lungă ucenicie care presupunea diferenţierea şi dezvoltarea simţului estetic al viitorului tehnoredactor. Prin anii '70, un matematician, Donald Knuth, profesor de `arta programării calculatoarelor' la Stanford s-a însărcinat cu codificarea acestor reguli într-un program de calculator, cu scopul iniţial de a realiza stocarea electronică a textelor de matematică şi în special arhiva Societăţii Americane de Matematică (sponsorul proiectului).

TeX a avut (şi a rezolvat) o serie de cerinţe care i-au conferit printr-o combinaţie de efecte diverse `calităţi subtile':

• pentru a-şi îndeplini funcţia de arhivare, acelaşi fişier sursă trebuie să producă exact acelaşi rezultat grafic pe orice combinaţie calculator/dispozitiv grafic (sau imprimantă), existentă la data scrierii sau oricând în viitor; nu numai în principiu, dar TeX trebuia să fie efectiv portabil şi portat pe orice maşină/imprimantă existentă sau viitoare;
• autorii nu trebuie să ştie mai nimic despre regulile estetice menţionate ci doar sintaxa limbajului (uneori destul de simplă, un text alfanumeric terminat cu '\end' este de exemplu un 'program' TeX corect care se tipăreşte sub forma unui document de calitate) toate aspectele de formă tipografică specifice documentului trebuind sau asigurate de sistem sau introduse într-un fişier separat de un tehnoredactor; această calitate trebuia păstrată la niveluri multiple de competenţă estetică şi TeXistică ale unei posibile ierarhii de tehnoredactori;
• trebuia să fie posibilă reprezentarea estetică a oricărei scrieri, alfabetice, silabice, ideografice sau schematice, dispărute, curente sau care avea să fie inventată într-un viitor rezonabil;
• trebuia să fie facilă generarea conţinutului, sau unei părţi a conţinutului documentelor în mod automat (de exemplu, în sensul sistemului Sweave [4]).

La aceste cerinţe s-au adăugat cerinţe personale ale autorului, cum ar fi o anumită cvasiperfecţiune a programului şi documentaţiei, astfel încât programul să ilustreze--pentru uzul studenţilor--fezabilitatea scrierii unui program care rezolvă o problemă reală şi este în acelaşti timp perfect din punct de vedere ingineresc. Indirect, această cerinţă este legată de cea de portabilitate în timp şi spaţiu, pentru că dacă programul ar avea erori ar avea şi versiuni multiple iar textele n-ar mai fi portabile. Cvasiperfecţiunea programului este demonstrată prin concordanţa între implementare şi manualul de utilizare (desigur, elaborate separat) şi prin oferirea unui premiu pentru orice divergenţă raportată autorului. În realitate s-au descoperit mici discordanţe, foarte ezoterice, o dată la câţiva ani, şi sistemul are versiuni succesive dar diferenţele între ele sunt chiar neglijabile şi pentru a exprima această dispariţie asimptotică a erorilor, versiunile sunt numerotate prin siruri tot mai lungi de zecimale ale numărului π, convergând spre acest număr.

Sistemul TeX nu a fost standardizat oficial pentru că nu era nimic de standardizat: există practic o singură sursă şi un singur manual care sunt la fel de valabile şi funcţionează identic pe toate tipurile şi combinaţiile de hardware.

TeX a fost adoptat rapid pentru tipărirea şi arhivarea documentelor tehnice, în special din matematică şi fizică, de cele mai multe organizaţii de profil, cum ar fi Asociaţia Americană de Matematică, Societatea Americană de Fizică, IEEE, IEE, ACM, arxiv, cvasitotalitatea editurilor de publicaţii tehnice şi ştiinţifice şi de firme ca HP şi IBM. Utilizarea lui este in creştere, mai ales recent; de exemplu numărul de hit-uri la una din arhive a crescut cu 60\% între aprilie 2005 şi aprilie 2006 [5].

Asta nu l-a împiedicat pe un amic, mare specialist în Linux, să exclame mai deunăzi într-un e-mail: `sublimul (La)Tex e inaccesibil/inutil pentru 99.995% din userii de computere (putem constata asta si statistic)'. Ţinând cont că în majoritatea ţărilor dezvoltate, în care mai toată populaţia activă este ă din utilizatori de calculatoare, proporţia celor cu studii superioare şi angajaţi în cercetare ştiinţifică e cam de 3\%, cam jumătate activând în inginerie şi ştiinţe cantitative, dar şi de utilizarea de către studenţi şi practicieni, probabil că o estimare mai realistă a proporţiei nesemnificativilor utilizatori de TeX este între 1 şi 5% din toţi utilizatorii.

Totuşi, este un sistem în mare parte necunoscut publicului. Şi s-ar putea să rămână aşa, dar în acelaşi timp majoritatea populaţiei să înceapă să-l folosească fără să ştie, deoarece formează o combinaţie excelentă ca motor de tipografie pentru documente sau date SGML (ale cărui reîncarnări devin rapid modul preferat de stocare a documentelor, chiar daca acronimul e în general necunoscut).

O astfel de combinaţie este folosită în distribuţiile de Linux. TeX este sistemul de typesetting standard, toată documentaţia de Linux fiind pusă în forma tipărită în TeX, dar reprezentarea sursă fiind docbook-sgml.

APL (notaţia Iverson, J, S, Splus, R)

APL este un limbaj de programare care excelează în operatori matriciali şi în conciziunea cu care se pot exprima prelucrări complexe ale unor seturi de date. Din el a fost inspirat un limbaj de prelucrare statistică a datelor numit S, dezvoltat prin anii '70 la Bell Laboratories. S a combinat o sintaxa mai familiară, asemănătoare C-ului, cu operatori matriciali şi cu proceduri statistice şi grafice.

Cea mai mare parte a cercetării în institutele şi facultăţile de profil s-a făcut în acest limbaj, aşa încât s-au făcut biblioteci cu aproape toate metodele statistice cunoscute, implementarea în S precedând de regulă alte implementări. Dezvoltarea lui a fost preluată de o firmă privata, dar din 1988 o echipă din lumea statisticii academice a dezvoltat o versiune free, numită R, care este un frontend S cu un backend Scheme. Acest proiect s-a dezvoltat spectaculos, acoperă azi practic `toată' statistica şi a înglobat şi echipele altor proiecte cu surse deschise `concurente' aşa încât azi nu mai are practic decât concurenţi comerciali. R ar putea reprezenta punctul de convergenţă al statisticii computaţionale pentru multă vreme de-acum înainte.

Sistemul R este inclus în toate distribuţiile Linux de uz general.

Lisp

Limbajele de programare se distribuie, după intenţia proiectantului lor, între două extreme: limbaje apropiate de maşină şi limbaje apropiate de gândirea omenească. În afara limbajului de asamblare, toate celelalte sunt limbaje care fac o concesie familiarităţii pentru programatorul uman, eventual în dauna eficienţei sau simplităţii compilatorului.

La celălaltă extremă se găseşte Lisp, un limbaj care la origine (în anii '50) a fost o simplă notaţie pentru care nu se intenţiona o implementare. Limbajul Lisp este o reprezentare formalizată, foarte abstractă, a gândirii omeneşti despre date, numere, tipuri, algoritmi, funcţii, simboluri, metode şi agregate ale acestora. Într-o formulare suficient de abstractă de fapt toate aceste elemente se reprezintă până la urmă prin acelaşi fel de structuri.

Evident, această reprezentare ar fi interesantă dar, cel puţin în implementarea directă, deosebit de ineficientă. Este mai subtil evident că o reprezentare cu suficientă putere de expresie, ale cărei consecinţe sunt explorate suficient de departe, poate realiza şi traducerea (compilarea) unor astfel de reprezentări în programe maşină la fel de eficiente cu cele scrise direct în cod, programatorul nefăcând altceva atunci când programează decât să traducă astfel de reprezentări într-un limbaj apropiat de maşină, manipulându-le ca pe nişte date. Oricărui cititor avizat ar trebui însă să-i fie evident că scrierea unui asemenea compilator trebuie să fie un proiect gigantic, poate posibil doar în teorie.

În realitate însă, un astfel de compilator este posibil practic şi s-a scris. Este adevărat că durat aproape o jumătate de secol, este adevărat că din credinţa imposibilităţii lui practice s-a născut o întreaga industrie (a maşinilor Lisp) care ulterior a dispărut, şi este adevărat că toată povestea e neverosimilă. Dar este tot aşa de adevărat că este reală şi că un program Lisp echivalent cu un program Fortran va fi compilat, dacă este scris corect, la fel de eficient de compilatorul de Lisp, de exemplu de cmucl, ca şi de cel de Fortran [8].

Lisp-ul este un limbaj atât de general încât interpretoare sau compilatoare ale tuturor limbajelor se pot redefini în Lisp prin programe relativ triviale, chiar dacă uneori voluminoase, făcându-le---dincolo de considerente practice de moment---inutile pentru clase largi de probleme. Mediul de programare Lisp are nevoie de zeci de Mb de memorie şi de procesoare de o viteză decentă (măcar de ordinul a 1 GHz), dar aceste cerinţe au fost îndeplinite de curând pe scară largă.

Clase importante de mecanisme de expresie în lisp, cum ar fi macro-urile structurale [9]

Standardul de Lisp, adoptat de ANSI şi ISO în anii '80 poartă numele de CommonLisp, un limbaj extensiv care tratează ca esenţială compilabilitatea eficientă. Un alt standard (adoptat de IEEE) priveşte un dialect reducţionist de Lisp, numit Scheme.

În special în forma reducţionistă, Lisp-ul este un instrument minunat pentru formarea unei minţi deschise şi armonioase în chestiuni de programare. Din această cauză este folosit ca prim limbaj de programare pentru novici în multe universităţi de vârf, începând cu M.I.T. [6].

Prin acest proces şi prin calităţile intrinseci ale limbajului, mulţi specialişti (printre care R. Stallman şi P. Graham) prezic în viitorul apropiat înlocuirea cvasitotalităţii celorlalte limbaje, în special cele de scripting, cu Lisp. Guile, de exemplu, este un proiect care urmăreşte în mod specific unificarea limbajelor de scripting cu Scheme. Este adevărat că această profeţie nu se poate împlini complet decât în aproximativ două generaţii profesionale (până când generaţiile care au pornit în programare cu Pascal sau Java, şi mai ales nefericiţii care au descoperit programarea prin Basic, vor ieşi la pensie) dar este indiscutabil că anvergura aplicaţiilor Lisp este în creştere.

O categorie de limbaje care nu vor putea fi însă înlocuite de Lisp sunt cele de timp real, descrise mai jos.

O primă expansiune a infrastructurii limbajului a fost apariţia şi propagarea maşinilor virtuale interpretate gen Java Virtual Machine, care împrumută mecanisme mai simple ale maşinii Lisp.

Între limbajele în care sunt scrise sursele unei distribuţii standard de Linux, Lisp ocupă locul 4 ca număr de linii de program (după C, C++ şi Shell). Distribuţiile de Linux de uz general vin de regulă cu doua sau trei medii complete de CommonLisp (gcl, cmucl, clisp), cu multiple versiuni generale de scheme (guile, scm, rscheme) şi cu mai multe dialecte de Lisp ca limbaje de extensie ale unor utilitare (gimp, emacs, R).

Ada şi VHDL

Pentru o clasă importantă de programe ciclul editare-compilare-testare nu funcţionează, în sensul că testarea în condiţii reale este imposibilă. Un exemplu extrem este o navă spaţială: nu se poate testa direct faptul că programul care o controlează va funcţiona conform cerinţelor în condiţiile reale. La fel pentru un element de muniţie (cu software incorporat) şi la fel pentru orice software care urmează să funcţioneze în condiţii despre care putem simula un scenariu pe care ni-l imaginăm noi, dar pe care nu le putem descrie în întregime. Şi la fel pentru un design de circuit integrat, despre care nu se ştie sigur dacă va funcţiona decât după ce va trece faza costisitoare a producţiei.

La o examinare mai atentă, această dificultate de a testa se întâlneşte de fapt în tot mai multe sisteme software şi în special în aplicaţii de reţea care rulează multiple fire de execuţie---de exemplu, câte unul pentru fiecare utilizator---fire care interacţionează între ele. La extrema cealaltă se găsesc programe `batch', cu intrări de date simple şi complet cunoscute, care se execută determinist.

În programele multithreaded apare o clasă de erori care nu se pot reproduce prin testare pentru că este implicată secvenţa de execuţie a thread-urilor, aşa cum s-a întâmplat să se producă sub acţiunea evenimentelor exterioare.

Problema este atât de severă încât schema actuală general acceptată pentru abordarea ei o ocoleşte fără ca măcar s-o menţioneze. Această schemă (numită şi LAMP adică Linux Apache MySQL Perl/PHP/Python) separă problema firelor de execuţie care interacţionează în motorul de baze de date (MySQL), în Apache şi în Linux, programe cu o definiţie relativ fixă, la care s-a ajuns in zeci de ani şi testate de milioane de utilizatori, programatorul scriind de fapt componente care pot fi considerate programe (script-uri) batch.

Dar forţarea aplicaţiilor în această schemă impune distorsiuni, ineficienţe şi complicaţii care sunt tot mai problematice pe măsură ce dorim mai multă funcţionalitate/performanţă de la aplicaţia de web respectivă.

Din această cauză soluţia problemei generale de a putea prezice că programul va funcţiona, fără să fie posibilă testarea lui propriuzisă, ar putea să devină tot mai relevantă.

Limbajele, oarecum înrudite, Ada şi VHDL au fost proiectate anume ca să asigure că dacă un program se compilează este foarte probabil ca el să şi funcţioneze. Limbajul Ada a fost impus de criticitatea aplicaţiilor aerospaţiale şi militare descrise la început, este standardizat MIL (din 1983) şi ISO (din 1995) şi cu ajutorul său este scris software-ul de control din majoritatea sistemelor de armament şi avionică moderne. Nu este aici locul să povestim cum s-a atins această `calitate ascunsă', dar în parte programele se scriu cu un fel de redundanţe care, în caz că se fac erori de scriere, vor permite compilatorului să le detecteze înainte să se ajungă la execuţie---cumva tot aşa cum concordanţa între cod şi documentaţie, produse separat, a asigurat lipsa de erori a programului TeX.

Compilatorul de referinţă al standardului ISO curent, Ada-95, cu toate extensiile existente şi propuse este parte din GCC. Sintaxa sau structura limbajului se regăseşte în alte limbaje, unele experimentale (Eiffel, AdaScript) altele de producţie şi larg utilizate (VHDL, PL/SQL).

Sisteme cu microkernel

Aceste sisteme nu sunt descrise aici pentru că evoluţia, starea şi motivele pentru care, în condiţiile unei conştientizări tot mai largi a importanţei fiabilităţii şi eficienţei, vor avea o importanţă tot mai mare sunt expuse în altă parte mai bine decât aş putea-o face eu.

COBOL

Limbajului COBOL, standardizat din anii '60, trebuie să-i recunoaştem o calitate subtilă, dar unică: programele pot fi scrise doar de programatori, dar pot fi citite de oricine, şi în special de orice contabil care trebuie să răspundă pentru validitatea rezultatelor. Pentru un motiv neclar, această nevoie de validare directă a programelor de contabilitate nu este încă percepută de profesia respectivă în ansamblul ei, profesie care se împacă deocamdată cu nenumăratele probleme cauzate de imposibilitatea controlului rezultatelor. Dificultatea, ce-i drept, nu survine decât la aplicaţiile contabile complexe (care în bună parte sunt deja scrise în COBOL) nu şi la cele care încap într-un spreadsheet.

Dacă această calitate specială va reapărea, şi dacă sistemul în care o să reapară o să se numească tot COBOL sau o să semenea foarte mult cu COBOL-ul vom vedea.

FORTRAN

Trăiască, în veci, FORTRAN! [2]

Bibliografie

1. A History of Markup Languages
2. Real programmers don't use Pascal
3. Linux Med News
4. Sweave
5. The UK TeX Archive. Usage statistics
6. Structure and interpretation of computer programs
7. Counting Source Lines of Code (SLOC)
8. Programming language benchmark
9. Lisp. Paul Graham