言語がどれほど複雑であるかではなく、構文とセマンティクスの観点からプログラミング言語の複雑さの客観的な尺度はありますか？
私は多くの主観的なコメントを読みましたが、厳密な分析はほとんどありません。
4343 次
11 に答える
6
プログラミング言語に適用した場合、複雑さが明確に定義された用語でさえあることは私にはわかりません。
「客観的」とは「定量的」を意味する場合、次のような質問をすることができます。
曖昧さのない文法はどれくらいの大きさですか？
動作するyacc文法の大きさはどれくらいですか？
正式なセマンティクスを持つ言語はほとんどないため、定量的な調査を行うことは困難です。しかし、あなたは尋ねることができます
- 同じメタ言語（インタープリターが書かれている言語）を使用する他の言語のインタープリターと比較して、その言語の最も単純なインタープリターはどれくらいの大きさですか？この尺度は、コルモゴロフの複雑さにいくらか関連しています。
好奇心の問題を除いて、この質問が尋ねる価値があるかどうかは私にはわかりません。有用な答えを想像するのは難しいです。
于 2009-07-22T21:34:13.030 に答える
4
表示的意味論は、言語からの式の意味を記述する数学的対象（表示と呼ばれる）を構築することにより、プログラミング言語の意味を形式化するためのアプローチです。
プログラミング言語の操作的意味論は、有効なプログラムが一連の計算ステップとしてどのように解釈されるかを記述します。これらのシーケンスは、プログラムの意味です。関数型プログラムのコンテキストでは、終了シーケンスの最後のステップでプログラムの値が返されます。（一般に、プログラムは非決定論的である可能性があるため、単一のプログラムには多くの戻り値が存在する可能性があります。また、決定論的プログラムの場合でも、セマンティクスがその値に到達する操作のシーケンスを正確に指定しない可能性があるため、多くの計算シーケンスが存在する可能性があります。）
于 2009-07-22T22:08:33.053 に答える
3
私が見た言語の最良の尺度は、ランダムな文字列が有効なプログラムになる確率です。Perlはこのスケールで上位にランク付けされている言語であり、Adaはかなり下位にランク付けされています。
このメトリックが意味することは、まったく別の問題です。
于 2009-07-22T21:31:07.840 に答える
3
原則として、構文またはセマンティクスまたは実装がより動的で抽象化されているほど、言語はより複雑になります（あなたが述べたように使用しないでください）。
したがって、JavaはCよりも複雑な言語です。理由は次のとおりです。
- Cには単純なスコープルールとJavaの比較的複雑なルールがあります
- タイプはより複雑で、メソッドの解決とオーバーロード
- 継承、引数の列挙とチェック、メソッドのオーバーロードなどは、コンパイルプロセスをはるかに複雑にします。
Pythonは、オブジェクトモデルは複雑ですが、より単純な形式に縮小するという点で単純であるため、これに基づいてJavaよりも単純であると主張します。時間と計算の観点から、特定の構文をより単純な形式に簡単に変換できることも、角度になる可能性があります。
一方、lispのような言語は、使用するのが複雑ですが、非常に単純であると主張する人もいます。Haskellのようなものにも同じことが言えます。
次のいずれかの方法で複雑さを測定できますが、完全ではありません。
- 単純な問題のキーワードの数、コードの行、およびセマンティクスの複雑さ（識別子の解決など）。フィボナッチの計算は1つかもしれません。一般的なアルゴリズムのかなり効率的な実装を比較します。
- いつ何が起こりますか？名前は実行時に遅くバインドされますか、それともコンパイル時に解決されますか？
- 識別子、タイプ、および外部コードのすべての事実が与えられていない場合、与えられたコードのスニペットは複数の方法で理解できますか？
たくさんの方法があります。特定の構文のコンパイルプロセスの計算の複雑さを測定できます。
これらの例のすべてが正しいわけではありません。一部のオブジェクトモデルは非常に複雑ですが、高速な基盤を使用しているため非常に高速です。自己は一例かもしれません。
于 2009-07-22T21:35:03.743 に答える
1
正当性の証明の領域を見ると、意味の複雑さのより詳細な分析が見つかると思います。CSP（および程度は少ないがラムダ計算）のようなシステムは、分析によって扱いやすいように設計されています。言語が基礎となる形式体系の表現に近いほど、意味論の観点からは単純です。
反例は、Cプログラミング言語のようなものです。どのOSとハードウェアで実行されるかを知らなければ、Cプログラムが実際に何をするのかを理解することはできません。
于 2009-07-22T22:09:34.237 に答える
1
これを評価してくれたProjectEulerが大好きです。:)
于 2009-07-22T21:49:09.003 に答える
1
最も簡単な2つの完全に客観的なものは、言語で定義された記号とキーワード/予約語の量、およびそのBNFでの生成の量です。
あなたがそれらを持っているそれらの言語のためにあなたが見ることができるもう一つのことはそれらの標準文書の相対的なサイズです。ただし、すべての標準ドキュメントが同じレベルで作成されているわけではないと主張する人もいます。
于 2009-07-22T22:04:44.870 に答える
1
他のユーザーが投稿したように、キーワードはプログラミング言語がどれほど複雑になるかを客観的に測定したものです。文法/構文は、コード構造がどれほど複雑になる可能性があるかを説明します（キーワードの組み合わせが許可されます）。コードの一部がどれほど複雑であるかを測定するためのソフトウェア品質関連のコードメトリックがあります。
意味の複雑さは、測定するのが難しいように思えます。それは表現力に関連しています（プログラミング言語レベルが高いほど表現力が高くなります）。表現力を測定するために、さまざまな言語で実装されたさまざまなソリューションを比較しようとしても意味がありません（つまり、オイラープロジェクトの問題の実装=ソリューションを使用します）。問題自体と各プログラミング言語パラダイムは、比較にバイアスをかける可能性があります。
高水準プログラミング言語の場合、（抽象的な観点から）特定の問題に対して可能な実装の数は、意味の複雑さの良い尺度であると思います。
低水準プログラミング言語の場合、仕様言語がどのようにコードを生成するかを見るのは興味深いかもしれません（実装=与えられた問題の解決策を見つけてください）。これに関係なく、抽象化が限られているため、この測定値はソフトウェア品質コードのメトリックと密接に関連しているようです。
ご覧のとおり、抽象化とセマンティックの複雑さは自動化が困難です（実装=仕様に基づいたソリューションを生成します）。プログラマーの知識、知性、心理学が入ってくるところがあります（AIはこの点に到達していません）。
于 2016-04-19T19:01:47.523 に答える
0
言語の使用がどれほど複雑かは、ある程度主観的です。
一方、言語のセマンティクスがどれほど複雑であるかについての質問には答えることができますが、それは他の言語と比較した場合に限られます。ただし、これらは必ずしも有用ではありません。たとえば、Smalltalkにセマンティックの複雑さを1、C ++に9の複雑さを与えます。ただし、これを読んでいるブラウザーがSmalltalkではなくC++で記述されていることは間違いありません。
于 2009-07-22T21:24:33.047 に答える
0
そのような客観的な尺度がある場合、それはおそらく、与えられた目的のために与えられた言語を使用することの有用性またはコストを評価するためにほとんど役に立たないでしょう。空白やbrainfuckを除外するのに役立ちますが、ソースコードを主観的に観察し、それを使って真剣な作業をしたくないことを理解することで、そのような客観的な手段にリソースを費やすことなく、同じように簡単に行うことができます。
ほとんどの言語には、達成しようとしている目標や満たす必要のある条件と比較検討する必要のある多くの長所と短所があります。
于 2009-07-22T21:25:09.660 に答える