PHP 8 is op komst

JIT, stable sorting en meer vernieuwingen

Het ontwikkeltraject van PHP

Sinds de release van PHP in 1997 heeft de taal een flinke ontwikkeling doorgemaakt. Het begon als een eenvoudige wrapper om C, zodat Rasmus Lerdorf sneller websites kon bouwen, maar de syntax van versie 7.4 lijkt weinig meer op deze eerste PHP-release.

De reputatie dat PHP geen serieuze ontwikkeltaal zou zijn, ligt al ver achter ons. Bijna 80 procent van alle websites die aan de serverzijde worden opgebouwd, zijn geschreven in PHP. Ook de leukste techsite van Nederland is 'powered by' PHP.

In december verschijnt een nieuwe major versie, PHP 8. De eerste testversie van PHP 8 is al drie maanden beschikbaar en de eerste release candidate staat gepland voor 17 september. Met een feature freeze ruim een maand achter ons, is dit een mooi moment om te kijken welke veranderingen PHP 8 met zich meebrengt.

ElePHPant, de mascotte van PHP

RFC-proces

Om te begrijpen hoe deze nieuwe versie van PHP tot stand is gekomen, is het belangrijk om te kijken naar het ontwikkeltraject. Het begint met de beschermers van PHP, de core developers. Dit zijn de ontwikkelaars met de meeste ervaring met het werken in de broncode van PHP en zij handelen de bugreports af. Zij hebben de bijkomende taak om de ontwikkeling van PHP in de juiste richting te sturen. Niet alleen de broncode van PHP is open, maar ook het ontwikkeltraject. Het staat iedereen die een beetje karma heeft verzameld, vrij een Request For Comments in te dienen om de taal te verbeteren.

Of een RFC slaagt, hangt ervan af of de auteur de core developers heeft kunnen overtuigen van het nut van de RFC. De core developers kijken niet alleen naar het voorstel zelf, maar ook naar de impact op de rest van de taal, of het strookt met de visie van PHP en in hoeverre er rekening gehouden is met backwards compatibility.

Voor beginners is het verstandig om onderzoek te doen en de wijziging te polsen bij de core developers, zodat er geen onnodige energie wordt gestoken in een voorstel dat het waarschijnlijk toch niet gaat halen. Een voorstel om de functienamen en volgorde van argumenten gelijk te trekken, zal waarschijnlijk niet worden geaccepteerd, omdat de gevolgen hiervan te groot zijn.

Wanneer een voorstel genoeg steun heeft, kan deze door een lid op de wiki worden gepubliceerd, en worden aangekondigd op de PHP-mailinglist. Daarna volgt er een discussiefase, waarbij iedereen vragen kan stellen en voorziene problemen kan aankaarten over de RFC. Deze vragen en problemen worden allemaal in de RFC vastgelegd. Wanneer de discussie afgerond is, maar niet eerder dan twee weken na publicatie van de RFC, volgt er een stemming. De stemming is altijd een ja/nee-stem waarbij een tweederdemeerderheid nodig is om de RFC te laten slagen. Soms zijn er naast een ja/nee-stem ook nog een of meerdere vervolgstemmingen, die kunnen gaan over de implementatieaanpak. Het stemmen is voorbehouden aan ontwikkelaars die hebben bijgedragen aan de broncode van PHP, afgevaardigden vanuit de PHP-community en vaste deelnemers aan de interne discussies.

Snelheidswinst

De upgrade van PHP 5 naar 7 heeft er voor gezorgd dat veel websites veel sneller konden worden gerenderd, zonder dat de PHP-code aangepast hoefde te worden. Dit kwam door de update van de virtuele machine die de php-code uiteindelijk uitvoert, de zend engine, van versie 2 naar 3.

Dmitry Stogov, de ontwikkelaar die de taak op zich had genomen om PHP sneller te maken, wilde in het begin snelheidswinst behalen met JIT. Hij hoopte PHP-code sneller uit te kunnen voeren door deze vlak voor de uitvoering om te zetten naar machinecode, net als in bijvoorbeeld Java.

Hij merkte echter dat het geheugenbeheer en de interne functies knelpunten waren voor de uitvoeringstijd. Hij besloot daarom om dit eerst te verbeteren, in de hoop dat PHP-code sneller uitgevoerd kon worden. Na een paar maanden werk bleek inderdaad dat er een flink snelheidswinst was behaald, en stond deze proof of concept met de naam phpng aan de wieg van zend engine versie 3.

In PHP 8 wordt nu wel JIT geïntroduceerd. JIT, of just in time, is een manier om een script te compileren voordat het wordt uitgevoerd. Dit is de tegenhanger van AOT, of ahead of time, waarbij je vooraf een programma compileert, zoals het geval is in bijvoorbeeld C en C++.

Het voorstel om JIT op te nemen in PHP 8 werd vorig jaar maart met ruime meerderheid aangenomen

Om te begrijpen wat dit als voordeel heeft, is het belangrijk om te begrijpen hoe PHP uitgevoerd wordt. Een PHP-script wordt eerst door een lexer omgezet naar tokens, die daarna door een parser worden omgezet naar een abstract syntax tree, of AST. De AST wordt vervolgens gecompileerd naar opcodes die door de virtuele machine worden uitgevoerd. In PHP 7 kan de opcache-extensie de gecompileerde versie in het geheugen opslaan, zodat het lexen, parsen en compileren niet steeds opnieuw gedaan hoeven te worden en de opcodes direct in de virtuele machine worden uitgevoerd. Hierdoor kunnen veelgebruikte scripts sneller worden uitgevoerd.

JIT gaat een stap verder en slaat niet de opcacheversie van een script op, maar compileert de opcode naar machinecode, zoals x86-instructies. Hiermee wordt de code dan niet in de virtuele machine, maar direct op de processor uitgevoerd. Hiermee kunnen scripts in theorie nog meer snelheidswinst behalen. De kanttekening hierbij is dat dit vooral voordeel heeft voor code die gebonden is aan de cpu. Veel PHP-applicaties zullen echter vooral io bound zijn, omdat ze bijvoorbeeld wachten op een database. Het is dus de vraag in hoeverre JIT voor websites die geschreven zijn in PHP voor snelheidswinst kan zorgen. Het lijkt daarom dat JIT vooral interessant kan zijn om andere typen applicaties te maken in PHP. Tevens zou het een alternatief kunnen zijn voor sommige extensies die nu nog in C geschreven zijn, om deze om te zetten naar PHP-code.

Veranderingen onder de motorkap

Negatieve sleutelwaarden uitbreiden

Het is in PHP mogelijk om een array uit te breiden met een nieuw element, waarbij de sleutelwaarde ‘doortelt’ aan de hand van de hoogste sleutelwaarde. Dit doortellen werkt alleen als de sleutelwaarde 0 of groter is. Is er geen sleutelwaarde van 0 of groter, dan begint het doortellen bij 0.

<?php
$d[-2] = true;
$d[] = true;
$d[] = true;

In PHP 7.4 en lager geeft dit een array met de sleutelwaarden -2, 0 en 1. In PHP 8 is de restrictie vervallen dat een sleutelwaarde 0 of groter moet zijn. Dit houdt in dat in PHP 8 de sleutelwaardes -2, -1 en 0 zijn.

Nog meer veranderingen

PHP heeft de afgelopen releases vaker wijzigingen doorgevoerd die de ontwikkelaar in staat stellen de taal strikter te gebruiken. De declare(strict_types) van versie 7 is daar een recent voorbeeld van. Ook de standard PHP library, of SPL, lijkt strikter te worden, of in ieder geval consistenter, door vanaf PHP 8 vaker een error te geven. Nikita Popov, een van de coredevelopers, heeft hiervoor een RFC ingediend en deze ook zelf gebouwd. Hierdoor zullen meer functies die een argument van het verkeerde type ontvangen, geen waarschuwing geven, maar een TypeError geven, zoals nu ook gebeurt in userlandfuncties met type hinting.

Een andere technische wijziging in PHP 8 is de zogenaamde stable sorting. Voor PHP 8 was de positie van elementen met dezelfde waarde in een array na sortering niet gegarandeerd. Het kan dus betekenen dat die elementen na sortering in een andere volgorde staan. PHP 8 biedt de garantie dat elementen in dezelfde volgorde staan als voor de sortering, wanneer elementen gelijk aan elkaar zijn. Dit lijkt een klein verschil, maar kan bij bepaalde code subtiele bugs veroorzaken. Deze zullen dan waarschijnlijk aan het licht komen bij de upgrade naar PHP 8.

Syntax-wijzigingen

PHP 8 heeft enkele RFC’s geaccepteerd die vooral het lezen en typen van code makkelijker maken, zonder dat dit effect heeft op de uitvoering van een script.

Verbeterde argumentdefinitie in functies en closures

Het zal in PHP 8 mogelijk zijn om een lijst van argumenten te laten eindigen met een komma in een functie-definitie en in closures, zonder dat hier een nieuw argument op volgt. Dit was al mogelijk binnen een arraydefinitie, en bij het aanroepen van functies, maar nu dit ook bij functiedefinities mogelijk is, wordt de taal consistenter. Het voordeel van het toestaan van zo’n komma is dat de diff patches simpeler zijn, en het maakt het toevoegen van nieuwe waarden eenvoudiger.

Constructor property promotion

Een andere wijziging in PHP 8 is de mogelijkheid om eenvoudiger een value object te maken dankzij constructor property promotion. Hiermee kan een ontwikkelaar op één plaats in een klasse het type met de zichtbaarheid, toekenning en een eventuele standaardwaarde definiëren van een property, in plaats van dit op drie plaatsen te moeten doen. De RFC voor deze wijziging heeft het volgende voorbeeld van code in PHP 7.4:

<?php
class Point {
	public float $x;
	public float $y;
	public float $z;
 
	public function __construct(
		float $x = 0.0,
		float $y = 0.0,
	float $z = 0.0
	) {
		$this->x = $x;
		$this->y = $y;
		$this->z = $z;
	}
}

Met constructor property promotion kan deze code in PHP 8 als volgt worden geschreven:

<?php
class Point {
	public function __construct(
		public float $x = 0.0,
		public float $y = 0.0,
		public float $z = 0.0,
	) {}
}

De code hoeft minder vaak te worden getypt, waardoor er minder kansen zijn op fouten bij het maken en refactoren van code.

Uitgelichte nieuwe functionaliteiten

Naast optimalisaties en aanpassingen van de syntax, heeft PHP 8 weer een aantal nieuwe functionaliteiten die het werk van ontwikkelaars makkelijker kunnen maken. Hier volgt een overzicht van een aantal geaccepteerde RFC’s.

Attributes

Voor veel volgers van de ontwikkelingen van PHP 8 zijn attributes de feature waar het meest naar uitgekeken wordt. Dit is ook te zien aan het aantal RFC’s, want een groot deel van de RFC’s verwijzen direct of indirect naar attributes.

De eerste poging om attributes aan PHP toe te voegen stamt uit 2016, deze RFC haalde toen onvoldoende stemmen. Met PHP 8 worden attributes een onderdeel van de taal. De nieuwe RFC is inhoudelijk anders dan het aanvankelijke voorstel voor attributes, maar de belangrijkste reden dat deze nu wel is geaccepteerd, is waarschijnlijk dat de taal nu wel 'rijp' is voor deze toevoeging.

Het concept van attributes is in Java beter bekend als annotations en in Python als decorators. Het is een manier om metadata toe te kennen aan een klasse, interface, eigenschap, (anonieme) functie, methode, klasseconstante of hoedanigheid. Deze metadata kan vervolgens worden uitgelezen met de reflectionextensie.

Ondanks dat PHP geen officiële ondersteuning had voor attributes, werden door verschillende applicaties en frameworks alternatieven bedacht. Een veelgebruikt alternatief is het gebruik van annotations in doc-comments, waar een regel in de doc-comment begint met een apenstaartje gevolgd door een trefwoord dat een speciale betekenis heeft. Het nadeel van het gebruik van doc-comments is dat de applicatie of framework zelf de inhoud van een doc-comment moet parsen. Door attributes onderdeel te maken van de syntax van PHP kunnen deze attributes simpelweg worden uitgelezen met Tokenizer, een standaardonderdeel van PHP.

Een attribute wordt als een klasse geresolved en geïnitieerd, die zelf voorzien moet zijn van een attribute om aan te geven dat deze geschikt is als attribute. Een attribute kan optioneel argumenten bevatten, die in de constructor van deze klasse worden meegegeven. De RFC laat vrij wat een attribute precies doet. Een attribute kan bijvoorbeeld gebruikt worden door een framework om methodes in een klasse te markeren als een route, of door een ORM om variabelen te voorzien van de benodigde metadata voor het opslagtype.

<?php
// PHP 7
class Product
{
	/**
	* @ORM\Id
	* @ORM\Column(type="integer")
	* @ORM\GeneratedValue
	*/
	protected $id;
}
 
// PHP 8
class Product
{
	#[ORM\Id]
	#[ORM\Column(type="integer")]
	#[ORM\GeneratedValue]
	protected $id;
}

