「こんにちは、ここであなたのプロジェクトは[プログラミング言語X]で書かれていることに気付きました。 関数Zの点で優れているため、Yですべてを書き換える必要があります。さようならありがとうございます！
このフォームに記載されているように、提案はまったく難しいとは思えません。 Z関数の方が優れているため、もちろん誰でもすぐにYでプロジェクトを書き換える必要があります。
最近、Gnomeスタックのさまざまなソフトウェアプロジェクトで使用されるツールを、シェル、Awk、Perlの混合からPython 3に変換する傾向があります。このような変換を支持する主な議論は、中毒、アプリケーションは、WindowsなどのプラットフォームでGnomeテクノロジーを使用してコンパイルしやすくなります。 プロジェクトからプロジェクトへの移行も容易になります。
このような変換を行うツールの1つはGTK-docで 、これは主にPerlで書かれたドキュメント生成ツールです。 クリエイターチームとPython 3への変換に取り組みました。 それは多くの点で有益な経験でした。 まず、原則として、2つの言語間の変換は3つのフェーズに分割されることが判明しました。
- 手動構文変換。
- 変換エラーに起因するバグの修正。
- コードを慣用的なターゲット言語に変換します。
GTK-docを使用してPerlをPythonに変換するのは比較的簡単です。 作業は、主に正規表現、配列、辞書を使用して実行されます。 これらの3つのタイプのエンティティはすべて、両方の言語でほぼ同じように動作するため、ほとんどの場合、最初のフェーズは純粋に機械的な作業になります。 2つ目は、前の段階で行われたすべてのエラーと動作の変更を修正することです（多くの場合、最初のステップでのタイプミスや不注意が原因です）。 これは基本的にデバッグ段階です。 3番目のステップは、正規表現とグローバル変数をオブジェクトやその他の通常の読み取り可能な構造に変換することです。
変換するとき、私は主に最初のステップに取り組み、GTK-docプロジェクトを率いる開発者は2番目と3番目のステップを完了することに同意しました。 gtkdoc-mkdbファイルの6000行以上を変換するプロセスで、いくつかの測定を行ったところ、1時間あたり500行の最大速度で変換できることがわかりました。つまり、コードの行ごとに約7秒かかります。 このような結果は、コードの変換が簡単で、すべての作業がEmacsの印刷速度のトレーニングに減った場合にのみ達成されました。 時々、Perlのより複雑な機能に出くわし、これらの断片では、作業のペースが10、100、さらには1000倍遅くなりました。 また、アーキテクチャの変更に必要なポートがある場合（たとえば、より柔軟な言語からコンパイラがオブジェクトの有効期間をチェックする言語に変換する場合など）、さらに時間がかかります。
2番目と3番目のステップがどれほど骨の折れる作業であったかはわかりませんが、チャットに表示されたコメントのいくつかを思い出せば、それはかなりだと思います。 最も楽観的な推定によると、これら3種類の要素の作業速度は、1時間あたり平均250行のコード速度でした。
そして今最も悲しいこと。 このような速度で絶えず変換することは不可能です。 ある形式から別の形式にコードを手動で変換することは、想像できる最も退屈な仕事であり、破壊し、道徳的に殺します。 私は1日数時間以上それをすることができませんでした-ある時点で、私の目はドル記号、セミコロン、および様々な括弧から目で波打ち始めました。 これに基づいて、開発者が単独で作業することで安定して維持できる変換速度は1時間あたり約100行であると推定できます（プロジェクトの作業が数週間続く場合でもこれが現実的であるとは思いませんが、測定はありませんので、省略します）この考慮事項）。
Ohlohによると、cURLプロジェクトは約100,000行のコードで構成されています。 任意の2つの言語間の変換が単純なPerlとPython間の変換よりも複雑ではないと仮定すると（そして、これはありそうにない）、プロセス全体に1000人時間かかります。 つまり、8時間の就業日で5か月間のフルタイムの仕事です。 そして、完了したら、変換中に行われたすべての変更を転送する必要があります。 ある言語から別の言語に翻訳している間にプロジェクトを停止することはオプションではありません。
このすべてから、「なぜ人々はコードを別の言語に翻訳しないのですか？」という質問に対する明確でシンプルな答えが生まれます。
「Xに書き換えるだけ」は不可能です。
PS言語から言語に自動的に変換するツールがあります。 彼らは助けることができますが、最初の段階でのみです。 手動で変換されたコードは人々にとって理解しやすいため、2番目と3番目の段階は良心に残り、時間がかかる場合があります。 完全性のチューリング理論は、すべてが非常に悪いことを示唆しています。