Kernontwikkeling van PHP wordt in toekomst door PHP Foundation uitgevoerd

De ontwikkeling van PHP wordt in de toekomst door de nieuwe PHP Foundation uitgevoerd. Verschillende bedrijven, waaronder JetBrains van hoofdontwikkelaar Nikita Popov, hebben zich bij die stichting aangesloten.

Popov verlaat JetBrains om zich volledig te gaan richten op het ontwikkelen van compiler LLVM. Popov was een van de belangrijkste ontwikkelaars van PHP. Zijn vertrek is daarom een belangrijke reden om de programmeertaal onder te brengen in een stichting, die PHP Foundation is genoemd. Naast JetBrains gaan ook onder andere Laravel, Acquia, Zend en Automattic daaraan meewerken, schrijft de stichting in een blog. De PHP Foundation wordt een nonprofit die gaat zorgen voor de kernontwikkeling van PHP, al ontbreken details nog. De stichting is opgezet onder het Open Collective-model, waar andere programmeertalen en frameworks zoals Vue.js en Open Web Docs ook zijn ondergebracht.

De eerste prioriteit voor de PHP Foundation is volgens de oprichters om geld op te halen. De stichting hoopt jaarlijks 300.000 dollar aan donaties op te halen, en JetBrains vult daar nog eens 100.000 dollar bij aan. De stichting wil 'marktconforme salarissen bieden' aan core-ontwikkelaars voor de taal. "Hoe meer we ophalen, hoe meer ontwikkelaars fulltime aan PHP kunnen werken", schrijven de oprichters. Aanvankelijk krijgen die ontwikkelaars geen contracten van onbepaalde tijd. De stichting waarschuwt dat het bestuur ze altijd kan ontslaan.

De stichting begint met een tijdelijk bestuur. De samenstelling van een permanent bestuur komt als de stichting eenmaal aan de slag is. Nikita Popov is een van de bestuursleden. De stichting zegt dat het huidige proces voor RFC blijft bestaan en dat belangrijke beslissingen rondom de core aan de PHP Internals-community worden overgelaten.

Reacties (70)

[jaenster]

Ik vond de rfc altijd een prettig concept, kon altijd zien wat er aan kwam, waar over gepraat werd en waarom sommige keuzes werden gemaakt.

Het kan aan mij liggen maar is het niet beetje raar dat er leven in een taal gepompt moet worden? Dat toont toch beetje aan dat het op zijn retour is, of misschien gewoon redelijk af nu het JIT, attributes en preloading heeft en een goede class structuur. Afgezien van concurrency en generics is er niks wat php mist zo ver ik weet?

[BobV]

De RFCs blijven, ze gaan alleen ontwikkelaars financieel ondersteunen. Het is het probleem dat ieder open-source project kent: als er geen geld is, hebben mensen nog een andere baan nodig waardoor er minder tijd beschikbaar is voor open-source.

Probleem nu is voornamelijk dat de persoon die de laatste tijd heel veel gedaan heeft, stopt. De busfactor ligt helaas een beetje laag, en die proberen ze op te hogen door financiële vergoedingen beschikbaar te maken.

[Rvanlaak]

Relevant om bij het vermelden van de busfactor ook de blogpost van Joe Watkins (krakjoe, php core member) te vermelden. Zijn post van afgelopen mei was mede een aanleiding voor JetBrains om meer vaart te gaan zetten aan het coördineren van de vorming van de stichting: https://blog.krakjoe.ninja/2021/05/avoiding-busses.html

Door thePHPcc is overigens in 2019 ook een poging is gedaan een foundation op te richten. In tegenstelling met toen wordt nu aangesloten bij het volledig transparante Open Collective waardoor administratieve taken dmv oa open accounting en budgettering bij de stichting worden weggehaald.

[ro8in]

Wie stop er nu dan?

[BobV]

Nikita Popov

[ro8in]

Oeps excuus ik las het artikel verkeerd. Ik las het even als Nikita Popov stopt bij Jetbrains om bij die PHP foundation te werken. Maar die stopt gewoon helemaal met PHP en gaat aan iets totaal anders de LLVM compiler werken dus.

[HashIT]

