On programming language agnosticity

2025-02-02

Trying out a new category of writing. Blog-like, opinionated thinkpieces. Short-medium length, I don't know how much text I can squeeze out of myself while just musing on an idea. Not sure if this is worth sharing, but I don't think anyone reads this, so... ( to the left of these parens lied a publish tag )

I used to opearate with an idea that there was always a 'best' programming language. A spec that had something in it that made it superior to other specifications. A way of writing code that was in some way objectively better than all of the other ways to write code. To be specific, I kept making projects with a strong preference towards using C. I actively wanted to deepen my knowledge of it, I would seek out jobs that had me writing it, so on and so forth.

I clung to this mindest, and I still see a lot of developers continuing to stick to their guts when it comes to it, but, over the years, I kept learning about different programming languages and how they functioned and I eventually came to a conclusion of my own.

There is no objectively best programming language. I don't think that there even is an objectively best paradigm. Good programming does not stem from language design. Good programming stems from thoughtful, elegant design and high quality of communication within the code itself.

I can write garbage in Rust, Uxn or forth as much as I can write eloquence manifest in Java, C++ or PHP.

I don't really think that there is such a thing as a truly, genuinely bad programming language. If it's Turing complete, a capable programmer can abstract away any and all rough edges and write in such a way as to make the result performant, elegant, consistent and readable.

And so, the real choice lies in everything surrounding the language itself, those being:

• Quality of documentation, this really influences how well one can implement new ideas and use new libraries.

• Quality of community, how friendly it's users and advocates are, and if there are any red flags to make using the language itself not worth it.

• Quality of libraries, I can give a good example with two languages:

  • C tends to have a fair bunch of critically useful and reliable libraries, but they are almost always very low-level and oriented towards system development. In other words, you are almost coaxed into projects that are in the spirit of C, that being of a low level, systems-oriented language.
  • But, interestingly, take something like Rust. On a conceptual level, as a language, Rust attempts to target the same field, and as such, is outfitted with a similar standard library. (File I/O, threading, notably no HTTP library).

  Taken by themselves, these two programming languages achieve the same exact goals, however, their library ecosystems are vastly different. One can find convenient web frameworks for rust, one can find modern database frontends for rust, discord client API bindings, web service libraries, all of these neat and tidy, high-level frameworks, all actively maintained, all actively used.

  It is normal and maybe even common to write a webapp or a component of one in Rust. It is an unusual undertaking to write one in C. That's what I meant when I wrote 'Quality of libraries'.

• And most importantly, the applicability of a specific language for your project. As funny as using using scratch to write a linux kernel module is, the adage of 'right tool for the right job' still applies.

The fact of the matter is, no programmer should be bound by their language, for that leaves them bound to the limits of the solution space of their language of choice. If you're capable of solving the problems needed for making a webapp, you sure as shit are capable of kernel development, with enough time and patience. Widen your horizons.