De RFC stipt aan dat het gebruik van attributes daarnaast de weg vrij maakt voor PHP om deze attributes zelf te gaan gebruiken. Zo zouden attributes in de toekomst bijvoorbeeld gebruikt kunnen worden om PHP te helpen met het markeren van functies die wel of niet geschikt zijn voor JIT.

De RFC heeft een makkelijke overwinning behaald, maar er volgden nog enkele RFC’s over de implementatie. In de eerste geaccepteerde versie was er sprake van om << en >> te gebruiken als scheidingstekens voor attributes, maar als snel volgde er een verhitte discussie of dit leesbaar, makkelijk te schrijven is en niet verwarrend is voor de al bestaande bitwise operations. Daarna volgde een RFC om @@ te gebruiken en op de valreep een RFC om toch "#[" als start- en "]" als eindmarkering te gebruiken. Ook andere 'details', zoals het attribute dat een attribute zelf markeert en of een attribute als een enkele token of reeks tokens wordt gezien, zijn besproken in daaropvolgende RFC’s.

Union types

PHP 8 komt met union types ontwikkelaars tegemoet die type hinting willen gebruiken voor meerdere types. Met de union type kan een ontwikkelaar meerdere type hints voor dezelfde parameter specificeren, zonder hiervoor speciaal een Interface aan te maken. Naast meerdere klassen te specificeren, kunnen ook scalars in union types gebruikt worden.

Er is ook een speciaal type false dat in een union type kan worden aangegeven. In PHP zijn er een aantal functies die een waarde teruggeven, of in het geval dat er iets misgegaan is: false. Userlandfuncties kunnen dat met deze pseudo type ook aangeven. Dit is semantisch gezien correcter dan bool als return type, omdat dit impliceert dat er ook true teruggeven zou kunnen worden.

<?php
class SimpleCache {
	private array $storage;
 
	public function setData(string $key, string|int|float $data): void {
		$this->storage[$key] = $data;
	}
	public function getData(string $key): string|int|float|false {
		if ( ! array_key_exists($key, $this->storage)) {
			return false;
		}
 
		return $this->storage[$key];
	}
}

Non-capturing catches

In 2013 was er een RFC ingediend voor een anonieme try-catchconstructie. Die RFC is toen gesneuveld voor de stemronde, maar een nieuwe RFC met een bijna identiek voorstel is met een overgrote meerderheid geaccepteerd voor PHP 8. Dankzij deze RFC is het in PHP 8 mogelijk om een try-catchconstructie te schrijven, zonder de exception aan een variabele toe te kennen. Het voorbeeld vanuit de RFC:

<?php
try {
	changeImportantData();
} catch (PermissionException $ex) {
	echo "You don't have permission to do this";
}

De exception wordt aan de $ex-variabele toegekend, maar niet gebruikt. Dit kan intentioneel zijn, maar wellicht heeft de ontwikkelaar vergeten iets met de exception te doen. In PHP 8 is het mogelijk om dit als volgt te schrijven:

<?php
try {
	changeImportantData();
} catch (PermissionException) {
	echo "You don't have permission to do this";
}

Hiermee is het voor de lezer duidelijk dat de ontwikkelaar de exception alleen wil afvangen, maar verder niet wil gebruiken.

Named arguments

Met named arguments is het in PHP 8 mogelijk om per argument op te geven welke parameter daar bij hoort. Zo kunnen optionele argumenten worden overgeslagen, en kan het de leesbaarheid vergroten als er meerdere argumenten zijn.

In het volgende voorbeeld wil een developer enkel de parameters string en double_encode doorgeven aan htmlspecialchars, maar omdat de double_encode de vierde parameter is, moet de developer ook parameters 2 en 3 opgeven met de juiste standaardwaarden. Ook is het niet duidelijk bij welke parameter false hoort. In PHP 8 kunnen de andere parameters overgeslagen worden, en is ook direct duidelijk dat false het argument voor double_encode is:

<?php
// PHP 7
htmlspecialchars($string, ENT_COMPAT|ENT_HTML401, ini_get('default_charset'), false));
 
// PHP 8
htmlspecialchars($string, double_encode:false);

Match expression

PHP 8 introduceert de match expression: een variant op de switch statement die een strikte vergelijking doet, geen fallthrough heeft en direct aan een variabele kan worden toegekend.

<?php
$winner = match (1337) {
	1336 => 'Adriaan',
	1337 => 'Henk',
	1338 => 'Bassie',
};

Nullsafe operator

De nullsafe operator maakt het eenvoudiger om methodes te chainen, zonder expliciet op null te hoeven testen. De nullsafe operator onderbreekt de chain zodra er een null-waarde in de chain optreedt.

<?php
// PHP 7
$theAnswer = null;
 
if ($earth !== null) {
	$human = $earth->extractHuman('Arthur Dent');
 
	if ($human !== null) {
		$brain = $human->getBrain();
 
		if ($brain !== null) {
			$theAnswer = $brain->getAnswer();
		}
	}
}
 
// PHP 8
$theAnswer = $earth?->extractHuman('Arthur Dent')?->getBrain()?->getAnswer();

Standard PHP Library-aanpassingen

Buiten de engine beschikt PHP ook over een uitgebreide verzameling interne functies: Standard PHP Library, of SPL.

Philipp Tanlak, een PHP-gebruiker, heeft zijn eerste RFC ingediend voor str_contains, een functie die kijkt of een substring voorkomt in een string. PHP heeft al sinds versie 4 de strpos-functie, die de positie van een substring in een string aangeeft en begint bij 0. Een probleem doet zich volgens de RFC voor, wanneer de uitkomst van deze functie wordt vergeleken met een boolean. Het probleem ontstaat doordat een integer 0 naar boolean false wordt gecast als de substring in de string voorkomt op de eerste positie.

De nieuw voorgestelde functie str_contains zal altijd een boolean geven, waardoor dit veiliger is te gebruiken als deze met een boolean true of false wordt vergeleken.

Will Hudgins, eveneens een onbekende in de wereld van RFC’s, heeft voorgesteld om ook str_starts_with en str_ends_with-functies te introduceren, die net als str_contains een boolean teruggeven. Deze RFC is ook geaccepteerd en daarom zullen deze drie functies in PHP 8 beschikbaar zijn.

Deprecations

Ondanks dat RFC’s onder andere beoordeeld worden op backwards compatibility, is PHP 8 een nieuwe major versie en zullen er dus zaken worden verwijderd die niet meer ondersteund zijn.

PHP heeft de conventie om zaken die worden verwijderd, eerst als deprecated te markeren, voordat deze in een major versie worden verwijderd. Wanneer ontwikkelaars dus goed hun logbestanden in de gaten hebben gehouden, en geen minor versie overslaan bij het upgraden, zullen deze afschrijvingen niet onverwachts komen.

Tot slot

Om op de hoogte te blijven van alle veranderingen van PHP kun je de RFC's gaan lezen, je op de nieuwsgroep van PHP abonneren of een PHP-usergroep in de buurt opzoeken.

Voor een volledig overzicht kun je bij de release notes van PHP 8 kijken, en kom je beslagen ten ijs wanneer je gaat upgraden. Wat PHP 8.1 ons zal brengen, is nog niet duidelijk, maar de eerste RFC's zijn alvast geschreven.

Reacties (200)

[David Mulder]

De reputatie dat PHP geen serieuze ontwikkeltaal zou zijn, ligt al ver achter ons. Bijna 80 procent van alle websites die aan de serverzijde worden opgebouwd, zijn geschreven in PHP.

Aantal dingen om stil bij te staan:

• De 80% komt waarschijnlijk van deze site en de echte claim is dat 80% van de website waar de backend taal kon worden herkend in PHP zijn. Dit is een groot verschil want PHP is traditioneel gebouwd rondom het idee dat je een '.php' extensie hebt die je ook op de frontend kunt zien. Dit maakt php 1 van de weinige talen waar je de server side programmeertaal vaak kunt herkennen aan de cliënt.
• Voor het maken van websites heb je geen serieuze ontwikkeltaal nodig. Het idee dat PHP geen serieuze programmeertaal is bestaat zeker nog steeds. Niet dat ik het eens ben met dat idee, maar om te stellen dat dat 'ver achter ons' ligt kan ik echt niet herkennen. Ik heb al in geen jaren een nieuwe applicatie gezien die in PHP werd ontwikkeld, enkel websites die tot applicatie zijn uitgegroeid.
• PHP is de zesde 'most dreaded language' (% of developers who are developing with the language or technology but have not expressed interest in continuing to do so) volgens de jaarlijkse StackOverflow Developer Survey. Bij PHP is dat percentage 62%

M'n punt is dus vooral dat die paragraaf echt wel een beetje kritischer kon staan tegenover PHP. Persoonlijk heb ik het idee dat de taal prima is verbeterd, maar in de praktijk zijn het vaak (zeker niet van toepassing op iedereen!) de zwakkere programmeurs die in PHP land zijn blijven hangen, gezien de sprong naar iets anders te veel gedoe was en PHP helemaal prima is voor websites. Daardoor heeft PHP in z'n geheel een extra negatieve nasmaak voor velen, die waarschijnlijk niet eerlijk is tegenover het werk dat is gedaan aan de taal zelf.

[Reactie gewijzigd door David Mulder op 22 juli 2024 19:21]

[Ventieldopje]

PHP is de zesde 'most dreaded language' (% of developers who are developing with the language or technology but have not expressed interest in continuing to do so) volgens de jaarlijkse StackOverflow Developer Survey. Bij PHP is dat percentage 62%.

Dit komt ook vooral omdat mensen na het leren van HTML/CSS bij PHP terecht komen, dat een paar maanden proberen en vervolgens van iedereen de stigma's over PHP om de oren krijgen om vervolgens dat maar voor waar aan te nemen en te switchen naar een taal die op dat moment helemaal hip is. Laat die nou ook vooral de mentaliteit hebben "we stackxchangen het wel even" en dan vliegt dat percentage wel omhoog ja

quote: robertpNL

Happy Birthday PHP!

Het is geen twijfel dat de huidige ontwikkeltrend in webdevelopment meer richting zogenoemde Single Page Applications gaat waar browser geen reloads meer doen, maar gebruik maken van allerlei Javascript technieken. Er is een enorme groei van javascripts libariers, frameworks zoals React en Vue.

Uiteindelijk is PHP een server-side rendering en dat is natuurlijk prima. Maar iemand die in 2020 een nieuwe website gaat beginnen, zal niet snel meer kiezen voor een server-side rendering mogelijkheid. De huidige javscript frameworks als next of Nuxt zetten PHP buiten spel.

Nogmaals happy birthday PHP, maar raak niet van streek als op termijn minder voor PHP wordt gekozen. Het is 2020.

Deze reactie van robertpNL hier een perfect voorbeeld van zo'n stigma dat mensen maar klakkeloos aannemen.

[Reactie gewijzigd door Ventieldopje op 22 juli 2024 19:21]

[ocf81]

PHP zit ook in de hoek van de minst betalende talen, dat is ook een factor die de populariteit kan beïnvloeden.

[szjoin]

Beetje offtopic, maar Perl een van de best betalende talen?
Is Perl niet allang aan het afsterven, met Perl 6 als veel te late reddingsboei?
(heb zelf vele jaren Perl geprogrammeerd dus viel even van mijn stoel toen ik het plaatjs zag)

[ataryan]

in NL is dat booking.com z'n schuld

[2thomas]

Niet alleen booking maar ook veel fintech bedrijven hebben een groot deel van de infrastructuur in perl.

Gooi maar eens perl amsterdam in google en je komt zo de vacatures tegen.

[ataryan]

< zelf censuur

[szjoin]

...Sollicitatie opsturen doet... ;-)

[ataryan]

haha

[Htbaa]

Wellicht doordat Perl programmeurs er niet in overvloed zijn? Overigens heeft het voor mij nooit betekend dat ik meer betaald krijg :-).

Perl 6 is nooit de opvolger geworden die het had moeten worden. Of eigenlijk, dat is ook nooit de bedoeling geweest. Ondertussen heet het ook al geen Perl 6 meer, maar Raku. Maar de imagoschade is wel gedaan. Perl 7 wordt de opvolger van Perl 5, wat in feite Perl 5.32 is. Maar in Perl 7 gaan zo vooral uit van nieuwe sane defaults, zoals dat use strict; en use warnings; standaard aan staan. Meer info op https://www.perl.com/article/announcing-perl-7/. Ben er zelf nog niet over uit hoe blij ik met deze ontwikkeling ben. Voornamelijk omdat Perl 5.32 (of 5.30, ik weet zo niet wat de laatste Perl 5 wordt) nog wel een poos blijft hangen en ik bang ben dat je dependency hell gaat krijgen doordat de ene module afhankelijk wordt van Perl 7 en de andere van Perl 5.32. Ik heb ook begrepen dat /usr/bin/perl zowel voor Perl 5 als Perl 7 gebruikt gaat worden, terwijl ze beter een /usr/bin/perl7 zouden kunnen doen dan.

