プログラミング言語

出典: フリー百科事典『ウィキペディア(Wikipedia)』

出典: フリー百科事典『ウィキペディア(Wikipedia)』
検索に移動

プログラミング言語[1](プログラミングげんご、: programming language)とは、コンピュータプログラムを記述するための形式言語である[2]。なお、コンピュータ以外にもプログラマブルなものがあることを考慮するならば、この記事で扱っている内容については、「コンピュータプログラミング言語」(: computer programming language)に限定されている。

日本産業規格の JIS X 3000 シリーズの規格名称では、全て「プログラム言語」になっている(例: JIS X 3001 プログラム言語 Fortran、JIS X 3014 プログラム言語 C++)ため、それに合わせてプログラム言語とされることもあるが、英語では programming language であるため、それに合わせればプログラミング言語となる。個々のプログラミング言語の名称は、Javaなど単にその名前だけで呼ばれることもあるが、「C」のように1文字などの場合、たいていの文脈ではわかりにくいといった理由から、「言語」の部分だけを接尾辞として用いた「C言語」などとすることも多い。

概要[編集]

自然言語と同様、構文規則言語学で言う統語論の規則)と意味規則(同じく意味論の規則)で定義される。形式的ないし非形式的(自然言語による)な仕様が(構文規則は形式的で、意味規則はそうでない、というものが多い)実装とは独立した文書で示される言語もあれば、実装のみの言語もある。 プログラミング言語は、情報を組織し処理するタスクについての理解を容易にし、アルゴリズムを正確に表現することができる。特に、チューリング完全である事が特徴である[3]。また、プログラミングへの応用も想定して設計されたロジバンのように、人間の言語とプログラミング言語の中間に位置するものがある。

プログラミング言語は人間同士の会話と比較して、正確性と完全性の要求性が非常に高いという特徴がある。自然言語で人間同士が対話する場合、スペルミスや文法的なエラーがあっても相手は状況から適当に補正し、正確な内容を把握する。しかしコンピュータは指示が曖昧では動作せず、プログラマがコードに込めた意図を理解させることはできない。言語仕様とプログラムとその入力データの組合せで、そのプログラムを実行したときの結果(外部から観測される振る舞い)が完全に指定できなければならない。

多くの言語は、新たなニーズを満たすべく設計され、他の言語と組み合わされ、最終的に使われなくなる。あらゆる用途に使える万能言語を設計しようという試みはいくつかあったが、そういう意味で成功した言語は存在しない [4]。多様な言語が生まれる背景には、言語が使われる状況の多様性がある。

  • 趣味で書く短いスクリプトから、数百人のプログラマが書く巨大なシステムまで、様々なプログラムがある。
  • プログラマも、言語に単純さを求める初心者から、相当に複雑な言語を好むエキスパートまで様々である。
  • システムにもマイクロコントローラからスーパーコンピュータまで様々あり、その中で性能、サイズ、単純さのバランスを保つ必要がある。
  • いったん開発されるとずっとそのまま使われ続けるプログラムもあれば、定期的に修正されるものもある。
  • 最終的にプログラマは好みによって言語を選ぶ場合もある。

プログラミング言語開発における共通の傾向として、より高いレベルの抽象化によって、より高い問題解決能力を得ようとしている。初期のプログラミング言語は、コンピュータのハードウェアのレベルと極めて近かった。新たなプログラミング言語が開発される度に機能が追加され、プログラマはハードウェアの命令からより遠い形でアイデアを表現できるようになっていった。プログラミングをハードウェアから分離することで、プログラマの生産性は向上する[5]

プログラミングにおけるプログラミング言語の必要性を排除する方法として、自然言語処理が提案されてきたという面もある。しかし、その方向性は実用化には達しておらず、議論が続いている。エドガー・ダイクストラは形式言語の使用によって意味のない命令を防ぐという立場で、自然言語によるプログラミングを批判していた[6]アラン・パリスも同様の立場であった[7]。このあたりの歴史的に錯綜した議論は、結局のところ「コンピュータを活用するにはプログラミングが必要であり、プログラミングはプログラミング言語で行われる」というある種のドグマが、次の2つの事象に分解されることで無意味な議論になった。すなわち「コンピュータをほどほどに活用する程度のことならば、各種アプリケーションソフトウェアや自然言語認識や自然言語処理技術の活用など(スマートスピーカーなど)により、利用者が自分でプログラミングすることは必ずしも必要ではなくなった」ということと「コンピュータのより徹底した活用、具体的にはそういった自然言語認識や自然言語処理のシステムそのものを作るには、プログラミングが必要ということは全く相変わらずであり、プログラミング言語の重要性は増えこそすれ、減りはしない」ということである。

