像许多人一样，如果不是全部的话，我也有我喜欢在项目中使用的最喜欢的编程语言，阅读，倡导，睡觉等等。我称之为 lang.y
为了不重新发明轮子，我尽可能在我的项目中使用其他人的作品（n|re）。但有时，已经制作的轮子是用其他语言（lang.x）编写的，而不是我使用的。
这主要发生在我需要使用主要由大型组织或学术项目创建的不太常见的应用程序时。
如果实现我需要从该项目中使用的功能不是那么复杂，我主要从 lang.y 中的 strath 编写它。
如果没有，我会尝试使用 lang.x，直到我对我不喜欢关于 lang.x 的所有废话感到愤怒，并搜索可以将应用程序/库与 lang.y 一起使用的桥应用程序
我也失败了，我只是倾向于放弃。所以，对于这个问题，从 lang.x 移植到 lang.y 对我来说似乎是合理的（对于 osi 批准的许可应用程序/库），但我也想有其他人的想法。
你会移植，还是使用 lang.x？
正如其他人所说 - 这取决于。
如果重新编码很重要，那么当原始 lang.x 库发生更改时，您将面临两难境地——您是否重新移植更新的版本，以及如何做到这一点？
一般来说，最好在 lang.y 中编写一个调用 lang.x 库的库包装器。这样，您就可以在“真正”使用该库的代码中使用 lang.y 的良好特性，而您只需担心接口代码中的混乱。稳定的库可能不会经常更改其接口（不是每个版本），因此您可以升级 lang.x 库而无需重新编码包装器代码。当您确实需要增强包装代码时，添加新功能或修改更改的一两个接口通常是一个简单的练习。
另一种方法是成为 lang.y 中库的维护者。您必须与 lang.x 实现并行编辑您的 lag.y 实现。您可以非正式地这样做（也就是说，您和您的雇主可能是唯一的受益人——请注意图书馆的许可条款！），或者正式成为图书馆开发团队的成员。然后，您可以影响库的设计，以便您的 lang.y 实现更容易与 lang.x 实现保持同步。
摘要：尽可能长时间地保留图书馆的原始语言。除非您愿意进行必要的维护，否则请谨慎进行转换。
正如其他人所说，这完全取决于情况。
举个例子，我目前正在将 Google 的Protocol Buffers框架移植到 C#。我试图保留一个类似于 Java 版本的 API，但也要让 .NET 程序员熟悉它。同时，一位朋友 (Marc Gravell) 正在做一个更像 WCF 的更“从头开始”的项目。拥有这两个项目很好，因为它们满足略有不同的需求。拥有它们也很好，因为这意味着 Java、C++、Python、C#（等）项目可以有效地相互通信。尝试使用 C# 中的 C++ 版本会很糟糕。
但是，与此同时，我看不出制作 VB.NET 版本有什么意义。它会有一些小优势——使开发人员能够将生成的代码与其他项目保持在同一个项目中——但这可能不值得付出额外的努力。大多数情况下，VB.NET 开发人员只需构建生成的 C# 代码并从他们的 VB.NET 项目中引用它就可以了。
不同的项目会有不同的考虑因素来权衡。迟早它总是关于价值（无论这对项目意味着什么）与努力。
如果库是成熟的、经过良好测试和封装的，我会将其保留为原始语言。但是当它在 COM 或 .NET 中时更容易，因为它们具有良好的互操作性和低开销。
只有当环境发生重大变化、语言过时，或者库需要进行重大的前瞻性开发工作时，我才会移植，这实际上意味着无论如何都需要对其进行全面重新测试。
这取决于...
显然，从 Lisp 到 C# 的移植将是重写而不是移植，但我经常从更相似的语言移植东西。
如果您发现它的工具集如此缺乏，也许您应该评估您选择的语言 Y？
如果您的首选语言不能很好地互操作，那么在需要大量互操作的项目中使用它可能是一个错误。
例如，python 是 Eve Online 服务器场的绝佳选择，但该项目几乎都是用 python 开发的，没有太多的互操作性。对于必须与许多其他不可更改的产品集成的企业应用程序，Python 可能不是一个很好的选择。尽管这门语言很神奇，但它不是万能的，也不应该被误用。
我对所有我不喜欢的关于 lang.x 的废话感到非常生气
在没有 lang.x 的所有失败的情况下，必须有一个比 lang.y 更好的互操作性的折衷方案。一些高级语言可以很好地处理本机代码。想到了 C#。