Viitorul meseriei de programator

Am surprins o discuție la cafea între mai mulți băieți de-ai mei. Unul susținea că AI-ul va spăla pe jos cu programatorii, aruncându-i la gunoi, în timp ce altul dădea exemple de aberații de cod generate de AI-urile orientate spre programare. A apărut și „realistul”, probabil cel mai detașat și hazliu om cu care reacționez zilnic, pentru a pune bomboana pe colivă. „Știți ce m-a rugat Mirela să-i fac?” - i-a întrebat el, referindu-se la o bombă sexy care lucrează în proximitatea noastră, cu care mai interacționăm la cafea și după care li se scurg ochii băieților. „Nu, spune-ne!” - au întins ei gâturile curioși nevoie mare, lăsând în urmă discuția existențială. Omul nostru, luându-și tacticos cafeaua și dozându-și perfect momentul exploziei a rostit sacadat, ca o mitralieră: „M-a rugat să-i adun două coloane în excel într-o coloană, iar într-o altă coloană să împart rezultatul la doi ca să aibă media. Când i-am spus că se poate face totul într-o singură coloană a rămas atât de surprinsă încât cred că acum se gândește la mine ca la cel mai deștept om de pe lumea asta. Dacă n-ați înțeles că Mirela va fi programatorul viitorului, n-ați înțeles nimic!”.

A izbucnit toată lumea în râs însă discuția e mult mai lungă și merită să zăbovim puțin asupra ei. Promit că voi folosi un limbaj cât se poate de facil, astfel încât să poată fi înțeles chiar și de cei care n-au habar de domeniu. 

Povestea începe în anii 70, atunci când sir Arthur Sinclair l-a dus pe matematicianul Nigel Searle în SUA cu un scop precis: acela de a reuși imposibilul, adică să construiască un calculator științific cu un chip care nu știa să facă decât patru operații: adunare, scădere, înmulțire, împărțire. Chip-ul TMS0805 avea loc în ROM doar pentru 320 de instrucțiuni, iar inginerii de la Texas Instruments considerau că numărul este mult prea redus pentru a se mai putea dezvolta ceva avansat cu el. Ei bine, Nigel Searle a reușit imposibilul, înghesuind în 40 de instrucțiuni funcțiile trigonometrice(sin, cos, tan) și în 30 de instrucțiuni funcțiile trigonometrice inverse. Ca să înțelegeți, economia de spațiu din memoria calculatorului i-a făcut pe cei care s-au înhămat la această afacere să tipărească pe carcasa produsului final valorile constantelor pe care nu le-au putut stoca în memorie, precum π (3.14159), ln(10) (2.30259), e (2.71828), 180/π (57.2958, folosit pentru conversia gradelor în radiani). Însă produsul final, calculatorul Sinclair Scientific, a fost un succes absolut, fiind mult mai ieftin decât competitorii(HP35) și având astfel o piață mult mai mare. La fel cum a fost și Sinclair Spectrum, pe care cei mai maturi și-l amintesc ca HC-85 la noi.

Nu întâmplător v-am descris povestea. Nigel Searle este unul dintre primii programatori, iar ceea ce trebuie să înțelegeți e că meseria unui astfel de individ era una de la bază, omul având nu doar cunoștințe științifice aprofundate, ci și capacitatea de a învinge limitările tehnicii de calcul de început. Prin 1985 avem citatul care-i este pus în gura lui Bill Gates, cum că „640K (de memorie) ar trebui să fie de ajuns pentru oricine”. Vă imaginați că azi și ceasul smart sau echipamentele electronice cele mai chioare au infinit mai multă memorie? 

Nigel Searle este cumva reprezentantul programatorilor de primă generație. Aceștia programau în ceea ce se numește cod mașină, manipulând totul la nivel de bit. Puțini mai au azi habar că o deplasare a biților la stânga echivalează cu înmulțirea cu o putere a lui doi, iar deplasarea spre stânga cu o împărțire la o putere a lui 2. Ca să nu mai vorbesc de faptul că, printre programatorii de azi, doar o minoritate insignifiantă mai are habar că există o programare low level, în cod mașină. Și totuși, programatorii aceia de început erau niște genii. Altfel n-aveai cum. Cine mai știe azi ce-s ălea registre, mod de adresare a memoriei și cine mai are habar acum că un singur octet scris greșit îți bloca întreg sistemul? 

Programatorii în limbaj de asamblare ai anilor 70 erau la nivelul 9, înțelegând perfect nivelele 10(setul de instrucțiuni al mașinii) și 11(microarhitectura). Acestora le-au urmat programatorii care lucrau cu compilatoare(fortran, C, pascal etc.). Munca era extrem de complexă, dar față de limbajul de asamblare era pistol cu apă. Apoi vine era programării obiectuale, de complexitate ridicată, dar mai ușoară decât cea anterioară. În această perioadă(1980-1990) explodează interfețele grafice, iar calculatorul intră ușor, ușor în viața de zi cu zi. Web-ul aduce după sine o nouă generație de programatori. Limbajele dinamice, ale Web-ului, fac ravagii: Perl, PHP, Ruby, JavaScript. Apoi vine revoluția framework-urilor cu NET de la Microsoft, Java de la Sun s.a.m.d. Cam aici suntem noi, mai precis la finalizarea acestui pas. 

