許多人一樣，如果不是全部，我也有喜歡的編程語言，我想在項目中使用，閱讀，倡導有關，睡眠用等。我會打電話給lang.y從lang.x移植庫/代碼lang.y理智？
要不要重新發明輪子，我主要在我的項目中使用他人的作品。但有時候，已經制作好的車輪是用其他語言（lang.x）編寫的，而不是我用的。
這種情況主要發生在我需要使用不是很常見的應用程序，這些應用程序大多是由大型組織或大學項目創建的。
如果實現我需要從該項目中使用的功能並不那麼複雜，我主要是從lang.y中的stracth寫出它。
如果沒有，我嘗試使用lang.x，直到我得到friggin瘋狂的所有廢話我不喜歡lang.x和搜索橋應用程序，將使它可以使用該應用程序/庫lang.y
我失敗過，我只是傾向於放棄。因此，對於這個問題，從lang.x移植到lang.y似乎是合理的，我（對OSI批准許可的應用程序/庫），但我也希望有別人的想法。
你會端口，或者你會去lang.x？
如果庫是成熟的，經過嚴格測試和封裝，我把它留在原來的語言。但是，當它在COM或.NET中時更容易，因爲它具有良好的互操作性和低開銷。
只有當存在重大的環境變化，過時的語言或圖書館需要大量的前瞻性開發工作時，我纔會移植，這意味着無論如何都需要完全重新測試。
這取決於...
顯然從Lisp語言C＃的一個端口將是一個重寫不是一個端口，但更類似於語言，我經常手口東西。
也許你應該評估你選擇的語言Y，如果你發現它的工具集如此缺乏？
如果您的首選語言不能很好地互操作，那麼在需要大量互操作的項目中使用它可能是錯誤的。
作爲一個例子，python是Eve Online服務器羣的絕佳選擇，但是這個項目幾乎全部是在Python中開發的，並沒有太多互操作性。對於那些不得不與其他許多不可更改的產品集成的企業應用來說，Python可能不是一個很好的選擇。就像語言一樣驚人，它不是萬事通，也不應該被誤用。
我得到所有的垃圾我 不喜歡lang.x
還有得是，沒有lang.x.的所有的失敗比互操作性展示更好lang.y的妥協受詛咒的瘋狂一些高級語言可以很好地處理本地代碼。想到C＃。
正如其他人所說 - 它依賴。
如果重新編碼是不平凡的，那麼當原始語言朗讀時，你將面臨兩難的境地。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＃（et al）項目可以有效地相互通信，所以它們的所有也是很好的。試圖從C＃使用C++版本將會非常糟糕。
但是，同時我看不到還有生產VB.NET版本的問題。它具有很小的優勢 - 使開發人員可以將生成的代碼保留在與其餘部分相同的項目中 - 但這可能不值得付出額外的努力。大多數情況下，VB.NET開發人員只需構建生成的C＃代碼並從其VB.NET項目引用即可。
不同的項目會有不同的考慮因素來衡量。遲早總是關乎價值（無論對項目意味着什麼）與努力。