Porting library / code from lang.x to lang.y sane?
Like many, if not all, I also have a favorite programming language that I like to use in projects, read, protect, sleep, etc., which I will call lang.y
In order not to reinvent the wheel, I mostly use other work in my whe (n | re) projects sometime. But sometimes already made wheels are written in other languages (lang.x) than I am using.
this happens mainly when I need to use less common applications that are mostly created by large organizations or academic projects.
if it is not that hard to implement the functionality I need to use from these projects, I basically write it from stracth in lang.y.
If not, I am trying to use lang.x until I get mad about everything I don't like about lang.x and looking for bridge apps that will allow this app / library to be used with lang.y
i which fails too, I'm just inclined to give up. So for this question, porting from lang.x to lang.y seems to make sense to me (for approved licensed osi apps / libraries), but I'd like to have others' ideas as well.
would you port, or would you go with lang.x?
source to share
As others have said, it depends.
If the recoding is non-trivial, then you are in a dilemma when the original lang.x library changes - are you redirecting an updated version and how can you do it?
In general, it is best to write a wrapper in lang.y that refers to the lang.x library. This way, you can use the good lang.y functions in code that "really" uses the library, and you only need to worry about messing up the interface code. Chances are, the stable library won't change its interfaces as often (not every release), so you can update the lang.x library without having to recode your shell code. And when you need to improve your wrapper code, it's usually just an exercise to add new functionality or change one or two interfaces that change.
An alternative is to become the library curator in lang.y. You will have to edit your lag.y implementation in parallel with your lang.x implementation. You can do this informally (that is, you and your employer may be the only beneficiaries - see the license terms in the library!) Or formally by becoming a member of the library development team. You can then influence the design of the library to make your lang.y implementation easier to sync with your lang.x implementation.
Summary : keep the library in your original language for as long as possible. Be careful about converting if you are not prepared to perform the required maintenance.
source to share
If the library is mature, well tested, and well encapsulated, I leave it in the original language. But it is easier when it is in COM or .NET because there is good compatibility and low overhead.
I will only migrate when there is a significant change in the environment, an outdated language or library requires significant forward-looking development, which effectively means it will need to be fully tested anyway.
source to share
if your preferred language does not communicate well, then it is probably a mistake to use it in projects that require a lot of interaction.
as an example, python is a fantastic choice for an Eve Online server farm, but this project has been developed in almost all python languages, not diversity. Python may not be such a great choice for enterprise applications that need to integrate with many other immutable products. As surprising as the language is, it is not a full-fledged trader and should not be misused.
I'm fooled by all the shit I don't like lang.x
there must be a tradeoff that hooks better than lang.y without all the lang.x crashes. some high level languages can do well with native code. C # comes to mind.
source to share
As others have said, it totally depends on the situation.
As an example, I'm porting Google Protocol Buffers to C #. I'm trying to keep an API that is similar to the Java version but also familiar with .NET programmers. At the same time a friend (Mark Gravell) is doing a more "from scratch" project with more WCF-like. It is good to have both projects as they serve slightly different needs. It's also good to have them at all, as that means Java, C ++, Python, C # (and others) projects can communicate effectively with each other. Trying to use the C ++ version from C # would be terrible.
At the same time, however, I do not see that it is very important to specify the VB.NET version. This would have minor advantages - allowing developers to keep the generated code in the same project as the rest of it, but it probably isn't worth the extra effort. For the most part, VB.NET developers will be fine building the generated C # code and linking to it from their VB.NET projects.
Different projects will have different weighing considerations. Sooner or later, it always matters (whatever that means to the project) and effort.
source to share