自然言語との違い

プログラミング言語は、もともと人間がコンピュータに命令を伝えその実行方法を指示するために作られたものであり、コンピュータが曖昧さなく解析できるように設計されている。多くの場合構文上の間違いは許されず、人間はプログラミング言語の文法に厳密にしたがった文を入力しなければならない。

これに対して、一般に自然言語の文法規則はプログラミング言語にくらべてはるかに複雑であり、例外も多い。ただしこれは規則が一般にいいかげんであったり、曖昧であるということではない。一般に自然言語の規則は奥が深く、驚くほどの非合理性に裏打ちされていることもあれば、驚くほどの合理性に裏打ちされていることもある。驚くほどの非合理性でも合理性でもないものに裏打ちされていることもあれば、驚くほどの裏打ちの無さがあることもある。

また、自然言語の意味は、その文脈(コンテキスト)によって定まる部分も多い。これに対して、プログラミング言語は、コンピュータによって扱いやすいように、文脈によって意味が変わることができるだけないように設計されているが、その文脈によって定まる部分がある場合も無くはない。たいていの言語にいくつかはある。

自然言語は、誤用や流行などにより長い時間をかけ、たくさんの人間の利用により、意図せざる形で変化していく。しかし、プログラミング言語の規則は、言語設計者の意図と作業によってのみ、変更される。実際には言語設計者が「たくさんの人間」である場合もあり(仕様が簡単な言語であれば多くの実装者がいることも多く、そういう場合は個々の実装ごとのその仕様があるとも言える)、長い時間をかけ、自然言語と全く同様にたくさんの人間の利用により変化してきたプログラミング言語もある(Lispなど)。また、プログラミング言語にも同様に流行があり、もともとの言語仕様では規定が無かったような一種の「誤用」に、後から仕様が定められる、といったことも必ずしも珍しくはない。

人間がふだん使っている日本語などの自然言語を使ってコンピュータに指示することができるのが理想ではある、と空想する者もいる。しかし、自然言語はあまりにも複雑で曖昧で変則的なので、それを機械語にコンパイルできるようなプログラムを作成することはとても難しい(コンパイルできるできないの問題ではなく、そもそもその意味が「複雑で曖昧で変則的」であること自体が問題なのだが、それを理解できない者が冒頭のように空想するのである)。そのような研究も進められているが、未だに汎用で実用になるプログラムは作成されたことがない。

そこで、自然言語よりも制限が強く、単純で厳密で規則的な人工言語を作って代用する。これがプログラミング言語である。プログラミング言語は自然言語よりもいくらか人間には扱いづらいが、機械語よりは遥かに親しみやすく、人間の指示の手間を軽減している。ちなみにコンピュータ向けの形式性と人間向けの柔軟性を兼ね備えるロジバンなど、本来の開発目的が違えど潜在的に一つのプログラミング言語として機能しうるものもある。

大部分のプログラミング言語は、基本的には概ね文脈自由文法に沿っているが、プログラミング言語における文法的な制限は必ずしも全て文脈自由文法で表現できるとは限らず、文脈自由文法より制限されていることもあれば文脈自由文法より拡張されていることもあり、多くの場合は文脈自由文法には完全には沿っていない。


分類・種類[編集]

プログラミング言語の分類法は多数ある。

ひとつの分類法としては(そして計算機科学の教科書や情報処理技術者の教科書などで、まっさきに一種の定番のように挙げてある分類方法としては)、機械寄り(CPU寄り)か人間(の思考)寄りか、で分類する方法であり、低水準言語: low-level programming language) / 高水準言語: highh-level programming language)と分類する方法である。(" 低級言語 / 高級言語 " とも) 低水準言語の例としては、機械語の「命令コード」[8]と1対1に対応する「命令語」[9]を用いてプログラミングを行うアセンブリ言語: assembly language)がある。(機械語も低水準言語のひとつに数える場合もある。)対比される高水準言語の例としてはPerlVisual BasicLispPHPJavaPythonなどを挙げることができる。(なお、境界はやや曖昧で、C言語はかつては「高水準言語」と見なされていたが、その後それよりもレベルの高い高水準言語が多数登場したので、今日ではメモリ管理もしないC言語は「低水準言語」に分類されることもある。)

