Nu mica mi-a fost mirarea când am citit un articol în care Nicholas Negroponte critica vehement orientarea universitatilor americane spre cercetari aplicative foarte apropiate de mainstream, de piata. Justificarea ca în felul acesta se obtin bani frumosi nu avea nici o greutate în ochii celebrului analist (fondatorul si directorul laboratoarelor Media Labs de la MIT). Lumea academica, în viziunea sa, ar trebui sa pluteasca într-o lume f erita de mizeriile comertului, pentru ca doar acolo se pot naste marile idei capabile sa duca tehnologia mai departe, ideile „traznite“, dar revolutionare, în care nici o companie comerciala n-ar investi nici macar cinci centi...
E interesant de urmarit, din aceasta perspectiva, de unde vin marile idei în lumea informaticii si cam ce traseu urmeaza ele în drumul spre afirmare. Cu siguranta fiecare dintre dumneavoastra poate sa analizeze, retrospectiv, cel putin câteva tehnologii care astazi sunt larg acceptate (daca nu chiar unanim...). Ma voi aventura si eu pe acest teren, marginindu-ma însa doar la domeniul software (cu riscul obiectiilor – îndreptatite de altfel – ca softul nu a evoluat chiar de capul lui, fiind influentat de hardware, comunicatii, etc.).
O prima constatare este ca o multime de tehnologii au pornit din centrele de cercetare ale unor mari companii, iar exemplul notoriu la care ma voi opri putin va fi Xerox PARC ( Palo Alto Research Center). Acronimele GUI si OO va spun ceva? Daca da, atunci sa le punem cap la cap si obtinem Smalltalk. De ce am ales aceasta cale si nu am mers pe linii separate? Interfetele grafice au fost aduse în lumea comerciala de Apple (Steve Jobs e un nume care trebu ie pomenit) si au ajuns pe calculatoarele dvs. prin Microsoft. Programarea orientata pe obiecte a urmat un drum mai întortocheat, dar astazi pentru cei mai multi dintre noi ea înseamna C++, de unde imediat ajungem la Visual C++, Microsoft. Preluarea unei idei de catre Microsoft pare sa însemne consacrarea ei ca loc comun.
Smalltalk este un caz mai special. Cu toate ca se apreciaza ca se afla în spatele a 15-20% dintre aplicatiile comerciale client/server dezvoltate în tehnologie OO, Smalltalk nu si-a spus înca ultimul cuvânt (ca dovada înca nu exista un MS Smalltalk). A l ansat însa câteva idei care vor marca cu siguranta viitorul proiectarii de software. Una dintre ele este notiunea de framework. De aici o alta idee conexa: un limbaj nu e totul.
În urma cu vreo câtiva ani (înainte ca termenul visual sa apara în fata tuturor numelor de medii de dezvoltare) am vazut o caseta video în care un proiectant de la Next prezenta modul de dezvoltare a unei aplicatii (o aplicatie clasica, cu baze de date, machete de culegere, rapoarte, etc.) pe o masina Next r ulând sistemul de operare NextStep. Se dezvolta vizual, pe baza de obiecte, într-un framework. O paranteza pentru cei care cred ca singurul limbaj pentru profesionisti este C++: NextStep a fost scris în Objective-C. O parte din munca de pionierat dusa la Next (înca o data amintesc numele lui Steve Jobs) este deja valorificata în mediile de dezvoltare curente. Insist sa cred ca PC-urile viitorului vor semana mult cu raposatele calculatoare Next.
Profesorul Niklaus Wirth este cunoscut mai ales ca inventator al limbajului Pascal. În vremea când eram student, Pascal si C îsi disputau înca întâietatea, dar între timp lucrurile s-au asezat: C a învins în lumea programatorilor profesionisti, în timp c e Pascal a ramas instrumentul didactic predilect al profesorilor de programare (ultima reduta a Pascal-ului în lumea comerciala, Delphi, a schimbat macazul spre C++). Cu toate acestea, în backgound, Pascal a jucat un rol mai important decât se crede. La ETH Zürich (Institutul Federal Elvetian pentru Tehnologie – un acronim important în cele ce urmeaza), echipa lui Wirth a realizat un compilator Pascal care producea un cod intermediar ( P-Code), ceea ce nu numai ca a permis portarea foarte rapida a limbajului pe diferite platforme, dar mai ales a sugerat o idee care va deveni peste douazeci de ani extrem de importanta: aplicatii independente de platforma. Ca sa fiu mai explicit: nu se urmarea portabilitatea codului sursa (atât de mult urmarita de C) ci a unui cod pre-compilat, care necesita pe platforma tinta doar un interpretor specific. Suna cunoscut, nu-i asa? Aceasta idee este preluata de University of California din San Diego, care impl ementeaza un astfel de compilator pe un Apple II, cu interpretoare pe mainframes.
Dar, influentat de efervescenta creatoare de la Xerox PARC, Wirth merge înainte si reeaza Modula-2 (în care apare ideea mo-dularitatii si extensibilitatii), fiind apoi implicat într-un alt proiect de la Xerox PARC, numit Cedar. Acesta era un limbaj derivat din Pascal si Modula-2 , dar care prelua arhitectura din Smalltalk (fiind totodata si un sistem de operare). Rezultatul a fost spectaculos, dar prea co mplex pentru gusturile lui Wirth (deviza sa este un celebru îndemn al lui Einstein: Make it as simple as possible, but not simpler).
În 1985, Wirth porneste la ETH un proiect nou: un sistem de operare pentru statiile de lucru Ceres. În acest scop defineste un limbaj nou, mai simplu decât Pascal, modular si cu extensii obiectuale. Numele sau, Oberon, este preluat si de sistemul de ope rare. Întreaga constructie, de o eleganta inegalabila (cred eu), are ca scop extensibilitatea, fiind orientata pe componente. Abia zece ani mai târziu componentele vor veni în actualitatea industriei de software. Despre Oberon am scris mai multe articole, asa ca nu voi insista asupra caracteristicilor sale (vezi OPEN-TI 2/94 si BYTE România 3/96, sau pe Web: http://www.agora.ro/open/open2/oberon.html si http://www.agora.ro/byte/byte96-03/mir.html).
Între timp, Oberon a fost portat pe diferite platforme si cunoscut mai multe versiuni (ultima este System 3), bucurându-se de o popularitate crescânda în lumea academica. La un moment dat însa (prin 1992) apar procesoarele PowerPC, astfel încât ETH a fos t pus în situatia de a întretine doua versiuni pentru Macintosh: una pentru procesoare Motorola 68020 si una pentru PowerPC. Atunci apare una dintre acele idei „traznite“ si revolutionare la care poate se referea Negroponte în articolul sau. Datorita arh itecturii modulare a sistemului Oberon, cu încarcare dinamica a componentelor, s-ar putea realiza o distributie unica. Codul intermediar nu va fi însa interpretat, ca în vechea solutie multiplatforma pentru Pascal, ci va fi compilat la momentul încarcari i („on the fly“ sau „just in time“ cum se spune astazi). Ar urma deci ca fiecare distributie sa constea dintr-un nucleu în cod nativ (cuprinzând functii de administrare a memoriei, acces la fisiere si încarcare dinamica), un compilator on-the-fly specific procesorului, restul codului fiind unic. Având în vedere arhitectura diferita a procesoarelor tinta (CISC si RISC), codul intermediar nu poate fi un „cod masina generic“ (din motive de performanta), ci un cod care sa poarte cu el structura prog ramului. Aceasta reprezentare intermediara, numita Slim Binary , dezvoltata de Michael Franz la University of California at Irvine, a condus la realizarea unei distributii unice pentru MacOberon de doar 0,8 MB, la care se adauga codul nativ pentru 680x0 (0,6 MB) si cel pentru PowerPC (0,7 MB), fata de doua distribut ii a câte 0,5 + 2,2 MB (680x0) si respectiv 0,6 + 2,7 MB (PowerPC). MacOberon a devenit astfel prima aplicatie care ruleaza în cod nativ pe ambele familii de procesoare utilizate de Macintosh. A urmat o implementare asemanatoare pentru procesoarele Intel , care utilizeaza exact acelasi Slim Binary ca si versiunile pentru Mac. Detalii si articole tehnice la http://www.ics.uci.edu/~oberon/research.html.
Sa iesim putin din universul cercetarii si sa aruncam o privire asupra prezentului lumii comerciale. Industria de software trece printr-o criza pe care astazi nimeni nu o mai neaga. Schimbarile rapide ale tehnologiilor hardware, diversificarea continua a platformelor si esuarea tentativelor de a impune standarde în software au pus în fata proiectantilor de software nivele suplimentare de complexitate. Astfel încât, în ciuda instrumentelor de dezvoltare tot mai sofisticate (prea sofisticate...), producti vitatea proiectantilor de software a scazut cu aproape 15% fata de nivelul anului 1993 (nu cumva e anul în care s-a impus Windows 3.1?).
Un fenomen paralel este „explozia“ Internet. Dupa ce a cucerit lumea ca mediu de informare, Web-ul a reusit sa impuna standarde, deoarece nevoia de a vedea Reteaua si de a fi vazut din Retea a devenit vitala indiferent de platforma folosita. Web-ul ti nde sa se impuna ca platforma de calcul iar adoptarea tehnologiilor sale si în retele private (intranet) accentueaza aceasta tendinta.
În aceste conditii, doua sunt sperantele industriei de software: componentele software si limbajul Java.
Componentele software sunt esentiale pentru a putea stapâni complexitatea de-a dreptul monstruoasa a aplicatiilor actuale. S-au obtinut deja succese marunte (diverse plug-ins, controale vizuale de gen VBX, etc.) dar eforturile de a stabili niste standarde minimale necesare pentru interoperativitatea componentelor esueaza mereu.
Java pare sa fie marea speranta a industriei de software. Faptul ca este independent de platforma este, deocamdata, cel mai mare atu al limbajului, ceea ce îl recomanda pentru appleturi Web. În schimb, performanta este punctul nevralgic. O alta lipsa est e absenta unui fundament pentru componente (JavaBeans vine oarecum sa se aseze „deasupra“ limbajului).
Oberon versus Java? Este o batalie inegala: un proiect academic împotriva unui proiect comercial sustinut de un colos de talia firmei Sun. Cu toate acestea, ar fi de remarcat câteva aspecte:
Acum, o scurta comparatie între Java si Oberon nu este lipsita de relevanta. În primul rând, o astfel comparatie readuce în discutie vechea întrebare: C sau Pascal? Dar, dincolo de aceasta problema de suprafata, cele doua limbaje prezinta multe similitud ini: ambele sunt orientate pe obiecte, ambele impun o tipizare stricta, ambele exclud aritmetica pointerilor si ruleaza în medii de executie cu colectare automata a memoriei reziduale, ambele dispun de o anume forma de modularitate.
Juice este pentru limbajul Oberon cea ce este JVM ( Java Virtual Machine) pentru limbajul Java. De unde provine totusi diferenta semnificativa de viteza? Explicatia este destul de simpla: din formatul codului binar portabil. Codul binar produs de Java, numit bytecode, este un fel de cod masina destinat unui procesor (real sau simulat prin software). Acest cod este fie interpretat, fie este compilat pentru platforma concreta la momentul încarcarii (Just-In-Time). Fiind în esenta un cod masina, asupra lui nu se po t aplica multe dintre optimizarile de performanta cum ar fi cele inter-modulare, cele de paralelizare a codului sau global trace scheduling. Codul binar portabil pentru Juice (Slim Binary) este bazat pe arbori sintactici abstracti ( abstract syntax trees) care aduc cu ei întreaga informatie din codul sursa, necesara pentru optimizarile avansate din procesul compilarii.
Cercetarile pe care se bazeaza Juice au început în 1989 iar prima utilizare a „binarelor suple“ dateaza din 1993. Lucrarea de doctorat a lui Michael Franz, care face publica tehnologia Juice („ s“) dateaza din 1994. Adica cu un an si jumatate înainte de nasterea limbajului Java.
Asadar: cafea sau suc? Cred ca mai degraba amândoua.
Dl. Mircea Sârbu este director editorial la Computer Press Agora. Poate fi contactat prin e-mail la : .