6 ms·

I think any one who has worked with a code base that has to interop between languages understands some of the pain here. There have been projects I've been a pa

I think any one who has worked with a code base that has to interop between languages understands some of the pain here. There have been projects I've been a part of that interop between C, C++, C#, and Python, with mandatory support for Matlab. This is a nightmare for maintainability. It typically ruins the advantages of every language with lifetime management. No more RAII in C++, everything is IDisposable in C#, Python and Matlab support require very specific version management. It also leads to situations where it is exceedingly difficult to find references to given functions, as methods get wrapped into different languages. Error handling mechanisms frequently cannot cross language boundaries, leading to situations where you have to do conversions. Often it also leads to non-idiomatic language code, as each language has a different idiom. It leads to silo-ing, because certain developers are better with some of the languages than others. It can lead to contention because someone wants to implement something in the language they prefer. Bindings are also annoying to maintain.

ammo1662 2y ago
Agreed, the biggest problem of such project is where is the boundary. Once you implemented some fundamental features in language A, others will be forced to use that language for succeeding jobs. Even if you have already implemented some functions in language B, due to the limitation of integration, error handling or some other more important reasons, you still need to choose language A. Maybe after a lot of discussion, a solution can be finally reached. However, the effort consumed, or like now, causing personnel turnover, will significantly increase the cost of project. IMO if there is no extremely important reason, do not mix multiple languages within one project. If must, define some boundaries at the initial stage. Any attempt to change these boundaries should require agreement from everyone involved.

ammo1662 2y ago

Agreed, the biggest problem of such project is where is the boundary. Once you implemented some fundamental features in language A, others will be forced to use that language for succeeding jobs. Even if you have already implemented some functions in language B, due to the limitation of integration, error handling or some other more important reasons, you still need to choose language A. Maybe after a lot of discussion, a solution can be finally reached. However, the effort consumed, or like now, causing personnel turnover, will significantly increase the cost of project. IMO if there is no extremely important reason, do not mix multiple languages within one project. If must, define some boundaries at the initial stage. Any attempt to change these boundaries should require agreement from everyone involved.