他の分類法としては、実行方法によってプログラミング言語を分類する方法もあり、インタープリタ方式言語interpreted language(s)) / コンパイラ方式言語(コンパイル方式言語、compiled language(s))と分類する方法である。 インタープリタ方式言語の例としてはPHPやRubyを挙げることができる。コンパイラ方式言語の例としてはC言語、C++、ErlangHaskellRustGo、FORTRAN、COBOLなどを挙げることができる。なお言語によってはインタープリタ方式で実行でき、かつコンパイル方式で実行することができるものもある。そして「一応、どちらの方法でも実行できるが、基本はコンパイル方式」などという場合もあるので、やや分類が曖昧になる場合がある。コンパイル方式でしか実行できない言語をわざわざ指さなければならない場合に「pure compiled language(純コンパイル方式言語)」などと分類する人もいる[10]。なおJavaはコンパイルをしてから実行するので、一応「コンパイル方式」に分類することも可能ではある言語だが、実行時コンパイラ(JIT)Java仮想マシンを使うので、「Javaは、コンパイル方式とインタープリタ方式の中間的な方式」としばしば指摘され、曖昧な位置づけである。

かつては人間側の用途で分類する方法もしばしば用いられたことがある。たとえば、汎用プログラミング言語 / 事務計算用プログラミング言語/ 科学技術計算用プログラミング言語 ...などと分類する方法である。1970年代-1980年代などは「事務計算用プログラミング言語の例はCOBOLで、科学技術計算用プログラミング言語の例はFORTRAN」などと書かれたが、近年ではそのような分類はあまりされなくなった。なお「汎用プログラミング言語」に分類されるのはJava、C#、Python[11]、Visual Basic、Rubyなどである。

手続き型言語[12]かそうでないかで、手続き型言語: procedural language) / 非手続き型言語: non-procedural language)と分類する方法もある。手続き型言語の例としてはFORTRAN、ALGOL、C言語、COBOL、BASICPascalなどを挙げることができる。

オブジェクト指向プログラミングに適したしくみを備えているか否かで、オブジェクト指向言語object-oriented language(s))/ 非オブジェクト指向言語non-object-oriented language(s))と分類されることもある。

構造化プログラミングに適した仕様になっているか否かで判断して、適したものだけを構造化プログラミング言語: structured programming language) と分類する方法もある。

スレッドを複数個生成・管理できるか否か、で並行言語 / 非並行言語 と分類する方法もある。

なお1950年代(や1960年代)計算理論チョムスキー階層という構想や理論が発表された時代には、計算表現能力に基づいてコンピュータの言語を、抽象的に、「タイプ0 / タイプ1 / タイプ2 / タイプ3」などに分類しようとしていたこともあった。ただし近年ではそのような分類法は滅多に持ち出されない。世の中のプログラミング言語のユーザーたちや言語開発者たちの関心は、すでに別のレベルに移っているからである。[13]

(他の分野でもありがちなことなのだが)プログラミング言語も分類法があまりに多数あるので、混乱しがちな分類法を整理整頓しようと「分類法の分類」をする人も出てくる。たとえば高級言語の分類方法について「プログラミングパラダイムによる分類法 / そうでない分類法」という分類ができる、などと言う人も出てくる。

以上のようにプログラミング言語の分類法は多数あるので、各プログラミング言語は複数のカテゴリに分類可能である。たとえばアセンブリ言語は「低水準言語」に分類され、かつ「非オブジェクト指向言語」に分類される。Javaは「高級言語」に分類され、かつ「オブジェクト指向言語」に分類され、かつ「並行性言語」に分類される。Pythonは「オブジェクト指向言語」であり「スクリプト言語」である。Lispは「マルチパラダイム言語」で「関数型言語」で「手続き型言語」である。

それ以外に、コンピュータがプリンター(やモニタ)などを制御するために使うプログラミング言語を分類するための「ページ記述言語」という分類法もある。 ページ記述言語の代表的な例としては、PostScriptを挙げることができる。たとえば、プリンターで美麗な印字をする場合、画面上のボタンやメニューで「印刷」という命令を選ぶわけだが、その時点でPC内のプリンター制御用プログラムがPostScript言語でプログラムを自動生成し、そのプログラムをケーブルやWifi経由でプリンターに向けて送り出し、それを受け取ったプリンターの側でそれを実行するということで美麗な印字、繊細な曲線に満ちたフォントの印字を実現している。