Trebuie să înțelegem că un programator actual(care e practic la nivel 1), spre deosebire de unul din trecut, are de rezolvat o problemă de complexitate orizontală: el integrează diverse componente pre-programate într-un sistem funcțional, fiind mai degrabă un integrator. Programatorul din zilele noastre lucrează la vârful unei tehnologii vaste, pe care nu o înțelege. Între el și hardware sunt o grămadă de straturi de a căruor existență nu are habar. Codul său Python sau JavaScript este interpretat, transformat în bytecode, după care e rulat de o mașină intermediară care transformă instrucțiunile în apeluri de proceduri la nivelul sistemului de operare. Care sistem de operare rulează într-un container, astfel apelurile de funcții ale sistemului de operare se transferă în apeluri către mașina aparent fizică, care însă, fiind un container, este abstractizată de acesta. Containerul, de obicei, stă pe un alt sistem de operare care, de cele mai multe ori, rulează pe o mașină virtuală, care mașină virtuală rulează pe un hypervisor, adică un strat software specializat care gestionează harware-ul fizic al furnizorului. Înțelegeți nivelul de complexitate? Dacă ați citit până aici s-ar putea să știți ceva mai mult despre arhitectura sistemelor decât știu 60%-80% dintre programatorii de azi!

Și uite-așa ajungem rapid la ceea ce urmează, anume generarea automată a codului. Teoretic, generarea automată a codului o transformă pe Mirela în programator. Trebuie doar să-i spună sistemului ce vrea, în limbaj natural, și gata, codul e generat. Este însă suficient? Aici e o problemă clasică de înțelegere, control și optimizare. Să vă dau uin exemplu. 

Prin anii 2000, programarea sistemelor distribuite era teribilă. Se introduceau standarde, se făceau tot felul de proiecte ambițioase. Fiecare jucător avea standardul său, care căuta să funcționeze peste tot. Doar că nu prea era putere de calcul și toate mergeau teribil de greu. Atunci i-am implementat unui client o soluție low level care l-a costat cam o zecime din cât îi cerea un jucător mondial. Nu doar că soluția noastră mergea bine, dar nici nu trebuia să-și înlocuiască aproape întreaga infrastructură informatică.Am rămas plăcut surprins să constat că sistemul îi funcționează inclusiv acum, la o performanță extremă. Culmea, am constata-o când a venit la noi și ne-a cerut ceva funcții suplimentare, punându-ne grav la încercare întrucât sculele de acum 20 de ani pe care le-am folosit pentru construirea soluției, pur și simplu nu mai există. Am reușit să refacem din backup-uri infrastructura noastră de atunci pentru a ne reaminti ceea ce făcusem și pentru a-i construi o soluție adoptată nevoilor de-acum. Gândiți-vă totuși că sistemul construit acum 20 de ani funcționează încă și a fost suficient de extensibil pentru a-i suporta toate nebuniile de până acum. Aici e frumusețea programării cât mai spre low level!

Să revenim la povestea cu Mirela: da, ea va fi capabilă să „programeze” cu un asemenea instrument AI. Nu vreau să aduc în discuție complexitatea procesului de la generarea codului și până la „instalarea” sa, sau eventualele bug-uri care sunt inevitabile. Voi presupune că diverse sisteme automate vor face cu succes ceea ce numim deployment. Dar ce se întâmplă când un fragment, de la momentul X, nu va mai funcționa? Sau când va funcționa aberant? În primul rând, va fi cineva capabil să descrie problema, o va descoperi cineva? Apoi, atunci când se vor solicita facilități noi, va avea cineva garanția că algoritmii evoluați vor mai avea habar de specificațiile inițiale, de ideea din spatele unui anumit sistem? Vor putea fi integrate noile facilități în ceea ce deja merge?

E de fapt o provocare teribilă. Dacă te lași pradă scrierii automate de cod te prostești iremediabil deoarece e mai greu să înțelegi codul scris de altcineva decât cel pe care l-ai gândit tu. Și când un generator de cod ți-a produs câteva mii de linii de cod în câteva minute, cu siguranță n-ai chef să stai să înțelegi ceea ce a gândit robotul. Mai ales dacă ești strâns cu ușa. Și așa, treptat, se instalează incompetența. Culmea, aici e o mare provocare. 

Probabil într-o fază imediat ulterioară momentului actual va fi jale pentru programatori. Accesibilitatea noilor unelte îi va transforma în victime. Va rezulta însă un teribil haos la nivelul celor care vor adopta în masă noile unelte. Asta pentru că, în procesul de elaborare a unei soluții, o mare parte este dedicată analizei și optimizării. În acest proces, managerul de proiect și programatorii efectuează ajustări, astfel încât totul să se integreze logic. Acum? Într-o primă fază „va merge și-așa”, după care se va instaura haosul, iar clienții vor fi obligați ori să-și rescrie tot ce a scris AI-ul, apelând la un consultant foarte scump, ori să migreze către platformele care le oferă o înaltă standardizare. Însă ce haos va fi și în spatele acelor platforme, ca efect al „fenomenului Mirela”, e  greu de imaginat!

Dar întrebarea persistă: va mai fi un viitor al meseriei de programator? Momentan suntem în plin uragan. Îl vedem formându-se și vom vedea ce va ieși după. Din ceea ce am văzut până acum, tendința e clară, dar asta cred eu că înseamnă oportunități extraordinare pentru cei care au habar cu ce se mănâncă domeniul. Povestea scrierii software-ului nu este una legată de scrisul efectiv al codului, ci de partea creativă, de concepție, de structurare a datelor și de gândirea sistemului pentru extensii viitoare. Poate gândi mașina așa ceva? Poate că da, poate că nu, dar părerea mea e că vom avea o explozie a bubelor rezultate din diferențele de „gândire” dintre om și mașină. Nu uitați un lucru: Mirela avea nevoie de două coloane pentru o banală medie aritmetică și nu prea se descurca să definească o formulă, astfel încât a avut nevoie de omul nostru. Iar Mirela, în viitorul apropiat va scrie cod! Ce-ar mai fi de spus? Că Mirela e deosebit de frumoasă. La fel cred că va fi și codul generat de ea!