It's not the language - it's you

Note: this is a post created with respect to the discussion stemming from this post. I felt the need to write a reaction (it's not a rebuttal, sorry - it's not in support either) because the post makes some good arguments yet it was met with the sort of fanatical derision which is fairly common in the PHP world (there is absolutely nothing questionable about the pinnacle of computing technology that is PHP).

it's not the language, it's you

This is a reply in one of the comments. In an absolute way, it's definitely true.

A language is a rather inert thing. Sure, it evolves as it's developed by its creators/maintainers but it does so in line with its ways and its philosophies which may not align with what you think it's best.

There's no guarantee that your way and the way of the language will converge and you, as a developer, need to be aware of that when making a choice.

That's not to say a language it's perfect. It's to say that it's an evolving tool which you use, but don't control.

Of course, as a developer you will not become an expert before deciding whether it's usable to you or not and there's also some expectation that a language will be consistent with itself as well as intuitive in line with its philosophies.

a bad language

No language is perfect, not to everyone at least. People will complain that Go(lang) doesn't do more to adopt OOP concepts. People will complain about typing in Javascript. People will complain about the over restrictive OOP (every bleeping thing is an object) in Java. And so on.

Developers do need to go out of their base language and learn a bit about another language with a critical eye on their own main tool. It's good to have a main tool, just don't live with the illusion of perfection.

how to tell

There's a simple way. To compensate for bad design, people create tools to make up for shortcomings in the language. That's ok, people should try to make things better. But it's a mistake not to recognise that a top reason for tooling is that those things are commonly used yet not part of the language package.

Sometimes they do become that, as part of language's evolution. It's a great way to recognise that needs of developers evolve and the language is supportive of that. The best languages are those that evolve and incorporate (and are not afraid to remove stuff as well).

Some examples? In PHP, since we've started there.

• the large list of built-in utility functions (mainly for arrays) which are shorthands for mapping functions. Of all the things could be in a library and not in the main language, those are it.
• inconsistently parameterised functions (arrays and strings mainly): sometimes it changes the subject itself (by reference, orly?!), sometimes the subject is the first, other times it's last. Annoying more than anything, but speaks to consistency.
• lack of standard serialization (xml/json). PHP has its own serialization model (useless for data exchange with anything else, which is the very definition of serialization) but no useful standard json/xml. It does have support in the sense that you can easily serialize arrays, but not objects. Say what? Yes, you can json_encode class A to json, but decoding will give you a stdClass.

Some non-examples? PHP has worked hard to offer optional strong(er) typing. As an interpreted weak-typed language as a philosophy, this is not a point I would take against the language. That's part of its reason to exist and its conception. But it's still a weakness - a recognised one.

Why is it a weakness? Because people not just fight hard to make up for that (see not just the number of static code analysis tools, but also what they check for) via tools and libs but they're also pretty much a default part of a project setup. What, you don't have PHPStan/EasyCodingStandard/PHPCS/PHPMD and so on ...? Yes, they exist to make up for PHP's weaknesses. Which is good, but it would be a mistake not to recognise their limits.

The next step would be to make them part of the standard PHP setup. Honestly that would be way more useful than more "utility" functions in the language.

takeaway

It's good to know how to critically evaluate a language. A language should have features and philosophy, but it should also be consistent with it and willing to become better.