Some of it is still true, some of it isn't true anymore and some of it simply isn't very relevant.

Comparison still isn't transitive. Not very relevant in the real world because you simply don't use "==" unless you know what you're doing.

json_decode still returns null on invalid input, so you either have to use the JSON_THROW_ON_ERROR option to make it throw an exception instead or use json_last_error().

Both are unfortunate, of course, but it's hard to fix mistakes made 25 years ago.

And for many of us, these 25 year old warts are a benefit...

Rather than just "fixing" json_decode and breaking backwards compatibility, old code still works.

The business doesn't care about the new shiny. When someone pays to have a simple site developed, they don't want to be paying a contractor in a year to have a bunch of stuff updated so the language it's written in is "more correct" or whatever the overriding reason is to change this. That is completely tangential to what they care about.

I recently went through "modernizing" a 15 year old, 1.93 million line php 5.x app.

We put in a shim for the mysql_ extension as it had been depreciated with 7.x, and fixed up maybe a dozen places where it was doing something exceptionally wacky and then tested like crazy and sent it out the door. Works fine.

The business doesn't care that the code is shit. They care that it makes them a million dollars a month and no matter how gross it is there's no defensible rationale as to why they should stop doing things that make them more money for the next 2-3 years while a team goes through and rebuilds the entire thing to be "more correct".

Something like pyenv/nvm/etc doesn't exist for PHP. You can just install the latest version and with very few exceptions whatever code/library/etc you find will just work. There's a lot more value in that in the real world than "fixing" json_decode.

It's nice, that "the business" does not care, but that does not say anything about the language design of PHP.

PLT doesn't care whether "the business" cares.

> it's hard to fix mistakes made 25 years ago.

I like PHP, less and less since I started with it in the 90s. Largely because of the current stewardship and syntactical changes. Many languages move forward rapidly. A difference between PHP and, say, Python is that PHP seems to move more slowly to the same end. There are still trivially fixable problems that would qualify as breaking changes. Seems lazy. Instead, we have a bunch of hand wringing because those who make the releases are heavily involved with projects that move slowly out of fear...ostensibly because they have customers they don't want to antagonize. They might jump to another framework or language.

Why are you using "=="? Use "===" and make explicit casts as required.

Sometimes "==" is used under the hood ( switch/case i think?) and it's hard to avoid it completely even if you always use "===" in the code

You don't need to use switches. In fact, I'd argue that if blocks are better if you're evaluating against variable data types. Alternatively, if you really, really want to use a switch statement and loose typing might cause issues, it's pretty easy to compare types before the switch statement, e.g,

    if(gettype($a) !== "...") { return false; }
    switch($a) { ... }

Either choice doesn't really look like the sane language anymore

When you have dynamically typed languages, whether to coerce or not is a design decision with usability trade-offs. Javascript exhibits pretty similar behavior with switch statements for exactly the same reason: it also has two types of equality comparisons.

Also, PHP allows you to add explicit type casting to case statements. e.g.,

    case (string) 1:

And what is the equivalent of "===" for ">" and "<"?

An argument I've heard advanced for both PHP and JS is that their evil is well-documented and well-understood (e.g. one of the Facebook efforts was to write an extensive spec for PHP). Contrast this with, say, Python, which is much more nicely designed, but implementation-defined and with some gotcha areas with poorly understood and documented behavior - rarely encountered, but when encountered, hard to grok or avoid, also because they can readily keep changing from version to version (some of the corner case details of slots come to mind as an example).

I can see a pragmatic point there - anything has warts, the warts you know and don't move are easier to contend with (and lint for). I'd still pick Python for most projects in that comparison, but at a certain scale of effort I'd possibly begin to wonder about the trade-offs.