Volgens zijn aankondiging (https://externals.io/message/116475) is bij niet helemaal weg bij PHP, maar is hij niet meer fulltime beschikbaar. Op het moment wordt hij betaald door Jetbrains om PHP verder ontwikkelen, maar dat stopt.

[xleeuwx]

daarintegen zit hij wel in het bestuur

[Toettoetdaan]

PHP heeft echt hele grote stappen gemaakt en het voelt inderdaad wel een beetje af.

Maar er is nog een hoop te winnen hoor, zo kan multithreading voor CLI nog wel wat liefde krijgen en voor non-CLI is het niet eens een optie.
Ook is het memory management bij langer lopende code niet geweldig.

Toch is PHP bij uitstek een zeer geschikte taal voor alles wat met web te maken heeft, dus dat retour wat mensen al jaren roepen zal, afgezien van de jaarlijkse programmeertaal hypes, wel uitblijven.

[Svenbuis]

Het zeiken op de taal staat denk ik sowieso los van de security van PHP.

Veel mensen die zeiken over PHP die roepen bijvoorbeeld ook al meer dan 10 jaar 'PHP is dead' e.d.. Ondertussen wordt het nog extreem veel gebruikt en in mijn ogen verre van dood.

De reden voor het gezeik heeft met name te maken dat het een erg flexibele taal is. Dit heeft vele voordelen, maar uiteraard ook vele nadelen. Doordat het zo flexibel en toegankelijk is heb je al snel mensen die zich 'PHP programmeur' noemen, maar als je dan de code bekijkt is het behoorlijk bedroevend. Voor deze mensen dwingt PHP dus te weinig af. Gelukkig is dit in de laatste jaren goed verbeterd. Als je nu code schrijft die andere gebruiken kan je in ieder geval zaken beter afdwingen.

Zoals altijd blijft een stigma op iets lang hangen, ook hier.

[AlRoke]

Het sterven van een taal kost altijd tijd, maar er zijn genoeg indicatoren die je kunt bekijken: In 2013 gaven op de SO survey 35% van developers aan ook met PHP te werken, terwijl dat op dit moment 'maar' 22% is. Voor context: JS zit op 65% nu, Python op 48%, Java op 35%, C# op 28% en C++ op 24%.

Dus ja, je hebt altijd oude codebases die onderhouden moeten worden, en Wordpress is nog steeds 1 van de meest populaire manieren om websites op te zetten, dus denk ook niet dat het in de komende 10 jaar significant zal dalen meer.

[Reactie gewijzigd door AlRoke op 24 juli 2024 01:51]

[bobdetweaker]

Zijn er sinds 2013 niet veel meer ontwikkelaars die SO zijn gaan gebruiken? De daling in percentage staat niet gelijk aan het aantal mensen dat het minder of meer is gaan gebruiken.

Populariteit uitdrukken in percentages geeft in dit geval geen duidelijk beeld en slaat alleen maar op wat er op SO gebeurd.

[AlRoke]

Natuurlijk, SO is maar 1 bron, in mijn ogen een extreem goede bron (hoe meer gebruikers het gebruiken, hoe groter de kans dat het percentage de realiteit reflecteert), alhoewel mogelijk biased richting gratis publieke programmeertalen. Als we naar verschillende language tracking indexen kijken zien we echter hetzelfde, bij TIOBE (kijkt ook bijv. naar vacatures enzo) ging PHP van plaats 5 naar 8 in de laatste 10 jaar. Volgens IEEE (een andere industry wijde index) staat PHP niet eens meer in de top 10 (plaats 13).

[SPee]

Percentages geven wel een beeld van wat de populatie (op Stackoverflow) gebruikt.
Die nieuwe ontwikkelaars op SO zullen niet allemaal dezelfde programmeertaal gebruiken. Die zullen over die programmeertalen verdeeld zijn. Eventuele verschillen door de grotere aantallen zullen klein zijn.

Wat je wel kan zien is de trend. Met PHP gezakt van 35% naar 22%, dan zal die groep ergens anders heen gegaan zijn. En Javascript is van 48% naar 60% gegaan. Met de ontwikkeling van node.js is het best aannemelijk dat een groep daarnaartoe is gemigreerd.

[mcDavid]

En toch draait het overweldigende deel van het internet nog altijd op PHP:
https://arstechnica.com/g...de-programming-languages/

Ik denk dat er eerder gewoon méér JS en Python developers bij zijn gekomen, maar dat zegt niets over het absolute gebruik van PHP.

[AlRoke]

Die percentages zijn het absolute gebruik, dus als iemand zowel JS, Python en PHP gebruikt dan telt dat voor alle 3. Dus het absolute percentage van developers dat PHP gebruikt is van 35% naar 22% gezakt.

Wat betreft W3Tech, hun reports zijn betaald, maar zover ik weet is het grootste gedeelte van het web gewoon 'unknown'. PHP 'by default' exposes itself, dus de meeste websites die het gebruiken zijn makkelijk te herkennen. Daarnaast is het kijken naar 'aantal websites' een stuk slechtere indicatie dan 'aantal programmeurs', want 1 programmeur kan makkelijk duizenden websites online zetten en dat zegt weinig over de populariteit van PHP en meer over het feit dat PHP primair voor websites wordt gebruikt.

[Reactie gewijzigd door AlRoke op 24 juli 2024 01:51]

[Svenbuis]

Percentages zijn nooit cijfers van 'absoluut gebruik'. Voorbeeld:

35% van 1.000.000 = 350.000
22% van 1.590.909 = 350.000

Absoluut gebruik is niet verandert. De pool waaronder het gebruik gemeten is wel. Kortom, het kan best kloppen dat het absolute gebruik niet is afgenomen. Kortom, de context van de gegevens percentages ontbreekt.

Een daling in percentage zie ik niet perse als een taal die dood gaat. Vroeger kon je veel minder met javascript en noemde mensen zich zeker niet echt 'javascript developer'. Dat is nu wel anders, maar nog steeds wordt het veel naast een andere taal gebruikt.

Als ik bijv. javascript erbij ben gaan doen, is het aantal mensen die javascript doet toegenomen. Mensen die PHP doen alleen niet gedaald.

[Reactie gewijzigd door Svenbuis op 24 juli 2024 01:51]

[NoobishPro]

Wat hij denk ik bedoelt is dat er gewoon aanzienlijk minder vraag was voor JS devs toen PHP in zijn prime was. Tegenwoordig is een interactieve website/applicatie een must en daarom zijn er aanzienlijk meer JS devs bij gekomen. Een nieuwe instroom dus, als het ware.

Er zijn nu tenslotte ook veel meer devs dan destijds. En iets als "PHP 'by default' exposes itself" kun je 1 op 1 overnemen voor JS.

Iedere taal (en al helemaal JS) heeft z'n eigen problemen en voordelen. Daarom bestaan er ook zoveel. PHP gaat eigenlijk nog prima en lijdt vooral onder stigma. Het maakt mij niet zoveel uit hoe succesvol het is/wordt/blijft, hoor, maar het is wel kort door te bocht om te stellen dat het een stervende taal is.

[AlRoke]

Er zijn nu tenslotte ook veel meer devs dan destijds. En iets als "PHP 'by default' exposes itself" kun je 1 op 1 overnemen voor JS.

Dit is zover ik weet niet waar, als ik naar mijn meest recent node.js project kijk is er geen 'x-powered-by' header of iets vergelijkbaars.

Na wat googlen zie ik echter dat Expres (veruit de meest populaire node.js library) het wel degelijk exposed, dus in praktijk is het verschil kleiner dan ik dacht.

Iedere taal (en al helemaal JS) heeft z'n eigen problemen en voordelen. Daarom bestaan er ook zoveel. PHP gaat eigenlijk nog prima en lijdt vooral onder stigma. Het maakt mij niet zoveel uit hoe succesvol het is/wordt/blijft, hoor, maar het is wel kort door te bocht om te stellen dat het een stervende taal is.

Zelf heb ik zo iets van: Iedere taal heeft z'n eigen problemen en voordelen, en het enigste wat mij uitmaakt is hoe populair het is, want ik wil niet eindigen zoals een familielid die een expert is in Progress/OpenEdge wat een echte 'dode taal' is in mijn ogen. Uiteindelijk is het gewoon ook werk, en om de vrijheid te hebben een bedrijf te kiezen moet er een gezond grote markt zijn. Op dit moment is die er nog voor PHP, maar dat is niet een garantie, dus het kijken naar trends is nuttig.

[Reactie gewijzigd door AlRoke op 24 juli 2024 01:51]

[NoobishPro]

Ik ben blij dat je in ieder geval dat gedeelte kunt erkennen. Dat toont dat je niet al te bevooroordeeld bent.

Een argument wat ik zou willen maken is dat het voorbeeld wat jij noemt, van b.v. "Expres", één van die voor-en nadelen is welke ik wilde benoemen. Node is bijna compleet gebouwd op plugins en modules. Hierin leg je het vertrouwen dus bij veel verschillende partijen en uiteraard krijg je hiermee ook een grotere kans op conflicterende modules.

JS is eigenlijk een nog flexibelere taal dan PHP en de problemen waar PHP van werd beschuldigd zijn hier dus aanweziger. Deze problemen van PHP stammen van een tijd waarin JS nog extreem onpopulair was (en zelfs standaard uit stond in browsers). Waar JS deze zaken laat afhandelen door bijzaken zoals typescript, modules en wat dan ook, doet PHP eigenlijk al jaren lang exact hetzelfde. Hiervoor hebben we libraries, IDE's en frameworks.

Ik zelf werk liever met vanilla PHP en vanilla JS, maar die security flaws zijn eigenlijk erg makkelijk op te lossen met wat "good practice". De valkuilen liggen voornamelijk bij onervaren developers en dat geldt naar mijn inzien voor zowel node als PHP.

PHP is een absoluut heerlijke taal voor een boel zaken. Het werkt ook heerlijk samen met een JS-based front-end. Je kunt er ook heerlijk snelle kleine scriptjes mee schrijven voor applicaties welke bijvoorbeeld voornamelijk front-end based zijn, maar je met PHP het e.e.a. aan data of verificatie wil afhandelen. Het is flexibel en er zijn dingen mee mogelijk welke (destijds) niet zo makkelijk mogelijk waren met ASP, c#, etc.

Waar deze andere hele strikte talen juist steeds minder strikt zijn geworden zodat ze bij konden blijven met de tijd, staan PHP en JS eigenlijk aan de andere kant van dit spectrum. Deze waren juist gigantisch flexibel, en bieden nu steeds meer opties aan om strikter te werken.

Ik zie dit dus meer als een 'natuurlijke evolutie en verbetering' dan een 'hahaha hoe slecht, want taal X'. Werkelijk iedere taal heeft zijn voor- en nadelen. Welke taal je ook noemt, dit blijft een waarheid. JS en PHP lijken in zowel werking als syntax enorm veel op elkaar. Ik zelf vind globals ook heerlijk handig voor specifieke doeleinden. Semantieke regeltjes als "gebruik nooit globals" zijn gemaakt voor mensen die niet weten wat ze doen. Mensen die wel weten wat ze doen, kunnen er echter enorm veel profijt uit krijgen. Hoe specialistischer je bent, hoe meer je de voordelen van een taal lief gaat hebben en de werkelijkheid is dat zo'n 70% van developers waarschijnlijk niet erg specialistisch zijn en enkel de laatste zo makkelijk geld verdienend mogelijke trend volgen. Zie als voorbeeld zaken zoals Magento, Wordpress, Angular, Laravel, React en ieder ander "framework of the week" welke intussen is gekomen en gegaan.

Kleine edit: We spreken nu bijvoorbeeld over "JS", maar je merkt al dat het erg moeilijk is voor mensen om over 'vanilla JS' te spreken. Ze spreken vaak eerder over angular, vue, react, node enz.
Ze hebben het feitelijk dus niet eens over de taal zelf maar hun eigen werkwijze en dat spreekt, vind ik, boekdelen over de daadwerkelijke kennis van de taal.

[Reactie gewijzigd door NoobishPro op 24 juli 2024 01:51]

[bazzi]

Als hij nog een baan zoekt, dan weet ik er wel een voor een Progress programmeur. Niet aan te komen ;-)