その他に、あまり真面目な分類ではないが、わざわざ理解が難しくなるように作られた(冗談のような)プログラミング言語を特に「難解プログラミング言語」と分類することもある。

プログラミング言語の種類

毎年のように新たなプログラミング言語が作り出されている。2008年2月時点で、「コンピュータ言語辞典[14]」には8152種のプログラミング言語が記載されていた。

ウィキペディアに記事が掲載されているプログラミング言語を知りたい場合はプログラミング言語一覧を参照のこと。

歴史[編集]

初期の発展[編集]

「コンピュータ」(という語)の定義次第ではあるが、それを「コンピュータ・プログラムによって駆動される機械」とするならば、コンピュータ・プログラムはコンピュータとともに生まれ、育ったということになり、そのプログラムの記法としてプログラミング言語があった、ということになる。チャールズ・バベッジ階差機関に続いて計画した解析機関は、パンチカードの先祖と言えるような穴の開いた厚紙の列によって制御されるという機構を持っていたため、その特徴から「19世紀のコンピュータ」「蒸気動力のコンピュータ」などと呼ばれることがある。

20世紀初頭には、タビュレーティングマシンによってパンチカードを使ったデータの機械処理が始まっている。そういった実際面ばかりではなく計算理論としても、1930年代から1940年代にかけて、アルゴリズムを表現する数学的抽象表現を提供するラムダ計算アロンゾ・チャーチ)とチューリングマシンアラン・チューリング)が考案された。ラムダ計算はその後の言語設計にも影響を与えている[15]

1940年代、世界初の電子式デジタルコンピュータ群が製作された。1950年代初期のコンピュータであるUNIVAC IIBM 701では機械語を使っていた。機械語によるプログラミングは、間もなくアセンブリ言語によるプログラミングに取って代わられた。1950年代後半になると、アセンブリ言語でマクロ命令が使われるようになり、その後 FORTRANLISPCOBOLという3つの高水準言語が開発された。これらは改良を加えられ現在でも使われており、その後の言語開発に重大な影響を与えた[16]。1950年代末、ALGOLが登場し、その後の言語に様々な影響を与えている[16]。初期のプログラミング言語の仕様と使い方は、当時のプログラミング環境の制約(パンチカードによるプログラム入力など)にも大きく影響されている[17]

改良[編集]

1960年代から1970年代末ごろまでに、現在使われている主な言語パラダイムが開発されたが、その多くはごく初期の第三世代プログラミング言語のアイデアの改良である。

これらの言語のアイデアは様々な言語に引き継がれており、現在の言語の多くは、これらのいずれかの系統に属する。

1960年代と1970年代は、構造化プログラミングに関する論争が盛んに行われた時期でもある[20]。この論争で特に有名なものは、1968年にCommunications of the ACMに掲載されたエドガー・ダイクストラのレターGo To Statement Considered Harmful[21]であろう。その後の反論と指針としてはクヌースStructured Programming with go to Statementsがある。

1960年代と1970年代は、プログラムのメモリ使用量を削減し、プログラマやユーザーの生産性を向上させる技法も進展した時期である。初期の4GL(第四世代プログラミング言語)は、同じプログラムを第三世代プログラミング言語で書いたときよりもソースコードの量を劇的に削減した。

統合と成長[編集]

1980年代は、相対的な統合の時代であった。C++は、オブジェクト指向とシステムプログラミングの統合である。アメリカでは、軍需に使うことを目的としてAdaというシステムプログラミング言語が標準化された。日本などでは、論理プログラミングを応用した第五世代言語の研究に資源を費やした[22]。関数型言語コミュニティではMLとLISPの標準化の動きがあった。これらはいずれも新たなパラダイムを生み出そうというものではなく、それまでに生み出されたアイデアに改良を加える動きであった。

1980年代の重要な言語設計傾向の1つとして、大規模システムのためのプログラミングを目的としてモジュールの概念を採り入れた点が挙げられる。1980年代にモジュールシステムを採り入れた言語として、Modula-2、Ada、MLがあるが、それ以前には、既にPL/Iがモジュラープログラミングをサポートしていた。モジュールシステムはジェネリックプログラミングの構成要素とされることが多い[23]

1990年代中頃には、インターネットの急激な成長によって新たな言語が生み出される機会が生じた。Perlは1987年にリリースされたUNIX上のスクリプト言語だったが、ウェブサイトの動的コンテンツ作成に使われるようになった。Javaはサーバ側のプログラミングに使われるようになった。