Overigens is Perl 5 naar mijn mening nog steeds actueel. Mojolicious is by far het beste web framework wat ik heb gebruikt en gebruik het nu nog steeds. Bij Perl is backwards comptabiliteit een speerpunt en dat zie je ook terug in de libraries die op CPAN staan. Mojolicious gebruik ik al sinds 2011 denk ik en ja er zijn de nodige wijzigingen geweest, maar nooit problematisch om te upgraden. Kijk ik terug naar Zend Framework, daar kon je niet van 1 naar 2 en daar zit je dan... Overigens onder Perl ook een stokoude Catalyst service draaiende gehad die na toen gemigreerd moest worden naar een andere server waar ik een boel problemen bij verwachte, maar na het installeren van de dependencies draaide het direct als een zonnetje.

Backwards comptabiliteit is voor mij echt het allerbelangrijkste in een programmeertaal en frameworks. Ik heb geen zin en tijd om iedere 4 jaar een applicatie volledig om te moeten bouwen omdat de developers weer bedacht hebben "we doen het dit keer wél goed" (*kugh* Zend Framework)

[ocf81]

Hoewel ik het met je eens ben dat backward compatibility op de korte termijn belangrijk is, is het wat mij betreft niet heilig. Er zijn genoeg cases te maken voor breaking changes die de taal vooruit brengen. Voorwaarde is echter wel dat je oude versies blijft onderhouden, zoals bij Python lange tijd voor de 2.x lijn is gedaan.

[Tielenaar]

Sommige bedrijven hebben te veel op Perl draaien en het vinden van developers ervoor kost nogal wat omdat niemand het nog wil doen
Booking.com is nog steeds een vrij grote Perl toko, en die haalt z'n Perlsoneel gewoon uit het buitenland.

[ocf81]

Ja, dat is gewoon een niche waar meer vraag dan aanbod is, net als bij COBOL bijv. het geval is.

[THETCR]

Dat is misschien een reden. Echter is het feit dat PHP elke keer weer opnieuw ge-bootstrapped moet worden een bottleneck (Phalcon is een framework die dit wel probeert op te lossen door het in het geheugen te houden).

NodeJS heeft het voordeel dat het een eventloop heeft en dus actief blijft. Echter heeft het native natuurlijk weer het probleem dat het maar 1 thread heeft, ook niet erg handig.

Composer is echter wel een stuk beter dan NPM. NPM heeft namelijk nog steeds last van een dependency hell, ondanks het mechanisme om te dedupen.

robertpNL heeft echter wel soort van een punt. Zodra/als de bovengenoemde problemen zijn/worden opgelost wordt het uiteindelijk wel de doodsteek voor PHP.
De huidige developers zijn op een dag vervangen door een nieuwe generatie en het wordt steeds aannemelijker dat PHP dan legacy is. Het ontwikkelteam voor PHP is ook veel kleiner in vergelijking met andere talen.

[Ventieldopje]

Echter is het feit dat PHP elke keer weer opnieuw ge-bootstrapped moet worden een bottleneck (Phalcon is een framework die dit wel probeert op te lossen door het in het geheugen te houden).

Dit is dus helemaal geen feit Er zijn zat frameworks die dit op dezelfde manier implementeren maar dit heeft ook wel degelijk nadelen (zelfde geldt voor NodeJS).

Ook is dit al amper een probleem meer met JIT en opcache preloading.

[THETCR]

Ondanks de frameworks die het oplossen is het wel een feit. Want Phalcon is zelf helemaal niet geschreven in PHP maar in C++. PHP zelf heeft dit probleem dus niet opgelost.

Ik denk dat JIT en opcache hier ook niet echt de oplossing voor zijn. Het vermindert de bottleneck absoluut, maar haalt het in de kern niet weg.

De andere argumentatie staat nog steeds. Voor versie 7 waren ze met drie developers waarvan er één ook nog is uitviel.

In vergelijking tot andere talen zijn dit bar weinig developers. De ontwikkeling cycles van bijvoorbeeld ECMAScript en NodeJS is vele malen sneller.

Ik heb enorme projecten in PHP gedaan waarvan ik voor een aantal zelfs de lead developer was. Dus het is niet alsof ik hier een blauwe maandag mee heb gewerkt en toen ben afgehaakt.

[Ventieldopje]

Ondanks de frameworks die het oplossen is het wel een feit. Want Phalcon is zelf helemaal niet geschreven in PHP maar in C++. PHP zelf heeft dit probleem dus niet opgelost.

Frameworks, ik heb het dus niet alleen over Phalcon. Kijk naar bijv. Swoole en ReactPHP etc.

Je hebt dus geen extensies nodig om dit mogelijk te maken en je hoeft dus echt niet elke keer te bootstrappen.

De andere argumentatie staat nog steeds. Voor versie 7 waren ze met drie developers waarvan er één ook nog is uitviel.

In vergelijking tot andere talen zijn dit bar weinig developers. De ontwikkeling cycles van bijvoorbeeld ECMAScript en NodeJS is vele malen sneller.

Mwa die drie developers hebben niet alles gedaan, er zijn wel een heel aantal contributors geweest. Maar goed dat ben ik met je eens, core development gaat een beetje vreemd. Het is een vrij gesloten en conservatieve groep die in vergelijking met andere talen best klein is inderdaad.

[THETCR]

Fair enough. Persoonlijk neem ik ReactPHP niet zo serieus wegens de langzame ontwikkeling die het heeft gehad de afgelopen jaren. Maar het dekt je argument inderdaad wel, er is een framework in PHP die dit probleem aanpakt.

Swoole is helaas ook geschreven in C en C++.

[sdevos13]

Daarnaast is het mogelijk om je gehele PHP applicatie te compileren als executable en op bijv. AWS Lamba volledig in het geheugen te draaien.

[webist]

HTTP is een "stateless" protocol.
Bootstrappen in een stateless omgeving is onkunde.
Een HTTP applicatie moet direct de pad resolve'n en naar de content oplevering laag.
Maar iedereen gebruikt klakkeloos een fancy router, ik gebruik alleen resolver, en in elkaar geweven model-view laag, waardoor onnodig functies worden doorlopen.
Wat er wel te bootstrappen zou vallen is de UI (html, css, js) voor hergebruik,
en dat is voornamelijk aan de browser en minder aan de server app.

PHP aan de CLI kant is onderontwikkeld, maar dat is ook niet de selling point van PHP.

[THETCR]

Echter blijft het feit dat server side, zodra de request is afgehandeld, bijvoorbeeld Nginx/Apache de boel weer afsluit en alles uit het geheugen gaat. Bij de volgende request moet alles weer opnieuw gedaan worden. Phalcon lost dit op door alles in het geheugen te houden. Dit was ook één van de dingen die NodeJS wou tackelen met server side JavaScript.

[Superstoned]

Het voordeel hiervan is dat je perfect horizontaal kunt opschalen. Wil je 2z zoveel requests afhandelen, verdubbel het aantal cores. Geen code wijzigingen nodig. Alle cores in gebruik? Zet een 2e server neer. 3, 4, 5 - schaalt perfect. Zelfs naar een 2e data center. En grotendeels of zelfs geheel zonder aanpassingen. Je bottleneck zit gegarandeerd in andere dingen als database, storage etc.

Bij de meeste andere talen stopt het makkelijke schalen na 1 server... dan moet je opeens flink aan de slag om het te herschrijven in micro services ofzo. Of bij java - super dure servers kopen want het schaalt gewoon NIET ;-))

[THETCR]

Op die manier moeten schalen kost ook geld. Fijn als je een (grote) commerciële partij bent, lastig voor bijvoorbeeld opensource projecten.

Er is ook nooit één bottleneck, het feit dat je database misschien een grotere bottleneck is doet niet af aan deze. je bent beter af met een framework die het actief in het geheugen houdt.

[FvdM]

Echter blijft het feit dat server side, zodra de request is afgehandeld, bijvoorbeeld Nginx/Apache de boel weer afsluit en alles uit het geheugen gaat. Bij de volgende request moet alles weer opnieuw gedaan worden.

Dat is wel een ouderwetse opzet. Inmiddels is PHP-FPM de standaard op webservers, waarbij het master PHP process actief blijft en lichte workers de scripts verwerken. Afhankelijk van de instellingen en load worden de workers gestopt of dynamisch bijgespawnd om de boel efficiënt te houden voor de webserver.

[reefclaw]

Het is wel zo dat als je stateless kunt ontwikkelen in andere talen zonder dat applicaties opgespint hoeven te worden per request.
Wanneer een applicatie goed gebouwd is om stateless te zijn (er zijn redenen te bedenken waarom een applicatie statefull moet zijn), dan is wat er gebeurd bij een request niets meer dan dat de applicatie parameters ontvangt, en die parameters verwerkt.
Dit kan door bijvoorbeeld iets weg te schrijven naar een database, iets op te halen uit een database, als een proxy te dienen of een mutatie doen op de parameters.
Die parameters worden nergens in de applicatie dan opgeslagen, en worden na dat het request is afgehandeld opgeruimt. Maar de applicatie zelf blijft draaien.

De enige state die de applicatie dan bij houd, en die 'gebootstrapt' zou kunnen worden, is de configuratie van de applicatie zelf. Bijvoorbeeld: waar staat een database, welke gebruikers rollen zijn er, hoe kan ik iemand authenticeren.
Dit is dus informatie die onafhankelijk is van de request zelf.

[Gopher]

Dat is uiteraard tegenwoordig wat minder. Tegenwoordig kom je eerder op nodejs uit waar je veel laagdrempeliger gebruik van kunt maken. Echter zijn er veel dingen in het verleden met PHP geprototyped, en verder uitontwikkeld tot een applicatie. Ook was in het verleden (voor 2000) hosting voor iets anders vrij complex. Denk maar aan Java applicatieservers toen en een spring boot nu.

Wat er veelal nu draait op het web zijn van die Drupal en Wordpress applicaties. Waarvan de meeste developers vooral bezig zijn met plugins installeren. En een varnish cache e.d. zijn ook altijd een must.

Sure we zijn bedrijven die er nog mee werken; neem bijvoorbeeld Bunq. Maar mij niet gezien ik heb een jaar of 4 met PHP gewerkt; maar never nooit meer als het aan mij ligt. Het is gewoon niet iets wat net zo makkelijk schaalt als populaire alternatieven.

[herovazy]

Vind het zelf wel heerlijk werken, zo lang jij en je collega's zich maar aan dezelfde style houden. Ik vind het in ieder geval een stuk prettiger werken dan die wirwar wat ze JavaScript noemen... (Veel verschillende frameworks met verschillende stijlen, vaak vind ik de documentatie van JS frameworks/'code' ook minder en snapt PhpStorm mijn PHP structuur vaak beter dan in JS)

Iedereen zal altijd zijn voorkeuren hebben, maar die van mij ligt (voorlopig) bij PHP

[Cartman!]

Het is gewoon niet iets wat net zo makkelijk schaalt als populaire alternatieven.

Waar baseer je dat dan op?

[Webgnome]

Dat is uiteraard tegenwoordig wat minder. Tegenwoordig kom je eerder op nodejs uit waar je veel laagdrempeliger gebruik van kunt maken. Echter zijn er veel dingen in het verleden met PHP geprototyped, en verder uitontwikkeld tot een applicatie. Ook was in het verleden (voor 2000) hosting voor iets anders vrij complex. Denk maar aan Java applicatieservers toen en een spring boot nu.

Wat er veelal nu draait op het web zijn van die Drupal en Wordpress applicaties. Waarvan de meeste developers vooral bezig zijn met plugins installeren. En een varnish cache e.d. zijn ook altijd een must.

Sure we zijn bedrijven die er nog mee werken; neem bijvoorbeeld Bunq. Maar mij niet gezien ik heb een jaar of 4 met PHP gewerkt; maar never nooit meer als het aan mij ligt. Het is gewoon niet iets wat net zo makkelijk schaalt als populaire alternatieven.

Care to elaborate?

[Gopher]

@Cartman! Volgens mij al ergens anders herhaald; Doordat je elke keer je hele stack moet opbouwen heb je gewoon meer overhead. Sure in theorie schaalt het wel, maar je hebt meer resources nodig. Ondanks dat je opstart misschien snel genoeg is om dit te kunnen negeren (andere opties hoeven dit vaak niet omdat ze bijv. constante connecties kunnen hebben met databases andere systemen met bijv. websockets etc.). Zul je door telkens het hele zooitje te moeten opstarten meer geheugen gebruik hebben, dubbele instanties (per request) etc.

Daar zijn volgens mij ook weer wat oplossingen voor, maar in de basis schaalt het gewoon minder lekker.
Neem databases bijv. daar worden vaak elke keer nieuwe connecties mee gemaakt, en dat dan weer per request.

[Cartman!]

