You know, after seeing over and over how the supposedly worse ways actually worked better - perhaps it's time to re-decide what is actually good and bad in a language?
It just depends where you are in terms of experience. It's not that one is good or bad. PHP is easy to understand, and you can jump right into it with no experience. However over time if you have any potential as a serious programmer you will find the pain points and repetitive tasks.
In many ways, experienced programmers and language elitists are a lot like corporations. They are risk-averse. The reason best practices are what they are is to avoid known problems (sort of like bureaucracy). This will make you a better programmer to a certain point, but it's also so easy to overestimate risk. The painful truth is that a 20-year-old hacker figuring out things as he goes may be able to plow through the naive problems he inevitably creates and arrive at a finished, valuable product faster than a seasoned developer who writes uber-maintainable code with a comprehensive test suite and every best practice he can lay his hands on.
The ecosystem a piece of software is attached to is tremendously important. PHP did a great job with fitting into the existing one. It's not that PHP is better. It did a better job in the most critical ways. (It was also decently fast.)
the argument against this is usually performance and code maintenance. writing something in a strict but clearly articulated language means there's a better chance the next person looking at the code will be able to figure it out. that said, php in many ways better reflects the opportunists in us all and is more familiar because of it. by using a hodgepodge of conventions all abstracted away from their parent languages into the same compiler, php lets us pick from a much wider palette of metaphors when we're conceptualizing how we approach solving a problem. which can be pretty damn useful for those of us who don't know all the answers. it feels as though it's designed for us (messy) humans.