要素[編集]

構文[編集]

シンタックスハイライトによりソースコードの構造や文法ミスを認識しやすくなる。ここでの言語はPython

プログラミング言語の見た目は、その構文(syntax・統語論)で決定される。図形などを使うグラフィカルなプログラミング言語もあるが、たいていのプログラミング言語のソースコード文字列である。ファイル形式ではプレーンテキストすなわちテキストファイルが用いられる。

また、たいていのプログラミング言語では、まず、(英語では lexical syntax などと呼ぶ)ソースの文字列から空白類を取り除き最小の意味のあるカタマリを取り出した「字句(トークン)」があり、構文は字句の並びである、という扱いのことが多い。字句を切り出して分類する処理を字句解析、その並びを調べる処理を構文解析という。

(字句解析のために)字句規則を示すのには正規表現が、そして(構文解析のために)構文規則を示すのにはバッカス・ナウア記法が使われることが多い。

下記はLISPの構文のごく小さなサブセットである。

expression ::= atom | list
atom  ::= number | symbol
number  ::= [+-]?['0'-'9']+
symbol  ::= ['A'-'Z''a'-'z'].*
list  ::= '(' expression* ')'

これは、次のような規則である。

  • expressionatomまたはlistである。
  • atomnumberまたはsymbolである。
  • numberは1文字以上の数字列であり、オプションとして符号が前置される(空白は含まない)。
  • symbolはアルファベットで始まる任意の文字列である(空白は含まない)。
  • listは括弧記号の対であり、その間に0個以上のexpressionがある。

これに従った例として、'12345'、'()'、'(a b c232 (1))'などがある。

構文上正しいプログラムが全て意味的に整合しているとは限らない、という設計の言語も多い[24][25]。また、意味的に整合していても、それを書いた人が、自分の意図を正しく反映できていない場合もある。

以下のC言語のコード断片は構文上は正しいが、意味的には問題がある。pヌルポインタなので、p->realp->imを評価しようとすることは「未定義」であり、この場合はおそらくセグメンテーション違反をひきおこす。

complex *p = NULL;
complex abs_p = sqrt(p->real * p->real + p->im * p->im);

意味[編集]

自然言語の言語学に構文論(統語論)と意味論があるように、そのプログラムが表現しているものは何か、というのが、プログラミング言語の「意味」である。たとえば「a + b という式の値は、aの値とbの値を加算した値である」といったような規則の集まりであり、プログラム意味論という分野で形式的な意味論(形式意味論: formal semantics)も研究されているが、C言語の標準規格など、自然言語で意味を与えている言語や、形式的でない擬似言語のようなもので与えている言語もある。

型システム[編集]

型システムは、プログラミング言語において式の値となるデータ型について、型理論にもとづいて分類しどう扱うかを示すものである。

また、内部的には、ディジタルコンピュータでは全てのデータバイナリ二進法)で保持される。

型のある言語とない言語[編集]

型のある言語は、型システムによって、それぞれの値のデータ型に応じて、定義されていない操作が実行されないよう(多かれ少なかれ)チェックされる機構を持つ[26]

例えば、"this text between the quotes" は文字列型の値である。ふつう、数を文字列で割る操作には意味がない。そのため、そのようなプログラムは拒絶する。言語によっては、コンパイル時に検出し(静的型検査)コンパイルを失敗とする。言語によっては、実行時に検出し(動的型検査)、例外とするものもあればなんらかのコアーション(型の強制)を行うものもある。(理論的には、静的なシステムのみを指して「型システム」とすることもある)

