> How are pass-by-value and pass-by-object distinguishable for immutable values?
They aren't really. There's no real technical difference, just a terminology difference. All that you need to know is that whether it be Python, PHP, Java, or whatever that passing around scalars and objects works out the same.
> You said (array) as a cast is useful because a function can accept either a single value or an array of values, and the (array) cast will produce an array either way.
I never said anything about functions -- just that the cast itself is useful.
> because passing a single value that happens to be an object will cause the function to cast it to an array of the object's contents, which will have fascinating but useless results.
People cast objects to arrays in PHP all the time because that can be a useful operation. I understand you point, but I don't really think it's too valid. If you're explicitly doing a cast, you should know what you're casting from. This is sound advice no matter what language you're using.
> strictly speaking Python isn't interpreted, whereas e.g. shell is.
It's an implementation detail that's not significant. The next version of bash should byte-code compile everything behind the scenes and run it (like PHP does) and it wouldn't make any difference. You could write an interpreter for C code (they exist) and it wouldn't change anything about C.
> Note that, for the same reason, you also can't chain calls like `foo()()`.
Honestly, there's no language grammar reason why that shouldn't work in PHP. It's just that parser sucks and they're very slow/careful to make changes to the parser. If it's a function name, a closure, or an object that supports being called they're called the same. If you can do $foo() then you should be able to do foo()(). The same is true about foo()[]. These things don't have to special-cased so much as the parser has to be modified to be more generally accepting.
> What language are you thinking of where there's a distinction made -- in the parser, no less -- between a variable and an expression?
PHP makes no distinction between a variable and an expression (except as described above). It's make a distinction between scalars and objects.
> Sure, why not? Not that I was suggesting PHP direly needs scalar methods, but if a number responds to strlen(), why not to ->strlen()?
Then there's really no point in having scalars be objects. You could add syntactic sugar to make strlen($x) and $x->strlen() do exactly the same thing but what would be the point? I'd rather they do something more interesting with that ability. I think it's the only way they can successfully implement unicode.
> Leave the existing function totally broken. Create a new one with a confusing and even longer name. Make everyone fix their code and remember to use the new function in the future.
MySQL made this decision, not PHP. They just give you the library to use. Anyway, you seem to have a problem with the concept of backwards compatibility -- it generally does mean "continue to use this broken thing because you don't want to change your code".
> I'm hearing this a lot, but (as far as I can be trusted to say this) I don't see it.
Someone tells you that you lack perspective and you don't see it -- so ironic! (I'm just being cheeky)
> I draw a lot of comparisons to Python and Perl because they're in the same family and I know more about their inner workings than anything else. That doesn't mean they're the only languages I've used or the only languages I think are worthwhile.
Yes, but going off on public/protected/private as if it's a flaw in PHP because you don't like them is not a valid critique. That's just one example but there are others. Even saying everything should be an object is more personal taste than anything else. I very much like "everything is an object" but it's not clear how best to implement that in PHP yet.
> It's the little things that matter. Every language (ahem, most) has function calls, data structures, and loops. What differentiates them is the little day-to-day stuff.
I disagree. I think I probably switch between languages a bit more than you do and the little things don't matter that much. What matters is the big things. Most of the stuff you mention in your article, if I encounter them at all, I don't even notice. It's such a non-issue that unless you bring it up, I wouldn't think to tell you. In fact, in some cases, I wasn't even sure what you were talking about because I don't encounter them (the lack of stack traces on errors, for example).
> I've heard a lot of defenses and a lot of statistics, but not too many outright advantages.
Indeed. I'm not saying PHP has advantages over other platforms -- it has some -- but, in the end, the differences between any of the platforms aren't significant and mostly personal taste. I continue to code in PHP because I know PHP, I know the frameworks, and I have lots of existing PHP code. If I had to write Python or Ruby, I would. I'm going to be writing ASP.NET code for next 6 months.
I just think your article blows everything out of proportion. Much of it is "look how this crazy unreasonable code reacts in PHP". It's not invalid but it's not really indicative of developing in PHP. Similar lists have been made for JavaScript and yet that doesn't affect opinions too much. Similar lists have been made for C and C++ but everybody knows what they're getting into there.
Here we are talking about mysql_real_escape_string() and that's as legacy as you can get.