PHP versies
Het is toch eigenlijk wel bijzonder dat wanneer imand de versie van PHP omhoog zet, dat je dan ineens errors krijgt!
Wie kent er nog een enkele andere programmeertaal, waarbij je bloedeigen bestaande en eerder correct geteste code ineens niet meer werkt, door 'backward incompatible changes' zelfs bij een minor versie upgrade? Bij de overgang naar PHP 8 werd zelfs booleaanse logica aangepast waardoor je feitelijk al je (unit) tests na zou moeten kijken. En je moet minimaal elke 3 jaar, liefst jaarlijks door dat hele traject heen. Omdat er elk jaar een nieuwe PHP versie komt, die maar 3 jaar ondersteund wordt met beveiligsupdates.
Uit eigen ervaring heb ik vernomen dat er bedrijven zijn die 30% (dertig procent!) van hun ontwikkeltijd volledig kwijt aan het oplossen van bugs. Als ik alleen al vanuit bedrijfsmatig perspectief kijk, dan lijken PHP-programmeurs goedkoper dan voor andere talen, maar je moet die prijzen bijna met factor 1.5 omhoog gooien als je alle bugs mee telt.
PHP wordt ook wel ingezet voor bedrijfskritische processen (heb ik zelf eerder ook gedaan). Maar ik heb het idee dat de ontwikkelaars van PHP zichzelf verheven voelen boven alles wat 'userland' is. Voelen jullie je wel serieus genomen met PHP?
Overigens ben ik niet op zoek naar de standaardreflex onder PHP-programmeurs van 'als het je niet bevalt ga je toch fijn ergens anders heen?' Dat heb ik al gedaan voor mijn belangrijkste project, Rust bleek een prima alternatief. Maar ik heb nog een aantal andere kleinere projecten die (nu nog wel) op PHP werken.
Gewijzigd op 10/07/2023 09:36:57 door Ad Fundum
Zelf programmeer ik heel veel in Python en in PyQt. Het verschil tussen PyQt 5 en 6 is enorm.
Maar ook als ik een andere package, bijv psycopg van versie 2 naar 3 update zijn er grote verschillen.
Ook de verschillen in Python 2 en 3 zijn heel groot.
Het enige voordeel is dat je dit allemaal nog redelijk zelf in de hand hebt. En bij PHP is dit toch afhankelijk van of je een eigen server hebt of een hosting. Wanneer de hosting je pusht om een nieuwe versie te gaan gebruiken of wanneer je zelf moet gaan upgraden i.v.m. security issues (maar dan kun je dit wat beter plannen).
Al met al zou je toch altijd bezig moeten blijven om alles up-to-date te houden.
Vaak zie je dat iemand een script met de display_errors UIT heeft gemaakt, maar na een update staat die setting ineens AAN.
Dan krijg je topics dat er "ineens" 100 fouten op een pagina zijn. Terwijl die er al 4 jaar waren, alleen dan niet zichtbaar.
Het je een development traject waarbij je op z'n minst een devel server hebt waarop de error-reporting hoog staat en display-errors aan, dan hadden veel van die fouten al direct verholpen kunnen worden.
Naast de fouten als $i = $i + 1; als $i nog niet bestond, (niet ernstig)
zou je ook fouten als
$Telefoon = 1;
echo $telefoon;
(wat serieuzer) hebben gezien.
Daarnaast zou je ook ruim van te voren zijn gewaarschuwd dat (voorbeeld van vorige week) dat de parameters van de functie explode() niet meer "verkeerd om" mogen staan.
Ik heb nooit de logica gezien waarom dat mocht.
De reden dat het vernielen van bestaande code door backward incompatible changes zo ontzettend slecht is, is omdat er vaak erg veel uren zit in die code. Maar dat is bij PHP duidelijk ondergeschikt aan de taal zelf.
Ik wist niet dat er ook nog andere scripttalen zijn die datzelfde principe volgen, al zie ik in jouw lijstje nog geen minor versie updates. En een groot aantal wijzigen in PHP betreft API-changes, maar een net zo aanzienlijk deel molt dus je bestaande (test)code.
@Ivo P; ik ben het niet met je eens dat het eigen schuld is. Programmeren is vaak ook een samenspel tussen programmeur en de compiler (of interpreter). Als jouw code eerst valide is, en later niet meer omdat de programmeertaal te slecht is ontworpen zodat er steeds allerlei verbeteringen moeten plaatsvinden die jouw code invalideren, dan is dat vooral ook de schuld van het slechte ontwerp van de programmeertaal.
Ik heb jaren geleden al zitten zeuren dat het onzinnig is dat er functies bestaan als utf8_encode(), die alleen kunnen transcoden van een enkele naar een enkele andere encoding, terwijl er nog 3 extensies zijn waarmee datzelfde veel beter kan. Inmiddels zijn ze deprecated, maar het kwaad is al geschied bij het verzinnen van die functies.
PHP is in het verleden nooit bedoeld als programmeertaal, maar als een C-toolkit met prefab oplossingen. Ontwikkelaars van PHP denken er zelfs zo naief over dat ze bijzonder idiote voorstellen doen, zoals flexibele functienamen. Gelukkig zijn er ook verstandiger mensen die daartegen hebben gestemd. Maar het punt is, dat er eigenlijk helemaal geen ontwerp achter PHP zat, en dat er pas achteraf een poging wordt gedaan om PHP te laten concurreren met serieuzere talen. Het probleem is dat PHP nu zo ontzettend groot is dat een ontwerp vooraf onontbeerlijk is om niet elke keer het wiel opnieuw uit te moeten vinden op allerlei terrein.
In de tijd van Rasmus Lerdorf was er ook al lang een opleiding voor computer science, alleen heeft hij zich daar klaarblijkelijk niet zoveel aan gelegen gelaten. Met als gevolg dat het nu lastiger is om een goede grote webapplicatie te maken (en te onderhouden!) in PHP dan dat het is met andere talen. Dat wordt ook onderschreven door de uitvinder van PHP:
"Yes, from many points of view, PHP is a horrible language, but if you’re in a situation where you need the shortest possible way to solve a web-related problem, have little prior experience with web programming, and long-term consequences are of little concern, then PHP makes a starts making a lot more sense."
Met andere woorden, PHP is leuk als hobby.
En ik ben het er nog niet eens mee eens, want om een goede webapplicatie te maken met PHP heb je wel degelijk heel veel ervaring en kennis nodig. Wat ik voor PHP vind spreken is dat het een lage instap biedt om überhaupt een webapplicatie te kunnen maken. Om programmeren te leren is het voor veel situaties een optie.
Gewijzigd op 10/07/2023 23:04:01 door Ad Fundum
Hoe vaak zien we niet topics langs komen van gebruikers die ineens hun scherm vol hebben staan met meldingen over "undefined index xyz" als ze de site op een andere server zetten of na een PHP upgrade waarbij de errors niet meer onderdrukt worden.
Ik kan me ook nog wel vinden in het verwijderen van functies als mysql_query() na 10 jaar of zo waarschuwen.
Gedrag veranderen als $array->$var[0] ( is dat nu $var[0] = 'X'; dus $array->x of is het
een array $array->x en dan daarvan element [0], kan wel tot onvindbare bugs leiden.
Of je om te beginnen al variabele vars wil hebben, is een tweede.
Ik denk dat PHP daar veel te flexibel is.
Waar ben je dan eigenlijk wél naar op zoek? Het lijkt erop alsof je bevestiging zoekt van jouw eigen standpunt. En als iemand daar dan op reageert, dan ben je het er niet mee eens en lijk je je eigen mening te willen opleggen.
Je hóeft niet met PHP te programmeren. Als jij liever iets anders gebruikt, prima toch? Niemand dwingt je ertoe. Op het moment dat je voor een programmeertaal kiest, dan weet je wat de gevolgen zijn. PHP wordt zeer veel gebruikt. En dat is niet voor niks. Blijkbaar voorziet het in een behoefte. En soms werken dingen niet meer en ja dan moet je een paar dingen aanpassen. Dat hoort erbij. We hebben te maken met een taal. Iedere taal evolueert in de loop der jaren op basis van voortschrijdend inzicht. Techniek evolueert op basis van voortschrijdend inzicht. Dat is maar goed ook, want stilstand is achteruitgang. Dingen waarvan men ooit dacht dat ze logisch waren, worden op basis van voortschrijdend inzicht verbeterd. Ik neem aan dat jouw allereerste website ook van een ander, minder, niveau was dan je laatste website? Ik neem aan dat ook jouw eigen inzicht en technieken in de loop der jaren zijn gewijzigd en verbeterd? Zo werkt het met alles. Herinner je je nog VHS, cassettebandjes, cd's? Ooit heel normaal, nu ouderwets. Alles evolueert, zo ook een programmeertaal. En ja, dan verdwijnen soms functies of ze worden aangepast. En ja, dat houdt in dat je soms zelf ook even iets moet aanpassen. Maar weet je ... zo is het leven. De dingen om ons heen veranderen. Dat geldt voor alles en niet alleen voor PHP.
mijn SD kaart van 128MB past niet meer in mijn nieuwe camera. Dat moet nu een micro SD zijn en 128MB is bij lange na niet voldoende;
Mijn telefoon kan niet met een mini-sim overweg (ik heb ooit een toestel gehad waar dat hele creditcard-formaat stuk plastic als SIMkaart in moest, zonder er iets uit te drukken).
Sowieso denk ik dat dat toestel zich op de huidige gsm-netwerken niet kan aanmelden.
App's op telefoon doen het niet meer sinds een update van de Android-versie.
Ik heb hier een printer staan die geen drivers heeft voor Windows 11.
MEt een oudere auto moet je bij het tanken extra stoffen toevoegen omdat euro-95 niet voldoet. En al helemaal niet als het E10 is.
Met die auto mag je dan verschillende binnensteden niet meer in.
TV kijken met een antenne? Moet nu digitaal.
Kortom: verandering zit op vele vlakken, niet alleen in PHP.
En soms moet je je daarop aanpassen.
Ozzie PHP op 11/07/2023 10:06:42:
>> Overigens ben ik niet op zoek naar de standaardreflex onder PHP-programmeurs van 'als het je niet bevalt ga je toch fijn ergens anders heen?'
[..]
Je hóeft niet met PHP te programmeren. Als jij liever iets anders gebruikt, prima toch?
[..]
Je hóeft niet met PHP te programmeren. Als jij liever iets anders gebruikt, prima toch?
Dat is de reactie waar ik niet naar op zoek ben.
De vraag die ik met wat meer woorden stel is of er meer mensen zich niet helemaal serieus genomen voelen met PHP, doordat de makers van de taal geen rekening wensen houden met jouw code.
Ik bedoel, het ontwikkelteam zou ook voor een andere werkwijze kunnen kiezen: in plaats van het jaarlijkse incompatibility circus waardoor je je hele codebase moet nalopen en je halve testsuite, is het ook mogelijk om dat gewoon een paar jaar eens niet te doen.
Fix in één keer alle issues met PHP onder een major release, bijvoorbeeld versie 10.
En release de rest onder minor versies zonder dat het onze code breekt. Want daar word je als bedrijf gewoon heel erg moe van, als je een groot deel van je tijd en ontwikkelbudget kwijt bent aan het fixen van dergelijke bugs.
@Ivo P, ja natuurlijk zijn er veranderingen. Maar waarom lukt het andere talen dan wel om dat niet te doen met backward incompatible changes?
Nee, ik ervaar dat niet zo.
Stel iemand heeft 5 ervaren programmeurs op de loonlijst van een bv.
Dat kost 5x 100k bruto per jaar, plus 100k reserve voor als er iemand langdurig ziek wordt.
Alleen al het fixen van bugs kost een bv dan 180k per jaar.
Een deel daarvan wordt veroorzaakt door de jaarlijkse incompatiblity changes.
Wat zou die iemand dan weerhouden om ook te kijken bij andere programmeertalen?
Ter vergelijk, een taal als K&R C is nog steeds ongewijzigd, code van 40 jaar terug compileert nog steeds.
Ik maak me hier druk over omdat ik het zonde vind van en voor PHP.
Omdat ik met 22 jaar PHP ervaring mijn webapplicatie liever in PHP had gehouden.
Maar nu mijn applicatie groter wordt, heb ik het moeten omschrijven naar een andere taal.
De conversie heeft me meer dan een half jaar gekost.
Je hebt mijn topics met meerdere overwegingen wel voorbij zien komen.
@Michael, dit is helaas gebeurd met alles in eigen beheer, inclusief de hosting.
Ik vraag me dan ook af waarom anderen daar geen of minder last van hebben?
Gewijzigd op 12/07/2023 10:46:32 door Ad Fundum
Als jij reden ziet om iets om te bouwen naar een andere taal, omdat PHP eens in de zoveel jaar her en der een aanpassinkje maakt, staat dat je geheel vrij. Voor mij is dat geen reden. PHP wordt met iedere wijziging weer een stapje beter. De developers staan (gelukkig) niet stil.
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 ?
Gewijzigd op 12/07/2023 12:45:41 door Ad Fundum
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.
Gewijzigd op 12/07/2023 19:51:55 door Ward van der Put
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.
Gewijzigd op 12/07/2023 21:02:47 door Ad Fundum
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?
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.
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. ;)
Gewijzigd op 13/07/2023 08:28:50 door Ward van der Put
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.
Gewijzigd op 22/07/2023 00:31:53 door Willem vp
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.
Gewijzigd op 30/07/2023 09:43:48 door Ad Fundum