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