表現力 はウィキペディアで次のように定義されています:
..その言語で表現および伝達できる幅広いアイデア。
「アイデア」は、マシンに通信できるもの(操作、構造、アルゴリズムなど)を指しますか??それとも、他の人間にその言語で捉えて伝えることができる「人間」の概念を指しているのでしょうか?
表現力はどのように評価および測定されますか?
たとえば、JavaScriptのような言語を使用し、変数名に奇妙な制限を課した場合などの変数は、アンダースコアが前に付いた8桁の数字で、/^_[0-9]{8}$/
、表現力を失いますか?
それともonlyはばかげて迷惑なのでしょうか?
明確にするために:
表現力は、言語に固有の一般的なアイデアによって測定されます。
または、特定の数、言語が表すことができるユニークなアイデア:
表現力に関する画期的な論文は On the Expressive Power of Programming Languagesby Matthias Felleisen(1991) です。これには、言語の表現力の数学的に厳密な定義が含まれています。
直感的に、言語で記述できるすべてのプログラム[〜#〜] a [〜#〜]も言語で記述できる場合[〜#〜] b [〜#〜]ローカル変換のみありますが、言語で書かれたプログラムがあります[〜#〜] b [〜#〜]言語で記述できない[〜#〜] a [〜#〜]グローバル構造を変更せずに(つまり、純粋にローカルな変換ではない) 、次に言語[〜#〜] b [〜#〜]は、言語よりも表現力があります[〜#〜] a [〜 #〜]。
この定義の1つの優れた特性は、[〜#〜] x [〜#〜]にプログラムがある言語のペアが存在する可能性を認めることです。[〜#〜] y [〜#〜]で表現され、プログラムは[〜#〜] y [〜#〜 ][〜#〜] x [〜#〜]で表現できないため、言語は異なりますが、どちらの言語もより表現力があります他より。これは、いくつかの点で優れている言語と他の点で優れている言語があり、どちらも一般的に他の言語より「優れている」という私たちの実際の経験とうまく適合しています。
表現力 はウィキペディアで次のように定義されています:
そのページをもう一度読んでみましょう。最初に注意すべきことの1つは、「プログラミング言語」ではなく「言語」を示しており、その例のほとんどがプログラミング言語ではないことです。最初の例は、OWL2 ELとOWL2 RLの比較です。OWL2ELはどちらもオントロジー言語です。
この概念をプログラミング言語に適用できますが、パターンマッチング言語、マークアップ言語、クエリ言語、ビジュアルスタイルシート言語、正規表現(およびそれらが参照するすべての正規言語)などにも適用できます。英語などの自然言語の表現力を参照することもできます。これは、非常に非公式に行われることが多いですが、自然言語処理に関連する問題を考えると、より深刻になります。
「アイデア」とは、マシンと通信できるもの(操作、構造、アルゴリズムなど)を指しますか?それとも、他の人間にその言語で捉えて伝えることができる「人間」の概念を指しているのでしょうか?
それは、その言語で表現できるものを指し、純粋にそれ自体としてのものと見なされます。
たとえば、あなたの質問はあなたが知っている言語の1つであることを示しているので、(私の例では全体を通してjavascriptを使用します)javascriptステートメントを検討してください:
var x = 3 + 4;
これは、3と4の合計値が計算され、特定の名前空間スコープ内のラベルx
に関連付けられた値が計算されることを表します。
世界のすべてのコンピューターを破壊し、そのコードを一枚の紙に書いたとしても、JavaScriptで同じ意味が残っていることに変わりはありません。そのようなコードを実行することはできませんが、言語の抽象的な定義については、まだ話をすることができます。
これは見苦しいように見えるかもしれませんが、実際のコンピュータを考慮せずに、言語が抽象的に推論できるものであることは実際には非常に重要です。一つには、実際にはまだ実現可能ではなかったコンピュータ言語の理論的なポイントについて推論する人々は、私たちが今日のところにいるようになったことの1つです。コンピューターにはコンピューターサイエンスが必要ですが、コンピューターサイエンスにはコンピューターは必要ありません。計算のアイデアだけです。
もちろん、私たちは現実の世界でコンピューターを使用しており、最近では理論的に議論する専門家は少なく、実際にコンピューターを使用する人がたくさんいます。あなたがリンクしたページは言う:
表現力という用語は、さまざまな意味で使用できます。それはその言語で表現できるアイデアの尺度を意味するかもしれません:
使いやすさに関係なく(理論的表現力)
簡潔かつ容易に(実用的な表現)
最初の意味は、言語の正式な記述とその意味を扱う数学と論理の分野、たとえば正式な言語理論、数学的論理、プロセス代数などで支配的です。
非公式の議論では、この用語はしばしば第二の意味、またはその両方を指します。これは、プログラミング言語について議論する場合によく起こります。これらの非公式な用語の使用を正式化するための努力が払われてきた
これら2つの用語の使用のうち、最初の実際の影響は単独でコンピュータに伝達できるものに関連しています。
2つ目は読み書き両方における人間の理解に関係していますが、その程度は、非公式であり、厳密に定義されていないため、用途によって大きく異なります。
たとえば、JavaScriptのような言語を使用し、変数名に奇妙な制限を課した場合、たとえば、変数は
/^_[0-9]{8}$/
に一致するアンダースコアが前に付いた8桁の数字でなければならない場合、表現力を失いますか?
正式な定義では、表現力は失われていません。変数は100,000,000に制限されていますが、本当に必要な場合は、新しく作成された名前空間内により多くの変数を保持するオブジェクトを作成することで回避できます。そのため、今日のJavaScriptで記述されたプログラムは、この新しい形式で書き直すことができるため、同等に表現力があります。
非公式の定義では、一部を失っていますが、どれだけが非公式であるかに依存します。これは、非公式な使用に関する「ルール」とは何も言えないため、状況によって異なります。同じ名前空間に100,000,000を超える変数を含むプログラムは、単純な置換を超えて書き直さなければならないため、わずかな損失があったと言えます。さらに非公式な使用は、そのような不格好な変数名が人間の包括的なものに与える精神的な影響を指します。
また、人々が非公式に厳密には言語の一部ではないものを考慮することにも注意してください。 Javascriptの作成から今日までの変更を検討してください。
最も正式な定義では、表現力はほとんど変わっていません。結局のところ、それは最初からチューリング完全でした。
より非公式な定義により、配列操作、例外処理、および(おそらく最も重要な)正規表現を含めることで、表現力が大幅に向上しました。これらは、JavaScriptでこれまでできなかったことを何もしませんが、数行で実行でき、1秒未満の実行時間でjavascript1.0に書き込むのにキロバイトのコードがかかり、実行に長い時間がかかります。
はるかに非公式な定義により、ブラウザでのJavaScriptの最初の使用からの変更(フォーム入力の値を変更できるdocument.write
は、ページが最初に解析され、新しい場所に移動するか、戻るまたは進む歴史、しかしそれ以外はほとんど何もありません)今日まで(サーバー呼び出しからのデータに基づくことを含め、ページ上のほとんどすべてを変更することができます)は絶対に計り知れませんが、ほとんどはJavaScriptに関連していませんが、言語ではなく、オブジェクトモデルとAPIが利用可能になりました(たとえば、IEのvbscriptは、これらの変更から等しく恩恵を受けました)。
私の考えでは、その最後の使い方はあまりにも非公式なので、実際には正しくありませんが、それは非公式な定義の問題です。
正式な定義により、それは実際にはそれほど表現力を増していません。
変数の命名規則が「表現力」の意味を本当に捉えているとは思いません。 「表現力」というのはもっと根本的なことだと思います。たとえば、Linqを使用するC#と、Linqを使用する前のC#を比較してください。 Linqの追加後、SQLのようなクエリを直接C#で記述できるようになりました。これは、以前の選択肢よりもはるかにエレガントです。 SQLを文字列リテラルに入れてサーバーに渡すか、「for」を使用してコレクションを繰り返します。
もう1つの良い例は、プロトタイプベースの継承を持つ言語です。これらの言語では、実行時に新しいメソッドをインスタンスまたはクラス(「クラス」が指定された言語で記述される名前なら何でもよい)に単純に追加することが可能です。 C++やC#では実際にそれを行うことはできません。プロトタイプベースの言語と比較して、この程度の表現力はありません。 (C#には拡張メソッドの概念があり、それらは確かに表現力を追加すると言えるでしょう。)
ウィキペディアの記事で言及されているように、表現力とは、言語で表現できるプログラムのセットを指します。 「プログラミング言語」(JavaScript、LISP、C#、Perlなど)と考えるものはすべて本質的にチューリング完全です。つまり、「計算可能」と言われるものはすべて表現できます。
ただし、正規表現は通常のプログラミング言語ほど表現力がないことは明らかです。さらに、シェルのワイルドカードは、正規表現よりも表現力に欠けます。
共通テーブル式を使用したSQLのバージョンは、CTEを使用すると、SQLで表現することが不可能である再帰クエリを表すことができるため、バージョンのないバージョンよりも表現力が高くなります。
表現力を理解するためのより単純で簡単な方法がありますが、最初に言語の意味を確立する必要があります。言語を学ぶ分野には、言語学とオートマトンの2つがあります。どちらも、言語は連結を使用して有限のアルファベットから構成される単語のセット(有限シーケンス)であることに同意します。通常、興味深い言語(興味深いとは、有用な方法で解釈できる言語を意味します)には、言語に含まれる単語と含まれない単語を管理する一連のルールもあります。表現力が存在するのは、解釈がある場合のみであることに注意してください。
解釈とは、ある言語のWordが与えられたときに、オブジェクトのセットからオブジェクトを選択する関数の存在を意味します(これは自然言語では明らかに議論の余地があります)。
「Word」を使って誤解しないでください。 JavaプログラムはJava言語の単語です(ただし、スペースで区切られた複数の文字列を含む複数のファイルにまたがることがあります)。
この比較的単純な概念に対処するために、現代のプログラミング言語などの複雑な言語を使用することは逆効果です。そのため、代わりに数式を使用します。
言語Aを整数加算を含むすべての式であると定義しましょう。
言語Bを整数乗算を含むすべての数式の言語として定義しましょう。
どちらの場合も、identity要素の使用は禁止されています。したがって、言語Aには「1 + 1」、「1 + 2」、「1 + 3」、「2 + 3」などの単語が含まれています。言語Bには、「2 * 2」、「2 * 3」、「2 * 4」、「3 * 4」などの単語が含まれています。また、通常の解釈を「*」と「+」(整数の加算と整数の乗算)にそれぞれの記号に割り当てます。したがって、「1 + 1」の解釈は2であり、「2 * 2」の解釈は4です。
整数では乗算が繰り返し加算としてキャストされる可能性があることは事実ですが、一般的に加算を乗算として表す方法がないため、言語Aは言語Bよりも厳密に表現力があることに注意してください。
要約すると、言語Aは、解釈関数が共通領域を共有する場合、言語Bよりも表現力が高いと言えますが、Bの解釈関数のイメージは、Aの解釈関数のイメージの適切なサブセットです。