PHP versies

Ik met mijn webapplicatie bezig sinds Internet Explorer 5, ik heb er al behoorlijk wat kilometers opzitten.

De webapp deed was eerst simpel. Het gebruikte de standaard sessiefuncties van PHP. Totdat ik er achter kwam dat de opslaglocatie /tmp niet zo'n goed idee is. Toen de code aangepast en SessionHanderInterface geimplementeerd, tot je er achter komt dat niemand weet wanneer de functies in welke volgorde precies worden getriggerd. Daarna maar het wiel opnieuw uitgevonden en eigen sessiefuncties gebouwd, was nog makkelijker te porteren ook.
Zo groeit een webapp en wordt het steeds professioneler. Maar eigenlijk is het gek dat er niet 1 goede manier is waarmee PHP met sessies omgaat.

En dat geldt ook voor een 'aanpassinkje' als de encoding. Werkt alles eerst met latin1, dan komt er ineens een veranderingetje (met PHP 5.4 als ik me niet vergis) naar UTF-8. Niet erg hoor, en logisch ook met de transitie richting HTML5, we passen alles wel weer aan. Maar dat is niet simpel of snel gedaan, getuige bijvoorbeeld deze thread op SO. En dan moet je database MySQL ook nog meewerken, want als je zegt dat die unicode moet doen, ondersteunt die alleen de eerste plane en mis je 15/16 van alle unicode karakters. Kan je alles weer omzetten naar utf8mb4.
Alleen al daarmee ben ik een klein halfjaar mee bezig geweest.
En dan bestaat het de veelgebruikte DOMDocument extentie ook nog eens om UTF-8 karakters standaard verkeerd te printen met saveHTML(), moet je daar nog een ongedocumenteerde parameter in gooien voordat-ie het wel wil doen, en voordat je daar weer achter bent.
En dan zit PHP vol met nuttige (?) features als een boolean '&&' operator en een tweede boolean 'and' operator die niet hetzelfde werken. Lekker handig, maar dan ben ik nog heel mild in vergelijkig met de vele rants op internet tegen PHP.

Nee, ik wil niet zeuren over wat er allemaal slecht is aan PHP, want iedere programmeertaal heeft wel verbeterpunten.
Maar om nou te zeggen dat het slechts om aanpassinkjes gaat met weinig gevolgen vind ik geen recht doen aan alles wat we hebben moeten doorstaan de afgelopen decennia.
En als ik dat afzet tegen een andere taal als C, waarbij je dit soort dingen van te voren weet en dat je bestaande code niet breekt maar blijft werken, of een nieuwe taal als Rust waarbij je niet eens na hoeft te denken over Unicode omdat dat allemaal al in 1x goed geregeld is, dan komt in mijn optiek PHP wel steeds meer op achterstand.

En ja, dat is mijn mening. En ja, een ieder mag zijn eigen mening hebben.
Maar daarmee blijft de vraag of we niet méér geholpen zouden zijn als in ieder geval de basis van de taal PHP en de grammatica wel overeind blijft en backward compatibel blijft, dus niet zoals met de overgang naar PHP 8 ?
Dat we straks alle PHP 8 code kunnen blijven draaien t/m PHP 8.9, en dat PHP 9 of 10 nu eens in 1x goed zou zijn ?
Dat zou voor mij en mijn bedrijf enorm schelen. En misschien ook voor nog anderen ?

Laten we de rollen eens omkeren: wat zou je ervan zeggen wanneer klanten gaan eisen dat de versie die je nu in Rust hebt gebouwd The Final is...?

Op internet duurt een jaar drie maanden. Eisen dat een technologie in dit domein niet verandert, is niet alleen onrealistisch maar vooral onverstandig.

Specifiek voor PHP geldt, denk ik, dat met name beveiligingsfouten uit het verleden een rol spelen. Daarvan hebben we helaas geleerd dat als je gebruikers niet dwingt om een update te installeren, er altijd een te grote groep is die dat domweg niet doet.

Er wordt véél meer gezocht naar het onderdrukken van PHP deprecated warnings dan naar best practices voor loggen. Script kiddies die liever niet herinnerd worden aan prutswerk, de error reporting daarom uitzetten en vervolgens een paar jaar later tegen de lamp lopen... Er is goed te leven met de lang van te voren aangekondigde en goed gedocumenteerde updates van PHP, maar dan moet je niet zo iemand inhuren voor cheap fixes of quick wins.

