shared global mutable state: the session, a superglobal with no controls around it. Once. you start using it, it's debugging hell
the inconsistencies around "utility" functions (particularly arrays and strings). Sometimes the subject is first, other times last, sometimes it's passed by reference, other times it returns the changed item
still allowing require/include with code execution. Assuming the existence of parent-level variables is a sure-fire way to fool any static code analysis tools and an easy way to introduce bugs.
PSR standards are great but there's still no platform-level way to enforce routing, for example. Routing is still a mix of PHP and external pathfinding (from web server) which means that not only you're still allowed to hit random scripts that may be lying around but the only thing standing in the way of security is your ability to master not just the language but at least one web server. Which in turn hampers usability of PHP in cloud.
speaking of cloud, aside from inefficiencies of an interpretend language, when using PHP in a container orchestrated environment, you will still need an extra proxy in front (eg: in k8s a request usually goes through an external LB through an ingress controller, through nginx and then through FPM - that's an extra networking node not needed for other platform). => fortunately there are modern platforms like Roadrunner that are able to efficiently replace FPM.
Basically what I would expect from PHP 8 to fully stand its ground are:
no more includes, bake in autoload and that's it.
default to PSR7 and 15 at platform level, no more haphazard entry scripts
cut down utility functions. In PHP8 with JIT there's little difference between baked in array walkers and writing your own.
type inference when strict types are on
either wrap session in some collection (see how Symfony does it) or structured object or just be done with it.
have a multithreaded webserver already within the platform. Srsly, maybe just replace FPM with RR officially.
On a more general level, if you spend enough time with PHP and then look at things like Elixir or Go, it's natural to start question if there's a purpose to having so much tooling and conventions (standards) that on a higher level are all meant to make up for the shortcomings of the language and platform. Sure, PHP is not the worst offender in this regard (thinking Node/JS - but Node, aside from having its own lightweight runtime that doesn't need external tooling also has ReScript that helps with language issues).
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Hm, so let's start with the obvious one: Inconsistency of the standard library especially in utilities
Yes. Although I have seen arguments on how the libraries in itself are consistent, that doesn't help for userland.
Before going into the rest of your points, I want to clarify why I consider some of them as opinion: The opt-in approach to many features like typing, PSR etc while maintaining comparability to features like include have pros and cons. I can see how a team can say that there is too much room for bad practices and too much knowledge of side effects is required. On the other hand, I also understand the power of being able to grow within a language and disregarding these arguments with "of course you can use a knife as a weapon, but that doesn't make a knife a bad thing". As such, much of the following is my opinion.
Superglobals
With a huge amount of approaches available to create statefull apps, the more interesting question is why e.g. SESSION remains the standard implementation. You mentioned approaches yourself, so we don't have to go into it, but it's a nice example of many "we will stay compatible to X" that has defined discussions of PHP externals (and I of course internally) for years. The reason this is such a heated topic is in itself proof of different opinions even with very familiar and experienced devs. So yeah, if you can't live with these decisions, I guess you are not alone.
Routing
That's an interesting viewpoint and a new one to me. Ironically, one of the reasons I would opt for using PHP is when exactly that behavior is beneficial. Just like with asynchronous behavior and all the other features that nowadays are possible with PHP, I am not a fan of tweaking basic principles. So some of the points you make - and I may interpret that wrong, so please correct me - aim at a one-for-all solution, while other options (languages) might be a natural fit.
"On the other hand, I also understand the power of being able to grow within a language and disregarding these arguments with "of course you can use a knife as a weapon, but that doesn't make a knife a bad thing"." - definitely, though the issues come when working with others.
If I would have to categorise the issues I have with PHP, aside from language issues, those would be:
cognitive load: language quirks + the need to know other infrastructure-related things (like Nginx/Apache) - plenty of gotchas to go around (though JS is a worse offender and you can see that just by how many "truthy/falsy values in JS" and "'this' in JS" articles appear every day when someone discovers how nonsensically it behaves that it bears another explanation)
legacy load: on a language level there will be a push to maintain compatibility but major versions are an opportunity to get rid of garbage and PHP 8 somewhat missed that. Seems that in PHP it aimed at deprecating behaviours, which is ok but here's the thing ....
There are load of people trained under old PHP versions (I myself started with PHP 4, although one of my favourite PHP WTF's happened in PHP5 where you had a DateTimeInterface which you couldn't implement yourself). These people will hang on to doing things their own way. The platform still allows that! It takes a lot to reframe people's minds and doing that when you happen to have someone used to PHP 5.6 on your PHP8 project is overload. I really think PHP evolution should do more to cleanup garbage and push for evolution, otherwise PHP 5 practices just get carried over and help preserve that bad reputation of the language.
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Yes, I think I got your view the first time around. I understand these concerns and know that many devs feel that "disabling the possibility for bad behavior" is the solution. And it's not that I necessarily disagree. As you said, especially when collaborating a more opinionated structure can avoid a lot. All I am saying is that the reason why this is not what happened in PHP8 is due to the fact that arguments from the "other side" prevailed. I think in a few years we'll be able to compare this better as e.g. Rust promised to never have a version 2 (so no breaking changes ever). After all, it seems to me that the internals team settled for "deprecation over time" concerning some of your points.
I remember a discussion regarding laravel a few years back where security concerns based on the misusage of model methods were addressed. I found myself thinking that a dev should be expected to know what usage of certain features implies, while the vast majority took a similar position as you and argued that the framework itself should make it impossible to produce this vulnerability. The problem I see with this notion is that I wouldn't know where to stop: after all, if you know what you are doing, then opinionated structure is just a limitation to innovation as you automatically set certain things in stone. And the necessity in many cases isn't there. It not that tooling like e.g. precommit hooks can't address many team based opinions.
"if you know what you are doing..." - well, it's a valid point, but I don't think there's an algorithm for it. It's valid to say it's a potential slippery slope but let's also consider that nobody's under any obligation here to set any hard thresholds. To me it's an issue when there's a sizable number of developers that build vulnerabilities using formerly valid practices. At some point it becomes hard to build enough conventions and practices (and hope that people will follow them under pressure) and it's easy to say "hey, that other platform/language is better because it prevents the things that make life hell for us". This is a lot of what cognitive load is about: I'm using language practices that are/were valid but they cause issues under a certain framework. I'd argue that either the platform OR the framework should prevent that. The number of things like this to keep in mind (in addition to all the gotchas and quirks) is much higher in PHP (for most of the very same things in JS, the TS platform actively fixes and deprecates stuff). Sure, as a PHP developer you should always know these (+ whatever framework you happen to use) but I'd argue that the platform and/or the framework should not be afraid to reduce the cognitive load.
"opinionated structure is just a limitation to innovation" - I've heard this before, and I know many people find joy in tooling as much as in the platform itself but IMHO innovation doesn't come from building often redundant tooling (sure, one static code tool is ok, but 10 is already too much) but from getting to code solutions.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Well, on 3 ... where do we start ...
Basically what I would expect from PHP 8 to fully stand its ground are:
On a more general level, if you spend enough time with PHP and then look at things like Elixir or Go, it's natural to start question if there's a purpose to having so much tooling and conventions (standards) that on a higher level are all meant to make up for the shortcomings of the language and platform. Sure, PHP is not the worst offender in this regard (thinking Node/JS - but Node, aside from having its own lightweight runtime that doesn't need external tooling also has ReScript that helps with language issues).
Hm, so let's start with the obvious one:
Inconsistency of the standard library especially in utilities
Yes. Although I have seen arguments on how the libraries in itself are consistent, that doesn't help for userland.
Before going into the rest of your points, I want to clarify why I consider some of them as opinion: The opt-in approach to many features like typing, PSR etc while maintaining comparability to features like include have pros and cons. I can see how a team can say that there is too much room for bad practices and too much knowledge of side effects is required. On the other hand, I also understand the power of being able to grow within a language and disregarding these arguments with "of course you can use a knife as a weapon, but that doesn't make a knife a bad thing". As such, much of the following is my opinion.
Superglobals
With a huge amount of approaches available to create statefull apps, the more interesting question is why e.g. SESSION remains the standard implementation. You mentioned approaches yourself, so we don't have to go into it, but it's a nice example of many "we will stay compatible to X" that has defined discussions of PHP externals (and I of course internally) for years. The reason this is such a heated topic is in itself proof of different opinions even with very familiar and experienced devs. So yeah, if you can't live with these decisions, I guess you are not alone.
Routing
That's an interesting viewpoint and a new one to me. Ironically, one of the reasons I would opt for using PHP is when exactly that behavior is beneficial. Just like with asynchronous behavior and all the other features that nowadays are possible with PHP, I am not a fan of tweaking basic principles. So some of the points you make - and I may interpret that wrong, so please correct me - aim at a one-for-all solution, while other options (languages) might be a natural fit.
"On the other hand, I also understand the power of being able to grow within a language and disregarding these arguments with "of course you can use a knife as a weapon, but that doesn't make a knife a bad thing"." - definitely, though the issues come when working with others.
If I would have to categorise the issues I have with PHP, aside from language issues, those would be:
There are load of people trained under old PHP versions (I myself started with PHP 4, although one of my favourite PHP WTF's happened in PHP5 where you had a DateTimeInterface which you couldn't implement yourself). These people will hang on to doing things their own way. The platform still allows that! It takes a lot to reframe people's minds and doing that when you happen to have someone used to PHP 5.6 on your PHP8 project is overload. I really think PHP evolution should do more to cleanup garbage and push for evolution, otherwise PHP 5 practices just get carried over and help preserve that bad reputation of the language.
Yes, I think I got your view the first time around. I understand these concerns and know that many devs feel that "disabling the possibility for bad behavior" is the solution. And it's not that I necessarily disagree. As you said, especially when collaborating a more opinionated structure can avoid a lot. All I am saying is that the reason why this is not what happened in PHP8 is due to the fact that arguments from the "other side" prevailed. I think in a few years we'll be able to compare this better as e.g. Rust promised to never have a version 2 (so no breaking changes ever). After all, it seems to me that the internals team settled for "deprecation over time" concerning some of your points.
I remember a discussion regarding laravel a few years back where security concerns based on the misusage of model methods were addressed. I found myself thinking that a dev should be expected to know what usage of certain features implies, while the vast majority took a similar position as you and argued that the framework itself should make it impossible to produce this vulnerability. The problem I see with this notion is that I wouldn't know where to stop: after all, if you know what you are doing, then opinionated structure is just a limitation to innovation as you automatically set certain things in stone. And the necessity in many cases isn't there. It not that tooling like e.g. precommit hooks can't address many team based opinions.
"if you know what you are doing..." - well, it's a valid point, but I don't think there's an algorithm for it. It's valid to say it's a potential slippery slope but let's also consider that nobody's under any obligation here to set any hard thresholds. To me it's an issue when there's a sizable number of developers that build vulnerabilities using formerly valid practices. At some point it becomes hard to build enough conventions and practices (and hope that people will follow them under pressure) and it's easy to say "hey, that other platform/language is better because it prevents the things that make life hell for us". This is a lot of what cognitive load is about: I'm using language practices that are/were valid but they cause issues under a certain framework. I'd argue that either the platform OR the framework should prevent that. The number of things like this to keep in mind (in addition to all the gotchas and quirks) is much higher in PHP (for most of the very same things in JS, the TS platform actively fixes and deprecates stuff). Sure, as a PHP developer you should always know these (+ whatever framework you happen to use) but I'd argue that the platform and/or the framework should not be afraid to reduce the cognitive load.
"opinionated structure is just a limitation to innovation" - I've heard this before, and I know many people find joy in tooling as much as in the platform itself but IMHO innovation doesn't come from building often redundant tooling (sure, one static code tool is ok, but 10 is already too much) but from getting to code solutions.