Don't commit to one programming language for life: choose the right one for your job

When we programmers start a project, one of the key decisions we need to make is to choose a language, or a set of languages, to use 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 program that is part of the project. Many times, we choose a language without thinking too much based on some very fickle factors: this language is what I usually use to implement this kind of Systematic; I know this language best; it is my favorite language and I enjoy programming in it; etc.

Since this decision will lead to profound and long-term consequences, shouldn’t we be more pragmatic when making this decision? Too often, we are blindly biased by the language we choose. And, sometimes the reasons why we don't like choosing that language may be the very reasons why we choose that language.

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

There is no perfect language

This is to be expected of anyone, even a newbie, and many of us are willing to admit, “Of course, this language is not a perfect language,” but At the same time, many of us 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 perfect language: every language has its advantages and disadvantages.

For example, many developers who typically use runtime languages ​​such as Java or Python claim that C or C++ is breathless because they focus on low-level details such as memory management, or care about compile-time types Strict granularity of inspections while stifling decentralized responsibilities on developers. This is true as long as the project we are developing does not focus on seemingly trivial tasks such as memory management or the number of copy-assignments that occur in a single loop.

Conversely, if we work on a project, or part of a project, it is natural to have biased needs for how efficient the code should be and how critical and safe the program is, these seemingly tedious details may be exactly the level of granularity we are looking for . In this new context, the runtime nature of Java or Python seems too uncaring or too absent-minded. Instead, we want to be able to strictly control how many move-assignments and copy-assignments are executed when memory is allocated and freed, and catch as many errors as possible at compile time, rather than letting errors leak into the runtime (shown as runtime abnormal).

While in theory "no language is perfect" sounds obvious, our behavior as developers often departs from this concept: we say we know our favorite languages ​​are imperfect, but we still Continue to use this language for the projects we develop, regardless of whether it is appropriate. Furthermore, when another developer questions our choice of language, we vigorously defend our choice rather than see the truth in his or her rebuttal. Remember: every language has its pros and cons. Understand the strengths and weaknesses of the languages ​​you master and then make your choice based on your situation.

The reason you don’t like a language may be the reason you should use it

It may seem counterintuitive, but sometimes, the reason we don’t like a language may be the reason why we use it. Still with the above example, in my experience as a C++ developer, many times it takes too long to complete a project because there are so many different concepts to keep track of (memory management and object lifetime, the three principles of C++ programming, etc.) A simple function can become cumbersome. After a few weeks of developing in C++, using Python, Java or another "higher" language can feel like a godsend: but is it really so?

Sometimes, maybe the reason we don’t like a language is the reason why we use it. If I were developing a driver or some safety-critical, real-time system, the reasons stated above for being cumbersome might just be the greatest advantage of this language. For example, C++ provides a mechanism for expressing logic that is executed when an object is copied, which is invaluable when efficiency and rigor are in order.

This may all look good and great, so it’s hard to pinpoint a context in which a language you don’t like might be more helpful. So, how do we know which languages ​​you don’t like are helpful? This brings us to our second principle:

Be honest with yourself: know why you don’t like a language, and don’t dogmatize your dislikes.

For example, in the C++ example above, the reason why I don’t like to program in C++ for a long time is because this language requires rigorous thinking, otherwise it is easy to make mistakes, just like being trapped in the jungle ( Focusing too much on the trees rather than the forest as a whole). This rigor prevents developers from questioning things like, "Am I creating objects on the stack or on the heap, or partially on the stack and partially on the heap?" or "To make this class extensible, it should be through templates." Parameters or inheritance?" and so on. In other languages, developers can accomplish these tasks by simply creating an object each and using object-oriented inheritance, and then move on to the next feature because the language (or, more accurately, the compiler or interpreter) takes care of these tasks. detail.

But if I'm honest with myself, I will admit that the reason I don't like these features of C++ is because it puts the onus on me to express these details. In other languages, not only am I not responsible for these details, but I also don't have the responsibility to express them: they are abstracted away from the developer. In a context where these details are essential, the reasons I don't like C++ are exactly the reasons I should use this language.

