PHP 8.2

Jójó, de a HUP most PHP-ben van írva. Szóval ha most hirtelen nem lenne PHP vagy nem futna a PHP értelmező, akkor nem tudnál kommentelni. 😉

De nem volt nehéz, az ncurses alapú x-elgetőse elég kézenfekvő volt, vagy csak megszoktam. Debian érdekes, hogy sokkal később jelent meg a köreinkben, holott a Slackwarrel közel egyidőben indult.
Okát nem tudom megmondani. Lehet hogy csak nem kerestünk mást. Aztán egyszercsak bejött a SuSE és a Debian is a képbe. Ez kb. 1999 körül lehetett.

Visszagondolva a PHP+MySQL tényleg nagy technológiai robbanást hozott az ezredforduló környékétől. Addig a weblapok túlnyomó része statikus volt. Ellenben kevés energia kellett a kiszolgálásához.

Alapjában véve/természetesen egyetértek. Egy ideális világban így kellene lennie.

De a nyelv fejlesztőinek a valóságot is figyelembe kellene venni, hogy hiába csinálnak jó nyelvet, toolset-et "néhány" hozzáértő fejlesztő folyamatos igényei alapján, ha a PHP fejlesztők jó nagy része (akinek nem inge...) hozzá nem értő önjelölt amatőr webfejlesztő, és az általa használt (jellemzően nem a legfrissebb, mert a régebbiben lévő lehetőségeket sem érti igazán) verzió lehetőségeit sem ismeri, nemhogy az újításokat.
Emiatt aztán kiizzad egy úgy-ahogy működő valamit, aminek örül, hogy megjelenik a képernyőn, kb. az amit a megrendelő kért, és jónapot, úgy marad örökre.
Aztán a szerencsétlen megrendelő sem a PHP-t nem ismeri, sem a kódról nem tudja megállapítani mennyire jó, így elfogadja, mert azt látja, amit kért (vagy kap egy számára akkor hihető magyarázatot, hogy miért nem olyan teljesen...).
De amikor meg az üzemeltető frissíti a PHP-t a cucc alatt, mert a támogatás megszűnt, biztonsági rés volt, stb. akkor jön a gond. Megáll a cucc mint szög, mert 1) eredetileg sem volt jó a kód a régebbi PHP verzióhoz sem, csak kerülő "trükkökkel" életre keltették, 2) jó volt ahhoz a verzióhoz, de obsolote lett a használt funkció. A felhasználó meg nem érti, hogy kifizette, eddig működött, és most miért nem. Az őt igazából nem érdekli (és tényleg nem is kellene érdekelje), hogy miért kellett frissíteni, az meg pláne nem, hogy fizessen a "javításért" úgy, hogy maga a cucc pont ugyan azt fogja tudni, mint annak előtte, csak újra fizetni kell érte. Már persze ha olyan szerencséje van, hogy az eredeti fejlesztő elérhető és hajlandó javítani, vagy talál helyette valakit, aki meg tudja és akarja csinálni...

Egy csomó nyelv esetében elég ritkán van olyan változás, hogy megborul az app a nyelv frissítésétől. PHP esetében viszont aránylag gyakori, ami nagyon nem jó, és szerintem igazából nem is védhető semmilyen észérvvel (legalábbis ilyen gyakran). Ha más meg tudja oldani úgy a nyelv fejlesztését, hogy nem borul meg egy csomó minden tőle, akkor a PHP fejlesztőinek is meg kellene tudni oldani. De lehet úgy vannak vele, hogy már úgy is megszokta a világ, minek foglalkozzanak a kompatibilitással többet, mint eddig.

A PHP most nekem amolyan rolling release, ami esetében minden benne írt kódot folyamatosan vinni kellene előre a PHP fejlődésével párhozamosan, hogy ne legyen gond. De szerintem programnyelvek esetében működésképtelen ez a modell... Pláne, hogy rengeteg olyan rendszer készül benne, ami "statikus", úgy értve, hogy amikor elkészült, onnantól használják sokáig, módosítás nélkül.

Például a Wordpress elég nagy, elterjedt és aktívan fejlesztett rendszer. Elég gyorsan jelenik meg az új PHP verzió támogatása (általában 1-2 hónappal a friss PHP megjelenése után). A PHP 8.0 támogatás 2020 decemberében, a PHP 8.1 2022 januárjában jelent meg először benne (5.6-ban és 5.9-ben). Azóta kijött a 6.0 és a 6.1, utóbbi már támogatja a PHP 8.2-t papíron. Viszont az összes érintett (5.6-6.1) verzióhoz jelzik, hogy a PHP 8.x támogatás béta verziós, nem teljes értékű részükről, mint a PHP 7.4 támogatás... Ha egy ekkora projekt sem tud rendesen utána menni a PHP fejlődésnek két év alatt sem, akkor ki tud?