[JonKoops]

Doordat het zo flexibel en toegankelijk is heb je al snel mensen die zich 'PHP programmeur' noemen, maar als je dan de code bekijkt is het behoorlijk bedroevend.

Ik moet zeggen dat dit ook een bekend probleem is in andere communities zoals JavaScript en Python.

[Anoniem: 1193572]

Als ik iets heb gezien over de laatste 20 jaar, is het wel dat de populariteit van een programmeertaal behalve 'baangarantie' weinig toevoegt voor een gemiddeld bedrijf, en zelfs vaak nog een verborgen probleem met zich mee brengt.

Vanaf een recruitment perspectief is de formule simpel: Focus je op de talen die momenteel 'hot' zijn, want programmeurs willen graag met 'coole' talen werken, wat jou als startup / bedrijf helpt om snel stappen te maken.

Echter werkt het in de praktijk toch iets anders, namelijk dat juist de talen die 'hot' zijn vaak volzitten met zowel programmeurs die vandaag zijn begonnen, programmeurs die elke ~1,5 jaar van taal wisselen, programmeur die een miljoenensalaris achterna zitten, en programmeurs die simpelweg niet zo goed zijn. Natuurlijk heb je dan ook nog de wél ervaren programmeurs, maar helaas vallen die zo weg in de massa dat het vrijwel onmogelijk is om deze aan te nemen, en dat is dan ook precies het probleem.