(型のある言語の特殊例として、単一型言語がある。REXXといったスクリプト言語やSGMLといったマークアップ言語は、単一のデータ型しか扱わない。多くの場合、そのときのデータ型は文字列型である。

アセンブリ言語などの型のない言語は、任意のデータに任意の操作を実行可能であり、データは単にある長さのビット列として扱われる[26]。ある程度高い機能を持ちつつも型が無い(あるいは単一型の)プログラミング言語の例としては、BCPLForthなどがある(型という概念自体が無いわけではない。例えば「浮動小数点に対する加算」という演算子といったものは存在する。ただしその演算子により、オペランドが何であれそのワードのビットパターンが浮動小数点数を表現しているものとみなされて加算される、といったようなことになる)。

「多かれ少なかれ」と書いたように、「強い」型システムの言語は少なく、多くの言語はそれなりの型システムを採用している[26]。多くの実用的な言語には、型システムを迂回または打倒するような手段が用意されている。

静的型付けと動的型付け[編集]

静的型付け(静的型付き言語[27])では、全ての式の型はそのプログラムを実行する前(一般にコンパイル時)に決定される。例えば、1とか(2+2)という式は整数型であり、文字列を期待している関数には渡せず、日付(型)を格納するよう定義された変数には代入できない[26]

静的型付けでは、型を明記する場合と型推論を行う場合がある。前者ではプログラマは適切な位置に型を明記しなければならない[28]。後者では、コンパイラが式の型を文脈から推論する。C++Javaなどの主な静的型付き言語では、型を明記する。完全な型推論は主流でない言語に使われている(HaskellML)。ただし、型を明記する言語でも部分的な型推論をサポートしていることが多い。たとえば、JavaC#では限定された状況で型推論を行う。

動的型付け(動的型付き言語[29])では、型の安全性は実行時に検査される。言い換えれば、型はソース上の式ではなく、実行時の値に対して付与される[26]。型推論言語と同様、動的型付き言語でも式や変数の型を明記する必要はない。また、ある1つの変数がプログラム実行中に異なる型の値を格納することも可能である。しかし、コードを実際に実行してみるまで型の間違いを自動的に検出することができず、デバッグがやや難しい。動的型付き言語としては、RubyLISPJavaScriptPythonなどがある。

強い型付けと弱い型付け[編集]

実行意味論[編集]

データを入力されれば、コンピュータはそのデータに対して何らかの処理を実行する。「実行意味論(: execution semantics)」とは、プログラミング言語の構成要素がどの時点でどのようにして、そのプログラムの振る舞いを生成するのかを定義するものである。

例えば、式の評価戦略先行評価部分評価遅延評価短絡評価など)は実行意味論の一部である。また、制御構造における条件付実行の作法も実行意味論の一部である。

標準ライブラリ[編集]

「ライブラリ」は、プログラムを書いたり使用する上での、補助的なルーチン群である。多くのプログラミング言語には、言語仕様の一部、あるいは言語本体の仕様とは独立していることもあるが、標準ライブラリの仕様もほぼ必ず存在し、その言語の実装には標準ライブラリの実装もほぼ必ず付属する。標準ライブラリには、典型的なアルゴリズムデータ構造入出力機構などが含まれることが多い。

ユーザーから見れば、標準ライブラリも言語の一部だが、設計者から見れば別の実体である。言語仕様には必ず実装しなければならない部分が定義されており、標準化された言語の場合、それには標準ライブラリも含まれる。言語とその標準ライブラリの境界は、言語によって様々である。実際、言語によっては一部の言語機能が標準ライブラリなしでは使えないこともある(たとえば累乗の演算子がある言語があるが、それのコンパイル結果はその言語の多くの処理系で関数呼出であろう。それが、言語仕様として標準ライブラリの該当する関数を呼び出すよう決められているような場合は「一部の言語機能が標準ライブラリなしでは使えない」ということになる)。

マクロもライブラリに含まれることも多い。たとえばC言語の標準には、いくつかの名前が関数ではなくマクロで提供されるかもしれない、といったような規定などがある。またLisp系の言語では、いわゆる特殊形式の多くが言語組込ではなくマクロでも実装可能であり、ifとcondのようにどちらか片方は必要だが、片方があればもう片方はマクロにできる、といったようなものもある。Schemeの標準規格は、どれを言語組込とし、どれをマクロとするか、ほとんどを処理系実装者の自由に任せている。

設計と実装[編集]

コンピュータ・プログラミング言語の設計は「言語仕様」として示され、実装は「言語処理系」と呼ばれる。以下はそれらについての概観である。

仕様[編集]

前述のようにプログラミング言語は構文と意味から成るから、仕様についても、構文仕様と意味仕様がある。

構文仕様[編集]

構文仕様は一般にバッカス・ナウア記法などによって形式的に示される。

意味仕様[編集]

意味論の仕様は、自然言語などで記述されることが多いが、形式的に与えられている言語もある。

形式意味論(プログラム意味論の記事も参照)で意味論を記述した例として Standard ML[30]Scheme[31] がある。

その他[編集]

他に、以下のようなスタイルで仕様が与えられている言語もある。

処理系[編集]

