Acum mai bine de zece ani lucrurile păreau destul de clare în programare. Orice programator serios lucra în C sau un derivat al lui, cel mai probabil C++, eventual Java. Restul, mai ales cei care foloseau limbaje interpretate, precum Basic sau php pentru încă proaspătul fenomen web erau priviţi ca “amatori”.
Lucrurile au început să se complice prima dată atunci când cererea de aplicaţii web a devenit predominantă. Era vremea când Microsoft lansa .net pentru a putea ocupa o piaţă unde Java părea singura tehnologie posibilă. Şi s-au complicat şi mai rău atunci când jucătorii mari, începând cu Google, au hotărât să transforme industria de hosting într-un fel de hypermarket care să ofere tot ce o companie şi-ar dori ( şi să închidă “buticurile” numite datacentere pe care orice firmă medie le întreţine )
Dincolo de discuţia dacă această strategie e câştigătoare sau nu ( şi unde probabil răspunsul nu va fi nici nu şi nici da, ci “depinde” ) noul curent a descoperit iute că avem nevoie de limbaje noi, de tehnologii şi abordări noi. Pur şi simplu tehnologia momentului nu era potrivită scopului propus.
Mai întâi tehnologia web era incredibil de limitată comparativ cu cea desktop. Modul de lucru client-server era exact ceea ce îi spune numele: browserul întreabă, serverul răspunde. Nu este propriu-zis un canal bidirecţional, în tot cazul nu e sincron.
Pe de altă parte, mutarea serviciilor la provider înseamnă folosirea de altfel de servere. La tehnologia actuală, un singur server low end, destinat în general clienţilor mici, s-ar putea să facă faţă aproape oricărei aplicaţii “enterprise” pentru o companie medie sau chiar mare. Dar în “cloud” lucrurile stau altfel ( IBM a lansat anul ăsta un nou mainframe, după o pauză de câţiva ani) . Ori lucrul pe servere cu multe “core”-uri în condiţiile de folosire judicioasă a resurselor , cere tehnologie specifică. În plus, aplicaţile trebuie să poată fi mutate cu uşurinţă de pe o maşină pe alta, dintr-un datacenter în altul, în mod absolut transparent. Acest lucru cere tool-uri specifice, care trebuie să poată fi dezvoltate, şi mai ales sincronizate mereu, pentru că timpul este un adversar din mai multe puncte de vedere: timpul necesar dezvoltării, timpul necesar sincronizării aplicaţiilor, timpul necesar deployment-ului…. şi dincolo de toate, ceea ce îl interesează pe client, timpul de răspuns. Ceea ce noi rezolvăm de obicei cu un script s-ar putea să nu fie destul de bun într-un loc unde vorbim de mii de maşini sau de milioane de “containere”.
Aşa tehnologiile web au ajuns un amestec de limbaje şi tehnologii vechi, noi şi vechi dar modernizate. Bătrânele JavaScript-uri, jucării parte şi ele pe vremuri în “războiul browserelor” ( niciodată interpretorul Internet Explorer nu era compatibil cu cel Netscape/Mozilla ) au trebuit extinse, refăcute, mai mult sau mai puţin standardizate pentru a deveni o componentă esenţială în aplicaţiile actuale.
În zona web, limbajele interpretate par a fi câştigat războiul contra celor compilate. ( deşi lucrurile sunt relative, pentru că “server side” putem avea orice) . Cel puţin pe partea de client ele au cel putin avantajul de a putea fi actualizate transparent, iar problema puterii de calcul nu prea se mai pune.
În cealaltă zonă, a managementului, lucrurile sunt mai delicate. Acolo performanţele chiar contează, e nevoie de aplicaţii simple, robuste şi rapide. Acolo e zona în care Google a dezvoltat go, o extensie a ideilor din C .
O trasatură comună a noilor tehnologii pare a fi capacitatea de actualizare automată. Ele nu numai că sunt pentru web, dar “trăiesc” în web: într-un fel sau altul, mare parte din bibliotecile lor sunt stocate undeva într-un repository disponibil web. Abordarea diferă, dar într-un fel sau altul fiecare accesează acest “repository” cumva: fie o dată, pentru a descărca bibliotecile, fie la fiecare folosire (folosind bineînţeles şi mecanismul de “cache” pentru a îmbunătăţi viteza)
Ori, aceste repository-uri se schimbă şi se updatează mereu. Deocamdată nu ştim ce se va întâmpla, dar probabil că la un moment dat vom ajunge la un nou turn Babel al bibliotecilor, aşa cum programarea clasică, de desktop, a ajuns la cel al bibliotecilor dinamice, la vremea respectivă. Greu de spus cum se va remedia, dar am încă în faţa ochilor un tabel Excel pe care ni-l dăduse un trainer de la Fujitsu, cu lista de aplicaţii de management pentru servere şi versiunea de Java pe care funcţionează. Probabil în versiunea 2.0, tabelul Excel va fi disponibil şi el pe github.
Aikido cu mintea si corpul coordonate. Invatati cum sa va relaxati si cum sa va pastrati calmul in conditii de stress. 
Practic, calculatoarele noastre personale vor deveni simple statii de vizualizare a datelor si informatiilor stocate in data center-uri imense, in care securitatea si volumul informatiei vor fi cele mai importante aspecte.
Imi pare rau, dar articolul e greu de urmarit si de inteles chiar si de cei care lucreaza in domeniu si cunosc cum stau lucrurile, iar unele afirmatii sunt chiar uluitoare, de exemplu cea cu limbajele interpretate care au castigat razboiul cu cele compilate … in browser (pentru ca server-side chiar spuneti ca poate fi orice).
Puteti da exemple concrete de librarii despre care vorbiti si care e relevanta lor pentru cei care nu se ocupa de managementul unui data center? Pentru majoritatea oamenilor din IT problema nu exista pentru ca nu se intalnesc cu ea vreodata.
Daca articolul e greu de urmarit este probabil vina mea. ( daca nu stii sa explici clar inseamna ca nu cunosti destul de bine subiectul :) )
In ceea ce priveste librariile, primul exempu este chiar cel dat de mine, cu Java: rare sunt aplicatiile care merg pe orice versiune de Java ( si nici cu .Net nu imi e rusine). De fapt chiar ideea articolului a pornit de la faptul ca ma luptam cu ceva aplicatii de instalat in Ruby on Rails care, evident, necesitau biblioteci cu versiuni mutual exclusive ( dupa cum probabil stiti, sistemul este ca aplicatiile sa isi descarce „gems”-urile de pe net. Dar problemele astea sunt la fel de vechi ca Visual Basic-ul, aproape toate programelele veneau inca de atunci cu „dll-ul” lor (adica versiunea pentru care au fost scrise) . In programarea web, imi cam pastrez parerea, aplicatiile interpretate ( node.js, php, ruby, python etc etc) tind sa castige batalia.
Cred ca de fapt va referiti la (ne)seriozitatea unor dezvoltatori de aplicatii si limbaje de programare. PHP e gratuit, dar incompatibil de la o versiune la alta, pentru Ruby ati dat deja exemplul potrivit, problemele de compatibilitate cu Java sunt bine stiute. Cu Visual Basic singurele probleme de care stiu erau versiuni diferite de DLL decat „astepta” aplicatia sa aibe pentru ca fiecare aplicatie venea cu DLL-uri proprii care le suprascriau pe cele existente, astfel in functie de ordinea instalarii se putea ajunge ca versiunea curenta sa fie cea mai veche.
In schimb nu am auzit de un asemenea iad in limbaje suportate de companii serioase, gen Borland (da, nu mai este relevanta dar a fost), Microsoft (.NET are versiuni care coexista pasnic pe acelasi computer si fiecare aplicatie e compilata pentru versiunea dorita; am mentionat ca este compilata?) sau SAP (ABAP e folosit la greu in companiile mari, mai mult decat Java). Pentru ca iadul e creat in mare parte de jungla de aplicatii facute mai mult sau mai putin responsabil de dezvoltatori care au un interes limitat de a oferi suport complet sau de a mentine actuala aplicatia lor; sunt foarte multi binevoitori care publica gratuit o aplicatie, dezvoltatorii incep sa o foloseasca si intre timp autorul original se apuca de altceva si abandoneaza aplicatia. Se ajunge la un ecosistem compus din franturi de componente mai mult sau mai putin functionale, finisate, suportate si actuale – cred ca in mare parte e vina celor care folosesc acest zoo al IT-ului si nu a autorilor binevoitori care publica acele componente de obicei sub forma „take it as it is, if you don’t like it chose something else”.
Multumesc pentru completari, sunt cu adevarat binevenite. Eu nu vreau sa dau vina pe nimeni, cred ca asta este situatia; nici nu mi se pare foarte normal sa am si sa folosesc trei versiuni de .Net simultan ( asa pot folosi si sapte versiuni de ruby sau de Java simultan, dar nu e normal ). E si expresia unui nou stil de lucru, pe care (honni soit qui mal y pense) l-as numi „copy-paste”. Tendinta e de a construi totul din „prefabricate”, fie ca se potrivesc fie ca nu. Din cauza asta „prefabricatele” tind sa devina cat mai stufoase ( ca sa acopere toate cazurile) iar programele le folosesc in exces. Evident ca ulterior se dovedeste ca biblioteca nu e destul de completa, se mai adauga ceva, sa zicem un parametru care intamplator devine obligatoriu, noi nu am scris programul asa, daca il modificam pierdem „backward compatibility”, daca nu il modificam nu mai merge pe versiunile noi, deci mai introducem un case…. si tot asa, pana cand jumatate din softul nostru este despre biblioteci si o mica parte despre ceea ce are el de facut cu adevarat :)