En niet alleen dat; vaak zijn deze talen ook juist 'hot' omdat het nieuw is, wat betekent dat het wiel (weer) opnieuw moet worden uitgevonden, wat indirect ook weer zorgt tot een langere ontwikkeltijd of 'zwaardere' onderhoudsperioden.

Nu dat PHP niet meer zo 'hot' is (en de 'Wordpress boom' die PHP zijn slechte naam heeft bezorgd min of meer op zijn einde is), merk je toch dat de gemiddelde PHP ontwikkelaar die momenteel nog in het vak zit vaak ook een stuk beter is dan de gemiddelde JS ontwikkelaar. Niet alleen in de truucjes en structuur van de code, maar ook in het werkelijk schrijven van begrijpbare code en het onderhouden hiervan. Zo'n zelfde vergelijking zou ook opgaan voor bijvoorbeeld Java & .NET.

Ik heb geen cijfers, maar ik durf met vrij veel zekerheid te zeggen dat als je momenteel een groepje PHP ontwikkelaars en een groepje JS ontwikkelaars aan een identiek product zou laten werken (incl. de 'change requests' die bij een levend product horen), dat de ontwikkel- & onderhoudstijd, de user experience, en als gevolg de kosten binnen de PHP-ploeg ongeveer gelijk zullen blijven, terwijl die binnen de JS-ploeg in het begin erg gunstig lijken, maar na zo'n 5-6 maanden bijna exponentieel zullen ver-ergeren.

Het (in mijn ogen) enige echte nadeel? De krimpende populariteit van een taal zorgt toch ook voor krimpende werkgelegenheid, wat talen/communities van developers die erg goed zijn in wat ze doen met tijd forceren om uiteindelijk toch van taal te wisselen.

[Reactie gewijzigd door Anoniem: 1193572 op 24 juli 2024 01:51]

[JonKoops]

Ik heb geen cijfers, maar ik durf met vrij veel zekerheid te zeggen dat als je momenteel een groepje PHP ontwikkelaars en een groepje JS ontwikkelaars aan een identiek product zou laten werken (incl. de 'change requests' die bij een levend product horen), dat de ontwikkel- & onderhoudstijd, de user experience, en als gevolg de kosten binnen de PHP-ploeg ongeveer gelijk zullen blijven, terwijl die binnen de JS-ploeg in het begin erg gunstig lijken, maar na zo'n 5-6 maanden bijna exponentieel zullen ver-ergeren.

Ik kom van de JS kant en om heel eerlijk te zijn deel ik deze ervaring maar in een heel kleine vorm. In mijn ervaring zijn er maar weinig 'goede' front-end developers die echt een volledig begrip hebben van het web platform en bijbehorende APIs.

Maar, als we het hebben over user-experience geloof ik echt niet dat je met een blik PHP devs echt iets goeds op kan zetten dat beter is dan wat een front-ender zou maken. Dit namelijk omdat dit gewoon niet hun probleemdomein is en ze dus voornamelijk vanuit hun stack zullen gaan bouwen, niet per se iets wat gebruiksvriendelijk is.

Niet dat front-end developers een user-interface niet kunnen verneuken, ik heb er genoeg gezien die echt verschrikkelijke producten in elkaar hebben gezet. Maar deze groep staat vaak dichter bij het UX aspect van een applicatie dan de gemiddelde PHPer.

Daarnaast is het belangrijk om een distinctie te maken tussen de HTML en CSS schilders en 'echte' JavaScript developers. Vaak begint een pagina simpel en wordt dit steeds complexer over tijd, een goede dev weet deze complexiteit in goede banen te leiden zonder dat de code onpragmatisch wordt.

Ik denk dat veel 'backend' developers de complexiteit van de front-end onderschatten. Het is een inherent complex domein doordat je veel state moet managen over tijd met veel gebruikersinteractie. Waar zeker met PHP je vaak alleen bezig bent met een request en een response en je daarna al je state uit het geheugen blaast (op database/message queues na).

Het argument dat ik dan vaak hoor is dat wij front-enders het 'te complex' maken. En dat is ook vaak bij slechte devs het geval. Maar vaak is dit soort complexiteit gewoon nodig om de gebruikerservaring op te leveren die nodig is.

[BobV]

Mensen die nu nog de taal afzeiken baseren dat voornamelijk op de oudere versies, en hebben geen weet van de huidige changes. Security is ook zeker niet slecht, maar ja, een slechte developer krijgt het natuurlijk altijd voor elkaar om gaten te maken.

[AlRoke]

Denk dat het vooral komt omdat 'de betere' developers veelal overgestapt zijn naar andere talen, dus je hebt meer 'slechtere' developers in PHP dan bij sommige andere talen, en dus zijn PHP applicaties een combinatie van 'oude codebases' + 'slechter onderhoudt'. Het resultaat is dat PHP in z'n geheel een erg slechte naam heeft.

Heb zelf jaren en jaren met PHP gewerkt, maar ondanks veel verbeteringen kan ik me geen enkele reden voorstellen om er mee te werken. Het is niet dat PHP slecht is op dit moment, maar gewoon dat het geen enkel voordeel heeft en er meer momentum en geld is bij frameworks en tooling in andere talen. Plus dat ding dat ik het idee heb dat 95% van PHP developers 'website makers' zijn en niet 'applicatie programmeurs'.

[Reactie gewijzigd door AlRoke op 24 juli 2024 01:51]

[Crew One]

Ik werk nu 20+ jaar met PHP (sinds PHP/FI) en alhoewel ik zeker de meerwaarde zie van andere talen, frameworks - is er echt nog wel plek voor PHP in mijn optiek.

