Limbajul de programare Hack, apocalipsa PHP?
Introducere
Facebook a lansat acum aproape o luna limbajul de programare Hack.
De atunci, peste tot au inceput sa apara articole apocaliptice legate de acest limbaj si cum acesta va inlocui PHP. Titlul acestui articol a fost inspirat din “Will Hack Kill PHP?“.
Ce mi se pare si mai ciudat este ca a urmat un val de aprecieri negative legate de PHP, aparent Hack “repara” limbajul mai sus mentionat. Parerea mea este ca, in primul rand, limbajul ar fi trebuit sa fie “stricat” ca sa poata fi “reparat”.
Evident ca si PHP are multe lipsuri, la fel ca orice alt limbaj de programare, dar trebuie sa fie si un motiv pentru care este cel mai popular limbaj pentru Web. Pana la urma, Facebook l-a folosit atata timp, iar acum nu il schimba, incearca sa-l imbunatateasca… nu?
Un lucru este sigur, este probabil cel mai neinspirat nume. Atunci cand cauti “Facebook hack” gasesti orice altceva decat acest limbaj de programare…
Despre Hack
Hack ruleaza pe HHVM. HHVM este incercarea Facebook de optimizare a limbajului PHP prin Just In Time complication, ultima abordare de optimizare a limbajului. Practic, Facebook incearca sa-si reduca din costuri, optimizand interpretatorul de limbaj, iar acum un alt limbaj cu totul. Pana la urma, daca ne gandim la infrastructura Facebook, este normal sa faca asta. Chiar si o optimizare relativ minora duce la o reducere consistenta a costurilor.
Initial am crezut ca este o versiune “imbunatatita”, dar se pare ca este alt limbaj de programare, practic este un PHP cu ceva in plus!
Un mic tutorial al limbajului este la: http://hacklang.org/tutorial/.
Tutorialul nu prinde chiar toate facilitatile limbajului, mai multe detalii sunt la: http://docs.hhvm.com/manual/en/hacklangref.php.
Practic cam toate facilitatile care deosebesc Hack de PHP sunt de fapt optionale. Aproape ca poti scrie PHP si va functiona. Contrar asteptarilor, nu este obligatorie nici macar specificarea tipului de input/output pentru variabile.
Pentru ca pana la urma este un limbaj de programare, nu voi intra in detaliu legat de tot ce aduce nou. Acesta este mai degraba rolul unui carti, nu al unui articol.
Doresc sa subiliniez cateva lucruri care mi se par interesante.
In mod bizar, cel putin pentru inceput, la runtime tipul rezultatului chiar daca este trimis, nu este neaparat interpretat.
Sa luam un exemplu:
1<?hh
2
3function a($a): void {
4 return true;
5}
6
7echo a('a');
Acest exemplu va avea output… 1.
Practic, la runtime nu se verifica decat tipul de input, nu si cel de output.
Pentru a rula Typechecker-ul se adauga in directorul curent un fisier gol:
1$ touch .hhconfig
Apoi se ruleaza:
1$ hh_client
Dupa cum se poate vedea, tipurile de date se testeaza intr-un pas separat fata de runtime.
La rularea manuala de Typechecker, acesta va identifica toate inconsistentele. Scopul este ca acesta sa identifice problemele inainte de runtime, de exemplu cand se editeaza un fisier, nu cand ruleaza efectiv aplicatia.
Output-ul de la Typechecker este:
1../test.php:4:9,12: Invalid return type
2../test.php:3:17,20: This is void
3../test.php:4:9,12: It is incompatible with a bool
Din pacate mai este de lucru la aceste feature. Daca incercam sa validam doar la runtime, folosind “type hinting” la fel ca in PHP, functia devine:
1function a(int $a): void {
2 return true;
3}
4
5echo a('a');
Output-ul de la Typechecker nu se schimba, dar la rulare vom obtine:
1Fatal error: Argument 1 passed to a() must be an instance of int, string given in ../test2.php on line 5
Practic, Typecheckerul face ce nu face type hinting, iar cel din urma poate sa primeasca acum si argumente de tip scalar.
Chiar daca ar fi fost vorba doar de adaugarea de argumente scalare, tot mi se pare o inbunatatire importanta.
Este o formula mai degraba cunoscuta in limbajele functionale.
Un exemplu:
1<?hh
2
3$sqr = $x ==> $x * $x;
4
5echo $sqr(5) . PHP_EOL;
Rezultatul o sa fie, evident, 25.
Mi se pare un mod foarte interesant si lizibil de a ingloba logica de mici dimensiuni.
Folosind noua sintaxa, o functie poate intoarce si alta functie:
1$add = $x ==> $y ==> $x + $y;
2
3$result = $add(1);
4
5echo $result(2) . PHP_EOL;
Rezultatul o sa fie 3.
Daca o variabila din interiorul unei expresii lambda nu se intalneste in interiorul functiei care o defineste, atunci acesta va prelua variabila din mediul in care expresia este declarata:
1// variabila in scope-ul curent
2$z = 5;
3
4$addZ = $x ==> $x + $z;
5// schimbat variabila in scope-ul curent
6$z = 6;
7
8// efectuat adunare
9echo $addZ(1) . PHP_EOL;
Rezultatul o sa fie… 6!
Echivalentul in PHP ar fi:
1$addZ = function ($x) use ($z) {
2 return $x + $z;
3}
Valoarea lui $z se ia din mediul in care functia este definita, nu este o referinta la variabila.
Evident ca, in cazul in care variabila care este preluata din scope este un obiect, ea va fi preluata prin referinta:
1<?hh
2
3class a {
4 public function __construct(public string $x) {}
5 public function __toString() {
6 return $this->x;
7 }
8}
9
10// variabila in scope-ul curent
11$z = new a('Claudiu');
12
13$addZ = $x ==> $x . ' ' . $z . '!';
14
15// schimbat variabila care se va folosi la concatenare
16$z->x = 'World';
17
18// rulat concatenare
19echo $addZ('Hello') . PHP_EOL;
Rezultatul va fi:
1Hello World!
Din nou o sintaxa mai des intalnita in limbaje functionale. Scopul este de a valida un tip de structura mai specific decat un array.
Motivul este foarte bun, valiadarea de structuri de date simple. Structurile care se verifica ar trebui sa contina elementele care au fost definite in shape.
1<?hh
2
3// definirea unei structuri
4newtype Circle = shape('radius' => int, 'b' => int);
5
6// functie care foloseste tipul structurii de mai sus
7function areaCircle(Circle $param) {
8 return M_PI * $param['radius'] * $param['radius'];
9}
10
11// o serie de shape-uri care folosesc structura
12$circle = shape('radius' => 10);
13$cilinder = shape('radius' => 10, 'height' => 15);
14
15// o structura care nu ar trebui sa functioneze cu Circle
16$sqr = shape('side' => 10);
17
18echo areaCircle($circle) . PHP_EOL;
19echo areaCircle($cilinder) . PHP_EOL;
20echo areaCircle($sqr) . PHP_EOL;
Outputul este:
1314.15926535898
2314.15926535898
3
4Notice: Undefined index: radius in /home/brand/test.hh on line 6
5
6Notice: Undefined index: radius in /home/brand/test.hh on line 6
70
Un pic dezamagitor, speram ca parametrul care nu se potriveste cu structura sa genereze o eroare, dar se pare ca va trece mai departe.
Nici Typechecker-ul nu gaseste nimic in neregula.
Initiativa este foarte buna, acum trebuie doar sa asteptam varianta functionala.
Concluzie
Probabil Hack va influenta PHP, lucru normal pana la urma, se intampla asta tot timpul cu limbajele de programare.
Va inlocui PHP? Nu cred, probabil vor fi multi care il vor adopta pentru a reduce costurile si pentru o mai buna structura a codului.
Este foarte putin probabil ca acest limbaj sa aiba succes in urmatorii ani, in afara de proiecte de dimensiuni medii si mari. Pentru proiecte mici, in general se foloeste shared hosting, iar acesta de obicei nu are ultima versiune de PHP, putin probabil sa foloseasca ultima versiune de HHVM. Acesta poate nu este cel mai interesant argument, dar pana la urma cele mai multe site-uri de pe web sunt mici si foarte mici.
Un mod multi mai simplu de optimizare este sa folosesti HHVM si atat. Teoretic nu trebuie sa schimbi nimic si rezultatele se vor vedea imediat! Practic HHVM nu este 100% compatibil cu Zend Engine, dar probleme de compatiblitate se rezolva progresiv cu fiecare versiune. Una din prioritatile HHVM este sa intepreteze codul la fel ca Zend Engine, dar sa fie mult mai eficient!