Don't spend your life with a programming language: Choosing the right choice for your job

One of the key decisions that 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 will not only affect the implementation of the system, but also affect the design. For example, should we use object-oriented or procedural languages? Choosing what language has a profound effect on the life cycle of the project and the program that is part of the project, many times, we choose the language based on some very fickle factors, without thinking too much: this language is something I have used to achieve this kind of system, which I know most thoroughly; this is my favorite language. I enjoy programming in this language, and so on.

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

If we can open our minds and honestly treat our own prejudices, we can alleviate some of the pain of nailing a square nail into a circular hole when decorating. While there is no secret to choosing the perfect language for a project, there are some principles that can be followed to help us make a better, more appropriate language choice.

No perfect language.

This is not surprising to anyone, even novices, and many of us are willing to admit, "of course, this language is not the perfect language," but at the same time, many of us would say, "This language is the best programming language." The key to saying that a language is the best language for a project is the context of the project, meaning that the best language exists only within a certain range. This is our first rule:

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 not breath-taking, because they focus on low-level details such as memory management, or on the strict granularity of compile-time type checking, while strangling the responsibilities of a developer. This is true as long as we are developing projects that do not focus on seemingly trivial tasks, such as memory management or the number of copy-assignment that occur in a single loop.

Conversely, if we work on a project, or part of a project, then it is natural that the biased requirements of how the code should be efficient and the critical security of the program, these seemingly tedious details may be the level of granularity we are looking for. In this new context, the runtime nature of Java or Python seems to be too indifferent or too absent-minded. Instead, we want to be able to tightly control how many move-assignment and copy-assignment are executed when memory is allocated and released, and catch as many errors as possible at compile time, rather than letting the error seep into the runtime (as a run-time exception).

While it sounds obvious that "there is no perfect language" in theory, our behavior as a developer often deviates from this concept: we say we know that our favorite language is imperfect, but we continue to use the language for the projects we develop, whether or not it fits. Moreover, when other developers question the language of our choice, we are determined to defend our choice rather than to see the truth from his or her rebuttal. Keep in mind that each language has its advantages and disadvantages. Understand the strengths and weaknesses of the language you are mastering, and then make a choice based on the actual situation.

The reason you don't like a language is probably why you should use it.

It seems counterintuitive, but sometimes the reason we don't like a language may be the one that uses it. Or the above example, in my experience as a C + + developer, many times because there are so many different concepts to track (memory management and object life time, C + + programming Three principles, etc.), so that a simple function of the completion of the project will become cumbersome. After a few weeks of development with C + +, using Python,java or another "more advanced" language is just like a godsend: but is that really the case?

Sometimes, the reason why we don't like a language is precisely why we want to use that language. If I am developing a driver or some critical security, real-time system, the tedious reasons described above may be the greatest advantage of this language. For example, C + + provides a mechanism for expressing the logic that is executed when an object is copied, which is invaluable when the efficiency and rigor are orderly.

It may look good, so it's hard to point out that in a certain context, a language that you don't like is likely to be more helpful. So, how do we know which languages you don't like are helpful? This leads us to the second principle:

Be honest with yourself: know why you don't like a language, and don't be dogmatic about your hatred.

For example, in the above C + + example, I don't like to program for a long time with C + + because the language requires rigorous thinking, or it's easy to make mistakes, like being trapped in the jungle (too much attention to trees, not the whole forest). This rigor prevents developers from questioning, such as, "Do I create objects on the stack or on the heap, or part of the stack, and the other part on the heap?" "or" to make this class extensible, should it pass through template parameters or through inheritance? "Such decisions. In other languages, developers simply create an object individually and use object-oriented inheritance to accomplish these tasks, and then go to the next feature, because the language (or, more precisely, the compiler or interpreter) is concerned with these details.

But if I was honest with myself, I would admit that I didn't like the C + + features because it blamed me for the responsibility to express these details. In other languages, not only do I need to be responsible for these details, but I also have no responsibility to express these details: they are abstracted away from developers. In a context where these details are essential, I don't like C + + because that's why I should use this language.

Does this mean that we should be moping about using these features that will make us angry about this language? There is no need. Maybe you can change the angle: Don't use these features as a disadvantage, maybe we should hug them and use them as a necessity to accomplish the task. We should not say "This is a tragedy," and should say, "Thank goodness I can do this in this language." "Keep in mind that in some contexts these features will be the gift of heaven, and in other cases they are a nuisance." As to why you do not like the function of a language, please tell yourself honestly.

The more familiar the other languages, the better

For this, we are going to say a third principle:

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

This rule does not apply to software engineering, but it is a sharp manifestation of many software development scenarios. Many times, we choose a language, or a language-supported tool (such as Java's Jms,python 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." What should I do in Java? "This limits the tools available to us and artificially restricts the choice of the right tools for the work to be done."

The way to solve this problem is to broaden your horizons and understand the functions 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, learning a language will mean different things to different people. Another derivative problem is that we tend to use this language only for projects that are in progress, making the other language of learning useless. For example, if I were an Android developer and basically only use Java every day, then learning C # might seem like a waste of time.

Don't be fooled by the illusion. The advantage of learning other languages is that we can look at problems from different angles and use the tools that best suit the problem. To do this, we have to learn about warnings in other languages and how developers use these languages to solve problems. For example, if a developer wants to perform meta programming with 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 can reduce the risk that we think it is useless.

Another example, if we need to be able to change the runtime characteristics of a class, then a C + + developer who is deeply familiar with the intricacies of C + + may try to invent a solution that extends the bounds of this compile-time language. Another C + + developer, because of the knowledge of Java, can say, "I like C + +, but Java's runtime reflection is more appropriate to solve this problem." ”

Because there are so many programming languages for developers to clearly lunchbox, it is important to prioritize what languages to learn. Start with the most popular languages today (see "Most popular languages on GitHub", "Language Trends on GitHub", "the 9 most popular computer languages", "a Ccording to the "Facebook for Programmers", etc.).

Language is a means, not an end.

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

Programming language is a means, not an end.

Unless you are a language standard author or a compiler author, you should think of programming language as a means, not an end, to accomplish a project: The ultimate goal is to complete the project rather than use a specific language. This does not mean that every developer has no right to ask for a language he or she likes or dislikes (in fact, if we are honest with ourselves, these will benefit us; see the second rule above), but we should not deceive ourselves into making such a decision, such as, " This is a good opportunity for me to use this feature of the language "unless the language features really fit the needs of the project.

It's important to remember that language is just one way to express how to solve the problem at hand: Make sure you choose the language that best expresses the problem domain.

Other places to consider

Here are some additional things 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 completing most projects, but there is a well-defined component in your project that requires a very high level of granularity or efficiency (more appropriate for C or C + +), this does not mean that you cannot use Python on this project. Instead, consider using Python, a specific component written in C or C + +, and then use the Python C API interface for this component. Note that to develop such a solution, we need to know that Python has a C API, so it is helpful to understand these features in the most popular languages.

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

A strange place to embrace other languages. If you're a Java developer, you'll use packages to separate the source code's logical units, and if you're a Python developer, you'll use Python's package structure to do the same thing, and if you're a C + + developer, you'll use the namespace or prefix's class name (that is, " Dzone_myclassname "). Learn the special of the language you are using and hug them: in Rome, as in the Romans. Otherwise, it's like because you prefer to pronounce the words in Italian, and speak German in an Italian accent. It is also possible that a function of a language exists for a long time, but in this case there must be a reason: Make sure you understand the truth.

English Original: Do not Marry a language:selecting the Correct Language for the Job

