Is language X dead? Or the importance of critical thinking

It happens a lot. My feed is flooded by clickbait titles pretending to ask where some programming language or framework is dead. I generally have a better use of my time than digging into that, but sometimes I’m bored enough to do it and to little surprise I find that the writers of these posts fall into 3 categories:

• people who strongly believe that said language/framework should be dead because of a variety of reasons. Some are better argued than others, but in the end the outcome is wishful thinking. Even giving them the benefit of the doubt, the fact one think something should be dead as it holds no real value in today’s landscape doesn’t make it so.
• people who clickbait for the purpose of arguing the values of said language or framework. These generally aim at languages who have recently fallen down various lists of most used/most liked tools. The TLDR is always “is X dead? It’s so amazing that it will live forever and so many great companies are using it”
• people who genuinely believe something is as good as dead. Generally by people who left said tech in a while, lost contact with the community and as per their updated bubble X is no longer in demand (duh). These posts generally mirror the reasons said person moved on but are obviously stuck in the past and do not keep up with the ways in which X has changed. These touch on everything, from PHP to Java, Ruby to Rust. Doesn’t matter how old or new the tool is.

On the face of it, we can safely TLDR to “no, it’s not dead”. Languages don’t die. Cobol isn’t dead, Lisp (to my everlasting shock) isn’t dead, Smalltalk isn’t dead. They have fallen down lits for sure but at worst they’ve become niche (although Cobol is an example that finds some degrees of resurgence, despite the fact it will likely never break top 20). Frameworks do die, sometimes, but I’d say that’s irrelevant. Don’t make the mistake of thinking yourself as a “framework developer” — be a “language developer”, keeping your skillset updated and ready to change frameworks if needed.

I say the above while strongly critical of the PHP community where you see the largest number of developers that fancy themselves Laravel developers, Symfony developers, Yii developers, etc — while few “old schools” dev simply style themselves PHP developers.

I love critical posts

However, I do tend to enjoy the first type of posts. Sometimes it’s difficult to cut through the bias inherent to someone who dislikes a technology and wishes it would die.

I like these posts because I consider it extremely important to know the shortcomings of your technology, whether it’s for the purpose of finding ways to mitigate them or to simple choose a different technology if the situation demands it.

Haters tend to go out of their ways to unearth the slimmest faults, but to their credit even the exaggerations have often a seed of truth. In fact, it’s a rare thing to find a criticism that has no merit whatsoever. Of course, it’s obvious when something is a cosmetic thing (OMG!!! PHP is so bad because you have a gazillion ways to approach a solution) vs something that has an impact (OMG!!! PHP is so bad because functions dealing with a certain type aren’t named consistently or OMG!!! PHP is so bad because it defines interfaces you can’t implement yourself).

To find the value of the criticism you do need to cut down on the OMG part and to find the gist as well as to asses the potential impact. If you do criticise stuff yourselves, please try to cut down on the OMG part at the source to make said criticism useful for people. If you can direct said criticism at those empowered to make changes, all the better but at the end of the day this is also useful for regular users/developers — to know what to pay attention to.

Another perspective here is that criticism often comes from a different world. Java devs will criticise PHP for missing on stuff that Java has or has built over time. While it’s a fairly useless criticism to say that X should be more like Y (the point of diverse choices is to find different tools with different approaches that are useful in different situations) it also shines a sort of reverse light: for someone who may entertain the though of jumping ship, it will provide insight into how one language is different from the other.

As a Go developer I can’t say how many times I’ve seen devs coming from other languages asking what framework to use. Of course, if they were paying attention, you could find Go devs sneering at languages like PHP due to the sheer dependence of developers on frameworks, which is due exactly to language shortcomings that those frameworks are making up for.

Those are valid points, but they provide insightful value only when moving from one world to the other. For a PHP developer is a fact of life that frameworks are needed, but it’s worth keeping in mind that this is not true in many other worlds.

Conclusion

Criticism is important. Know your shortcomings and know the limitations of your tech stack — embrace it, mitigate it and learn from it.