Ook dat kun je met PHP gewoon doen (ReactPHP, Swoole) maar onder de streep zijn er maar heel weinig developers die hier mee te maken krijgen dat het echt nodig is. Je kunt t erover hebben of het de beste keuze is maar dat maakt de uitspraak dat het niet zo makkelijk schaalt niet waar. PHP kan fantastisch schalen maar het hangt van t doel af. Als dat API requests afhandelen is met bijv Redis dan is dat een super goede match (heb PHP APIs gebouwd die 5000 req/s deden met 10ms response tijd tijdens stress testing) maar het open houden van socketverbindingen zou ik niet snel met PHP doen.

[robertpNL]

Klakkeloos....dankje door mijn username zonder context te noemen.

[Reactie gewijzigd door robertpNL op 22 juli 2024 19:21]

[Ventieldopje]

Aangepast zodat dit duidelijker is

[winkbrace]

Ik ben zelf een enthousiaste php ontwikkelaar, maar wat robertpNL zegt klopt volgens mij precies. Een trend is nu eenmaal een trend.

[Toettoetdaan]

Jup, met PHP aankomen resulteert nog vaak in hoongelach.

Meestal van mensen die zelf totaal niet kunnen aangeven wat er niet goed aan is en vervolgens met talen aankomen waarop voldoende is aan te merken... Geen een taal is perfect en daarnaast is het ook een kwestie van smaak.

PHP is wel heel toegankelijk en daarom is het slechtere werk ook wat makkelijker te vinden in de PHP wereld. Maar een taal bepaalt niet hoe goed een programmeur is, een taal kan wel beïnvloeden hoe snel een programmeur zich ontwikkeld naar een betere software ontwikkelaar.

[martijnvanegdom]

Oke gaat tie dan.. ik heb zelf 8 jaar PHP en een jaar of 10 c# gedaan.. PHP is bagger.. want:

OO concepten werken in C# gewoon beter.. Interfaces en Abstracte classes gaan nog. Maar meerdere constructors is een ramp.. En over dingen als generics daar hoeven we helemaal niet over te beginnen in PHP.

Datastrucuteren zijn gewoon veel beter georganiseerd in C#, het kan allemaal wel.. maar uiteindelijk is het allemaal een associative array.. Dictionaries, Lists, HashSets het is gewoon veel beter verzorgd.

C# levert standaard functionaliteit voor routering, dependency injection en al die dingen waar je een 1000+ bestanden groot framework als lavarel voor inzet.

C# is véél sneller... in alle dingen die ik gedaan heb rent C# (en zeker .NET Core) rondjes om PHP

Als het gaat over databases.. in C# hebben we LINQ, ja de syntax is soms wat gek, maar het werk uitstekend..

In C# worden dingen als JSON parsing gewoon veel beter verzorgd.. geen string inputs of zo, gewoon direct je object structuur.

Async, moeten we daar nog iets over zeggen?

En zo kan ik echt nog wel even doorgaan.. als ik API’s moet bouwen is PHP de eerste taal die ik laat vallen.. niet omdat PHP zoveel slechter is.. maar meer omdat de ontwikkeling in andere talen veel sneller is gegaan.

[Ablaze]

Ik heb ervaring met beiden.
Of je een PHP framework of C# (ASP.NET) kiest, ligt helemaal aan de toepassing.

Als het gaat om relatief kleine projecten, kan ik het in Laravel maken in ongeveer de helft van de tijd, vergeleken met ASP.NET (Core). Niet omdat ik meer bedreven ben in PHP, maar omdat ASP.NET veel meer handelingen en klopwerk vereist. De scaffolding van Laravel is veel completer, je krijgt standaard een goede task runner, unit tests, database-ondersteuning, authenticatie/authorisatie, voorbereiding op NPM integratie, logging enzovoorts. Ook zijn er duizenden packages voor te downloaden via Composer, terwijl ik het aanbod op Nuget altijd wat vind tegenvallen. Iets simpels als een goede PDF generator is toch al weer even zoeken voor het .NET platform.

Voor grote (zakelijke) projecten die met meerdere personen worden ontwikkeld is ASP.NET Core beter geschikt, maar niet alle projecten zijn zo.

Entity Framework met LINQ is goed maar Laravel heeft standaard Eloquent, dat echt heel simpel en krachtig is.

C# is een veel nettere taal maar in Laravel (en ook al in Symphony) wordt zoveel voor je gedaan dat de meeste code die je klopt niet erg complex is. Van die duizenden bestanden merk je overigens niets (ASP.NET bestaat ook uit duizenden bestanden, maar dan zijn ze door MS gecompileerd in DLL libraries), het is meer een gevoelskwestie.

.NET intermediate code is sneller maar in de praktijk merk je dat bij veel gewone (niet al te grote) toepassingen niet. Daarnaast is het scalen van een server niet echt een probleem meer tegenwoordig en wordt PHP continu sneller gemaakt. Een ander voordeel van PHP is dat er geen compiler nodig is en dat je minder zit te wachten als developer (.NET heeft dan wel weer betere debugging).

Kortom, er is ruimte voor beide oplossingen.

[Reactie gewijzigd door Ablaze op 22 juli 2024 19:21]

[Xieoxer]

Je vergelijkt apples met peren. PHP was van oorsprong nooit bedoeld om OO (Object Oriented) te worden, dat is in de laatste jaren wel veranderd. C# is vanaf de oorsprong OO, waardoor sommige dingen stuk beter in elkaar zitten. Maar PHP wordt voornamelijk gebruikt voor websites en web backend. C# wordt amper gebruikt voor web applicaties, en was in het verleden vrij lastig draaiend te krijgen op Linux servers. PHP daarin tegen werkt op alle besturingssystemen. Op dit moment is het zo dat bijna alle webservers Linux gebaseerd is, dan is logischer om voor PHP te kiezen.

[Reactie gewijzigd door Xieoxer op 22 juli 2024 19:21]

[martijnvanegdom]

C# amper gebruikt voor een applicaties? In de enterprise wereld waar ik leef.. word het extreem veel gebruikt.. precies voor die complexere projecten..

En nee het is geen appels met peren vergelijken.. ASP.NET (en zeker Core) is gericht op
Web op de backend precies dezelfde use-case als PHP.

En alle dingen die Ablaze noemt - met uitzondering van PDF - zitten standaard in .NET, PDF is inderdaad niet ideaal

[Reactie gewijzigd door martijnvanegdom op 22 juli 2024 19:21]

[Groax]

Hij zegt toch echt Web Applicatie en niet Applicatie..
Ik beheers nu Java, C# en werk al jaren met PHP.
Toen PHP 7 uitkwam... jeetje wat was dit een verbetering! Laravel maakt deze taal zoveel beter omdat je snel een makkelijke web applicatie bouwt zonder veel poespas, wat packages erbij en klaar.

Java/C# zijn top talen voor applicaties en Java Spring is gewoon perfect voor API's.. Maar genereer je een HTML pagina? pak lekker PHP want die hoef je niet steeds te compilen....

[ataryan]

In mijn wereld draait php code ook gewoon via de cron; de vergelijking met gecompileerde C code word dan een heel stuk reeler omdat je de uitvoer tijd daardoor goed kunt meten. En daar zijn performance lijstjes van all over teh Interwebs.

C is echt onvoorstelbaar veel sneller; echter is de ontwikkeltijd en specialistische kennis ( lees: kosten ) veel hoger. Dat willen klanten niet betalen: " als het maar loopt ".

Een mooie crossover tussen die 2 zie ik in GOLANG; GO is vreselijk snel en ontzettend compact. Go heeft de voordelen van PHP en C bij elkaar opgetelt, en integreert heel mooi met container oplossingen.

[Htbaa]

Het in Go geschreven Hugo is overigens een enorm snelle statische website generator. Best leuk om mee te werken. Ontbreekt er alleen nog aan dat je tijdens het builden niet uit een dynamische bron kunt bouwen, m.a.w. een HTTP API aanspreken om content op te vragen en zo productpagina's te laten genereren.

[ataryan]

mja, Go is niet (altijd) een perfecte vervanging for all things PHP, maar voor key dingetjes ram ik er een servicecontainer bij met een L4 LB redirect. Voorbeeld: https://hub.docker.com/r/mailhog/mailhog/

Laat dat wat core is en (nog) niet aan vervanging toe is gewoon draaien, maar de klusjes en extra services (alvast) uitbouwen met Go viel mij niks van tegen.

[MeMoRy]

C# is vanaf de oorsprong OO, waardoor sommige dingen stuk beter in elkaar zitten.

OO dus beter? Daar verschillen de meningen nogal over...

[Patriot]

Dat is niet de conclusie die je aan die 'dus' moet hangen, de conclusie die daar wordt getrokken is dat het OO gedeelte veel beter in elkaar steekt in een taal die daar vanaf het begin af aan mee is opgegroeid.

[sdevos13]

PHP is bagger

Naar jouw mening, gebaseerd op jouw ervaring.

gewoon veel beter

...

1000+ bestanden groot framework

Een framework dat veel meer features biedt dan alleen routing en dependancy injection. Net als alle andere frameworks, in alle andere talen. Daarnaast was storage space misschien in het Zend 1 tijdperk tijdens het uploaden via FTP nog een dingetje, dat is het nu bij webapplicaties zeer zeker niet meer.

[martijnvanegdom]

Ja het is een mening.. voor mij was de overgang van PHP naar C# een verademing..

Het probleem is niet storage.. met 1000+ files.. maar IO..

Maar het grote voordeel van PHP is eenvoudigweg dat elke hoster het draait, ook de goedkope hosters.. en dat ligt bij .NET gewoon anders

[sdevos13]

Dat kan ik begrijpen.

I/O is sinds PHP 5.5 voor het laden van een framework een eenmalig probleem:
https://www.php.net/manual/en/intro.opcache.php

Shared webhosting is inderdaad een voordeel voor het gebruik van veel 1-click-install PHP applicaties. Maar juist van deze applicaties lijkt het stigma omtrent PHP vandaan te komen naar mijn mening. Slecht onderhouden, net te makkelijk in gebruik en veel voorkomende security issues zijn eerder regel dan uitzondering. Wanneer een andere taal hetzelfde 'gebruiksgemak' had geboden in de beginjaren dan was het stigma daarnaartoe verhuisd.

PHP heeft de afgelopen jaren echt enorme stappen gemaakt naar een serieus platform voor een grote variantie aan professionele toepassingen. De performance is in PHP 7 gigantisch verbeterd, maar wat nog veel belangrijker is, is het ecosysteem van stabiele frameworks met een hoge speed-of-development. Een hoge speed-of-development brengt uiteraard zijn eigen uitdagingen met zich mee, maar het 'kloppen' van 'slechte' of onleesbare PHP code ligt al jaren bij de developer en steeds minder bij de (volgens velen) inconsistente programmeertaal.

[Cartman!]

Dat je niet bekend met bent opcache in PHP geeft denk ik aan dat je al een jaar of 5 a 6 niet ermee gewerkt hebt maar toch nog vooroordelen hebt...

Sowieso vind ik opmerkingen als "taal X is bagger" een beetje sneu, er zijn veel talen en elke taal heeft sterke en zwakke punten. Het immens populaire JavaScript heeft ook enorme quirks maar het is niet erg als je weet hoe je ermee om moet gaan en zo is dat met PHP en C# niet anders. Omarm de variëteit aan talen, gebruik waar je je fijn bij voelt/boterham mee kunt verdienen en "taal X waar ik mee werk is beter dan taal Y waar jij mee werkt" voegt echt niets professioneels toe aan een discussie.

[Cartman!]

Er zijn al wat reacties en pak er random ook wat dingen uit:

C# levert standaard functionaliteit voor routering, dependency injection en al die dingen waar je een 1000+ bestanden groot framework als lavarel voor inzet.

Bij C# zijn dat net zo goed dependencies alleen dan op n andere manier weggestopt.

C# is véél sneller... in alle dingen die ik gedaan heb rent C# (en zeker .NET Core) rondjes om PHP

Hangt natuurlijk volledig van de toepassing af. Er zijn ook genoeg benchmarks waar PHP eruit komt als nummer 1 (ook boven nodejs en go).

Als het gaat over databases.. in C# hebben we LINQ, ja de syntax is soms wat gek, maar het werk uitstekend..

Dingen als Eloquent en Doctrine werken ook uitstekend, zonder gekke syntax

In C# worden dingen als JSON parsing gewoon veel beter verzorgd.. geen string inputs of zo, gewoon direct je object structuur.

Ik heb echt geen idee wat je hier bedoelt...?

Async, moeten we daar nog iets over zeggen?

Wat wil je hier over zeggen? Kan ook gewoon in PHP met bijv ReactPHP/Amp/Swoole.

Kortom, je klinkt voor mij wederom als iemand die een aantal jaren geleden gestopt is met PHP en denkt dat het daar stil is blijven staan. Net als verstokte MacOS gebruikers die denken dat Windows sinds versie 95 nooit meer is gewijzigd (of andersom natuurlijk ).

[Webgnome]

Je vergelijkt nu appels met peren. C# is vanaf begin af aan volledig oo. Php daarentegen...

[.oisyn]

Meestal van mensen die zelf totaal niet kunnen aangeven wat er niet goed aan is en vervolgens met talen aankomen waarop voldoende is aan te merken...

