The choice of a high-level language would be made because it is ultimately more economical in terms of overall effort (writing, maintenance, tests, etc.) compared to the disadvantages (speed, size of the program).

This is generally true.

I would like to add a point of view that complements rather than contradicts what has been said by other programmers. We could summarize in three points:

  • Generally, on a project we don't have a choice of language
  • The choice is not always made in favor of the higher-level language
  • The developer does not — rightly — generally have much say except at the margins because he only has one element of the equation.

1. The choice of language is constrained and limited.

Generally, there is no real choice for the development language, and it is only at the margins. There are typical architectures to follow with preferred languages.

Typically, if I have to write a batch process to load a database or an LDAP directory, if the general architecture involves a Linux server for processing and a PostgreSQL database (in principle under Linux) for the data, there are there is a strong chance that the project context will force me to use:

  • A shell script to encapsulate the processing call
  • A program written in a language widely used within the project
  • Java if the rest of the project uses this language (UI on Tomcat or JBoss server for example)
  • Python if Python is the choice for batch programs in the project
  • In PERL if this is the culture/choice for batch programs within the project
  • A PHP program if the rest of the project uses this language (and the project context does not favor Python, Perl, or Java.
  • A program in Groovy if the project uses Java and if this does not contradict the architectural choices of the project (Groovy is 100% Java compatible while greatly simplifying its use, but this has a "cost")

2. We don't always choose the highest level-language

You might ask what led to the choices of typical architectures to follow with preferred languages. We could say the experience on previous projects and the good (and bad) practices that have been identified.

Let's take two examples of the bash shell and groovy.

The preferred choice for writing scripts under Unix is increasingly to use scripting languages (Python, Perl, Groovy, Ruby, etc.) rather than the shell (bash or other).

However, to trigger batch processing, we systematically ask that the call to the processing be made through a shell script and not a Python script, Perl script, JavaScript, or any other higher-level language (even if it means that the shell calls a Python script or an executable written in a high-level language).

This is a legitimate requirement; the processing call interface must be technically homogeneous for maintainability and usability.

One reason is, for example, that it avoids installing the interpreter (Python, Perl, etc.) on the server if the processing launched via the shell does not need it, which simplifies the server's operation and reduces the attack surface.

3. Groovy's case is similar with differences in motivations.

I love Groovy for writing processing when the project's flagship language is Java. Groovy is 100% Java compatible while greatly simplifying its use, but the choice of Groovy has consequences on the installation and operation of the solution overall. It is, therefore, out of the question to use Groovy without a decision at the project level by measuring advantages and disadvantages.

However, Groovy is a higher-level language than Java with all the advantages in terms of ease that this brings. Personally, on projects where the use of Groovy is not justified, I reserve the use of Groovy for the creation of disposable scripts that can be used in the development or development phase but are not part of the deliverables of the solution.

4. The developer doesn't have much say in the language

You might think that it's abnormal that it's not the developer who chooses. After all, he's the one who knows computer languages ​​best, but that's not the case.

The choice of language is primarily imposed by project considerations and the business context for which the software is developed.

There is inertia and a good conservatism in the choice of technologies, which avoids—but not always—the appearance of a technological tower of babel, making IT solutions unusable in practice.

In a company with significant IT assets, it is ten times more economical to develop new development in the development sectors already used than to multiply the languages used depending on the development teams. It is already quite complex to manage version upgrades of languages, software libraries, and application servers without adding the need for skills in dozens of common languages.

This is why COBOL is still alive and why Java/J2E is not about to be dethroned by Goland, Python, or even DOTNET, despite the fact that—in my humble opinion—DOTNET has superior development qualities and is supported by Microsoft.

The developer cannot choose between Python, PHP, or Java. The context of the company and the type of project generally decide, and we select the developers according to the project's needs.

For example, for a certain company, for internal projects with a limited lifespan and a low number of users, the choice of PHP + MySQL is both authorized and recommended, but for an API project exposed on the internet in B2B, the enterprise choice is Java/JAX-RS for architectural and security reasons.

There are still cases where the developer has the choice of language, but this choice is in the list of options authorized within the project framework.

For example, there is a choice between bash script and python script for reasonably simple processing.

In all cases, the choice of language is an overall project responsibility, constrained by the repositories of business solutions, informed by the opinion of software architects, and considering usability requirements.

In Plain English 🚀

Thank you for being a part of the In Plain English community! Before you go: