Is porting a library/code from lang.x to lang.y sane?

Like many, if not all, i too have a favorite programming language that i like to use in projects, read about, advocate about, sleep with etc.. which i'll call lang.y

To not to re-invent the wheel, i mostly use others' works in my projects whe(n|re)ever i can. But sometimes, the already made wheels are written in other languages(lang.x) than i'm using.

this mostly happens when i need to use not so common applications that are mostly created by big organizations or academical projects.

if implementing the functionality i need to use from that projects is not so complicated, i mostly write it from stracth in lang.y .

if not, i try to use lang.x until i get friggin mad about all the crap i dislike about lang.x and search for bridge applications that will make it possible to use that application/library with lang.y

i that fails too, i just tend to give up. So, for this question, porting from lang.x to lang.y seems reasonable for me (for osi approved licensed apps/libs), but i'd also like to have others' ideas.

would you port, or would you go with lang.x?

From stackoverflow

• If the library is mature, well-tested and encapsulated, I leave it in the original language. But that is easier when it is in COM or .NET, since there is good interoperability and low overhead.

  I would port only when there's significant environment change, obsolete language, or the library is going to need significant forward-looking development work which effectively mean that it will need to be fully re-tested anyway.

• It depends...

  Obviously a port from Lisp to C# is going to be a rewrite not a port, but I frequently hand port things from more similar languages.

  Perhaps you should evaluate your choice of language Y if you find its toolset so lacking?

• if your preferred language doesn't interop well, then it's probably a mistake to use it in projects that require a lot of interop.

  as an example, python is a fantastic choice for the Eve Online server farm, but that project was developed almost all in python, not much interop. Python might not be such a great choice for enterprise applications that have to integrate with lots of other unchangeable products. As amazing as the language is, it's not a jack-of-all-trades, and shouldn't be misapplied.

  i get friggin mad about all the crap i dislike about lang.x

  there's got to be a compromise that interops better than lang.y without all the failures of lang.x. some high level languages can do pretty well with native code. C# comes to mind.

• As others have said - it depends.

  If the recoding is non-trivial, then you are faced with a dilemma when the original lang.x library changes -- do you re-port the updated version, and how can you do so?

  In general, it is better to write a library wrapper in lang.y that calls down to the lang.x library. That way, you get to use the good features of lang.y in the code that 'really' uses the library, and you only have to worry about the mess in the interface code. The chances are that a stable library won't change its interfaces all that often (not every release), so you'll be able to upgrade the lang.x library without having to recode the wrapper code. And when you do need to enhance the wrapper code, it will generally be a simple exercise to add the new functions, or modify the one or two interfaces that change.

  The alternative is to become a maintainer of the library in lang.y. You would have to undertake the editing of your lag.y implementation in parallel with the lang.x implementation. You might do this informally (that is, you and your employer might be the only beneficiaries -- watch the licencing terms on the library!), or formally by becoming a member of the library's development team. You could then influence the design of the library so that it is easier for your lang.y implementation to stay synchronized with the lang.x implementation.

  Summary: leave the library in its original language as long as possible. Be cautious about doing the conversion unless you are willing to do the necessary maintenance.

• As others have said, it entirely depends on the situation.

  Just as an example, I'm currently porting Google's Protocol Buffers framework to C#. I'm trying to keep an API which is like the Java version, but also make it familiar to .NET programmers. At the same time a friend (Marc Gravell) is doing a more "from scratch" project with a more WCF-like feel. It's good to have both projects, as they cater for slightly different needs. It's also good to have them at all as it means that Java, C++, Python, C# (et al) projects can communicate with each other efficiently. Trying to use the C++ version from C# would have been horrible.

  At the same time, however, I can't see that there's very much point in also producing a VB.NET version. It would have minor advantages - enabling developers to keep the generated code within the same project as the rest of it - but that's probably not worth the extra effort. For the most part VB.NET developers will be fine just building the generated C# code and referencing it from their VB.NET projects.

  Different projects will have different considerations to weigh up. Sooner or later it's always about value (whatever that means for the project) vs effort.