Dat iemand geen goede argumenten kan overbrengen impliceert niet dat ze er niet zijn, dus het punt van deze opmerking ontgaat me een beetje.

Het grappige is dat heel veel van de kritieke punten worden aangepakt met PHP7 en PHP8. Ik noem bijvoorbeeld het absurde gedrag van int vs string compares, of de left-associativity van de ?: operator (die in élke andere taal, vanaf CPL in de jaren '60, rechts associatief is). Kritiek die menig PHP'er maar nauwelijks kan accepteren ("het is toch gewoon gedocumenteerd?"), maar het feit dat het nu eindelijk wordt aangepast geeft aan dat de klagers weldegelijk een punt hadden .

Toen ik de RFC's las van PHP8 had ik eindelijk het gevoel dat de taal volwassen wordt. Er zit eindelijk een team achter dat echt wil nadenken over het design, met een gedegen peer review proces, ipv dingen gewoon klakkeloos te implementeren, dan naar het ontstane gedrag te kijken en dat dan te documenteren. De implementatie bepaalde de spec ipv andersom.

[Cartman!]

Kritiek die menig PHP'er maar nauwelijks kan accepteren ("het is toch gewoon gedocumenteerd?")

Mwa, ik zou dit niet zien als kritiek niet willen accepteren maar als "ik heb er geen last van in mijn werkzaamheden" dus waarom zou ik er een probleem van maken

[veltnet]

Een discussie over programmeertalen gaat al snel lijken op een discussie over religie.
Iedereen vindt dat zijn eigen god de beste is en de andere goden niet zouden mogen bestaan.
Hoe erger mensen vast zitten aan één taal des te meer worden alle andere talen verketterd (vaak door eigen onwetendheid/tunnelvisie)

Laat een prutser iets maken in een bepaalde programmeertaal en je krijgt prutswerk.
Laat een vakman iets maken in dezelfde programmeertaal en je krijg vakwerk.

[Xieoxer]

Heel jammer om te lezen dat mensen denken dat PHP geen serieuze programmeertaal is. Zeker sinds PHP 7.x is PHP flink verbeterd zowel met prestatie als de syntax zelf. Ik programmeer al zeker 10 jaar in PHP en nog steeds blijf ik het een fijne taal vinden zolang je de taal inzet voor het juiste doel.

De meeste API's op het internet zijn geschreven in PHP. Vroeger werd het front-end ook geschreven in PHP, maar dat is verleden zijn. Tegenwoordig zijn er front-end engineers die "praten" met de API om zo data te kunnen verzamelen en te tonen. De front-end is feitelijk javascript met een heleboel frameworks zoals React etc.

Inmiddels merk ik in mijn omgeving dat steeds meer native applicaties omgebouwd moeten worden naar web-apps (single page applications), omdat de klant niet afhankelijk wil zijn van een besturingssysteem en het overal wil laten draaien zoals op een iPad. Vroeger zat de koppeling met de backend rechtstreeks ingebouwd in de native applicatie, maar dat kan niet echt meer als je een web-app gaat bouwen. Je zult een backend in elkaar moeten schrijven waarmee je front-end mee kan communiceren. Mijn voorkeur gaat uit naar REST-API achtige constructie, maar met de flexibiliteit dat de de backend makkelijk uitgebreid kan worden met nieuwe functies. Ik kom dan 9 van de 10 keer uit op een de taal PHP uit, in combinatie met PHP-FPM en Nginx.

[Reactie gewijzigd door Xieoxer op 22 juli 2024 19:21]

[Blockchain]

Ik reageer niet vaak. Sterker nog, volgens mij is dit mijn eerste bericht hier

Wat ik zelf enorm sterk vind aan het gebruik van JavaScript als server-side taal is dat je heel veel functies en logica van je server letterlijk kunt copy/pasten naar je client. Zo bouwen wij vaak een stack zo op dat een JavaScript server statische HTML geeft, daarna maakt de client een WebSocket of API verbinding terug met de server voor het binnenhalen van updates. Voor die statische HTML gebruik je dan een simpele functie, denk bijvoorbeeld aan iets als:

let dayType = ([6,7].indexOf(day) > -1) ? "weekend" : "work day";

Door JavaScript als server en client te gebruiken kunnen we complete libraries maken die we zowel op de server als op de client gebruiken. Als we PHP zouden gebruiken, moeten we dit soort dingen allemaal opnieuw schrijven en twee keer unit testen.

[Ablaze]

Ik begrijp waarom dat gunstig is, het is echter wel zo dat dit vaak alleen bij websites een voordeel is. Als je een mobile app maakt die met een backend communiceert, is zo'n app toch vaak weer in een andere taal geschreven. In dat geval maak je toch gewoon een "normale" API en zijn backend en frontend gescheiden van elkaar, wat het beveiligen van je backend een stuk doorzichtiger maakt.

Ook PHP kun je gebruiken voor je frontend, sterker nog, PHP is ooit begonnen als template language. Omdat het op de server wordt uitgevoerd kun je uiteraard niet dynamisch het DOM aanpassen of iets dergelijks, maar dat is ook niet altijd noodzakelijk.

Een groot nadeel aan js vind ik dat dependencies meestal maar kort leven. Voor frontend design is dat niet zo'n ramp, maar een backend moet toch minstens een jaar of vijf kunnen draaien en soms zijn packages al obsolete voordat je je code publiceert.

[Gopher]

Echter zijn mobiele apps ook steeds vaker gebouwd met frameworks zoals React Native. Uiteraard is react geen backend library, maar de taal is hetzelfde.

Ik maak vooral gebruik van typescript, ik kan direct dezelfde types importeren in mijn applicatie.
Je geeft aan dat dependencies kort leven, maar ik vraag me af waar je dat dan vandaan haalt, ze updaten vaak omdat browsers gewoon snel ontwikkelen. Uiteraard zijn er packages met slechte support, maar dat is denk ik gewoon de wereld van open source ik zie heel vaak hetzelfde in de PHP wereld namelijk.

[MeMoRy]

let dayType = ([6,7].indexOf(day) > -1) ? "weekend" : "work day";

Ik ben geen Javascript expert, maar zo simpel ziet die functie er niet uit. Waarom niet gewoon
Let daytype = day >5?"weekend":"workday";
Even de case waar day undefined of null is daargelaten. En natuurlijk localities waar maandag niet de eerste dag van de week is...

[Blockchain]

Je hebt helemaal gelijk hoor. Ik wilde alleen ter illustratie even een voorbeeld geven.

Het gaat mij er meer om dat we zo een legio aan functies gebruiken die we ten eerste gebruiken voor het genereren van de HTML en daarna nogmaals gebruiken in de client zelf voor het bijwerken van die HTML. Door op de server PHP te gebruiken zou je zo'n functie opnieuw moeten schrijven.

[BikkelZ]

Ik ben op zich wel van mening dat PHP gewoon een grote waarde heeft, ik werk persoonlijk liever met PHP dan met een JS-based stack. Maar het was toch lang wel een beetje lastig om dingen als websockets of threads te doen, dingen die in andere scripttalen wel makkelijker konden.

[Erwin1985]

Eens. "De reputatie dat PHP geen serieuze ontwikkeltaal zou zijn, ligt al ver achter ons." is denk ik vooral een mening. Ik loop al 9,5 jaar van bedrijf naar bedrijf als freelance computerprogrammeur en elke keer als iets in de richting van .php zie binnen een omgeving vrees ik dat het programmeerwerk erin slecht gedaan is, en die verwachting komt ook meestal uit.

T.Net zal wel netjes geschreven zijn, daar ga ik van uit, maar slechte, door broodprogrammeurs geschreven lappen php code zonder enige standaard doen het imago van php geen goed. Met Java en C# wordt de programmeur al meteen zachtjes in de SOLID manier van denken gedrukt. En de "innovaties" in het artikel zijn in C# en Java (en ongetwijfeld ook andere gecompileerde OO talen) allang gemeengoed.

[SH4D3H]

T.Net zal wel netjes geschreven zijn, daar ga ik van uit, maar slechte, door broodprogrammeurs geschreven lappen php code zonder enige standaard doen het imago van php geen goed. Met Java en C# wordt de programmeur al meteen zachtjes in de SOLID manier van denken gedrukt. En de "innovaties" in het artikel zijn in C# en Java (en ongetwijfeld ook andere gecompileerde OO talen) allang gemeengoed.

Je moet daarbij niet vergeten dat php een hele andere geschiedenis heeft dan Java en C#. Het was nooit de bedoeling om applicaties in php te schrijven, dus waren de taal en tools er ook niet naar. Toen bleek dat php wel heel makkelijk te leren was en iedereen en zijn grootmoeder in php ging knutselen is de taal langzaam in de 'goede' richting gaan bewegen (php 5).

[DaFeliX]

Het feit dat PHP ooit begon als template-engine, en je nu een template-engine gebruikt om PHP weg te abstraheren is daar wel een mooi voorbeeld van

[Kees]

T.Net zal wel netjes geschreven zijn, daar ga ik van uit, maar slechte

Tweakers gaat al sinds '98 mee en is al die tijd ontwikkeld. En lang niet alles is elke paar jaar herschreven zodat er ook nog genoeg oude code is die niet aan de huidige codestandaarden voldoen

[chielsen]

Ik denk dat vooral het woord "reputatie" misschien niet goed gekozen is, want dat heeft het nog wel. Of het terecht is dat is een tweede natuurlijk.
Ik denk dat ze vooral een reputatie probleem hebben, want technisch valt het allemaal wel mee en heeft natuurlijk wel voor- en nadelen, maar zijn de meeste nadelen achterhaald of overdreven.

Voor het maken van websites heb je geen serieuze ontwikkeltaal nodig.

Nee klopt, je kan gewoon html met de hand coderen en dan heb je een website. Echter de meeste websites tegenwoordig zijn gewoon online applicaties. Of dat nou een webshop, site met cms, of iets anders is maakt niet uit.
De tijden van wat HTML en PHP in een bestandje zetten zijn allang voorbij. Dat soort sites worden tegenwoordig met Wordpress of Drupal gemaakt want dan krijg je er gratis 100 features bij. En dat soort systemen noem ik toch echt wel een applicatie.

Juist om wat tegenwicht te bieden aan alle negatieve verhalen rondom PHP lijkt mij dit artikel een wat enthousiastere toon aan te nemen, ook omdat Tweakers er zelf mee werkt. Volgens mij is daar niets mis mee.

[David Mulder]

Ergens heb je gelijk dat de programmeurs die aan Wordpress werken eerder aan een applicatie werken dan aan een website. Echter, puur omdat je een API gebruikt van iets complexers, maakt dat hetgeen je zelf bouwt nog niet meer complex. Als je een klassieke Desktop applicatie schrijft gebruik je bijv. Windows APIs voor tal van zaken, maar dat betekent nog niet dat je een besturingssysteem schrijf of iets doet op dat niveau. En de enige redenen waarom Drupal en Wordpress in PHP zijn, is omdat dat op dat moment de populairste taal was (en tegenwoordig is er te veel op gebouwd om nog ooit weg te switchen). En bi Wordpress merk je dat ze steeds meer bij PHP aan het weg migreren zijn.

Juist bij een dergelijk artikel waar je veel PHP programmeurs zult hebben is het nuttig om kritisch te zijn, want het is super makkelijk om in je eigen wereld te leven en niet te merken dat er meer bestaat buiten je eigen wereld. We namen een keer een programmeur aan die de laatste 10 jaar in Microsoft/.NET had geleefd en hij was er oprecht van overtuigd dat er buiten de Microsoft .NET wereld bijna niks bestond en dat de systemen daar de beste systemen waren ooit gemaakt... en toen werd hij plotseling geconfronteerd met alle andere frameworks, talen en aanpakken die net zo populair zijn.

[PatrickH89]

Ik denk dat kritisch zijn prima is, maar dan ook de andere kant op. Ik merk toch dat het beeld erg leeft van PHP developers die alleen maar PHP kunnen en waardeloze applicaties bouwen die beter in een andere taal gebouwd zouden zijn.
Het is gewoon een feit dat de meeste professionele PHP developers 'gewone' developers zijn die vaak best gewend zijn om te werken in meerdere talen (hobby of noodzaak).

De applicaties die gebouwd worden in PHP maken tegenwoordig ook 'gewoon' gebruik van CI/CD, code style enforcen, static analysis, unit tests, integration tests etc. De stack is gewoon professioneel genoeg en de kritiek komt over het algemeen van developers die ooit met PHP gewerkt hebben en nauwelijks bekend zijn met de huidige staat en het ecosysteem van de taal.

[Blue-eagle]

En die 80 procent zijn ook heel erg veel Wordpress en Joomla websites die over het algemeen niet als volwaardig worden aangezien. Met name de vele hacks (ook door de populariteit natuurlijk) zorgen ervoor dat beide CMS-en weinig vertrouwen opwekken, en ook PHP daardoor een slechte(re) naam krijgt.

Deze reactie op Reddit legt ook goed uit waarom PHP zo'n slechte reputatie heeft. Er zitten gekke dingen in bijna alle programmeertalen, maar PHP steekt er wel een beetje bovenuit, in negatieve zin Dat heeft ook veel te maken met de leidinggevende mensen achter de taal en het puberale gedrag van die mensen.

Er zijn zoveel mooie programmeertalen waar een developer mee bezig kan gaan. PHP, ook gezien de afzetmarkt, zou voor mij als allerlaatste (nog gebruikte taal) in de lijst staan. Misschien op gedeelde plek met Perl Leuk dat Tweakers en TMG er gebruik van maken, maar dat neemt niet weg dat er leukere klussen beschikbaar zijn in een breder segment als je gewoon Java, .Net, Node.js, Kotlin, Ruby, etc. leert te gebruiken.

[Sgreehder]

Een dergelijk cijfer is ook een beetje betekenisloos als het gaat om waar PHP effectief wordt ingezet. Frameworks zoals Laravel zijn op Github nog altijd wat populairder dan frameworks als Express, Next, etc. En dan hebben we nog een flink aantal sites die draaien op Wordpress, Joomla, enz. Mijn gevoel zegt dat de 80% waarschijnlijk flink overtrokken is, maar het staat vast dat PHP grote stappen heeft gemaakt sinds versie 7.

[8x4]

Een taal is slechts een tool, meer niet.

Daarnaast: programmeren doe je _into_ de taal, niet _in_ de taal; bij de ene taal dien je dit principe wellicht wat meer toe te passen dan bij de andere taal.

Gekibbel over een taal duidt juist een gebrek aan professionaliteit en kunde aan.

[Gopher]

Dit zie ik heel vaak gepost worden ondertussen. Maar een taal komt vaak met een ecosysteem; mogelijkheden voor hosting, dependancy management etc.

Ik denk dat je daar dus best een mening over kan hebben of dat ecosysteem ok is. Ik vind persoonlijk dan ook niet dat PHP verschrikkelijk is, maar als ik er omheen kijk word ik meestal al snel verdrietig als ik het vergelijk met de alternatieven :-).

