July 13, 2021

How do you murder a programming language?

Ahmet Çelikezer
Development
5 minutes read

“If the language you care about has released a stable and new version and capabilities of that language fit your requirements, that language is not dead”

Where are the killers? 🕵🏻♂️

Programming languages are not a biological beings as you know, they are
created by humans to be used by humans, so if we’re talking about a passing
away of the language, it should be a murder 🪓 because it is not a natural process.

So there are killers out there, who are they? are the creators of language? or
contributors of the language? or other developers who are using language?

Definition of dying 🪦

As I mentioned above, programming languages are not a biological thing so they will continue their existence as long as computers can process them (with up-to-date technologies). All the other reasons can not be related to the death of the language, because you can still work with it and your hardware can still execute the commands that you tell it via a programming language.

“So, if the language that we are talking about is still developing and getting new releases (just like PHP), it is a well alive language.”

The literally “dying” language is the one that is not updated for a long time, not able to run or hard to run on brand-new hardware or OS.

When all this is considered and the language is not dead it may have become a less preferred language.

An illustration of an elephant with “php” written on it, standing in the middle of a graveyard.
Designed by upklyak / Freepik

The Killers 🥷🏼

# Act 1 — Bigot Developers

These guys are fanatics and addicts of the language. They literally force the language to use it for everything.

In real life, each language is designed to solve problems by focusing on its own use cases. That means each language is the best ⁉️ language for special use cases, and each of the languages is just a waste of time ⁉️ for some use cases.

When you force the problem with the language that is not designed for your use case, you will start to code most probably in a bad way, out of its standards, hardly understandable by other developers, and maybe even you will screw things up to apply the patterns that are better for you to use.

# Act 2 — Programming Language Prone to Misuse

I believe the language that makes it easy to release some products is the language hardest to learn. Because that language is probably prone to misuse, think PHP again, there are almost limitless ways to do what you want to do.

It’s better to think through when you set up your own standards and your own structure to make it easy to understand for other developers and at some point even you. The weak type of a system will surely increase runtime errors.

So is it the language’s fault? Can you blame the car, the road or your local government because they don’t put signs for you like “Don’t Walk Here, Cars only!” when you are hit by a car while walking in the middle of the highway? Ok, I am not saying that “Signs are useless, we don’t need them”, but you should not write code just to complete your task. It will be hard to maintain it, painful for everyone. Long story short, garbage.

Of course, type-safe languages are safer to work with, they offer more opportunities to improve yourself. That’s why easy to run languages require more expertise, you don’t mess up your code-base even if you can easily do.

# Act 3 — Resentful Developers

If the quantity of these killer developers is too much and their code-bases spread enough into the language community it will negatively impact other developers.

Because day by day you are facing bad code-bases. Open-source contribution is going to be painful for your brain or maybe most of the third-party packages that are trending in the community are not well-written and you feel insecure to use it but you don’t have a better option to use.

These reasons are the tip of the iceberg, and they will make other developers feel resentful about that specific language.

We can go on and on about all of these reasons, but as you can understand, all of these reasons are not related to the language itself. A language is a tool that you use to solve problems. You can mess up with the best ⁉️ language or you can make majestic things with the poorest ⁉️ language.

Don’t care about the person telling you “This is the best tool, you have to learn and use it!” or “It is a dead tool, do not use it!”, These kinds of words are not objective and do not reflect reality.

Learn any language that you enjoy using and learn it very well, the actual experience you will receive would be the best practices, standards, patterns, concepts…

These concepts are not specific to a language and they can be easily transferred from one language to another. Use the right tool and don’t make any tool you use your Swiss knife, try new tools that give you new perspectives.

Most of the popular languages will exist longer than our lifetimes. Be relaxed and focus on the real problems. Cheers 🍻

After Credits

After all, we learn that we are the ones who change technology on both sides. Imagine yourself as a developer, what makes you feel comfortable? Let me write our ASMR; think the up-to-date codebase, well tested, high coverage, without the deprecated or unpopular third-party dependencies, no legacy codes, coded by someone who cares about principles like SOLID and you can easily guess what code pieces do because previously developers before you, tried so hard to follow the standards.

To be honest, a codebase that, like we imagined above, is not a utopia, but the key point is sustainability, you have to keep the codebase maintainable.

A rolling stone gathers no moss.

In Atolye15 we are trying to do this more and more day by day. Especially for me, I believe the biggest reason is most of the time we don’t rush it. That means time planning is an important matter, I don’t mean short estimates for your to-do’s but instead, consistent estimates.

The other key point is the “code reviews” because if your code has a badly written code or is hard to understand by other developers or there is a more effective way to do what you want to do you can receive feedback or suggestions about it. Shared wisdom will always improve you and give you a different perspective.

If you are not lucky enough yet to work with the un-killer developers, you can check out the pull requests that popular repositories have. The discussions in pull requests can lighten up your bulb💡

Don’t ignore the littlest problem or bad practices, to be honest; they will always cause bigger problems as the codebase grows and new developers join your team. As long as you ignore the little problems you will encourage others and can’t guarantee what features will be requested in the future and how that future will touch your little innocent problems.

Keep your mental health fresh for new technologies, tools, practices, and languages. Do not forget to have fun with your co-workers, we better understand the importance of that since the pandemic. Willingness to learn and research doubles according to your mood. Do not work in an environment / on projects that drain your motivation and bring you down if you don’t have to.

As you can understand, nothing that I mentioned above is directly related to the language that you used. As long as you keep trying new things that may be a better solution for your specific problem within the known and proven practices, you will always be fine.

This was my first blog post, I hope I could express my opinions clearly 🤓

See you in my next blog post! 👋

Ahmet Çelikezer
Development

You may also like