Rasmus basically said he doesn't care if he copies and pastes stuff around so long as it gives him the end result he wanted. The language reflects that.
And, actually, it's NOT necessarily a bad thing to have a language oriented around people who don't actually care that much about programming when it's also oriented around people who want to ship something useful to an end user (who might care if it's insecure but doesn't care if the code's pretty).
I've encountered a number of orgs now that have PHP on the front speaking XMLRPC or JSONRPC or whatever to a backend daemon (either Java or Perl in the cases I've seen) and since that means messiness on the front end shouldn't be able to violate business rules, it works out really well.
PHP is not much good for security though for beginner developers. It does not help with XSS, CSRF, or SQL injection prevention. If anything it does actually encourage them if you do not know of the risks.
I feel like this is more of a role for a framework built on top of PHP than for a language like PHP itself. PHP itself is pretty low-level. How would you suggest providing better protection against these?
In the past, of course, PHP did have magic_quotes, which was a misguided attempt at mitigating SQL injections. This has since been removed, and there's been a big push in the direction of using prepared statements/parameterized queries through a library like PDO, which I think was introduced in PHP 5.
Agreed, about that this is the role of a framework and this is in many ways what is wrong about PHP. It tries to be both language and a framework with its built in templating. But templating which does not include simple to use support for escaping HTML is a really dangerous tool in the hands of a beginner.
So was the (I believe now deprecated) mysql library they shipped and the tempting ease of string interpolation.
And, actually, it's NOT necessarily a bad thing to have a language oriented around people who don't actually care that much about programming when it's also oriented around people who want to ship something useful to an end user (who might care if it's insecure but doesn't care if the code's pretty).
I've encountered a number of orgs now that have PHP on the front speaking XMLRPC or JSONRPC or whatever to a backend daemon (either Java or Perl in the cases I've seen) and since that means messiness on the front end shouldn't be able to violate business rules, it works out really well.