"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.
"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.