tl;dr: I value consistency in my tools because it's a great measure of how frequently they'll trip me up and get in my way while reading or writing code. My biggest problem with PHP above all else, which I tried to write my article around, is that it's an inconsistent jumble from top to bottom.
You're absolutely correct, of course, in that you can write decent PHP by avoiding large chunks of the language, memorizing what things act differently from other things that look the same, not trying to do anything too dynamic, adding boilerplate to every project to fix useless default interpreter behavior, and so on. You can also waltz across a minefield if you just remember where all the mines are. But the necessity of doing all these things is exactly my argument: why bother with all this from a tool that's supposed to help you get stuff done? Because it has $_GET out of the box? You can't even claim "ease of learning" as an advantage after all this, because judging by your own responses, much of the language is pitfalls just waiting to trip up beginners who haven't yet learned the right painful lessons.
Yes, I'm not a PHP programmer. And as a not-PHP programmer, a lot of PHP looks totally crazy. But when outsiders complain about craziness in Python or Perl or Haskell or whatever, at least that craziness can usually be explained as consistent with the rest of the language, or part of an overall philosophy, or the result of some valuable tradeoff. And if not, we're very sympathetic about the ugly warts on our dearly beloved. Yet all anyone has ever been able to tell me about PHP craziness is "well, you shouldn't do that anyway" or "that's how it is in one of ten other languages" or "I have no explanation but here's a workaround so it's like the problem doesn't actually exist, right".
It is hard for me to understand how even someone who loves PHP can't see this as deeply alarming.
> You only need distinct operators if your language is weakly typed.
I don't dispute that: I claim that having separate addition and concatenation operators, but having a single set of equality/comparison operators, is inconsistent.
> Yes, like most ever other language in existence. You know, Java, C#, Python, etc.
Incorrect. Python passes everything by reference (value reference, not name reference) because everything is an object. Passing never performs a copy. I'm under the impression that Java is the same. Perl passes by alias, though the aliases are generally then copied to locals, and it has that whole array-flattening behavior which muddies things.
> Because all code should be contained within a namespace going forward. Constants should not be defined in the top-level.
Everything in Perl is in the `main` namespace unless otherwise specified. One wonders why PHP could not retrofit its new features onto the language like Perl has done for decades, rather than leaving half the language to flounder.
> No, it doesn't work that way. You have to explicitly cast. If you use an array type-hint you can only pass an array.
I'm assuming you're using the explicit cast inside the hypothetical function.
> PHP is also bytecode-interpreted. I'm not really sure what point you're trying to make.
You appeared to be citing interpreted-ness as a reason for having a wonky module system. I am naming other interpreted languages with useful module systems as counterexamples.
> The fact that is or is not a function is insignificant; you use it the same way.
Unless you want to do other function-y things to it, or any of the other pseudo-functions. The syntax is deliberately designed to make you think something is a function, but it only acts like a function in one particular way. (And as a side effect, there are a ton of simple function names you can't use as method names, because the parser gets very confused -- even though this seems like it should be unambiguous.)
> Oh, you're saying if you don't provide any of your own error handling and let it spill out the terminal -- yes, you're right -- no stack trace by default. Not that you should be doing that.
Defaults matter. This is an atrocious default.
> Turn on E_STRICT and it'll tell you.
It'll tell me what things I've already done; I can't easily find out what I should be avoiding proactively.
> Calling a string literal is pointless! 'test'() is test()!
So what? Both are values; why is there any distinction? Hell, you can call methods on numbers in Ruby and Python. I don't care about the practical value here; it's yet another place where PHP is inconsistent for seemingly no reason.
> If you've ever complained about security in PHP, you need to give that up right now. Because you just gave everyone a false sense of security.
Howso? The problem with mysql_escape_string was that it didn't take the current database handle into account. So: make it take the current database handle into account. It may not have solved everyone's problems, but the exceptions are obvious, and it would have fixed problems for far more people than the actual solution (zero).
If you're using multiple handles and passing them around explicitly, you'll have to fix your code either way.