> Every language now has very good package managers.
Not sure if composer is "very good," but it's generally worked out better for me than gem.
(Also, package managers are not an unqualified benefit. I like them for installing things I'm not developing, but as far as I can tell they essentially defer a legibility cost for developers. Sometimes worth it. Not always.)
> There is an abundance of dynamic languages, most of whom are more consistent than PHP.
I think it was Ralph Waldo Emerson who had some choice words about consistency. And this criticism has always rung a little hollow to me. I'd agree that some of PHP's dynamic multi-paradigm scripty siblings feel cleaner, but having written code in many of them, it's never felt like a major difference in productivity to sometimes have to pause and consider argument order or precise names. The lookup cost has always seem cheap on on par.
> I just hope that everyone is aware that the huge benefits that PHP offered in 2000 are no longer valid.
There's definitely a closing in the benefits gap since 2000. PHP is far from my favorite language. PHP is not right for many projects. There are still some benefits that PHP prioritizes that I think arguably aren't done better elsewhere
* Trivial deployment story. Your app is one or more files. Drop it in a directory on a wide variety of hosting environments. You're done! (Buuut, if you want something more involved, lots of choices available there too.
* The language is the template language (though there's other options). Some people consider this an anti-feature because it allows amateurs to build ill-organized applications around a dynamic-document-as-program paradigm. I think that's still a brilliant gateway that makes the marginal cost of moving from a static document to a dynamic one small while still allowing an easy transition to front controllers. And it means the templating performs at parity with the language itself and can do as much as the language can do.
Pair it with a simple routing library and model layer and it's as easy to build something reasonable quickly as it is with comparable Python & Ruby frameworks, often with fewer moving parts and similar magnitude of performance.
So sometimes when I have smallish web-facing projects (or projects I think I might want to distribute for others to run on the web), I still often find myself reaching for it, even with plenty of other options at hand, even with languages I like better.
Not sure if composer is "very good," but it's generally worked out better for me than gem.
(Also, package managers are not an unqualified benefit. I like them for installing things I'm not developing, but as far as I can tell they essentially defer a legibility cost for developers. Sometimes worth it. Not always.)
> There is an abundance of dynamic languages, most of whom are more consistent than PHP.
I think it was Ralph Waldo Emerson who had some choice words about consistency. And this criticism has always rung a little hollow to me. I'd agree that some of PHP's dynamic multi-paradigm scripty siblings feel cleaner, but having written code in many of them, it's never felt like a major difference in productivity to sometimes have to pause and consider argument order or precise names. The lookup cost has always seem cheap on on par.
> I just hope that everyone is aware that the huge benefits that PHP offered in 2000 are no longer valid.
There's definitely a closing in the benefits gap since 2000. PHP is far from my favorite language. PHP is not right for many projects. There are still some benefits that PHP prioritizes that I think arguably aren't done better elsewhere
* Trivial deployment story. Your app is one or more files. Drop it in a directory on a wide variety of hosting environments. You're done! (Buuut, if you want something more involved, lots of choices available there too.
* The language is the template language (though there's other options). Some people consider this an anti-feature because it allows amateurs to build ill-organized applications around a dynamic-document-as-program paradigm. I think that's still a brilliant gateway that makes the marginal cost of moving from a static document to a dynamic one small while still allowing an easy transition to front controllers. And it means the templating performs at parity with the language itself and can do as much as the language can do.
Pair it with a simple routing library and model layer and it's as easy to build something reasonable quickly as it is with comparable Python & Ruby frameworks, often with fewer moving parts and similar magnitude of performance.
So sometimes when I have smallish web-facing projects (or projects I think I might want to distribute for others to run on the web), I still often find myself reaching for it, even with plenty of other options at hand, even with languages I like better.