Ten eerste; er is makkelijk personeel voor te vinden. Je hoeft geen universitair informaticus te zijn om in de e-commerce/retail branche inzetbaar te zijn als PHP developer. Genoeg mankracht nodig voor 'domme' financiele rapportages, simpele websites, aanpassingen, etc. (Grootste fout van mijn leven om dat wel te doen; technische informatica studeren. Nergens meiden te vinden... )

Kennis van me werkt in de embedded software branche, daar is domweg geen nederlandstalig personeel meer te vinden en gaat alles naar oostbloklanden en india. Heel irritant, zeker als iemand weg gaat. Dat probleem is er voor PHP nog niet. Als een collega vertrekt, helaas, maar iemand die PHP kan lezen, schrijven en onderhouden is nog wel te vinden.

Ten tweede; het is een mooie sweet spot tussen ontwikkelsnelheid en executiesnelheid. Voor het intensere werk zijn wij (grote e-commerce winkel) gaan interfacen met golang microservices, maar PHP speelt nog een grote rol. Vroeger had je nog wat knullige 'template' dingen zoals Smarty (bestaat nog), maar wat ons betreft is Twig al tijden een mooie en stabiele templating engine die wij veel gebruiken.

Ten derde; er is goede support voor vanalles en nogwat. MySQL. PostgresSQL. Wazige ODBC connecties met exact via OpenEdge. Memcached. Redis. FOP. SOLR. XSL/FO. Er is voor nagenoeg alles-en-dan-nogwat wel ergens support te vinden. (Dat andere talen ook veel support heeft staat overigens niet ter discussie hiermee.)

Het zal wellicht per bedrijf en wat het uit het verleden heeft meegenomen verschillen, maar PHP heeft nog steeds onze voorkeur als het gaat om webdevelopment. Pas als we tegen de grenzen gaan aanlopen gaan we eens verder kijken of we iets anders moeten inzetten. (C++ aansturing voor een PLC gestuurde inpakmachine, microservices, enz.)

Dit heeft natuurlijk ook te maken met het feit dat ons personeel PHP door en door kent en in andere talen niet zo. Zo spelen er meer dan technische redenen een rol bij de inzet van een programmeertaal.

[Reactie gewijzigd door Crew One op 24 juli 2024 01:51]

[Berlinetta]

Wat moet je kunnen voor de embedded software branche?

En heb je statistieken dat er zo weinig personeel is?


Ik probeer hiervan te leren.

[Crew One]

Voor embedded waar mijn vriend mee werkt, is het allemaal C++ werk. Statistieken heb ik niet, sorry - alleen het geklaag dat er weer een collega uit nederland is vertrokken en ze al 2 jaar niemand hebben kunnen vinden die aan hun eisen voldoet

[demianmonteverd]

Meer betalen helpt vaak.

[henkbiertank]

Ik denk dat je te lang uit de PHP community bent Nu zal ik ook een deel niet zien, want ik werk alleen aan applicaties en niet de simpele WordPress-site die je misschien bedoelt. Maar om me heen zie ik ook genoeg PHP-applicaties. Ik zie dat ook terug in de aanvragen die ik binnenkrijg als freelancer. Neemt niet weg dat er ook een groot deel websites zijn a la WordPress / Joomla / Magento etc.

[crazyboy01]

PHP is zeker niet dood oid en ik zet het zelfs nog wel eens in, bijvoorbeeld voor klanten met een shared hosting is het ook erg makkelijk om formuliertjes en dat soort dingen in PHP te doen. Daarnaast zijn er ook nog best wat bekende kant-en-klare systemen die PHP gebruiken. Veel van de ouderwetse taken zijn bij ons echter wel vervangen voor iets moderners, zo wordt er nu ook veel met runtimes als NodeJS gedaan en zijn dingen als AJAX/PHP long polling vervangen voor websockets. Maar het is niet onze specialiteit, dus altijd bij met de allerlaatste technieken zijn we ook niet.

