私はマルチプラットフォームプログラミングに関する論文に取り組んでおり、長所/短所に関するセクションを含めたいと思います。私の理解から; アプリケーションをマルチプラットフォームにすることは、開発者にとって大きなセールスポイントです。これは、ほとんどすべてのコンピューターユーザーを潜在的な購入者として利用できるようにするためです。私は考えられる不利な点を理解しようとしています。もしあれば？
1260 次
8 に答える
2
プラットフォームに依存しない言語(タイトルで質問)に不利な点はありますか?
言語の実装者として、何かを複数のプラットフォームで実行するのは、はるかに手間がかかると言わざるを得ません。余分な作業のほとんどは、ランタイム システムにあります。プラットフォームに依存しないものを作成するのはさらに困難です。ANSI C のような非常に広く使用されている標準に固執する必要があります。
必ずしも多くのコードを記述する必要はないことを付け加えておきます。あなたはもっと一生懸命考えなければなりません。 Luaは、巨大な大規模な実装を持たない、プラットフォームに依存しない言語の良い例です。 GHCはその逆です。多くのプラットフォームで優れたパフォーマンスを得るために大量のコードが必要ですが、ランタイム システムだけでも、バージョン 6 Unix の 4 倍のサイズになります。
于 2010-02-14T16:33:26.833 に答える
2
「なんでも屋の達人」はいかがですか？
1 つのプラットフォームで設計および実装された言語を使用すると、そのプラットフォームに合わせて設計を調整できます。また、リソースは通常限られているため、実装とデバッグは多くのプラットフォームではなく 1 つのプラットフォームに集中します。
これは、Perl などのリソースが豊富にあるコミュニティの取り組みには当てはまりません。
于 2010-02-14T16:34:15.800 に答える
2
一般に、マルチプラットフォーム環境では、言語とマシン (インタープリターや JVM など) の間に追加レベルの抽象化が必要になります。この追加レベルは、特定のマシンにその環境でコードを実行する方法を伝え、特定の一連の命令を処理するためにコンピューターが実行する必要があるコードをさらにもたらします。このため、マルチプラットフォーム アプリケーションは一般的に遅くなります。
この背後にあるロジックは、環境ごとに同じアプリケーションを何度もコーディングする代わりに、コーダーがプログラムするための一種のインターフェイスを作成することです。各プラットフォームには、このインターフェースの独自の実装が必要ですが、統一された方法でコードを実行することを目的としています。
また、このレイヤーは複数のプラットフォームで普遍的な動作を提供することを目的としていますが、プラットフォームごとの命名規則とファイル ストレージの違いを考慮する必要がある場合もあります。
Web ブラウザーは、この最も一般的な例です。優れたブラウザーを使用している場合、Web 標準コード (HTML/CSS/JS など) を解釈し、コード ライターがこれらの違いに対応する必要がなく、特定のプラットフォームで表示する方法を処理します。
于 2010-02-14T16:37:46.447 に答える
1
主な欠点 - プラットフォーム固有の拡張機能を使用できない...
これはより哲学的な問題です。言語能力とコンパイラ能力の境界はどこにあるのでしょうか...
directxコードを書くことができます..しかし、同じ結果がLinuxで発生するために...
于 2010-02-14T16:36:11.787 に答える
0
Common Lispは、このケーススタディのようなものです。:-)
いくつかの点で、彼らはそれをかなり正しく理解しました。理論的な観点からは奇妙に見えるが、最新の非特殊プロセッサがそれを迅速に実装できるようにするものがいくつかあります。たとえば、エラー状態を通知する代わりにガベージを返すことが許可されている無意味な算術式がいくつかあります。これは、その方がはるかに効率的である可能性があるためです。
他の方法では、彼らはプラットフォームに依存しないように努めましたが、それはほとんどまたはまったく利益をもたらさずに複雑さを追加しただけです。典型的な例の1つは、パス名サブシステムです。関数のシグネチャは次のようになりmake-pathnameます。
make-pathname &key host device directory name type version defaults case
標準化された1980年代に、非常に豊富なファイルシステムのネイティブサポートを含めることは合理的であるように思われたかもしれませんが、VAX（またはバージョン管理されたファイルシステムを備えた他のシステム）は10年以上見ていません。今日、ほとんどの人が気にしないのは複雑さです。（パス名と論理パス名は技術的に別個の機能であることは知っていますが、それらが実行しようとしていることはそれほど遠くありません。）
プログラマーとして、将来どの領域に柔軟性が必要になるか、あるいはどの軸に柔軟性が必要になるかを推測することはできません。プログラマーはこれをよく知っているため、「アジャイル」のような安っぽい言葉が一般的になっています。プラットフォームに依存しない言語を設計するときは、両方の世界の最悪の事態に対処します。言語は抽象化のためのものであり、プラットフォームは非常に具体的です。案の定、すべてのプラットフォームに依存しない言語は、C以降、かなりの量の吸血鬼でいっぱいです。
于 2010-02-14T17:33:38.187 に答える
0
主な欠点は次のとおりです。
- プラットフォームの違いによる開発の余分な時間 (たとえば、ファイルシステムへのアクセスはプラットフォームによって異なります)
- より多くのテストが必要になるため、サポートされている複数のプラットフォームでテストするには、より多くの費用がかかります。
于 2010-02-14T16:35:16.343 に答える
0
多くの場合、言語の機能が低下したり、より大規模で複雑なランタイムが必要になるために速度が低下したりします。ほとんどの言語はそれをうまくやってのけることができますが、プラットフォーム間での実装の恩恵を受けていない可能性が高い言語がいくつかあります.
于 2010-02-14T16:37:12.157 に答える
0
サンに聞いてください。Java の全体像は、会社にとってどのように機能しましたか? （ええ、私は知っています、1つとすべてのサンプル）
この場合、私はベンダーの立場からそれを見ています。彼らが作った言語は人気がありましたが、彼らが販売した OS の (実際の!) パワーを活用するには何もしませんでした。Windows 上で実行する必要がありましたが、そのようなことには意味がありませんでした。子プロセスをフォークして、親と子の間に 1 つまたは 2 つのパイプを開きたいですか? 残念な。スレッドのバグを楽しんでください。犬のように遅いファイル I/O を楽しんでください。(Java が最終的に "nio"実装を組み込んだのはいつですか?)
もちろん、Microsoft は .NET でそのような間違いを犯していません。また、複数のランタイムの実装にリソースを費やすのではなく、より優れた言語機能に重点を置いていました。
于 2010-02-14T18:24:22.650 に答える