Noile limbaje de programare declarative precum HCL și Polar ar putea fi modalitatea perfectă de a spori productivitatea cu Infrastructure as Code (IaC).

Există o mulțime de limbaje de programare – peste 700, după cum le listează Wikipedia. Și totuși, se pare că nu avem suficiente limbaje de programare. Nu de când cloud-ul a schimbat modul în care aplicațiile sunt construite.

Dezvoltatorii se îndepărtează de gestionarea serverelor fizice care apelează API-uri ce apelează resursele de stocare, de calcul și de rețea. În schimb, dezvoltatorii încearcă să automatizeze totul ca secvențe de cod prin configurații statice, scripturi și fișiere. O astfel de automatizare ar fi mai ușoară dacă dezvoltatorii ar avea la dispoziție limbaje de programare la îndemână, dar nu au. Deci, folosind un limbaj cu scop general, cum ar fi Java, un dezvoltator ar putea scrie mii de linii de cod pentru a încerca să exprime logica de afaceri… și în mare parte ar eșua.

Pentru a rezolva acest lucru, vedem companii precum HashiCorp (HCL) și oso (Polar) lansând limbaje declarative dedicate. Chiar și cu riscul de proliferare a limbajelor de programare, acest lucru pare a fi calea corectă: un limbaj special conceput în loc de limbaje cu scop general. Cu toate acestea, este posibil să vedem că multe dintre aceste limbaje de programare apar și dispar înainte de a ne stabili un set util de limbaje declarative standard.

Limbaje de programare declarative funcționale: Ce este vechi, este nou din nou

Ironia este că „noua” abordare adoptată de limbajele declarative cu scop special nu este într-adevăr foarte nouă. Cu ani în urmă, limbajele de programare s-au împărțit între limbaje de programare funcționale (declarative) precum Lisp și limbaje de programare imperative precum C. În timp ce acestea din urmă au dominat timp de decenii, limbajele funcționale declarative revin, a declarat într-un interviu Jared Rosoff, un director de software ce a contribuit la produse ale VMware, MongoDB și multe altele.

„Limbajele imperative erau mai potrivite pentru codarea logicii de afaceri pentru aplicații”, a remarcat Rosoff. „Dar în Infrastructure as Code [IoC], lumea nu este imperativă. Este bazată pe reguli. Și această lume devine mult mai ușoară atunci când schimbăm limbajele pe care le folosim pentru a o programa”.

Chiar și Polar, un limbaj de programare logică declarativă specializat pentru luarea deciziilor de autorizare și integrarea strânsă cu limbajul nativ al unei aplicații, nu este cu adevărat nou. După cum a sugerat într-un interviu Sam Scott, cofondator și CTO al oso, Polar își are rădăcinile în Prolog, care a fost dezvoltat încă din 1972, dar crează impresia unor limbaje imperative precum Python. (Iată un exemplu de cum arată Polar). Acest lucru este important deoarece este dificil să codificați logica de autorizare în limbaje de programare tradiționale, cu scop general. A face acest lucru într-un limbaj declarativ precum Polar este mai expresiv și mai concis – gândiți-vă la „zeci de linii de cod” în loc de „mii de linii de cod”.

Și totuși, mulți se vor pune la îndoială dacă crearea de noi limbaje de programare este abordarea corectă. De câte avem într-adevăr nevoie? Răspunsul scurt este „mai mult”. Iată răspunsul pe larg.

De ce nu pot folosi [inserați aici limbajul de programare preferat]?

Deși folosim în continuare COBOL și alte limbaje de programare mai vechi, continuăm să inventăm noi limbaje, fiecare cu propriile avantaje și dezavantaje. De exemplu, avem Rust și C ++ pentru programarea sistemelor low-level, sensibile la performanță (cu Rust adăugând avantajul siguranței); Python și R pentru machine learning, manipularea datelor și multe altele; și așa mai departe. Instrumente diferite pentru diferite nevoi.