Dank voor de alternatieve invalshoek.

Je krijgt van mij deels gelijk. Een aspect van een taal met een lage instap is dat het mensen aantrekt die geen hogere instap kunnen en/of willen maken. Dat wordt bevestigd met dito hosters die nog rustig PHP 5.x aanbieden omdat het kan, niet omdat het slim is. Vooral ook met MySQL, zonder keuze voor PostgreSQL.

Mijn klanten eisen dat mijn webapplicatie minimaal 5(+) jaar lang mee gaat. Als ik over 4 jaar iets moet wijzigen om wat voor reden dan ook, dan hoef ik alleen dat deel aan te passen dat aanpassing behoeft, en dan compileert de code nog steeds. In de tussentijd hoef ik niet elk jaar weer mijn programma te updaten, want alle randvoorwaardelijke code wordt in de executable statisch gelinked. Mijn programma is niet afhankelijk van een externe runtime. Dus zo lang er geen security issues (bekend) zijn hoef ik niet meteen iets te doen.
Bugs kosten zeker geen 30% van de tijd, vanwege strong typing, linting, en andere behulpzame mechanismen in de taal die zelfs veel security issues voorkomen, waardoor ook Google Rust is gaan gebruiken voor Android.

Ik weet dat de vergelijking niet eerlijk is, omdat PHP veel ouder is en vanuit een heel andere hoek komt. Voordat Rust wat meer mainstream is geworden, heeft Mozilla daar sinds 2008 in geïnvesteerd. En het publiek voor die talen is ook anders. De route van het in kleine stapjes beter worden oogt voor mij omslachtig.

Dat aanpassingen goed gedocumenteerd zouden zijn, daar kan ik me niet helemaal in vinden. Ik heb op SO chat de ontwikkelaars van PHP wel eens helpen herinneren dat de werking van een aantal onderdelen niet overeenkomt met wat ze zouden moeten doen, volgens de bijna immer karige informatie op php.net, en hun antwoord is dat ik het had kunnen weten omdat ze ook nog een apart onbekend systeem hebben voor het wijzigen van de documentatie, waar al een ticket voor was gemaakt.

En op dat soort momenten wordt er bij mij iets getriggerd en ga ik nog eens extra nadenken. En hoewel ik snap dat er een systeem achter zit, begrijp ik niet dat er wel tijd is om het systeem te vullen met tickets, maar niet om ze uit te werken in de documentatie.
Weer vergelijk ik dat met Rust, waarbij je via de compiler en de linter waarschuwingen verschijnen als je inline documentatie (als een soort docblock, met drie slashes) niet in overeenstemming is met de code. Wanneer ik kijk op crates.io is zelfs de documentatie van bijna alle crates volledig en actueel. Dat scheelt ook weer tijd en bugs.

Maar als iedereen verder content is met de omslachtige manier waarop het nu gaat met PHP en dat verder prima vindt omdat het al sinds het begin van PHP zo gaat.. dan hoef ik hier verder niet veel woorden te schrijven en kan ik beter zorgen dat ik mijn overige projecten zo snel mogelijk ga porteren.
Het heeft volgens mij niet veel zin om me hier in m'n eentje druk over te blijven maken.

Kleine aanvulling: ook op internet duurt een jaar geen 3 maanden. CSS1 wordt nog steeds ondersteund, net als XHTML en quirks mode, XmlHttpRequest is nog steeds niet vervangen voor Fetch. En dat is maar goed ook anders zou er een heleboel dingen niet meer werken.

Bijna krijg ik de indruk dat je verontwaardigd bent dat je niet de respons krijgt die je had verwacht. Maar besef goed, je bent hier op een PHP-forum aan het verkondigen dat de boel niet deugt. Dat is ongeveer hetzelfde alsof je de Mc Donalds binnenloopt en tegen de mensen die tevreden hun hamburger en milkshake verorberen zegt dat het eten niet te vreten is en dat ze beter naar de Burger King kunnen gaan. Op het moment dat je zo graag gesteund wil worden in je eigen opvattingen en je niet zo goed een weerwoord kunt incasseren, dan kun je je mening beter in de Burger King gaan verkondigen waar je hoogstwaarschijnlijk in dat geval wat meer bijval zal krijgen.