[faim]

Ik run zelf een softwarebedrijf, en vrijwel al onze back-end applicaties worden geschreven in PHP, in combinatie met Laravel of Phalcon. Gegeven, het is niet de meeste gestroomlijnde taal, vooral de continuïteit in functie benamingen laat nog wel eens de wensen over. Maar de afkeer ertegen is denk ik vooral voortgekomen uit codebases als Wordpress, Joomla, PhpBB, hier zit weinig structuur in en de helft is maar 'gewoon' globally gedefineerd.

Het ligt er voornamelijk aan hoe je je developers opleidt en de code laat structureren, bij vrijwel elke programmeertaal kan je hier een zooitje van maken als er geen structuur in zit.

[raptorix]

En wat was de reden om voor PHP te kiezen?

[Tielenaar]

Kan niet namens faim spreken, maar meestal een kostenkwestie. Vrij laagdrempelig om er mee te beginnen, alles is gratis en PHP hosting is vrij makkelijk opgezet. Veel personeel te vinden met genoeg ervaring hiervoor, en bij veel startups is het gewoon zo dat een van de oprichters toevallig PHP kan en daar dan dus voor kiest.
(hoi)

[Tielenaar]

Gaat eigenlijk altijd goed, een startup zal niet zomaar falen vanwege de keuze PHP.

[SH4D3H]

Aantal dingen om stil bij te staan:
[...]
- PHP is de zesde 'most dreaded language' (% of developers who are developing with the language or technology but have not expressed interest in continuing to do so) volgens de jaarlijkse StackOverflow Developer Survey. Bij PHP is dat percentage 62%

Dit beeld zal ook vertekend zijn door al die lui die na PHP 4 of 5 zijn overgestapt op iets anders en hun beeld nooit hebben bijgesteld. Als je gebruik maakt van iets als Symfony of Laravel en PHP7 (en straks 8 ) kan deze combi zich echt wel meten met alles van Node te bieden heeft en zelfs prima meekomen van applicaties in Java/C#.

Er is tegenwoordig in de community ook veel meer aandacht voor dingen als static analysis met bijv. phpstan of phan, zijn er diverse initiatieven om asynchronous php mogelijk te maken (bijv. ratchet en reactphp) en zelfs machine learning is mogelijk als je dat wilt (php-ml).

Edit: Oh, en als je een API wilt maken, is het in php geschreven api platform een van de beste en meest uitgebreide pakketten die je kunt kiezen.

[Reactie gewijzigd door SH4D3H op 22 juli 2024 19:21]

[delphium]

Je wordt keihard gemind hier, maar ik ben het met je eens. Frameworks als Laravel en Symfony, proberen design patterns uit Java over te brengen naar PHP. PHP is daar echter (nog) niet goed voor uitgerust, waardoor het inderdaad een beetje geknutsel blijft. Ook wordt PHP traag door zaken als dependancy injection, waar het gewoon niet geschikt voor is.

Bij Yii 1 waren ze op de goede weg. Dat framework maakte gebruik van de sterke punten van de taal zelf. Helaas zijn ze bij versie twee ook op basis van Symfony verder gegaan.

Verder is het vooral een kwestie van "the right tool for the job". PHP is een uitkomst voor mensen die graag wat meer geavanceerde dingen willen doen met hun website. Voor echt grote projecten, is het als initiële keus waarschijnlijk minder geschikt.

[PatrickH89]

Ik vind het vooral interessant dat de argumenten totaal uitblijven. Er is geen 'geknutsel', er worden gewoon design patterns gebruikt en PHP is niet traag. Het is simpelweg onwaar.

@raptorix Beweert met zijn kennis van .NET te vergelijken met PHP, maar heeft geen kaas gegeten van het huidige ecosysteem. Echte argumenten heb ik daar ook niet gezien, we hebben het alleen maar over 'neerkijken' (ook het feit dat er gelachen wordt omdat iemand zegt dat het core team van Laravel uit 5 man bestaat, terwijl Laravel een open source project is wat natuurlijk niet alleen door het core team gebouwd wordt) op de taal omdat .NET 'beter' is (wederom, ik ben benieuwd naar de argumenten).

[delphium]

Ik moet toegeven dat met PHP7 de problemen zijn verminderd, maar nog steeds maken frameworks als Symfony en Laravel je project echt apentraag. En ja dat komt door de design patterns, waar PHP gewoon niet op gebouwd is.

Ik heb jaren lang met Yii 1 gewerkt en met bijvoorbeeld codeigniter. Ik heb daar grote projecten in gebouwd die tot het einde toe zeer snel aanvoelden. Ook op oudere laptops van toen (3e generatie i5 enz.). Mijn eerste project in Symfony was een tafeltennisplatform. Dat was na drie weken programmeren echt niet vooruit te branden. Wel op de server, niet op onze laptops. We hebben het herbouwd in Yii 1 en het werkte weer als een zonnetje.

Het is op zich ook niet raar als je allerhande mega bloated troep als Doctrine en Twig aan elkaar gaat knopen met nog meer code die ook nog zwaar is wegens alle Java-trucs die worden gebruikt. Natuurlijk heeft het voor ontwikkelaars (met snelle hardware) ook voordelen, maar mijn punt was dat die frameworks en design patterns PHP traag maken.

@PatrickH89 Ik krijg van jou anders ook geen argumenten waarom wat ik zeg "onwaar" zou zijn. Leg maar eens uit hoe Laravel en Symfony PHP sneller maken dan.

[PatrickH89]

Het is vooralsnog 'wie stelt bewijst'. Ik hoef geen tegenargumenten te geven tegen non-argumenten, zo werkt een discussie

Ik heb eerste hand ervaring dat Symfony en Laravel je project nauwelijks trager maken, IO is altijd veruit de blockende factor, de roundtrips naar database en terug. De rest is, zolang je netjes de regels volgt (n+1 is een grote), peanuts bij het optimaliseren van een applicatie. 'Apentraag' dan is er echt iets mis gegaan bij het gebruik van het ORM of een ander onderdeel van het framework. Of je doet nou net iets waar PHP niet goed in is, dat kan natuurlijk absoluut.

[Tielenaar]

Dit is gewoon niet waar.
PHP is daar prima voor uitgerust, en DI werkt uitstekend zonder dat er ook maar iets traag wordt.

Het is niet zo dat Symfony of Laravel design patterns overbrengen naar PHP, dat doet PHP geheel zelf, alleen is het niet verplicht. De hele taal is erop ingericht inmiddels, daar heb je echt geen framework voor nodig die dat dicteert.

[raptorix]

Wij beweren ook niet dat het niet kan, het gaat erom dat als je bepaalde design patterns wilt toepassen er veel alternatieven zijn. Daarnaast als je kijkt naar c# met .NET hoeveel betere productivity tooling is, nog maar niet te spreken van de maturity van de veelgebruikte libraries, ik moest lachen dat iemand heel trots melde dat het Laravel wel 5 ontwikkelaars heeft, sorry maar als je belangrijkste framework zo klein is dan ga ik niet eens de discussie aan of iets volwassen is.

[Tielenaar]

Laravel heeft Symfony in de kern dus als je die developers erbij optelt heb je wel iets meer dan 5
Ik zou het niet als USP gebruiken, maar wat je met Laravel kan is gewoon alles dat je nodig hebt in een moderne webapplicatie. Niks mis mee.
Nee, je bouwt er ook geen Facebook mee. Maar daar is het ook niet op toegespitst. Ik weet niet wat voor applicaties jij over het algemeen bouwt, maar voor elk type applicatie is er een framework of taal te vinden. En Laravel heeft gewoon zijn doelgroep.

Doom is ook gebouwd door 5 man binnen een jaar, dat zegt op zich niet per definitie iets over de kwaliteit. De #1 core developer/oprichter van Laravel is gewoon zo'n megabrein die zijn visie goed in praktijk weet te brengen.

[PatrickH89]

Wie stelt moet bewijzen. Je kunt erg goed beweren dat er betere alternatieven zijn, maar ik heb je in geen enkele post zien komen met daadwerkelijke argumenten. Ik ben benieuwd of je kunt bewijzen dat je in de afgelopen jaren enigszins nieuws over PHP hebt gevolgd en begrijpt hoe het ecosysteem nu in elkaar zit. Voor nu lach ik eerder om jouw posts dan het aantal ontwikkelaars voor het core team van Laravel.

[henkbiertank]

Heb je weleens gekeken naar de ontwikkeling van deze frameworks? Dit zijn bewezen frameworks. Laravel bestaat al 9 jaar en Symfony zelfs al 15 jaar. Vrijwel alles wordt TDD ontwikkeld in deze frameworks. Symfony gaat nog een stap verder door daar waar mogelijk types te gebruiken (wat in PHP 7.4 zeer goed kan). Ontwikkelaars van beide frameworks knutselen niet wat in elkaar. Laravel heeft ondertussen een team van tenminste 5 ontwikkelaars en ze doen bijvoorbeeld inspiratie op uit frameworks van andere talen.

Daarnaast heb ik afgelopen jaren bij diverse grote bedrijven opdrachten gehad waar op een serieuze manier met PHP wordt gewerkt. En zoals altijd: het zijn de developers die de kwaliteit leveren van code en niet de taal. Dit zeg ik met pas 10 jaar ervaring.

[Cartman!]

Het is echt niet voor niets, dat als je een beetje bij de serieuze bedrijven kijkt, er gewoon geen PHP wordt gebruikt, en dat roep ik niet om te stangen, dit zeg ik gewoon uit 25 jaar ervaring.

Door dingen als "geknutsel" roepen over een taal en "serieuze bedrijven" geeft mij de indruk dat die 25 jaar niet veel betekent. Dan zou je juist moeten weten dat elke taal z'n toepassingen heeft en dat de term "serieuze bedrijven" ook kan betekenen dat je alleen bij grijze kantoren hebt gewerkt met medewerkers die aan een administratiepakketje mochten werken.

Omarm juist de verschillende talen ipv ze af te fikken.

[Tielenaar]

Die 80% is misschien niet super accuraat, maar een groot deel van de websites draait op Wordpress. PHP dus. Dat betekent niet dat er actief door de website eigenaar op ontwikkeld wordt, want je kan Wordpress gebruiken zonder 1 regel code te typen.
Zichtbare .php extensies zijn een ouderwetse indicatie dat een site op PHP draait, maar het gros van de PHP sites heeft dat al een jaar of 15 niet meer zichtbaar. Er zijn genoeg andere manieren om te scannen op wat voor servertechnologie een site draait.
Kijk eens op builtwith.com en vul daar bijvoorbeeld tweakers.net in. Je ziet meteen PHP staan, terwijl nergens een .php extensie zichtbaar is.

Ik denk dat je niet heel erg thuis bent in de wereld van PHP, maar het is een zeer veel gebruikte serieuze taal om flinke applicaties mee te bouwen. Met frameworks als Symfony of Laravel, of CMSen als Drupal (en Wordpress) kan je vrijwel alles op een zeer professionele manier in elkaar steken.