Dar, pe măsură ce ne mutăm în această lume Everything-as-Code, de ce nu putem continua să folosim aceleași limbaje de programare? La urma urmei, nu ar fi mai bine să folosiți Ruby pe care îl cunoașteți (cu toate instrumentele sale încorporate) decât să începeți de la zero?

Răspunsul este „nu”, așa cum a spus Graham Neray, cofondator și CEO al oso. De ce? Pentru că există adesea o „nepotrivire între limbă și scop”. Aceste limbaje imperative de uz general „au fost concepute pentru ca oamenii să construiască aplicații și scripturi de la bază, spre deosebire de definirea configurațiilor, politicilor etc.”.

Mai mult, amestecarea instrumentelor declarative cu un limbaj imperativ nu face lucrurile mai ușor de depanat. Luați în considerare Pulumi, care se prezintă ca „SDK infrastructure-as-code open-source care vă permite să creați, să implementați și să gestionați infrastructura pe orice cloud, folosind limbajele dvs. preferate”. Sună minunat, nu?

Din păcate, în timp ce programul poate fi executat, acesta este folosit pur și simplu pentru a construi o structură de date pentru ca Pulumi să o introducă în motorul său, care funcționează într-un mod mai declarativ (adică, luați structura de date, comparați-o cu starea actuală a infrastructurii și aplicați schimbările). Deși există instrumente de limbaj (de exemplu, debugger-e JavaScript), acestea nu sunt foarte utile deoarece depanarea Pulumi ar necesita o cunoaștere intimă a bazei de cod. Motorul Pulumi este încă foarte opac și greu de depanat. Aceasta nu este o critică pentru Pulumi – este doar o semnalare a problemelor inerente în încercarea de a aplica limbajele existente, imperative, la Everything-as-Code.

Aceeași problemă apare atunci când încercați să rezolvați problema cu date ca config. Este cam ca și cum ai folosi un limbaj existent (Hei! Știu deja JSON…). După cum a explicat Scott, pentru ca această abordare să funcționeze, un furnizor trebuie de obicei să îmbrace formatul de date cu condiții sau reguli personalizate (de exemplu, GitHub Actions) pentru a-l face să funcționeze pentru respectivul caz de utilizare. Sau pot folosi templating (de exemplu, Helm sau modul în care Ansible folosește Jinja2). În plus, în timp ce apelarea începe adesea cu formatul de date care poate fi citit de oameni, „fișierele au obiceiul urât de a deveni lungi și greoaie”, a spus el, ducând la postări de genul acesta, acesta, acesta sau acesta.

Acest lucru ne aduce înapoi la limbaje de programare declarative.

Declararea unui viitor purpose-built pentru limbajele de programare

Limbile declarative, cum ar fi Polar și HCL, sunt excelente pentru cazuri de utilizare precum configurarea, deoarece vă permit să declarați doar cum doriți să arate lumea și să nu vă faceți griji cu privire la ceea ce trebuie să faceți pentru ca acest lucru să se întâmple. Dezavantajul este că este nou: o nouă curbă de învățare, o nouă nevoie de a construi un ecosistem de instrumente în jurul ei etc. Este încă devreme pentru limbajele de programare declarative, dar este ok – este, de asemenea, încă devreme pentru lumea noastră Everything-as-Code.

Și, deși limbajele de programare declarative nu sunt perfecte, ele oferă avantaje semnificative față de limbajele de programare imperative, așa cum a spus Ben Kehoe de la iRobot. În următorii câțiva ani, bănuiesc că vom vedea că proliferează limbaje de programare declarative, industria standardizându-se în jurul celor care se descurcă cel mai bine în a se face accesibile începătorilor prin instrumente și abordare (de exemplu, îmbrățișând o sintaxă familiară). Dacă „dezvoltatorii sunt noii creatori de regi”, este timpul ca proiectanții de limbaje de programare declarative să înceapă încoronarea unor noi regi.

Sursa: TechRepublic