Does this mean we should frown and use features that make us irritated by the language? It's not necessary either. Maybe you can look at it another way: instead of seeing these features as drawbacks, maybe we should embrace them as necessities to get the job done. Instead of saying, “What a tragedy,” we should say, “Thank God I can do this in this language.” Remember: in some contexts, these capabilities will be a gift, and In other cases, they are a liability. 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

For this, here is the third principle we want to talk about:

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

This rule does not apply to software engineering, but it sharply characterizes many software development situations. Many times, we choose a language, or a language-supported tool (such as Java's JMS, Python's ASYNCIO, Rails' Ruby, 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 do I do this in Java?" This limits the tools available to us and artificially limits our ability to choose the right tool for the job.

The solution to this problem is to expand your horizons and understand 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. It's 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 this one language for ongoing projects, making learning another language useless. For example, if I'm an Android developer and basically only use Java every day, learning C# might seem like an untimely waste of time.

Don’t be fooled by illusions. The advantage of learning another language is that we can see a problem from a different perspective and use the tools that are best suited to the problem. In order to do this, we have to learn the caveats associated with other languages ​​and the way developers use those languages ​​to solve problems. For example, if a developer wants to perform metaprogramming in C++, then he or she can use Template Metaprogramming (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 deeming it 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++ may be tempted to concoct a solution that stretches the boundaries of this compile-time language. And another C++ developer, who also has some knowledge of Java, is able to say, "I like C++, but Java's runtime reflection is better suited to solve this problem."

Because there are so many programming Developers have the choice of language, so it is important to prioritize which languages ​​to learn. You might as well start with the most popular languages ​​today (please refer to "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 it can also be said to be the most important:

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

Unless you are the author of a language standard or the author of a compiler, you should treat programming languages ​​as a means rather than an end. The purpose is to complete the project: the ultimate goal is to complete the project, not Use specific language. This doesn’t mean that every developer doesn’t have the right to demand what he or she likes or dislikes about the language (in fact, if we’re honest with ourselves, these likes and dislikes can work in our favor; see the second principle above) , but we shouldn't fool ourselves into making decisions like, "This is a great opportunity for me to use this feature of the language," unless the features of the language truly fit the needs of the project.

It’s 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 things we need to consider when choosing a language:

Consider how the language interacts with other languages. For example, if you decide that Python is the best language for most projects, but there is a well-defined component in your project that requires an extremely high level of granularity or efficiency (which would be better suited to C or C++), that doesn't mean You cannot use Python on this project. Instead, consider using Python, writing a specific component in C or C++, and then using the Python C API to interface to this component. Note that to formulate such a solution we need to know that Python has a C API; therefore, it is helpful to know these features of the most popular languages.

Middleware can allow the use of multiple languages. For example, if you have two applications that must communicate, such as a mobile device and a server application, this does not mean that they must use the same language (of course they can be the same if you decide that is the best decision ). If the mobile device is an Android phone, and the server application is perfectly suited as a Python application, then using a message broker such as RabbitMQ allows you to communicate using both languages ​​at the same time: the Android application can use Java RabbitMQ API, while server applications can use Python RabbitMQ API.

Embrace the quirks of other languages. If you are a Java developer, then you will use packages to separate logical units of source code; if you are a Python developer, then you will use Python's package structure to do the same thing; if you are a C++ developer personnel, then you would use a namespace or prefix the class name (i.e. "DZone_MyClassName"). Understand the special features of the language you're speaking and embrace them: in Rome, do as the Romans do. Otherwise it would be like speaking German with an Italian accent because you prefer the Italian pronunciation of words, which would sound nondescript. Of course, it is also possible that a feature of a language has existed for a long time, but in this case, there must be a reason: make sure you understand the reason.

Original English text: Do Not Marry a Language: Selecting the Correct Language for the Job