How do different programming languages ​​integrate?

How many programming languages ​​are too many?

Different approaches increasingly make it possible to combine different programming languages ​​within a project. But not everything that is technically possible also makes sense. So the question arises: How many programming languages ​​are too many?

If you are interested in programming, you will naturally sooner or later deal with a programming language. Which that is is often more a matter of chance or the personal environment than that it would be a targeted choice. But no matter what language you start with - at the beginning very few developers think about the fact that sooner or later you will have to learn other languages.

Götz & Golo

"Götz & Golo" is a joint series by Götz Martinek and Golo Roden. One is the managing director of sodge IT GmbH, the other CTO of the native web GmbH. What unites the two is their great passion for software development. Since September 2019, they have been tackling a monthly topic on which everyone then describes their individual perspective without knowing each other's article in advance. The related article by Götz can be found on the sodge IT blog. The question asked for this article was: "Projects with many languages ​​are possible. But does that make sense?"

That is hardly surprising, after all, a single programming language initially offers such a large fund that one cannot even guess at the end of it. With experience, however, the realization grows that not all programming languages ​​are equally suitable for different tasks.

Of course, all common programming languages ​​are equally powerful in the theoretical sense, but hardly anyone will come up with the idea of ​​programming a web application in assembler - even if that would be entirely possible. But it's just not efficient. So you gradually learn that languages ​​have their respective thematic focuses and that you are well advised to choose a suitable language depending on your needs.

Technical integration and professional separation

First of all, different programming languages ​​seem like different worlds that have little or nothing in common with each other and are also incompatible with each other. Anyone who programs C ++ seldom combines it with Visual Basic. But even here you learn over time that different languages ​​can be technically integrated, be it at the linker level or on the basis of virtual machines that represent runtime environments for different languages, for example the Java Virtual Machine (JVM) or the Common Language Runtime (CLR).

There is also the option of integrating different languages ​​via network protocols. If you develop a service that can be addressed via HTTP, it does not matter whether the users of the service use the same or a different programming language. From this point of view, not allowing technology to become a system-relevant variable is one of the great advantages of a microservice-based architecture. If technicality is broken down into different services, technology decisions can be made for each service individually.

However, with extensive opportunities comes great responsibility. Not everything that is technically possible also makes sense. So after moving from a single language to a service-based technology zoo, the question arises: how much is too much? Does it make sense to develop each service in a different language? Or should one rather try to find a common denominator?

Programming languages ​​have focal points

In order to find a reasonable answer to this question, one must first bear in mind that the use of several languages ​​within a project is not as absurd as it initially seems: every client-side web application is ultimately based on HTML, CSS and JavaScript - simple this is because web browsers cannot do anything else.

The example also shows wonderfully that these three languages ​​have very different priorities: HTML is used for semantic structuring, CSS for visual representation and JavaScript for defining behavior. However, in this context you have no other choice: Web browsers understand neither C # nor Go, as much as you would like to use these languages. The environment determines the technology here.

But what about server applications that run as a backend and are only addressed via network interfaces? How do you deal with them? Are different languages ​​for different services desirable here or is it more important to avoid a mixture?

Technology is not an end in itself

The answer to this question is actually very simple - and very non-technical: Technology is not an end in itself, but always fulfills a (higher) purpose. Software is not written for its own sake, but to meet a technical requirement. For example, software is written to make the lives of people and / or animals easier, safer, more comfortable or more pleasant in some other way. It is therefore usually not at all important to those in charge whether technology A or B is used for the implementation.

What is important, however, is that the software developed adequately meets the technical requirements. This requires developers who have mastered their tools and know how to use them correctly. The first premise can be derived directly from this:

It is difficult and time-consuming to really know a technology well and to gain extensive experience with it. It is for a single person almost impossibleto be equally familiar with several technologies or programming languages.

That means, despite personal curiosity, you should first select the language and platform for a project that you are familiar with. In my personal case it was C # and .NET for a long time, now it's JavaScript, TypeScript and Node.js. Even if I personally find Lisp and Go quite exciting, I simply don't have the experience to use them productively in the same quality - and I don't have the time to acquire this experience if I don't want to neglect the existing technology stack at the same time.

If you are familiar with a programming language or a platform, you also know its strengths and weaknesses. So it makes perfect sense not to develop everything with a single language - the only question is whether you should deal with other languages ​​yourself in a productive environment or whether you shouldn't leave that to others for whom the chosen language is the daily task Represents bread.

Of course, it makes sense to think outside the box in order to broaden your horizons, but you don't have to (and cannot) learn everything to the same depth.

Software development is teamwork

As already mentioned in my plea for open and tolerant communication in the IT corporate culture, software development is not a matter of lone fighters, but teamwork. Good teams are characterized by the fact that, on the one hand, they have a certain common basis that connects the individual team members, but on the other hand there are enough differences that one can advance one another and learn from one another.

In a team, it is quite conceivable that different developers use different programming languages, because from a technical point of view it makes sense not to cover everything with a single language.

But you have to be careful not to lose the connecting element within a team: If each developer uses a different programming language afterwards, the team is no longer a team, but just a thrown together bunch of lone fighters. The same applies to the next higher level, i.e. across teams: It does not make sense for every team to completely redefine the technology stack. If you fail to do this, it ends in chaotic wild growth, which in the long term can no longer be maintained and cared for.

Find the right balance

If you summarize all of this, you can see that the right balance is important. The number of different programming languages, platforms and technologies used in parallel should be as low as possible, but as high as necessary. You shouldn't introduce a new programming language because a developer likes it better than the existing one. However, it should be introduced if it makes a significant contribution to solving a technical problem more efficiently.

You shouldn't introduce a new programming language just because it's hip. However, they should be introduced when it is foreseeable that the existing language will no longer be sustainable in the long term and one would like to gradually set the course for the future.

Language-interoperable platforms and microservices should not be the motivation to use different languages. It's perfectly fine for a landscape to be developed using a single language. Voice-interoperable platforms and microservices are, however, the necessary prerequisite for preventing technological decisions from becoming a system-relevant variable, from whose dependency one can never again break free. In this respect, these constructs can be assessed positively, one must not confuse potential and motivation.

Conclusion

In summary, it can be said that in principle there is nothing wrong with mixing different programming languages ​​if there are serious technical or technological reasons for doing so. However, one should be careful not to mix programming languages ​​only because it is technically feasible and because it gives way to personal preferences.

In this respect, the right balance is important, and it applies (as is so often the case) - as much as necessary, as little as possible.

tl; dr: It is getting easier and easier to combine and mix different programming languages ​​in projects. But there should be good technical or technological reasons for this. One should also be careful not to see technology as an end in itself and to overemphasize personal preferences.

Golo Roden

Golo Roden is the founder, CTO and managing director of the native web GmbH, a company specializing in native web technologies.

Read CV »