I'm going to go ahead and play devil's advocate here and make the argument that iteratively transforming PHP into a Java/C# clone is actually doing a disservice to PHP. The reason PHP is so popular, and it's greatest strength, is that it offers a "simpler" paradigm of development.
Many of the latest RFCs accepted (while I agree are great steps forward for the language) may actually reduce it's foothold going forward. That is, they are not a good fit for the community. I see no compelling reason to choose PHP for a greenfield project if, when used in a production environment with a stable framework, you are writing essentially the same code as you would for Java/C#. There is hardly a feature where an ASP.NET core C# project isn't still miles ahead of the same Symphony/Laravel back-end. Hell, with the new Razor-Pages template, you are essentially writing "PHP" in C#... where you get all of the bells, whistles, helpers, type-checking, generics, pattern matching, LINQ etc that C# already offers!
IMO (emphasis on the "O") they are missing the point. I don't want my PHP application to "look" just like a Java/C# app. I don't want a `Controllers` directory and `RepositoryInterface`s everywhere... I don't want all of the same ceremony it takes to develop a .NET Core/Spring app copied into PHP. What I want is a composition of "scripts" (functions)!
PHP should focus on and develop towards it's strengths not it's weaknesses. Lean in to include. Lean in to $GLOBALS. Lean in to a more functional approach. These are the things that have made PHP so dead-simple/approachable over the years.
You want more features? Fine. Add pre-processing directives (akin to .razor). Allow for files to truly be treated as modules. Simplify/abstract templating into the language better. That is, instead of focusing on the kinds of "features" that better-enable OOP (and move away from a composition of "scripts"), focus on making it easier/better to compose "scripts". Make _that_ safer, clearer, more ergonomic. There are _plenty_ of ways to dramatically improve PHP (as a platform) without simply updating the language semantics. The language was _never_ the draw!
As many of the comments in this thread indicate/imply, PHP isn't chosen because it is such a great language, rather, it is chosen because it offers an extremely convenient development paradigm. PHP is very-much "batteries included" when compared to its contemporaries[0]. _This_ is why people reach for it over and over again. So instead of changing the vehicle (PHP), how about we give it more/better batteries instead?
/devil's advocate
How'd I do?
[0] I have always found the whole "framework vs raw PHP" debate in the community a bit humorous. The "framework" crowd never seems to really understand that, in many ways, raw PHP is a framework. What other scripting languages automatically parse HTTP requests for you as part of the runtime? Or come with a default "routing" scheme? Or offer built-in templating semantics? PHP gives you all three out of the box.
Many of the latest RFCs accepted (while I agree are great steps forward for the language) may actually reduce it's foothold going forward. That is, they are not a good fit for the community. I see no compelling reason to choose PHP for a greenfield project if, when used in a production environment with a stable framework, you are writing essentially the same code as you would for Java/C#. There is hardly a feature where an ASP.NET core C# project isn't still miles ahead of the same Symphony/Laravel back-end. Hell, with the new Razor-Pages template, you are essentially writing "PHP" in C#... where you get all of the bells, whistles, helpers, type-checking, generics, pattern matching, LINQ etc that C# already offers!
IMO (emphasis on the "O") they are missing the point. I don't want my PHP application to "look" just like a Java/C# app. I don't want a `Controllers` directory and `RepositoryInterface`s everywhere... I don't want all of the same ceremony it takes to develop a .NET Core/Spring app copied into PHP. What I want is a composition of "scripts" (functions)!
PHP should focus on and develop towards it's strengths not it's weaknesses. Lean in to include. Lean in to $GLOBALS. Lean in to a more functional approach. These are the things that have made PHP so dead-simple/approachable over the years.
You want more features? Fine. Add pre-processing directives (akin to .razor). Allow for files to truly be treated as modules. Simplify/abstract templating into the language better. That is, instead of focusing on the kinds of "features" that better-enable OOP (and move away from a composition of "scripts"), focus on making it easier/better to compose "scripts". Make _that_ safer, clearer, more ergonomic. There are _plenty_ of ways to dramatically improve PHP (as a platform) without simply updating the language semantics. The language was _never_ the draw!
As many of the comments in this thread indicate/imply, PHP isn't chosen because it is such a great language, rather, it is chosen because it offers an extremely convenient development paradigm. PHP is very-much "batteries included" when compared to its contemporaries[0]. _This_ is why people reach for it over and over again. So instead of changing the vehicle (PHP), how about we give it more/better batteries instead?
/devil's advocate
How'd I do?
[0] I have always found the whole "framework vs raw PHP" debate in the community a bit humorous. The "framework" crowd never seems to really understand that, in many ways, raw PHP is a framework. What other scripting languages automatically parse HTTP requests for you as part of the runtime? Or come with a default "routing" scheme? Or offer built-in templating semantics? PHP gives you all three out of the box.