Verder zou ik zeggen, als je je er zo druk over maakt en blijft maken, dan bouw je alles toch gewoon om?? Daar heb je onze goedkeuring toch helemaal niet voor nodig?

Bijna? :-)

Je blijft aangeven dat ik het dan maar anders moet doen, alleen omdat jij mijn ervaringen niet deelt. Daar was ik niet naar op zoek, ik ben op zoek naar inhoudelijke reacties op mijn ervaringen. Want ik weet ook wel dat ik in een paar maanden tijd mijn andere projecten kan ombouwen. Maar waar het om gaat is dat ik 22 jaar ervaring heb met PHP, en dat het zonde is om daar niet mee verder te kunnen. Simpelweg omdat ik vanwege zakelijk succes met een andere bril naar code moet kijken.

Een aantal van de punten waar het voor mij op mis gaat heb ik hier geprojecteerd, om er op te kunnen reflecteren. Misschien zit ik er naast of heb ik dingen over het hoofd gezien. Maar als ik mijn posts en die van anderen terug lees dan is de trend wel duidelijk. Iedereen accepteert de makken van de organisatie rond PHP als een gegeven feit, iets waar je niets aan kunt doen en waar je maar mee moet zien te leven. Of je moet maar wegblijven van PHP.

De makken worden door de organisatie wel gezien, en men wil het zelfs voor een deel veranderen, maar het lukt slechts in stapjes en stappen.
Zo was het voornemen om PHP 6 volledig omzetten naar Unicode. Die stap bleek te groot, waardoor het er niet is gekomen. PHP zelf ging er bijna aan onderdoor, ontwikkelaar liepen weg. Maar vanaf PHP 7 zijn er op technisch gebied telkens grote stappen voorwaarts gemaakt. Nog los van enigszins begrijpelijke keuze voor prestatieverbeteringen en pogingen om PHP als taal aantrekkelijker te maken door nieuwe snufjes toe te voegen, in plaats van eerdere techniek te versimpelen en verbeteren. De taal is er nog complexer door geworden, en het was stiekem al vrij complex. Stiekem ook omdat de werking van heel wat functies afhangt van al dan niet standaardinstellingen die per locatie te maken zijn.

Hoewel PHP sneller en geavanceerder is geworden, is het niet veel beter geworden. Voor mij is nu duidelijk dat dit niet kan en zal veranderen, misschien op de lange termijn maar daar is geen roadmap voor. Daarmee zeg ik niet dat PHP niet deugt, anders was ik er niet zo lang bij gebleven. Het heeft ook een charme om een underdog positie in te nemen en van daaruit toch allerlei klussen te kunnen klaren. Maar naarmate mijn kunnen verder groeit merk ik dat PHP daar niet meer in mee kan gaan.
Ikzelf ben veranderd, PHP niet. Dus is het tijd om verder te gaan.

Ik verwacht dat het de komende jaren niet veel beter wordt, om uiteenlopende redenen, dus in dat opzicht heb je er goed aan gedaan om juist nu de knoop door te hakken.

Bijvoorbeeld functioneel programmeren is sterk in opkomst, een trend of tegenbeweging weg van objectgeoriënteerd programmeren. Daar zit ook wel een soort logica achter. De belangrijkste theorie rondom objectgeoriënteerd programmeren is zo'n twintig jaar oud. De belangrijkste voorvechters zijn oude knarren die tegen de pensioengerechtigde leeftijd aanlopen.

PHP zal dus vooral op functioneel programmeren worden uitgebreid. Daar is vraag naar omdat het nu in de mode is. En daarin is PHP van oudsher taalkundig een bende. Waarom wordt een string bijvoorbeeld met str aangeduid maar een array niet met arr? Waarom staat er een underscore in strip_tags() maar niet in stripslashes? Wat is str_getcsv() voor rare tussenvorm als je ook str_get_csv() of beter nog gewoon csv_to_array() had kunnen schrijven?

Het is dus kiezen uit twee kwaden: wil je deze fouten tot in lengte der dagen achter je aanslepen of ga je functies hernoemen, met alle gevolgen van dien?

PHP staat stijf van compromissen. En van non-keuzen: veel beslissingen worden al uitgesteld door de verantwoordelijkheid op het bord van de PHP-gebruiker te leggen. Een recent voorbeeld daarvan is hoe strict typing is ingevoerd. Ik kan me dus heel goed voorstellen dat iemand dit op een gegeven moment spuugzat is.