プログラミング言語の実装は、プログラミング言語処理系と呼ばれる。コンパイラは、ソースコードなどの入力を中間表現などの、より解釈実行しやすい表現に変換する処理系である。また、インタプリタは、入力されたプログラムを解釈実行する処理系である(ハードウェアのプロセッサは、機械語を解釈実行するインタプリタである、と見ることができる)。

コンパイラとインタプリタの関係は、理論的には二村射影により美しく定式化されている。

なお、「大きく分けて2つの方法がある。コンパイラインタプリタである。一般にある言語をコンパイラとインタプリタの両方で実装することが可能である。」などといったように(従来書かれた通俗的解説書などには大変多いが)理解していると、Javaなど近年の多くの言語処理系のスタイルが全くわからない、ということになる。

機械語にまで変換するもののみを指してコンパイラと呼びたがる向きが一部にあり、その立場にもある程度は理もあるのだが、そうするとJavaの一般的な実装を指す用語が無くなる)

「コンパイラの出力したものをインタプリタで実行する方式は、コンパイラとインタプリタの区別が曖昧な場合もある。」などという変な説明をする者もいるが、前述したように、そもそも間違った2分法で考えているから、そのような変な考え方になるのである。

一般に、機械語に変換したもの(実行ファイル)を直接ハードウェアで実行する方が、インタプリタで実行するよりもずっと高速である。インタプリタでの実行を改善する技法として、実行時コンパイラなどの動的コンパイル手法がある。


言語利用状況の計測[編集]

どのプログラミング言語が最もよく使われているかを判断することは難しい。また、利用という意味も文脈によって異なる。プログラマの工数、コードの行数、CPU時間などが尺度として考えられる。ある言語は特定分野のアプリケーションだけでよく使われているということもある。例えばCOBOLは企業のデータセンター(メインフレームであることが多い)では今でも使われているし、FORTRANは科学技術計算でよく使われ、C言語は組み込みシステムやオペレーティングシステムで使われている。

以下のように言語利用状況の尺度は様々であり、どれを選択しても一種のバイアスがかかっていると考えた方がよい。

  • プログラマなどの求人広告で言語が言及されている回数[33]
  • 言語に関する書籍(入門書など)の販売部数[34]
  • 言語ごとの既存のコード行数の推計。公開調査で見逃しやすい言語は少なく推定される傾向がある。[35]
  • 検索エンジンが見つけた各言語への参照の回数


参考文献[編集]

  • Daniel P. Friedman, Mitchell Wand, Christopher Thomas Haynes: Essentials of Programming Languages, The MIT Press 2001.
  • David Gelernter, Suresh Jagannathan: Programming Linguistics, The MIT Press 1990.
  • Shriram Krishnamurthi: Programming Languages: Application and Interpretation, オンライン版.
  • Bruce J. MacLennan: Principles of Programming Languages: Design, Evaluation, and Implementation, Oxford University Press 1999.
  • John C. Mitchell: Concepts in Programming Languages, Cambridge University Press 2002.
  • Benjamin C. Pierce: Types and Programming Languages, The MIT Press 2002.
  • Ravi Sethi: Programming Languages: Concepts and Constructs, 2nd ed., Addison-Wesley 1996.
  • Michael L. Scott: Programming Language Pragmatics, Morgan Kaufmann Publishers 2005.
  • Richard L. Wexelblat (ed.): History of Programming Languages, Academic Press 1981.

脚注・出典[編集]

[脚注の使い方]
  1. ^ 1960年代、JISでは「プログラム言語」の訳語が用いられた(JIS C 6201-1967「電子計算機プログラム言語FORTRAN」)。このためプログラム言語としている例もJISをはじめとして広く見られるが、英フレーズ programming language に当てる語として必ずしも適切とは言えない。[要出典]
  2. ^ ISO 5127—Information and documentation—Vocabulary, clause 01.05.10 では、プログラミング言語を「プログラムを記述するための人工言語」と定義している。
  3. ^ MacLennan, Bruce J. (1987年). Principles of Programming Languages. Oxford University Press. p. 1. ISBN 0-19-511306-3 
  4. ^ IBMは PL/I をリリースしたとき、やや野心的にマニュアルを The universal programming language PL/I (IBM Library; 1966) と名づけている。このタイトルはIBMが目標としていた無制限のサブセット化機能を反映している「PL/I は特定の応用に必要な部分を抜き出し、サブセットを分離可能なように設計されている」 (Encyclopaedia of Mathematics » P  » PL/I”. SpringerLink. 2006年6月29日閲覧。). AdaとUNCOLも同様の初期目標を持っていた。
  5. ^ Frederick P. Brooks, Jr.: The Mythical Man-Month, Addison-Wesley, 1982, pp. 93-94
  6. ^ Dijkstra, Edsger W. On the foolishness of "natural language programming." EWD667.
  7. ^ Perlis, Alan, Epigrams on Programming. SIGPLAN Notices Vol. 17, No. 9, September 1982, pp. 7-13
  8. ^ CPUの命令コードというのは、本当のCPUレベルではたとえば「00101011」のようにただの2進数の羅列であり、人間には意味不明である。
  9. ^ 数文字のアルファベットや数字を組み合わせて、CPUに対する命令やCPUが操作すべきレジスタなどを表記したもの。
  10. ^ [1]
  11. ^ [2]
  12. ^ [3]
  13. ^ なおチューリング完全な言語ならば、同じアルゴリズム群を表現可能である。
  14. ^ The Encyclopedia of Computer Languages Archived 2011年2月20日, at the Wayback Machine. (Murdoch University、オーストラリア
  15. ^ Benjamin C. Pierce は次のように書いている。
    ". . . the lambda calculus has seen widespread use in the specification of programming language features, in language design and implementation, and in the study of type systems."(訳:ラムダ計算はプログラミング言語の仕様記述、言語設計と実装、型システムの研究に広く使われている)
    Pierce, Benjamin C. (2002年). Types and Programming Languages. MIT Press. pp. 52. ISBN 0-262-16209-1 
  16. ^ a b O'Reilly Media. “History of programming languages”. 2006年10月5日閲覧。
  17. ^ Frank da Cruz. IBM Punch Cards Columbia University Computing History.
  18. ^ Richard L. Wexelblat: History of Programming Languages, Academic Press, 1981, chapter XIV.
  19. ^ François Labelle. “Programming Language Usage Graph”. Sourceforge. 2006年6月21日閲覧。. Sorceforge でのプロジェクト群で使われている言語の統計をとった結果である。C言語はよく使われているが、2006年には Java に抜かれている。ただし、C++を含めると一番多く使われていることになる。
  20. ^ Hayes, Brian (2006年). “The Semicolon Wars”. American Scientist 94 (4): pp. 299-303. 
  21. ^ Dijkstra, Edsger W. (March 1968). “Go To Statement Considered Harmful”. Communications of the ACM 11 (3): 147–148. http://www.acm.org/classics/oct95/ 2006年6月29日閲覧。. 
  22. ^ Tetsuro Fujise, Takashi Chikayama, Kazuaki Rokusawa, Akihiko Nakase (December 1994). "KLIC: A Portable Implementation of KL1" Proc. of FGCS '94, ICOT Tokyo, December 1994. 第五世代コンピュータ・プロジェクト・アーカイブ
  23. ^ Jim Bender (2004年3月15日). “Mini-Bibliography on Modules for Functional Programming Languages”. ReadScheme.org. 2006年9月27日閲覧。
  24. ^ 自然言語では Colorless green ideas sleep furiously. という例文がある。
  25. ^ その言語の設計次第である。構文的に正しければ必ず整合した意味を持つような設計というものもありうる。
  26. ^ a b c d e Andrew Cooke. “An Introduction to Programming Languages”. 2006年6月30日閲覧。
  27. ^ : statically typed language
  28. ^ たとえば変数の宣言などでは、その名前の直前ないし直後といったことが多い。ただしC言語では「void (*signal(int sig, void (*func)(int)))(int);」などといったように、いったいどこにあるのが名前なのか型なのか、全くわからないことになることがある。
  29. ^ : dynamically typed language
  30. ^ Milner, R.; M. Tofte, R. Harper and D. MacQueen. (1997年). The Definition of Standard ML (Revised). MIT Press. ISBN 0-262-63181-4 
  31. ^ Kelsey, Richard; William Clinger and Jonathan Rees (1998年2月). “Section 7.2 Formal semantics”. Revised5 Report on the Algorithmic Language Scheme. 2006年6月9日閲覧。
  32. ^ ANSI — Programming Language Rexx, X3-274.1996
  33. ^ Survey of Job advertisements mentioning a given language
  34. ^ Counting programming languages by book sales Archived 2008年5月17日, at the Wayback Machine.
  35. ^ Bieman, J.M.; Murdock, V., Finding code on the World Wide Web: a preliminary investigation, Proceedings First IEEE International Workshop on Source Code Analysis and Manipulation, 2001

関連項目[編集]