Privé gebruik ik nog aardig wat PHP. Ik maak namelijk vaak wat scripts voor kleinere acties (soort GUI's, generators of download/uploadtaken). Die gebruik ik het liefst in de browser, host ik meestal lokaal in het netwerk en op dat moment is het gewoon erg interessant omdat ik zelf vrijwel vloeiend met PHP overweg kan, er maar een paar regels code nodig zijn in één bestand zonder extra frameworks en dependencies die je moet hebben of draaien. Een standaard webserver met PHP zonder instelwerk is dan genoeg. Dat is voor mij gewoon veel efficiënter.

Als ik in deze tijd was begonnen met webtalen, tja, dan had ik PHP misschien wel links laten liggen. Of wat oppervlakkiger geleerd, want er zijn nu wel een hoop alternatieven die ook interessant zijn. Meer dan voorheen bij het grote publiek bekend was in ieder geval.

[Reactie gewijzigd door crazyboy01 op 24 juli 2024 01:51]

[HollowGamer]

Sterker nog, die zal diezelfde fouten maken in willekeurig elke andere taal.

[YopY]

De taal zelf is prima wat security aangaat, maar de developers kunnen wel hulp gebruiken.

Een grote oorzaak van dit stereotype is een grote hoeveelheid SQL injection aanvallen waar PHP code voor kwetsbaar was. Dit komt niet door de taal zelf, maar door jarenlang aan slechte tutorials en voorbeelden.

Dat gezegd hebbende, ze hadden in de taal zelf hier ook het een en ander aan kunnen doen, door bijvoorbeeld strenge waarschuwingen te geven indien er SQL geconcatenate werd.

[NielsFL]

Wat bedoel je precies? Volgens mij is deze stichting vooral omdat het vertrek van Popov te ordentelijk te laten verlopen en niet omdat er iets mis is met PHP?

[biteMark]

Qua unit testing en debugging kan er nog ontzettend veel worden gewonnen. Ja, er zijn “mogelijkheden” maar die zijn nog steeds niet heel prettig om mee te werken en bieden beperkte mogelijkheden.

Overigens moet ik wel zeggen dat het lang geleden is dat ik voor het laatst met php heb gewerkt dus ik hoop dat bovenstaande gedateerd is.

[PatrickH89]

Er moet geen leven in een taal gepompt worden hier. Dit is gewoon een poging om het 'busprobleem' op te lossen, omdat één ontwikkelaar heel belangrijk was voor de ontwikkeling van PHP zelf. Dat zegt natuurlijk helemaal niets over het gebruik ervan. Sowieso is roepen dat 'PHP is op zijn retour' een beetje vermoeiend, zeker omdat het zo onterecht populair is.

[HashIT]

Ik denk dat de grootste uitdaging voor de doorontwikkeling van PHP ligt in het vinden die kunnen werken aan PHP zelf. Daarvoor is een hele andere skillset nodig dan de meeste gebruiker van de taal zelf bezitten. PHP wordt ontwikkeld in C en bevat onderdelen als een compiler, VM en JIT. Er is maar een hand vol mensen die nieuwe features kunnen ontwikkelen, en minder dan een hand vol mensen die echt de VM en JIT goed snappen.

Daarnaast ontbreekt het aan een sterke commerciële (Java, .NET, JavaScript) of academische (Python) ondersteuning om dit soort ontwikkelingen te ondersteunen. Zend/Perforce en Jetbrains zijn denk ik de twee belangrijkste sponsoren voor PHP internals, maar volgens mij zijn de budgetten een fractie van die van andere talen.

Ik denk dat de PHP Foundation met name de krachten kan bundelen bedrijven die wel willen investeren in PHP, maar niet iemand voltijd aan kunnen nemen aan dat te doen.

[BobV]

Ik denk dat de nuance in dit artikel niet helemaal klopt: de stichting gaat de kernontwikkeling helemaal niet uitvoeren, ze gaan de kernontwikkelaars financieel ondersteunen.

[arjankoole]

Ik denk dat de nuance in dit artikel niet helemaal klopt: de stichting gaat de kernontwikkeling helemaal niet uitvoeren, ze gaan de kernontwikkelaars financieel ondersteunen.

de kernontwikkelaars komen in dienst van. En dus wordt (veel van) de kernontwikkeling onder de vleugels van de stichting uitgevoerd.

[BobV]

De kernontwikkelaars kunnen ervoor kiezen om op papier in dienst te komen van, maar dat is absoluut geen gegeven. Dus ja, de stichting zal op die manier waarschijnlijk het overgrote deel van de kernontwikkelaars ondersteunen. Maar meer dan dat is het (momenteel) niet. Het artikel impliceert dat de volledige ontwikkeling overgenomen gaat worden door de stichting, maar dat is dus niet zo. Vandaar de opmerking over de nuance

[Rvanlaak]

Ben ik het mee eens. De uitvoering blijft volledig bij het RFC-proces en de Internals-group liggen. Heb de oprichtingsstukken doorgenomen en in tegenstelling tot wat het artikel schrijft is de top-prioriteit ook absoluut niet het ophalen van geld, maar voor de eerste fase enkel het inhuren van core developers. Uiteraard is de impliciete bijkomstigheid dat er geld nodig is, maar geld ophalen vereist andere skills dan developers vinden en inhuren.

Deze eerste fase (het vinden van core developers) hebben ze een tot twee jaar voor uitgetrokken, en pas daarna zullen ze kijken of een focus op non-core projecten mogelijk gaat zijn. Vandaar ook dat er een tijdelijk oprichtingsbestuur is aangesteld (waar Nikita Popov nog onderdeel van uitmaakt). Mijn hoop (ivm busfactor) is dat Nikita ook in de toekomst die passievere rol als bestuurder wil blijven doen.

[HollowGamer]

Aanvankelijk krijgen die ontwikkelaars geen contracten van onbepaalde tijd. De stichting waarschuwt dat het bestuur ze altijd kan ontslaan.

Ik neem aan dat dit niet 'zomaar' mogelijk is? Er moet toch altijd een (goede) reden zijn voor ontslag?

Het is jammer dat er vaak nog altijd lacherig gedaan wordt over PHP, terwijl het prima samengaat met JS/TS en andere (web)tech. Laravel laat bijvoorbeeld goed zien hoe het kan, dus dat zij worden genoemd ben ik enorm blij mee.

PHP heeft de laatste jaren enorme stappen gezet: opcache/jit, verplaatsen naar namespaces, weghalen van oude/onveilige functies en de algemene opzet van het PHP project. Ik vrees wel dat er hier comments komen over hoeveel slechte programmeurs in PHP zitten, dat de taal niet async is (wat wel kan met extensies of jobs/queues), GLOBALS, etc.

Uit ervaring kan ik je vertellen dat dit bij andere 'booming' talen zoals JS/TS ook gewoon het geval is.
Daar zie ik genoeg nog altijd eval gebruiken of HTML direct renderen zonder sanitizer, async incorrect of niet implementeren, code niet testen en client/server-side zaken door elkaar halen. Dan heb ik het gewoon over senior-(web)developers met jaren aan ervaring.

Deze fouten zal ik zelf ook maken, waar mensen werken - worden fouten gemaakt, dus voor mij mogen al die comments/artikelen over hoe slecht PHP is/zou zijn, de prullenbak in als je niet kunt reflecteren op jezelf.

[Reactie gewijzigd door HollowGamer op 24 juli 2024 01:51]

[TooMuchRAM]

Je vergelijkt PHP met JavaScript/TypeScript. Beide talen vallen in dezelfde categorie (rare vorm van OOP), beide programmeren op een basisniveau erg hetzelfde en beide zijn slecht begonnen waarna men ze nog geprobeerd heeft recht te zetten. Kortom, stront met stront vergelijken.

[HollowGamer]

Ik vergelijk PHP helemaal niet met JS/TS, probeerde enkel aan te geven welke talen momenteel booming zijn en dat daar ook fouten mee worden gemaakt. Misschien kan je mijn reactie nog een keer lezen?

Ja, er is met beide talen nog genoeg mis, maar dat wordt langzaam rechtgezet en opgeruimd. Dat betekend helemaal niet dat beide talen slecht zijn of moeten worden vervangen door iets 'beters'. PHP8 !== PHP5 en JS is ook niet meer bij de eerste generatie.

Je kan iemand wel de 'beste taal' geven, maar dan alsnog hangt het van de skills/ervaring af van de programmeur wat hij ermee doet/kan. De programmeertaal zelf zegt allemaal niet zo veel.

[TooMuchRAM]

Ik vergelijk PHP helemaal niet met JS/TS, probeerde enkel aan te geven welke talen momenteel booming zijn en dat daar ook fouten mee worden gemaakt.

Zaken als eval en HTML sanitizen zijn toch dingen die je vooral tegenkomt bij JS en TS.

Ja, er is met beide talen nog genoeg mis, maar dat wordt langzaam rechtgezet en opgeruimd. Dat betekend helemaal niet dat beide talen slecht zijn of moeten worden vervangen door iets 'beters'. PHP8 !== PHP5 en JS is ook niet meer bij de eerste generatie.

De talen zijn zeker beter aan het worden, maar uiteindelijk ben je toch de boel aan het oplappen. Je gebruik van een triple equals is op zichzelf al een betoog daaraan. JS en PHP hebben allebei geen goede start achter de rug, en hoe goed je ze ook probeert te maken, je zit toch vast aan backwards-compatibility (vooral bij JS).

Je kan iemand wel de 'beste taal' geven, maar dan alsnog hangt het van de skills/ervaring af van de programmeur wat hij ermee doet/kan. De programmeertaal zelf zegt allemaal niet zo veel.

De programmeertaal zelf zegt wel veel. JavaScript en PHP staan bekend om hun rare gedrag en de mate waarin de compiler/interpreter probeert de code uit te voeren hoezeer dat ook echt niet de bedoeling is. Dat moedigt een laksere houding aan, want waarom zou je een langere tijd doen over het schrijven van fatsoenlijke code als je ook gewoon in een paar minuten tijd wat halfbakken code kan schrijven die toch werkt? Jij zou die tijd misschien nemen, maar een heleboel mensen doen dat niet. En die code komt terecht in libraries, welke weer gebruikt worden door andere mensen. Zo kan dat nog wel een snel gaan.
Een "beste taal" bestaat niet, maar een "goede taal" bestaat wel en een "slechte taal" ook. Een "goede taal" dwingt een programmeur om fatsoenlijke code te schrijven, op zo'n manier dat slechte code schrijven een expliciete keuze is waar de programmeur voor moet kiezen. Ja, dan is het nog mogelijk om slechte code te schrijven. Maar wel een stuk lastiger. En in dat opzicht zijn JS en PHP een "slechte taal".

[Reactie gewijzigd door TooMuchRAM op 24 juli 2024 01:51]

[henkbiertank]

Dat moedigt een laksere houding aan, want waarom zou je een langere tijd doen over het schrijven van fatsoenlijke code als je ook gewoon in een paar minuten tijd wat halfbakken code kan schrijven die toch werkt?

Bij mij moedigt het allesbehalve een laksere houding aan. Een laksere houding ligt volgens mij voornamelijk aan de programmeur en niet aan de programmeertaal. Ook in andere talen kun je 'onleesbare' code schijven. En daarnaast heeft vrijwel elke taal een geschiedenis waarin fouten zijn gemaakt.

Ik motiveer mezelf tot strict programmeren in PHP en dan kun je gewoon goede code schrijven. Door de ontwikkelingen van afgelopen jaren heeft PHP zich goed ontwikkeld en zie ik het als een goede taal.

[Berlinetta]

Dit is de eerste keer hoor over HTML Sanitizer, heb je nog meer suggesties? (Vraag dit om beter te worden.)

[BobV]

Als je een prettige template engine wil gebruiken kan ik Twig aanraden: die escaped standaard input bijvoorbeeld, alvorens het te rendered (https://twig.symfony.com/). Er zijn natuurlijk een hoop alternatieven (Laravel gebruikt blade geloof ik, maar daar heb ik geen ervaring mee). Sowieso is het aan te raden om een framework te gebruiken: die vangen al zoveel common dingen op, dat je met een hoop zaken een stuk minder rekening hoeft te houden.

[gybrus]

Correct, Laravel gerbuikt inderdaad Blade: https://laravel.com/docs/8.x/blade#displaying-data

Veel template languages maken gebruik van echo tags om van taal x naar html te gaan. Binnen blade heb je bijvoorbeeld de `{{ $variable }}` syntax die alles eerst door `htmlspecialchars()` haalt en `{!! $variable !!}` om de ruwe data direct weer te geven. Dit wordt gedaan om XSS attacks te voorkomen waarbij iemand in zijn naam een stuk JS code plakt bijvoorbeeld.

Daarnaast wat @BobV al aangaf zitten er nog andere mechanieken in de meeste frameworks die iets met CSRF/XSRF of database injecties kunnen afvangen. Laravel gebruikt bijvoorbeeld middlewares om de request als het ware te filteren voordat deze uitgevoerd wordt: https://laravel.com/docs/8.x/csrf

[HollowGamer]

Het hangt allemaal wel af van je scope (user input o.a.). Laat je dus ook niet gek maken dat je die zaken allemaal nodig hebt.

Beter worden kost tijd, elke dag leer je weer bij. Dat is het leuke aan programmeren, maar ook wel weer een minpunt. Als je dus nog altijd PHP5 zit, dan zal die stap maar PHP7/8 best wel een leercurve hebben.

Persoonlijk leer ik het meeste door mij te abonneren op blogs en code te bekijken op o.a. GitHub. Sommige leren weer beter met een video platform of boek. Dus zoek vooral op wat jij het prettigst vind.

[downtime]

Ik neem aan dat dit niet 'zomaar' mogelijk is? Er moet toch altijd een (goede) reden zijn voor ontslag?

In de VS niet. De regels zijn per staat verschillend maar in de meeste staten kun je gewoon van de ene op de andere dag zonder opgave van redenen op straat gezet worden. Dat is ook waarom grote bedrijven bij economische problemen zo snel personeel ontslaan. Dat zien ze als variabele kosten waar je snel op kunt bezuinigen.

[HollowGamer]

Betekend dit ook zonder handdruk of andere oplossingen zoals reïntegratie/hulp bij het vinden van een nieuwe baan?

Vraag mij ook af hoe het zit met mensen buiten de VS die zijn ingehuurd. Al lees ik niet terug waar precies de PHP Foundation wordt opgestart?

[Bender]

Een ontslagvergoeding in Amerika is eenmaal je laatste salaris, tenzij in je overeenkomst staat dat je ontslagvergoeding krijgt maar ik acht die kans klein.

En daar moet je het dan ook ongeveer mee doen.

[downtime]

Betekend dit ook zonder handdruk of andere oplossingen zoals reïntegratie/hulp bij het vinden van een nieuwe baan?

Ja. Dit soort praktijken worden in de VS altijd verdedigd met "vrijheid" waarbij ze dan altijd het voorbeeld geven van die arme kleine ondernemer met twee man personeel die wel de vrijheid moet hebben om snel van zijn personeel af te komen als het economisch tegen zit en hij zijn bedrijf moet redden. Die moet je niet lastig vallen met allerlei complexe ontslagregels.

[HKLM_]

Aanvankelijk krijgen die ontwikkelaars geen contracten van onbepaalde tijd. De stichting waarschuwt dat het bestuur ze altijd kan ontslaan.

Lekker begin van je werving… klinkt nu al als een partij die goed is voor zijn medewerkers. not
Daar ga je toch niet werken als ze al zo gaan beginnen.

[Reactie gewijzigd door HKLM_ op 24 juli 2024 01:51]

[Bender]

Je moet ook niet bij een foundation gaan werken als je het doet om een baan te hebben, maar uit idealistisch oogpunt.

[HollowGamer]

Genoeg CEO's die goed verdienen bij foundations. Dus helemaal idealistisch oogpunt zal het niet zijn.

[demianmonteverd]

Ik vraag mij af waarom je dit denkt. Er zijn meer dan genoeg mensen die een goede boterham verdienen bij een foundation.

Het is alleen maar een extra bonus dat veel foundations werken om een verbetering in het maatschappelijk domein te realiseren.

N.B. Ik werk zelf niet voor een foundation/stichting, maar zou het zeker serieus overwegen en niet alleen voor het geld.

[OMEGA_ReD]

Ja biedt niet veel zekerheid, maar dat zal te maken hebben met de afhankelijkheid van donaties. Gelukkig is het voor goede programmeurs niet lastig om aan een job te komen.

[Reactie gewijzigd door OMEGA_ReD op 24 juli 2024 01:51]

[mcDavid]

Gelukkig is het voor goede programmeurs niet lastig om aan een job te komen.

Al helemaal niet als je "PHP Core-developer" op je CV kunt zetten...

[NielsFL]

Jij denkt dat dit bij andere bedrijven anders is? Voor zover mogelijk binnen lokale wetten handelen alle bedrijven zo.

[downtime]

Wat is daar raar aan? In de VS kun je in de meeste staten elke dag zonder opgave van redenen ontslagen worden. Bij het minste beetje tegenslag is het ontslaan van personeel voor veel bedrijven de eerste stap.

[arjankoole]

[...]


Lekker begin van je werving… klinkt nu al als een partij die goed is voor zijn medewerkers. not
Daar ga je toch niet werken als ze al zo gaan beginnen.

Iedereen zal begrijpen dat een vers startende stichting nog niet kan committeren aan contracten voor onbepaalde tijd. En iedereen snapt ook dat je altijd ontslagen kunt worden. Het wordt expliciet benoemd zodat het juridische vinkje gezet kan worden.

[Bender]

400.000 dollar per jaar, gezien het salaris van developers en dat er ook nog wel iets van projectmanagement bij komt kijken en uiteraard nog andere bedrijfskosten.. zijn dat niet heel veel developers.

Begrijp me niet verkeerd, ik leg ook geen 100k bij, maar vraag me dan wel af hoe snel het kan vorderen.

[Oon]

Veel open source projecten worden grotendeels door 1 of 2 echte fulltimers onderhouden. PHP heeft geluk dat JetBrains hier altijd wat kapitaal achter heeft gezet, anders was 2/3e van de ontwikkeling van PHP in de laatste 5-10 jaar niet gebeurd.

[downtime]

400.000 dollar per jaar, gezien het salaris van developers en dat er ook nog wel iets van projectmanagement bij komt kijken en uiteraard nog andere bedrijfskosten.. zijn dat niet heel veel developers.

Hangt ervan af wat die mensen moeten gaan doen. Als dat het hele team is, en niemand anders iets bijdraagt, dan is het inderdaad niet veel. Maar PHP is toch open source? Dan kan ik me voorstellen dat deze mensen alleen maar nieuwe functionaliteit gaan bedenken en dat ze het onderhoud van bestaande code aan "de community" overlaten.

[basmilius]

Een hele goede stap voor de toekomst van PHP. Denk dat dit de ontwikkeling van PHP meer gaat stimuleren

[thePiett]

Zonde dat Nikita vertrekt. Hij heeft zoveel gedaan voor PHP. Hopelijk blijft hij nog een tijd in het bestuur.