プロジェクトのソリューションを動的言語でコーディングしてはならないことを示す要因は何ですか?
10 に答える
3
プログラマーの言語への習熟度と意欲。
あなたの動的言語はおそらく私の静的言語です。
于 2008-09-26T22:00:09.090 に答える
3
システム レベルの開発は、通常は動的言語で行うべきではないソフトウェアの重要なグループです。(ドライバー、カーネルレベルのものなど)。
基本的に、あらゆるパフォーマンスや低レベルのハードウェア アクセスを必要とするものはすべて、低レベル言語にする必要があります。
別の指標は、科学データの数値計算のように数値計算が高度であるかどうかです。つまり、高速に実行して数値計算を行う必要がある場合です。
共通のテーマはプロセッサー集中型の問題だと思います...この場合、パフォーマンスの違いが簡単にわかり、動的言語ではハードウェアを効果的に使用する力が得られないことがわかります。
とはいえ、プロセッサを集中的に使用する作業を行っていて、パフォーマンスへの影響が気にならない場合でも、動的言語を使用できる可能性があります。
アップデート：
数値計算とは、プロセスが数時間または数日間実行される科学分野での非常に長時間実行される数値計算を意味することに注意してください...この場合、2倍のパフォーマンスの向上は非常に大きなものです...それがはるかに小さい規模の場合、動的言語は引き続き使用できます。
于 2008-09-26T22:00:16.907 に答える
2
大部分において、プログラミング言語はスタイルの選択です。使いたい言語を使えば、最大限の生産性と幸福感を得ることができます。なんらかの理由でそれが不可能な場合は、他の誰かの恣意的なスタイルの選択ではなく、実行しなければならないプラットフォームや実際の経験的なパフォーマンス数値など、意味のあるものに基づいて最終的な決定を下すことを願っています.
于 2008-09-27T00:28:44.380 に答える
1
ビデオ カード デバイス ドライバー
于 2008-09-26T23:00:41.423 に答える
0
組み込みシステムのシステムレベルのコード。考えられる問題は、動的言語が1つの見やすいステートメントのパフォーマンスへの影響を隠すことがあることです。
このPerlステートメントを言うように：
@contents = <FILE>;
FILEが数メガバイトの場合、それはリソースを消費するステートメントの1つです。ヒープを使い果たしたり、ウォッチドッグタイムアウトが発生したり、一般に組み込みシステムの応答が遅くなったりする可能性があります。
「金属に近いプログラム」が必要な場合は、静的に型付けされた「中間レベル」の言語を使用することをお勧めします。
于 2008-09-26T22:49:22.763 に答える
0
通常、速度が主な答えです。これは最近ではあまり問題になりませんが。
于 2008-09-26T21:57:15.367 に答える
0
スピードが重要なとき。動的言語は高速化されていますが、コンパイルされた言語のパフォーマンスにはまだ及ばない.
于 2008-09-26T21:57:52.917 に答える
0
相互運用は、動的言語で完全に可能です。(「遅延バインディング」を備えた従来の Visual Basic を覚えていますか?) ただし、呼び出し元が名前で呼び出せるようにするために、COM コンポーネントをいくつかの追加機能でコンパイルする必要があります。
数値計算を静的にコンパイルする必要はないと思います。ほとんどの場合、それはどのように解決するかの問題です。Matlab は数値計算用に作成された良い例であり、コンパイルされていない言語を使用しています。ただし、Matlab には、数値と行列の非常に特殊なランタイムがあります。
于 2008-09-26T22:06:07.827 に答える
0
可能であれば、常に静的に型付けされた言語を選択する必要があると思います。C# や Java に優れた静的システムがあると言っているわけではありませんが、C# は近づいています。動的言語に見られる利点を提供しながら、静的に型付けされたもののセキュリティと機能を提供するため、適切な型推論が重要です。問題は解決しました - もうフレームワークはありません。
于 2008-09-26T22:06:40.353 に答える
-1
相互運用はどうですか？Ruby または Python から COM コンポーネントを呼び出すことはできますか?
于 2008-09-26T22:01:04.487 に答える