@Erwin1985 Kijk eens rond op de PHP vacatures voor medior+ en je zal zien dat een SOLID basis of flinke ervaring met grote frameworks of OOP zeer veel voorkomt.
Ik heb recent een aantal PHP baantjes achter de rug en de striktheid in het ontwikkelen is enorm en heerst onder een zeer grote hoeveelheid developers. Allemaal eigenlijk.
PHP developers "die maar wat doen" worden door mediors en seniors zeer snel klaargestoomd om wel op een professionele manier hun code te schrijven en als je in een team van meer dan 3 man terecht komt kan je echt niet meer wegkomen zonder code met fatsoenlijke OOP.
Ontwikkelstraten zijn streng; code sniffers, standaarden, en automatische tests zorgen ervoor dat software bijzonder stabiel kan draaien.

Ik heb al jaren geen vacature meer gezien waar de eis is dat je "php, html en mysql" kan schrijven.

"De reputatie dat PHP geen serieuze ontwikkeltaal zou zijn, ligt al ver achter ons." is absoluut waar, maar er zijn stugge mensen die al jaren geen PHP hebben aangeraakt die dit nog steeds denken.

[GamingZeUs]

Ik denk, eerlijk waar, dat PHP's nieuwe functies enorm gaan helpen bij het serieus kunnen nemen van PHP. De uitbreidingen laten de kracht van losjes typeren zien, versimpelen en verduidelijken.

Tegenover de recentere uitbreidingen aan Javascript, die vooral sneller willen kunnen maken, door de taal stricter te maken, en de asynchrone uitbreidingen (die vaak knap artistieke code maken) is de taal voorlopig gemoeid met een bizarre legacy aan 'super hacks' - manieren om de taal overal bruikbaar te maken.

C# en Java zijn ondertussen nog even 'gewoon goed' en dus een beetje krampachtig in gebruik als altijd. Opvallend is misschien C++ dat gewoon stabiel deel van de algehele chain uitmaakt.

Nog een keertje hulde voor Haskell en de academici die zich daaraan bezigt, want de meeste verbeteringen komen vrijwel direct uit dat stoere taaltje

[Peedy]

Overigens is het voorbeeld van de Union Types incorrect.

private string|int|float $storage;

Maar in de code wordt $storage als een array gebruikt. Het is niet mogelijk om de union types voor de inhoud van een array aan te geven.

Zo werkt de code wel;

class SimpleCache {
private array $storage;

public function setData(string $key, string|int|float $data): void {
$this->storage[$key] = $data;
}
public function getData(string $key): string|int|float|false {
if ( ! array_key_exists($key, $this->storage)) {
return false;
}

return $this->storage[$key] ?: false;
}
}

[Reactie gewijzigd door Peedy op 22 juli 2024 19:21]

[DaFeliX]

ach ja, stom

Aangepast

[Peedy]

Ook nog even return $this->storage[$key] : false; in return $this->storage[$key] ?: false; veranderen

[DaFeliX]

Ik had hier blijkbaar iets verkeerd gekopieerd, had "return $this->storage[$key];" moeten zijn. De ":?" gebruiken in voorbeeldcode wilde ik juist vermijden, zodat het voorbeeld ook duidelijk is voor mensen die nog niet zo bekend zijn met die syntax.

[las3r]

Leuk informatief artikel, en fijn dat jullie hier zaken over delen. Ik ben wel benieuwd of tweakers ook van plan is om php8 specifieke zaken te gaan gebruiken en/of ombouwen?

[DaFeliX]

Ter voorbereiding op dit artikel heb ik PHP gecompileerd en naast mijn eigen tests, ook gekeken of ik de test-suite van Tweakers kon draaien. Na wat gepiel kwam ik er achter dat er nog genoeg werk te doen is om over te kunnen stappen naar PHP 8; dat komt mede door externe libraries die we gebruiken en nog niet compatible zijn.

Wel heb ik al wat dingen gezien die we alvast zouden kunnen verbeteren om forwards-compatible te zijn, echt overstappen op PHP 8 zal nog wel eventjes duren.

[Kees]

Uiteraard. Het is dat ik de servers upgrade en wacht tot er een stabiele versie is met een paar patches, anders zouden de developers nu al een php 8 beta in productie willen draaien

[robertpNL]

Happy Birthday PHP!

Het is geen twijfel dat de huidige ontwikkeltrend in webdevelopment meer richting zogenoemde Single Page Applications gaat waar browser geen reloads meer doen, maar gebruik maken van allerlei Javascript technieken. Er is een enorme groei van javascripts libariers, frameworks zoals React en Vue.

Uiteindelijk is PHP een server-side rendering en dat is natuurlijk prima. Maar iemand die in 2020 een nieuwe website gaat beginnen, zal niet snel meer kiezen voor een server-side rendering mogelijkheid. De huidige javscript frameworks als next of Nuxt zetten PHP buiten spel.

Nogmaals happy birthday PHP, maar raak niet van streek als op termijn minder voor PHP wordt gekozen. Het is 2020.

[Bartmanz]

Je kunt PHP als server-side rendering gebruiken maar is zeker niet enkel beperkt tot dat. Ik zie zelf dat PHP juist heel veel als API-backend wordt gebruikt voor de single page applications (het moet ergens zn data vandaan halen hè).

[Reactie gewijzigd door Bartmanz op 22 juli 2024 19:21]

[Saven]

Precies dit dus

[Ventieldopje]

Dat de frontend en backend vaak losgekoppeld worden nu klopt maar waar denk je dat de frontend zijn data vandaan haalt? Juist, de backend.. en waar denk je dat die onder andere in geschreven wordt? Juist ja, PHP

Welkom in 2020

[ACM]

Heeft PHP dat nodig om je frontend dat te geven?

Je frontend doet asynchroon een request naar de backend, die dat in geval van PHP vaak parallel met de andere requests afhandelt.

De asynchrone serverside oplossingen zijn vooral gericht op het loshalen van het beheer van de verbindingen van het bijbehorende rekenwerk en dat eventueel weer van het wachten op data-bronnen.

Maar vanuit de frontendcode is het verder niet zo relevant of je tijdens het wachten dan op allerlei asynchrone processen of op een synchroon proces aan het wachten bent.

Het kan zijn dat je dan op een gegeven moment tegen beperkingen aanloopt op het gebied van schaalbaarheid, maar dan moet je wel aardig wat verkeer verwerken wil dat echt vervelend worden.

En natuurlijk zijn er frameworks boven op dergelijke backendoplossingen die helemaal op maat zijn gemaakt om die frontendwerkwijze te omarmen, maar in principe is dat ook bij PHP mogelijk.

[robertpNL]

Async, blocking I/O, Event driven enzovoort zitten voor wat ik weet niet standaard in PHP. Daarmee zeg ik niet dat PHP een slechte keuze is voor bv backend werkzaamheden. Maar het verbaasd mij nog wel. Maar misschien loop ik nog achter met mijn kennis. Dan hoor ik dat graag uiteraard.

[Cartman!]

Je loopt inderdaad ook achter, PHP kan dit dmv libraries/tools als Swoole, ReactPHP en Amp.

Zo makkelijk om iets te roepen zonder het eerst even op te zoeken.

[robertpNL]

Klopt maar ik schrijf ook express "standaard" dus bedoeld vanuit de taal of processor zelf. Zoals andere processors tegenwoordig doen.

[Cartman!]

De taal kan het dus wat mij betreft is dat dan "standaard" In NodeJS moet je ook zelf die loop maken, dat gebeurt ook niet magisch in die zin is het dus hetzelfde.

[Saven]

Dat doet nog steeds niks af dat je dat zoals ACM zegt helemaal niet nodig hebt in je backend. Dat is voor je front end, en dat kan prima in Javascript. NodeJS is bijvoorbeeld niks vergeleken met PHP wat betreft volwassenheid.

Je kunt prima een grote php backend draaien, wat je in de front end doet is aan jou. Dat kan vanilla Javascript zijn of iets als Vue. Voor de dataverwerking is php helemaal prima.

[timosmit]

Beetje kortzichtig (los van de toon van je reactie).. Je hoeft ook niet van server-side rendering/asynchrone processen in de back-end gebruik te maken om een back-end te schrijven in PHP. Gewoon JSON uitspugen is voldoende als je wat simpele database calls in je endpoints doet.

[Reactie gewijzigd door timosmit op 22 juli 2024 19:21]

[hackerhater]

Daaraantegen heeft het ook voordelen dat elk request op zichzelf staat.
Je veroorzaakt niet makkelijk geheugenlekken, waar je wel voor uit moet kijken in een taal die blijft draaien.

Voor mij is de programmeertaal om het even. PHP, Java, C# (sinds niet meer Win only), Python (al is die white-space irritant).

Al die OO-talen is 1 pot nat, use the right tool for the job.

class UserPermission {
private User $user;
private Permission $permission;

public function __construct(User $user, Permission $permission)
{
$this->user = $user;
$this->permission = $permission;
}
}

vs

class UserPermission {
private User user;
private Permission permission;

public function UserPermission(User user, Permission permission)
{
this.user = user;
this.permission = permission;
}
}

Syntax verschilt iets, verder 1 pot nat.
Edit: Whitespace blijft niet behouden

[Reactie gewijzigd door hackerhater op 22 juli 2024 19:21]

[Ventieldopje]

Al die OO-talen is 1 pot nat, use the right tool for the job.

Hoe je in één zin je jezelf tegen kan spreken Als je ervaring hebt met wat OO talen dan ben ik het met je eens dat de meesten wel op elkaar lijken maar qua features en filosofie wel enorm kunnen verschillen. "Verder 1 pot nat", nee dus

[hackerhater]

Wat ik ermee bedoel is dat ze zo erg op elkaar lijken dat het vrij triviaal is om van OO-taal A naar OO-taal B over te springen.

De filosofie verschilt inderdaad per taal en waar je ze het beste voor kan inzetten.
Maar bijvoorbeeld voor het web is er nog bar weinig verschil in de mogelijkheden van PHP vs Java vs C#, buiten dat PHP zo zijn upperlimit qua load heeft.

[Tielenaar]

Heb je iets beters dan OO? Ik ben heel benieuwd!

[rrs2]

FP (functional programming) is vrij populair. Beter is natuurlijk subjectief, maar een taal als Scala maakt het voor mij wel makkelijker om kwalitatieve code te schrijven.

[Tielenaar]

Alleen is Scala een beetje aan het doodbloeden, wellicht met reden

[veltnet]

OO is leuk om te modelleren maar in veel gevallen voldoet procedurele code ook prima.
Daar is op zich niets mis mee als je geen modellen nodig hebt.

[armageddon_2k1]

En vertel eens, wat ga je met al die asynchronous processing doen?

[Gopher]

Niet elke keer de hele stack opbouwen voor elk request.

[Cartman!]

Wat is daar perse erg aan als dit in praktijk bloedsnel is?

[Gopher]

Het is niet perse heel erg, ligt ook aan de situatie. Maar het scheelt altijd als bepaalde services en database connecties gewoon niet opnieuw gemaakt hoeven te worden. Zeker als je over applicaties spreekt met xx requests per seconde. Je zult in sommige gevallen echt al heel snel veel geheugen gaan gebruiken wat je in andere stacks veel minder hebt.

Talen/systemen met ondersteuning voor asynchroon processen hoeven meestal niet elke keer te doen, ook de mogelijkheid om meerdere services tegelijkertijd te raadplegen vanuit je backend kan heel krachtig zijn.

[Cartman!]

Dan heb je t meer over using the right tool for the job en dan vind ik PHP ook niet de meest geschikte keuze. Echter veruit de meeste mensen die een website/appje maken hebben helemaal niet te maken met xx requests per seconde.

Los daarvan, ook kun je slim gebruik maken van cache (Varnish, CDN) en dan kun je met PHP nog steeds prima af.

[Gopher]

Zolang je vooral statische content serveert is dat zeker waar. Maar in dat geval zou ik eerder naar een oplossing kijken welke statische html genereert. Uiteraard kijk ik dan misschien te weinig vanuit een oogpunt om even snel iets op te zetten. Ik heb wat dat betreft nog te weinig ervaring met statische website generators.

In mijn ervaring, zowel toen ik werkte met PHP als met Java en Javascript werkte ik vaak aan dynamische applicaties en daar vind ik PHP vaak niet super geschikt voor. In de praktijk zie ik echter veel bedrijven met developers welke met name/alleen PHP kennen en dat dan ook voor alle applicaties toepassen waarmee een oplossing word gemaakt welke uiteindelijk niet ideaal is.

Ik denk dat Tweakers een redelijk goed voorbeeld kan zijn waar het snel te complex word met PHP. Zover ik weet word er nogal veel caching toegepast. Het werkt uiteraard maar als ik anno 2020 kijk, denk ik dat er betere oplossingen zijn. Afijn, daar zijn uiteraard ook meningen over verdeeld.

[Cartman!]

Ik denk dat Tweakers een redelijk goed voorbeeld kan zijn waar het snel te complex word met PHP. Zover ik weet word er nogal veel caching toegepast. Het werkt uiteraard maar als ik anno 2020 kijk, denk ik dat er betere oplossingen zijn. Afijn, daar zijn uiteraard ook meningen over verdeeld.