Ik hoop dat je de Rust vindt die je zoekt. ;)

In dit draadje zie ik vooral de focus op PHP-code die je zelf schrijft, maar er is ook nog zoiets als 3rd party code. Zo maak ik bijvoorbeeld best veel gebruik van tools als Icinga en Zabbix en dat heeft best veel ellende opgeleverd toen ik PHP naar iets recenters dan versie 7.2 wilde upgraden. En een programma als Zabbix schrijf je niet even om naar een nieuwe PHP-versie...

Oorspronkelijk kom ik uit een Perl-omgeving en daar doe ik nog steeds het merendeel van mijn werk in, maar ik kom vrijwel geen enkel script tegen dat stopt met werken (of raar gedrag vertoont) bij de upgrade naar een nieuwe versie van Perl. Dat komt vooral omdat nieuwe functionaliteit expliciet moet worden aangezet. (Overigens heeft dat ook wel zo zijn nadelen, want net als bij PHP is versie 6 er nooit gekomen -die is na bijna 20 jaar werk/discussie onder een andere naam doorgegaaan- en de upgrade naar versie 7 was ook al aangekondigd voor twee jaar geleden, maar die heb ik ook nog niet zien langskomen.) Vrij recent heb ik een stuk software buiten gebruik genomen dat ik in 2005 heb geschreven en al die tijd zonder problemen is blijven werken. Het is dat de leverancier stopte met het aanbieden van de betreffende datastroom, anders had het nog steeds gewerkt. ;-)

Dus ja, ik vind PHP maar een gemankeerd taaltje (en daar heb ik veel meer redenen voor dan ontbrekende backward compatibility), net als VBScript overigens. Maar soms zijn er geen geschikte alternatieven voorhanden, dus we doen het er maar mee. Bovendien moet een beetje vakman om kunnen gaan met de beperkingen van zijn gereedschap. Maar het blijft lastig als je een nieuwe boormachine koopt en je oude boortjes blijken niet meer te passen.

Met relatief weinig moeite heb je snel van alles werkend, dat is het mooie aan PHP. Het werkt overal, en er zijn veel mensen die er kennis van hebben en die je willen helpen.

Het nadeel is dat PHP zelf houtje-touwtje is. Het wordt steeds mooier, met steeds meer glimmend plakband, maar in de praktijk kan je code die je schrijft voor PHP goed vergelijken met wegwerpcode.
In de analogie van de boortjes, je moet bij PHP om de 3 jaar een nieuwe boormachine kopen en daardoor jouw oude boortjes vervangen die het verder nog prima deden.

En ik ben het deels met Willem eens. Je hebt met weinig kennis en moeite relatief veel relatief snel voor elkaar. Maar je moet niet vragen hoe. Vergelijk het met andere wegwerpproducten. Een IKEA-kast kan je niet goed uit elkaar halen en opnieuw in elkaar zetten, dan valt-ie half uit elkaar. Wegwerpbordjes ga je niet eens afwassen, dat is de sop niet waard. En met PHP code ga je geen grote of langdurige projecten onderhouden (bijvoorbeeld deze site?), dat kan efficiënter.

Zo kan je vrij eenvoudig overstappen naar een ander merk boormachine. Eentje die kwalitatief beter is, maar die ook meer vakmanschap vereist om in te stellen en te bedienen. Met een kleine tijdsinvestering verdien je dat zo weer terug, omdat je uiteindelijk sneller klaar bent met minder moeite; de gaten zitten in één keer recht, lubberen niet uit, en je schilderij valt niet elke 3 jaar naar beneden met deuken in de omlijsting. Het scheelt ook dat je niet met een houtboor in een betonmuur hoeft te boren.

Het gebruik van PHP valt of staat met wat je wilt maken, en voor hoe lang. In mijn ervaring gaat de behoefte aan een op maat gemaakt programma langer mee dan PHP code, waardoor ik voor die projecten geen PHP meer gebruik. Blijkbaar ben ik daar bovenuit gegroeid.
Maar, daarbij moet ik tegelijk toegeven dat het PHP is geweest dat mij in staat heeft gesteld om destijds laagdrempelig in te stappen en te groeien in mijn eigen tempo. En hoewel ik het jammer vind dat PHP niet in mijn richting is meegegroeid (het was een lange weg vanaf Internet Explorer 5), kijk ik er met een goed gevoel op terug.