[apeace]

These "stop making fun of PHP" articles are all the same. They are full of strawman arguments like "PHP is not actually slow!".

Nobody is complaining about it being slow. What about the fact that using an undefined variable is not an error in PHP? Yes, even in the brand-new PHP8. The fact that the function to open a file can also open an HTTP URL, run a glob, or even execute a command over SSH? Take a look at some of the things that were just fixed in PHP8 and ask yourself: if these things were just fixed after this many years, what other monstrosities are still in there?

Instead of writing "PHP is good because I've been using it for 20 years", I want someone to tell me "no errors for undefined variables is good because _______".

[hakfoo]

It's less "good or bad" and more of a philosophical choice.

PHP, especially old PHP, prioritized survivability over technical correctness. The "no errors for undefined variables" thing is just one aspect of that. Unquoted text strings accepted rather than being treated as constant names or throwing errors. Functions that failed silently and you had to retrieve the error code with a seperate function or return value. Implicitly cast a string into a taco salad. All of these things mean that code with a modest density of minor bugs-- the sort of code you'd get from normal skill programmers with low-spec tools circa 2005-- will manage to stagger its way far enough to output something useful in a browser window. It won't pass any sort of rigorous analysis but it will still work well enough to solve real user problems and make real money.

You could make a case that while more restrictive paradigms may be desirable in 2020, they are not strictly required because they can be pawned off on the ecosystem. IDEs are more capable, there are any number of auto-linters and rule-enforcers available. So you can get most of the benefits of a shinier language, but with the flexibility of still being able to drop back to "here's the 20-year-old PHP4 code that does a business critical task and can never ever be touched" level mid-project.

I feel like comparing PHP with $trendy_newer_language is sort of like the HTML/XHTML divide a long time ago. Making an intentional brittle system that demands correct developer behaviour might force you to make better code, but cheap, quick, and practical might make a better business.

[apeace]

I hear what you're saying and I appreciate your answer to the question I asked. But I still can't see it that way.

I worked in PHP5 for many years. The "survivability" thing didn't make anything cheaper, quicker, or more practical. It just made it harder to find bugs, and slower to develop new code that could pass tests (since getting your tests to pass is the process of eliminating bugs).

Achieving correctness is not hard in most languages. It's possible in PHP, but more difficult than most. I'd say the same for readability, given PHP's wide array of naming conventions.

So if we're crossing off cheap, quick, practical, correct, and readable, what do we have left? I suppose if nothing matters, then programming language choice doesn't either. But I think what we have left is "using PHP". The reason people use PHP is because using PHP matters to them. It's just what they want to do. Look at the post we're commenting on, where nearly the entire argument is "I use it because I've always used it".

It's fine if people want to use it. What gets me is when a manager wants to use PHP and I explain what a poor decision that would be, and in return I get sent a blog post like this one which makes a bunch of strawman arguments without actually addressing the real issues with the language. Your attempt to address them is among the best I've seen, but I'm still not buying it.

With regard to survivability vs. correctness, I'm glad the language is going the other direction now. It looks like they added a bunch of errors to PHP8. I am holding out hope that as every major decision in the language gets reversed, eventually something unrecognizable and much better will emerge!