Hoe zou een site als Tweakers minder complex worden van een andere taal? Natuurlijk passen ze veel caching toe, dat doe je bij high traffic websites, ongeacht de taal.

[robertpNL]

Hetzelfde als sync processing, alleen non-blocking?

[Ventieldopje]

Dit is ook compleet zinloos want PHP en NodeJS (server-side) hebben een hele andere architectuur. NodeJS gebruikt één proces welke vervolgens door middel van events de requests laat afhandelen. In PHP wordt er voor iedere request een PHP proces gestart wat die request afhandelt en dan weer stopt. Voor PHP heb je daarom PHP-FPM dat een pool van processen klaar heeft staan zodat die afhandeling sneller gaat.

Het resultaat is hetzelfde Bovendien zijn er best asynchrone implementaties voor langlopende scripts zodat je op dezelfde manier als NodeJS te werk kan gaan.

[robertpNL]

Ja over NodeJs wat je zegt heb je gelijk. Dankje.

[Superstoned]

... en daarom schaalt php ook veel beter dan nodejs. Als je meer request aan wil dan geef je php meer cores. Dan zet je een 2e server neer. Php zal nooit je bottleneck zijn bij het opschalen - dat zit vrijwel gegarandeerd in je storage of database. Stateless heeft wat dat betreft een enorm voordeel.

[SH4D3H]

U vraagt, wij draaien: zie bijv. ReactPHP (en voor websockets Ratchet)

[ThemNuts]

Minder voor PHP kiezen ligt niet altijd bij de developer zelf. Heel veel legacy is geschreven in PHP en zal nog heel lang meegaan in PHP puur om het feit dat je het niet uitgelegd krijgt dat Vue en dergelijke veel beter zijn de dag van vandaag. Applicaties / sites moeten opbrengen, kosten sowieso al genoeg volgens de betalende partij (want het is toch maar een knopje en tekstje etc.) Niet voor niets dat 62% van de bovenvermelde survey zouden kiezen voor iets anders. De keuze kunnen doorvoeren is iets geheel anders.

[Cartman!]

Vue is dan ook geen vervanger voor iets dat server side z'n ding doet

[Superstoned]

Inderdaad wij gebruiken vue voor de front end en php back-end ;-)

[StephanVierkant]

Bedankt voor dit fijne overzicht! Ik ontwikkel zelf dagelijks in PHP (Symfony) en ben redelijk op de hoogte, maar desondanks vond ik het een informatief artikel!

Ben vooral benieuwd hoe de Attributes gaan landen. De annotations (phpdoc) werken nu heel fijn, maar ik mis wel een aantal features. Je kunt bijvoorbeeld in een Symfony controller method ('action') niet gemakkelijk zien welke route je op dat moment zit. Dat zorgt dus voor wat duplicate code. Zo fijn zijn als je die attributes in de functie/klasse kunt aanroepen, maar ik heb nog niet gezien hoe dat straks gaat werken. Reflection daarvoor gebruiken voelt was als overkill. Iemand al een idee hoe dat gaat werken? Iets als $this->attributes['route'] zou ik wel interessant vinden.

Met de Union types ben ik iets minder blij. Het was juist fijn dat PHP de laatste jaren een stuk strikter is geworden. De parameter hinting/return types hebben de kwaliteit van veel php-code in libraries en projecten heel sterk verbeterd. De wat zwakkere broeders (ja, ik heb het over jou WordPress!) gebruiken nog steeds de absurde praktijk dat een functie een null, een array/string of false (boolean) kan teruggeven, afhankelijk of het resultaat bestaat, niet bestaat of niet kan worden gevonden (error).

De voorbeeldcode bij de Nullsafe operator is overigens niet helemaal conform het Return Early Pattern . Het lijkt me een handig feature, maar dit is zo'n typisch geval waarbij programmeurs nog beter in staat worden gesteld lastig debugable code te produceren. De tijd zal het leren of ik deze feature gaat haten of juist niet.

[Ventieldopje]

Voor jouw voorbeeld met routes zijn attributes niet echt voor. Bovendien kan dat nu ook al met een attribute parser.

Voor wat je wil met routes in Symfony zie: https://symfony.com/doc/c...route-name-and-parameters

[Cerebrus]

Ik gebruik de nullsafe operator vrij regelmatig in C#, en dat werkt in die taal hetzelfde als hoe het in PHP 8 gaat werken. Ik zie niet hoe de nullsafe operator het Return Early Pattern doorbreekt of lastig te debuggen code produceert?

als een waarde in de chain null is, dan zorgt de nullsafe operator er simpelweg voor dat de waarde die toegewezen wordt op null gezet wordt en er geen null reference exceptie gethrowed wordt. Vroeg returnen kan dan nog steeds door te controleren of het resultaat null is of niet.

Ook zou het debuggen vrij eenvoudig moeten blijven. Met een debugger kan nog altijd bij elke method in de chain gestopt worden middels een 'step into' of breakpoint om te achterhalen waar de null vandaan komt.

[DaFeliX]

Ik ben ook heel benieuwd naar attributes. Enerzijds ben ik blij dat het nu een first-class citizen wordt, maar het kan natuurlijk zeer eenvoudig misbruikt worden. Het feit dat je reflection nodig hebt om ze uit te lezen maakt debuggen lastig; want kom er maar eens achter waarom je attribute niet "gezien" wordt.

In dat opzicht geloof ik meer in expliciet zaken configureren. Neem je voorbeeld van routes, met attributes kun je net zo makkelijk een collision krijgen (twee actions met dezelfde endpoint). Als je dit in een config-array plaatst, krijg je net zo eenvoudig een collision. Echter, kun je de config uitlezen in je debugger (of, var_dump-en ) en zie je precies welke route er 'gewonnen' heeft; of in ieder geval, in welke volgorde ze zijn gespecificeerd. Zoals met alles, voorzichtigheid is geboden bij het toepassen hiervan.

Ik erger mij ook aan het returnen van null, of nog erger, false voor functies die een exception zouden kunnen gooien. 'Helaas' is het nog wel een wijd verspreid fenomeen in de PHP code, en als gevolg daarvan ook in userland-code. Of union-types dit in de hand werken, weet ik niet. Wel zie ik liever een explicitiete return value int|false, dan niets en ik maar moet raden wat ik terug zou krijgen.

[BobV]

De huidige route kun je in een controller vrij eenvoudig achterhalen: gewoon een $request->get('_route'); gebruiken

En als je het anders wil doen: wij gebruiken vaak een abstracte controller laag over de standaard van symfony heen om dit soort trucjes makkelijker te maken.

[Saven]

Drie return types is inderdaad wat overdreven, maar een Object of Null returnen als het niet bestaat lijkt me een valide gebruik hiervan.

[StephanVierkant]

Return types kunnen al nullable zijn: function fooBar() : ?object.

[Webgnome]

Zelf kom ik toch elke keer weer terug op hoe makkelijk PHP is. Tegenwoordig is het met typecasting ea zaken die in 7 zijn geintroduceerd toch aardig goed te doen als oude java prutser. Het is nog niet perfect maar het gaat de goede kant op.

Persoonlijk zie ik liever PHP op een backend dan een javascript framework waar je 100 miljoen miljard imports hebt waar vervolgens niemand meer van weet wat ze doen.

Het enige waar ik niet blij van wordt zijn union types zoals ze hier besproken worden. In een taal als PHP begrijp ik het ergens wel maar toch .. als je een variabel hebt wat 100 verschillende typen kan zijn waarom dan union types introduceren. dAn weet je toch nog niet zeker wat je binnen krijgt / waar je mee te maken hebt.

[Reactie gewijzigd door Webgnome op 22 juli 2024 19:21]

[Ventieldopje]

Dat iets er in zit wil niet zeggen dat je het ook moet gebruiken. Ook union types kun je prima netjes gebruiken

[Webgnome]

ja dat geloof ik ook graag maar ik vrees dat het nog wel eens 'niet netjes' gebruikt gaat worden

[Ventieldopje]

Ongetwijfeld maar iedere taal heeft dit wel een beetje Ik heb al heel wat gruwelijk code gezien. Als je dat er uit zou halen dan zou je geen taal meer over houden.

Kortom, spaghetti code en Wordpress zijn écht geen goede voorbeelden van wat de code kan en hoort te zijn. PHP heeft juist een hele set standaarden om netjes te programmeren (PSR-2, PSR-12 etc.) en ook ondersteuning voor statische analyse (psalm, phpstan etc.) om mogelijke bugs en narigheid op te sporen die je over het hoofd hebt gezien. Veel van de slechte code die je tegen komt is van programmeurs die daar lak aan hebben of zelfs nog nooit van gehoord hebben. Dit doet echter niks af aan de taal maar aan de programmeur

[tricky_il]

Ik werd zelf dan juist wel weer blij van de implementatie van union types, mede omdat ik het in andere talen zoals TypeScript en Java gebruik. Denk dat je gewoon wat afspraken moet maken over het gebruik van union types

[winkbrace]

Ja het is nog steeds heel expliciet.

Waar ik ook verrassend veel plezier van heb zijn de arrow functions. Ook iets dat je kent uit js, maar waar ik niet verwacht had zo blij mee te zijn.

[hackerhater]

Grote voordeel van union types is als je maar 2 type waardes wilt toestaan (bijvoorbeeld string en int).
Nu in PHP 7 moet je het open zetten voor willekeurig elk type en moet je checken.

In PHP 8 (union type) kan je afdwingen dat alleen die 2 types binnen komen of terug gegeven kunnen worden.
Maar met je eens dat dit makkelijk misbruikt kan worden en het vaak op een slecht ontwerp wijst.

[Reactie gewijzigd door hackerhater op 22 juli 2024 19:21]

[Cerebrus]

Zelf geef ik voor dit soort situaties dan weer de voorkeur aan method overloading, iets wat in PHP (nog) niet ondersteund wordt maar wel in bijvoorbeeld Java en C#.

Door method overloading te gebruiken kun je twee aparte methods maken met dezelfde naam, waarvan één een string accepteert en de ander een int. Voordeel hiervan is dat voor elke afzonderlijke overload de return type aangegeven kan worden, waardoor union types niet nodig zijn en het altijd duidelijk is wat er gereturned wordt.

[Ventieldopje]

Dat is inderdaad de netter manier vind ik, naast generics vind ik method overloading nog wel een groot gemis in PHP. Helaas is dit al wel vaker aangekaart maar het lijkt heel lastig te implementeren. Maar goed, zo waren er in het verleden wel meer dingen lastig lijkt mij die er nu wel in zitten. Het gaat dus de goede kant op.

[casberrypi]

Je kunt unon types heel goed gebruiken als je van een dynamisch getypeerd project naar statisch wil gaan. Je kunt dan opeens wel een return type of typed parameter gebruiken zonder al te veel code direct te moeten reactoren.

[Anoniem: 58485]

PHP is ideaal. Vooral een eigen server met daarop verschillende versies die per selector in te stellen zijn. Ancient 5.4, 5.6, 7.2, 7.3 & 7.4. Versie 8 lijkt een behoorlijke omslag te gaan maken in code.

[DaFeliX]

je weet dat 5.4 al 5 end of life is? Just saying

[Arietje]

Voor de volledigheid, met CloudLinux heb je een PHP selector én zij patchen oude versies: https://www.cloudlinux.com/hardenedphp

[fretnn]

Waar ik het meest van hou van php is dat je bij elke request met een nieuwe state begint. (Session variables en cookies niet meegerekend)

[JustFogMaxi]

Dat komt natuurlijk omdat http stateless is by design. Dat heeft ASP.NET etc ook.

[EraYaN]

ASP.NET houdt er overigens wel degelijk singletons of andere permanente items op na en het proces runt op zich gewoon continue (totdat IIS in al zijn wijsheid natuurlijk wat moois doet). PHP met PHP-FPM is in dat opzicht een stuk absoluter met zijn one proces per request model.

[Gustaaf437]

Ik kwam laatst een artikel tegen met wat JIT testen (kan helaas de bron niet meer achterhalen) waaruit bleek dat JIT vooral een boost gaf bij abstracte code. Dit is enigszins logisch aangezien het compileren zelf niet zonder performance loss is, maar als een stuk code eenmaal gecompileerd is wel veel sneller is. Roep je dus 80x dezelfde functie aan, dan zal die functie 80x op de versnelde manier worden uitgevoerd.

Nu is het schrijven van abstracte code ook niet ik elke use-case goed, dus het hangt heel erg van de soort applicatie af of JIT winst brengt ja of nee.

[Ventieldopje]

Daarnaast is JIT niet aan of uit maar heb je een heel stel verschillende modi. Je zal dus moeten profilen om te kijken met welke modus de meeste winst gehaald wordt en op welk vlak.

[SilentLucidity]

Ruime meerderheid is maar net hoe je het opvat, eerder in het artikel wordt er gemeld dat er een tweederde meerderheid nodig is. In dat geval vind ik dat het voorstel er maar net door is.