0

すべてではないにしても、多くの人と同じように、私もプロジェクトで使用したり、読んだり、擁護したり、一緒に寝たりするのが好きなお気に入りのプログラミング言語を持っています..これを lang.y と呼びます

車輪の再発明を避けるために、私は自分のプロジェクトでできる限り他人の作品を使用しています。しかし、すでに作成されたホイールが、私が使用している言語 (lang.x) 以外の言語で記述されている場合があります。

これは、主に大規模な組織や学術プロジェクトによって作成された、あまり一般的ではないアプリケーションを使用する必要がある場合に発生します。

そのプロジェクトから使用する必要がある機能の実装がそれほど複雑でない場合、私は主に lang.y の stracth からそれを記述します。

そうでない場合は、lang.x について嫌いなすべてのがらくたにひどく腹が立つまで lang.x を使用しようとし、そのアプリケーション/ライブラリを lang.y で使用できるようにするブリッジアプリケーションを検索します

それも失敗し、あきらめがちです。したがって、この質問については、lang.x から lang.y への移植は (osi が承認したライセンス済みのアプリ/ライブラリの場合) 私にとっては合理的なように思えますが、他の人のアイデアも知りたいです。

移植しますか、それとも lang.x を使用しますか?

4

5 に答える 5

2

他の人が言ったように - それは依存します。

再コーディングが重要である場合、元の lang.x ライブラリが変更されたときにジレンマに直面します。更新されたバージョンをレポートしますか? また、どのようにそれを行うことができますか?

一般に、lang.x ライブラリを呼び出すライブラリ ラッパーを lang.y に記述することをお勧めします。そうすれば、ライブラリを「実際に」使用するコードで lang.y の優れた機能を使用できるようになり、インターフェイス コードの混乱を心配するだけで済みます。安定したライブラリのインターフェイスはそれほど頻繁には変更されない可能性があります (すべてのリリースではありません)。そのため、ラッパー コードを再コーディングすることなく lang.x ライブラリをアップグレードできます。また、ラッパー コードを強化する必要がある場合は、通常、新しい関数を追加するか、変更された 1 つまたは 2 つのインターフェイスを変更するだけで済みます。

別の方法は、lang.y でライブラリのメンテナーになることです。lang.x 実装と並行して、lag.y 実装の編集を行う必要があります。これは非公式に (つまり、あなたとあなたの雇用主だけが受益者である可能性があります。ライブラリのライセンス条件に注意してください!)、またはライブラリの開発チームのメンバーになることで正式に行うことができます。次に、ライブラリの設計に影響を与えて、lang.y 実装が lang.x 実装との同期を維持しやすくすることができます。

まとめ: ライブラリを可能な限り元の言語のままにしておきます。必要なメンテナンスを行うつもりがない場合は、変換を行う際には注意してください。

于 2008-11-15T16:16:35.577 に答える
1

好みの言語が相互運用性に優れていない場合、多くの相互運用性を必要とするプロジェクトでその言語を使用するのはおそらく間違いです。

例として、python は Eve Online サーバー ファームにとって素晴らしい選択ですが、そのプロジェクトはほとんどすべて python で開発されており、相互運用性はあまりありません。Python は、他の多くの変更不可能な製品と統合する必要があるエンタープライズ アプリケーションにはあまり適していない可能性があります。この言語は驚くべきものですが、何でも屋というわけではなく、誤用すべきではありません。

私はlang.xについて嫌いなすべてのがらくたにひどく腹を立てる

lang.x のすべての障害なしで、lang.y よりも相互運用性が高い妥協点が必要です。一部の高水準言語は、ネイティブ コードでうまく処理できます。C#が思い浮かびます。

于 2008-11-15T13:46:33.120 に答える
1

他の方もおっしゃっていますが、状況次第です。

例として、私は現在 Google のProtocol Buffersフレームワークを C# に移植しています。私は、Java バージョンのような API を維持しようとしていますが、.NET プログラマーにもなじみのあるものにします。同時に、友人 (Marc Gravell) は、WCF に似た感じの「ゼロから」のプロジェクトを行っています。わずかに異なるニーズに対応するため、両方のプロジェクトを用意することをお勧めします。また、Java、C++、Python、C# (その他) のプロジェクトが相互に効率的に通信できることを意味するので、それらを持っていることも良いことです。C# から C++ バージョンを使おうとするのは恐ろしいことでした。

しかし同時に、VB.NET バージョンも作成することにあまり意味があるとは思えません。開発者が生成されたコードを残りのプロジェクトと同じプロジェクト内に保持できるという小さな利点がありますが、おそらく余分な労力を費やす価値はありません。ほとんどの場合、VB.NET 開発者は、生成された C# コードをビルドし、VB.NET プロジェクトから参照するだけで問題ありません。

プロジェクトが異なれば、検討すべき考慮事項も異なります。遅かれ早かれ、それは常に価値（それがプロジェクトにとって何を意味するにせよ）対労力です。

于 2008-11-15T17:16:11.587 に答える
1

ライブラリが成熟し、十分にテストされ、カプセル化されている場合は、元の言語のままにします。ただし、COM または .NET の場合は、相互運用性が高く、オーバーヘッドが少ないため、より簡単です。

重要な環境の変更、廃止された言語、またはライブラリが重要な将来を見据えた開発作業を必要とする場合にのみ移植します。これは、とにかく完全に再テストする必要があることを意味します。

于 2008-11-15T13:33:40.163 に答える
1

場合によります...

明らかに、Lisp から C# への移植は、移植ではなく書き直しになりますが、私はより類似した言語からの移植を頻繁に行います。

ツールセットが不足している場合は、言語 Y の選択を評価する必要がありますか?

于 2008-11-15T13:34:00.897 に答える