一部のライブラリを多くのプログラミング言語に書き換えるのはなぜですか？

たとえば、Java（100％pure Javaなど）で記述されたLuceneなど、さまざまなプログラミング言語で記述されたバージョンで使用可能なライブラリがありますが、C ++、C、Perlのバージョンもあります、Ruby、Lispおよびその他の言語。そして、私はFFIインターフェースだけでなく、これらの言語での実装について話している。

なぜ人々はそうするのですか？明白な理由の1つを見ることができます。プロジェクトの依存関係が少ないほど、展開と配布（そしておそらく開発も）が容易になります。しかし、他に何かありますか？どのような状況で価値がありますか？

私がやったいくつかの理由（私の場合はHaskellでCコードを書き直してください）：

• 簡単な展開：1つのビルドチェーンのみ
• 依存関係の減少（より多くの採用を得るため）
• コードが高水準言語である場合、より移植性が高い（Windowsなど）
• 低レベルCでは簡単に行えない並列処理のサポートを追加する
• リソースを使用してコードを少し安全にする
• コードを信頼しやすくするため
• より慣用的（強力な型、より単純なAPI、より多くの再利用）

通常、ライブラリを特定のプラットフォームに「ネイティブ」に再実装すると、次のことが可能になります。

• より簡単な展開と配布
• 簡単なデバッグ
• 正確なプラットフォームに適した、より慣用的なAPI
• 多くの場合、パフォーマンスが向上します（プラットフォームの相互運用が面倒になる場合があります）
• 互換性のためにまだ元のデザインの問題を修正

例えば、私はJoda Timeの移植としてNoda Timeプロジェクトを始めました。.NET内から直接Joda Timeを使用するのは実用的ではありません...日付と時刻の計算を行うためだけにJVMをスピンアップする必要はなく、相互運用の方法を考え出す必要もありません。二つ。自動化されたポート（J＃など）は実現可能かもしれませんが、最終的な結果はC＃から使用する快適で慣用的なAPIではなかったでしょう。

一部の人々は、新しい言語を学ぶのを助けるためにそれをします。以前の言語で慣れ親しんでいたライブラリを選択し、新しい言語でそれが必要であることを確認し、移植を開始します。

馴染みのあるものを移植することは、新しい言語の言語部分のみに焦点を合わせるための最良の方法であり、実際に問題の領域を心配することはありません。

また、本やチュートリアルで見られるような多くのサンプルプロジェクトのように、一度コードを捨てることなく、コミュニティが実際に使用、追加、リファクタリング、議論などを行えるという利点もあります。

ソフトウェアが作成されたツール（Luceneの場合はJava）がオプションではないプラットフォーム用に開発している場合があります。コードを一から作り直さずに機能が必要な場合は、コードを移植します。