Blog | Pár přání do PHP

Pár přání do PHP

PHP je docela stabilizovaný jazyk. Nedějí se v něm žádné radikální věci. To je dobré pro lidi, kteří na PHP provozují existující aplikace. Není to tak dobré z marketingového pohledu. PHP zatím ještě přitahuje nové lidi a hodně lidí začíná programovat právě v PHP. Ale v budoucnu by to tak nemuselo být.

Dnes frčí JavaScript. Ten je PHP docela podobný. Má některé výhody, některé nevýhody. Neoddiskutovatelná je výhoda, že je v klientu i na serveru. Ale s transpilery (ScalaJS, ClojureScript, Haxe, Objective-J atd.) bude brzy možné napsat server i client side stejně v jakémkoliv jazyce, který si vyberete.

Dál má JS na serveru dvě zásadní výhody, na které PHP zatím nereagovalo a reagovat musí. JavaScript na serveru je a) brutálně rychlý (tak rychlý, že to bere vítr z plachet těm, kdo tvrdí, že dynamicky typované jazyky nikdy nemůžou být tak rychlé, jako statické), b) má asynchronní I/O. Dokud si vystačíte s jedním jádrem, je JS na serveru vynikající jak na CPU náročné, tak i na I/O náročné úlohy. Ve srovnání s tím je PHP mnohem pomalejší. V operacích náročných na CPU jde rozdíl ve výkonnosti až do desetinásobků. Co se I/O týká, PHP prostě čeká a nic nedělá, dokud I/O neproběhne. To už dneska nestačí.

Co by se mělo stát?

Just In Time kompilace

PHP může použít zdrojáky z HHVM, nebo může použít něco svého, to je jedno. Ale ať to, prosím, běží přinejhorším 2* pomaleji, než obdobná aplikace napsaná v C.

Odstranit memory leaky

Pokud má PHP někdo používat i třeba na obdobu socket.io apod., musí být PHP schopno opravdu dlouhého běhu. Zkušenost je taková, že PHP ty memory leaky obsahuje. Některé funkce neleakují a některé skripty můžou běžet bez restartu celé týdny. Ale jako celek, na PHP v tomto není spoleh.

PHP má vlastní webserver. Ve verzi 7 by mělo podporovat asynchronní I/O. To, když by se to spojilo s opravdu vysokou rychlostí, vezme všem těm, kdo přechází na JS, skutečný důvod.

Jen tyto 2 body + doplnění reaktivního I/O, které je, pokud vím, už v plánu, by PHP výrazně modernizovalo. Ale my chceme víc.

Pořádný type hinting

Tím se dostáváme k další části. Type Hinting je v PHP nedotažený. Neumí primitivní typy. Cesta, kam Type Hinting směřuje, mi přijde, že to bude zprasené řešení (bez typového polymorfismu, nedej bože, aby přidali type-casting type hinty).

Tím se dostáváme k tomu, že vlastně to, co by naplnilo výše zmíněné body, už tu existuje. Jmenuje se to Hack.

Napsat kus PHP v PHP

Jedna z takových běžných věcí je, že jsou často jazyky psané přímo v tom jazyce. Překladač se nejdřív napíše v existujícím jazyce a pak se přepíše do nového jazyka. Takže je dnes běžné, že překladač C bude v C, překladač v CoffeeScriptu je napsaný v CoffeeScriptu, překladač LiveScriptu je napsaný v LiveScriptu, překladač Clojure je napsaný v Clojure atd.

Když se píše jazyk přímo v daném jazyce, výrazně to zvedá agilitu řešení. Místo nízkoúrovňového jazyka, jako je C, zvládá PHP mnohem víc lidí. Bylo by mnohem snažší do jazyka dostávat různé změny, kdyby to nebylo jako dnes, kdy: „PHPčkaři závisí na Cčkařích, co jim do jazyka nadělí.“

S tím by se měl spojit i úklid v platformě. Existující funkce by měly být rozděleny do namespaců, měly by mít konzistentní pojmenování, pořadí parametrů. A samozřejmě autoloader by měl být schopen autoloadovat i funkce, nejen třídy.

Paralelismus

Další věc, která by PHP opravdu hodně posunula a která bude naprosto logická, jakmile bude někdo v PHP psát asynchronní a dlouho běžící aplikace, je paralelismus.

Do začátků by PHP nemuselo obsahovat všechna paradigmata. Ale co by aspoň pro začátek stačilo, by byl Actor-based model (znáte např. z Erlangu, Elixiru, Scaly, Clojure), nebo CSP (znáte např. z Go nebo Clojure) model.

Časem by měl přibýt ještě způsob, jak konkurenčně přistupovat k datům, ať už formou „půjčování si“ proměnných, jako je to v Rustu, nebo formou transakcí nad persistentními datovými strukturami, jako je to v Clojure.


Tyto změny by otevřely PHP úplně novým možnostem. Samozřejmě vítám změny, ke kterým už v PHP došlo v posledních letech, jako jsou anonymní funkce, lepší syntax pro pole, jmenné prostory. Ale přijde mi, že to je pulírování bez toho, aby se zasáhly ty opravdu hodně zásadní problémy a bez toho, aby se řešily seriózní hrozby, kterým PHP čelí.

Programování

Předejte zkušenosti i dalším a sdílejte tento článek!



Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích