Don’t stick with one programming language for life

[[222139]]

One of the key decisions we programmers need to make when embarking on a project is to choose a language, or a set of languages, to implement the system. This decision affects not only the implementation of the system, but also the design. For example, should we use an object-oriented language or a procedural language? The choice of language has a profound impact on the project and the life cycle of the programs that are part of the project. Many times, we choose a language without much thought based on some very fickle factors: this is the language I am used to implementing this type of system; this is the language I know best; this is my favorite language and I enjoy programming in it; and so on.

Since this decision will lead to profound and long-term consequences, shouldn't we be more pragmatic when making this choice? Many times, we are blindly biased about the language we choose. Moreover, sometimes the reason why we don't like to choose this language may be the reason why we choose that language.

If we can open our minds and be honest about our biases, we can alleviate some of the pain of trying to fit a square peg into a round hole. While there is no secret recipe for choosing the best language for a project, there are some principles that can help us make a better and more appropriate language choice.

No *** language

This is something that should come as no surprise to anyone, even a novice, and many of us are willing to admit, "Of course, this language isn't the best language," but at the same time, many of us will still say, "This language is the best programming language." The key to saying a language is the best language for a project is the context of the project, that is, the best language only exists within a certain scope. This is our first principle:

There is no best language: every language has its advantages and disadvantages.

For example, many developers who typically use runtime languages ​​like Java or Python claim that C or C++ are suffocating and stifle the responsibilities placed on developers by focusing on low-level details like memory management or caring about the strict granularity of compile-time type checking. This is true, as long as the project we are developing is not concerned with seemingly trivial tasks like memory management or the number of copy-assignments that occur in a single loop.

If, instead, we work on a project, or part of a project, it is natural to have a biased need for how efficient the code should be and how critically safe the program should be, and these seemingly cumbersome details may be exactly the level of granularity we are looking for. In this new context, the runtime nature of Java or Python may seem too indifferent or too absent-minded. Instead, we want to be able to strictly control how many move-assignments and copy-assignments are performed when memory is allocated and deallocated, and to catch as many errors as possible at compile time, rather than letting them seep into the runtime (manifesting as runtime exceptions).

While it sounds obvious in theory that there is no best language, our behavior as developers often betrays this concept: we say we know our favorite language is not the best, but we continue to use it for our projects regardless of whether it is a good fit. Furthermore, when another developer questions our choice of language, we fiercely defend our choice, unwilling to see the truth in his or her rebuttal. Remember: every language has its pros and cons. Understand the pros and cons of the languages ​​you know, and then make a choice based on the situation.

The reasons you don't like a language may be the reasons you should use it

It may seem counterintuitive, but sometimes the very reason we dislike a language may be the reason we use it. Using the example above, in my experience as a C++ developer, there were many times when completing a simple feature of a project became tedious because there were so many different concepts to keep track of (memory management and object lifespans, the three laws of C++ programming, etc.). After a few weeks of developing in C++, using Python, Java, or another "higher level" language can seem like a gift from heaven: but is it really?

Sometimes, the very reason we dislike a language is the very reason we want to use it. If I were developing a driver or some safety-critical, real-time system, the very reason I was tedious to express above might be the language's greatest strength. For example, C++ provides a mechanism for expressing logic that is executed when an object is copied, which is invaluable when efficiency and rigor go hand in hand.

This may all seem good and wonderful, so it is difficult for us to point out that in a certain context, a language that you don't like may be more helpful. So how do we know which language you don't like is helpful? This leads to our second principle:

Be honest with yourself: know why you don't like a language and don't dogmatize your hatred.

For example, in the C++ example above, the reason I don't like programming in C++ for a long time is that the language requires rigorous thinking, otherwise it is easy to make mistakes, like being stuck in the jungle (focusing too much on the trees, not the forest as a whole). This rigor prevents the developer from questioning decisions such as, "Do I create the object on the stack or the heap, or partly on the stack and partly on the heap?" or "Do I make this class extensible, through template parameters or through inheritance?" In other languages, the developer can accomplish these tasks by simply creating an object and using object-oriented inheritance, respectively, and then move on to the next feature because the language (or, more accurately, the compiler or interpreter) takes care of these details.

But if I'm honest with myself, I'll admit that the reason I dislike these features of C++ is that it places the responsibility of expressing these details on me. In other languages, not only am I not responsible for these details, but I have no responsibility to express them: they are abstracted away from the developer. In a context where these details are essential, the reasons I dislike C++ are exactly the reasons I should use the language.

Does this mean that we should grimly use features that annoy us about the language? Not necessarily. Perhaps you can look at it another way: instead of seeing these features as shortcomings, maybe we should embrace them as necessary to get the job done. Instead of saying, "This is such a tragedy," we should say, "Thank god I can do this in this language." Remember: in some contexts, these features will be a blessing, and in other contexts, they will be a nuisance. Be honest with yourself about why you don't like a feature of a language.

The more familiar you are with other languages, the better

This is where our third principle comes in:

If the only tool you have is a hammer, then every problem looks like a nail.

This rule doesn't apply to software engineering, but it acutely reflects many situations in software development. Many times, we choose a language, or the tools that a language supports (such as JMS for Java, AsyncIO for Python, Ruby on Rails, etc.), because we know they exist. If the only language we are familiar with is Java, then we will adapt all the problems we encounter to the context of Java. For example, "I need to create a routing framework for a communications application. How can I do this in Java?" This limits the tools available to us and artificially restricts our leeway in choosing the right tool for the job.

The solution to this problem is to expand your horizons and learn about the capabilities and intricacies of other languages. As Andrew Hunt and David Thomas suggest in The Pragmatic Programmer, a good practice is to learn a new language every year. This is not as easy as it sounds, and learning a language will mean different things to different people. Another derivative problem is that we often only use one language for the projects we are working on, making learning another language useless. For example, if I am an Android developer who basically only uses Java every day, then learning C# may seem an inappropriate waste of time.

Don't be fooled by illusions. The advantage of learning other languages ​​is that we can look at problems from different perspectives and use the tools that are best suited to the problem. In order to do this, we must learn the caveats of other languages ​​and the ways developers use those languages ​​to solve problems. For example, if a developer wants to perform metaprogramming in C++, he or she can use Template Metaprogrammming (TMP) in C++, but he or she can also use reflection in Java. Understanding how other languages ​​solve similar problems reduces the risk of us assuming it is useless.

As another example, if we need to be able to change the runtime characteristics of a class, a C++ developer who is deeply familiar with the intricacies of C++ might try to concoct a solution that stretches the boundaries of the compile-time language. Another C++ developer, with some familiarity with Java, might be able to say, "I like C++, but Java's runtime reflection is a better fit for this problem."

Because there are so many programming languages ​​for developers to choose from, it is important to prioritize which languages ​​to learn. It is a good idea to start with the most popular languages ​​today (see "most popular languages ​​on Github", "Language Trends on Github", "The 9 most popular computer languages", "according to the Facebook for programmers", etc.).

Language is a means, not an end

This is the fourth and final principle, which may sound the most philosophical, but can also be said to be the most important:

Programming languages ​​are a means, not an end.

Unless you are a language standards writer or a compiler writer, you should think of programming languages ​​as a means, not an end, to getting the project done: the end goal is to get the project done, not to use a particular language. This doesn't mean that every developer doesn't have a right to a language he or she likes or doesn't like (in fact, if we're honest with ourselves, these likes and dislikes can benefit us; see the second principle above), but we shouldn't fool ourselves into making decisions like, "This is a good opportunity for me to use this feature of the language," unless the language feature truly fits the needs of the project.

It is important to remember that language is just a way of expressing how to solve the problem at hand: make sure you choose the language that best expresses the problem domain you are solving.

Other things to consider

Here are some additional considerations when choosing a language:

1. Consider how the language interacts with other languages. For example, if you decide that Python is the best language for completing most of your project, but there is a well-defined component in your project that requires an extremely high level of granularity or efficiency (better suited to C or C++), this does not mean that you cannot use Python on this project. Instead, consider using Python, writing that specific component in C or C++, and then using the Python C API to interface this component. Note that to develop a solution like this, we need to know that Python has a C API; therefore, it is helpful to understand these features of the best language.
2. Middleware can allow multiple languages ​​to be used. For example, if you have two applications that must communicate, such as a mobile device and a server application, it does not mean that they must use the same language (of course, they can be the same, if you judge that this is the best decision). If the mobile device is an Android phone, and the server application is a good fit for a Python application, then using a message broker, such as RabbitMQ, allows you to use both languages ​​at the same time: the Android application can use the Java RabbitMQ API, and the server application can use the Python RabbitMQ API.
3. Embrace the quirks of other languages. If you're a Java developer, you use packages to separate logical units of source code; if you're a Python developer, you use Python's package structure to do the same thing; if you're a C++ developer, you use namespaces or prefixed class names (i.e. "DZone_MyClassName"). Understand the quirks of the language you're using and embrace them: in Rome, do as the Romans do. Otherwise it's like speaking German with an Italian accent because you prefer the Italian pronunciation of the word. Of course it's possible that a feature of a language persists for a long time, but if so, there must be a reason for it: make sure you understand the reason.