プログラミング言語

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動先: 案内検索
プログラミング言語に関する書籍。

プログラミング言語(プログラミングげんご、programming language[1])はコンピュータプログラムを記述する(コンピュータプログラミングする)ための形式言語である(「言語」と付いてはいるが、形式言語は、一般にいう言語である自然言語とは違うものである)[2]

概要[編集]

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

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

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

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

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

プログラミングにおけるプログラミング言語の必要性を排除する方法として、自然言語処理が提案されてきたという面もある。しかし、その方向性は実用化には達しておらず、議論が続いている。エドガー・ダイクストラは形式言語の使用によって意味のない命令を防ぐという立場で、自然言語によるプログラミングを批判していた[6]アラン・パリスも同様の立場であった[7]

自然言語との違い[編集]

以下の文章は、要するに「形式言語である」ということを、それではわかりにくい者のために、冗長に書いたものである。

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

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

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

自然言語は、誤用や流行などにより長い時間をかけ、たくさんの人間の利用により、意図せざる形で変化していく。しかし、プログラミング言語の規則は、言語設計者の意図と作業によってのみ、変更される。

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

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

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

要素[編集]

構文[編集]

シンタックスハイライトはソースコードを認識しやすくする。ここでの言語は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))' などがある。

構文上正しいプログラムが全て意味的に整合している、とは限らない、という設計の言語も多い[8](その言語の設計次第である。構文的に正しければ必ず整合した意味を持つような設計というものもありうる)。また、意味的に整合していても、それを書いた人が、自分の意図を正しく反映できていない場合もある。

以下の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言語の標準規格など、自然言語で意味を与えている言語や、形式的でない擬似言語のようなもので与えている言語もある。

型システム[編集]

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

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

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

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

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

(型のある言語の特殊例として、単一型言語がある。REXXSGMLといったスクリプト言語やマークアップ言語は、単一のデータ型しか扱わない(多くの場合、そのときのデータ型は文字列型である)。それ以前の話として、そもそもSGMLはプログラミング言語ではない

アセンブリ言語などの型のない言語は、任意のデータに任意の操作を実行可能であり、データは単にある長さのビット列として扱われる[9]。ある程度高い機能を持ちつつも型が無い(あるいは単一型の)プログラミング言語の例としては、BCPLForthなどがある。

「多かれ少なかれ」と書いたように、「強い」型システムの言語は(残念ながら)まだ少なく、多くの言語はそれなりの型システムを採用している[9]。多くの実用的な言語には、型システムを迂回または打倒するような(すなわち、自分で自分の足を銃で撃ちたい時には、それを可能にするための)手段が用意されている。

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

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

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

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

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

実行意味論[編集]

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

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

標準ライブラリ[編集]

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

ユーザーから見れば、標準ライブラリも言語の一部だが、設計者から見れば別の実体である(「ユーザー」という語が指す範囲が不明だが、それなりのプログラマであれば、普通はちゃんと識別するものである)。言語仕様には必ず実装しなければならない部分が定義されており、標準化された言語の場合、それには標準ライブラリも含まれる。言語とその標準ライブラリの境界は、言語によって様々である。実際、言語によっては一部の構文要素が標準ライブラリなしでは使えないこともある。例えばJavaでは、文字列リテラルは java.lang.String クラスのインスタンスとして定義される。同様にSmalltalkでは、無名関数はライブラリの BlockContext クラスのインスタンスを使用する。また、Schemeは言語仕様の大部分をライブラリマクロとして実装可能にしており、言語設計者はどこまでを言語本体で実装すべきかも明確に述べていない。

設計と実装[編集]

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

仕様[編集]

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

構文仕様[編集]

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

意味仕様[編集]

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

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

その他[編集]

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

処理系[編集]

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

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

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

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

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

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

意義と目的[編集]

(コンピュータ)プログラミング言語は、おもに英語の単語と記号を組み合わせた(英語である必然性はひと欠片も無いが)、特殊な文法(正確には「構文」。誰にとって特殊かは不明だが)で記述される。その意義は、人とコンピュータの意思疎通を容易にするため、数字の羅列に代えて人間に扱いやすい言語形式を提供することにある。プログラミング言語があれば、人は扱いやすく理解できる言葉でコンピュータへの指示を書くことができる。プログラミング言語で書かれたコードは、アセンブラコンパイラインタプリタなど「プログラミング言語処理系」と呼ばれるプログラムによって処理(機械語あるいは中間表現に変換されたり、解釈実行されたり)される。

プログラミング言語は、コンピュータ企業や技術者により目的に応じて開発され、様々なプログラミング言語が、毎年のように生み出されている。2008年2月時点で、「コンピュータ言語辞典[13]」には8152種のプログラミング言語が記載されていた。

定義[編集]

機能
プログラミング言語はプログラムを書くのに使われる言語であり、それによってコンピュータは何らかの計算[14]アルゴリズムを実行し、場合によってはプリンターロボット[15]などの外部装置を制御する。
対象
自然言語は人間同士の対話に使われるのに対して、プログラミング言語は人間が機械に指示を与えるのにも使われる。場合によっては、装置が別の装置を制御するのにも使われる。例えば、PostScriptプログラムは別のプログラムが生成し、プリンターやディスプレイの制御に使われる。
構成要素
プログラミング言語には、データ構造を定義し操作する構成要素と、実行の流れを制御する構成要素がある。
表現能力
計算理論では、言語はその計算表現能力で分類される(チョムスキー階層参照)。チューリング完全な言語ならば、同じアルゴリズム群を表現可能である。

計算を記述するのではない言語(HTMLのようなマークアップ言語など)はプログラミングではない(しばしば誤解されているが)。なお、JavaScriptやPHPのように、何らかの形でそういった言語に埋め込まれるプログラミング言語、といったようなものは存在する。

歴史[編集]

初期の発展[編集]

世界初のプログラミング言語は、いわゆるデジタルコンピュータの登場する前に存在した。19世紀には、プログラム可能な織機自動ピアノ向けの巻紙があり、そこには現代的分類で言えばドメイン固有言語とされるプログラミング言語でプログラムが書かれていた。20世紀初頭には、タビュレーティングマシンによってパンチカードを使ったデータの機械処理が始まっている。1930年代から1940年代にかけて、アルゴリズムを表現する数学的抽象表現を提供するラムダ計算アロンゾ・チャーチ)とチューリングマシンアラン・チューリング)が考案された。ラムダ計算はその後の言語設計にも影響を与えている[16]

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

改良[編集]

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

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

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

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

統合と成長[編集]

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

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

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

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

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

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

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

分類[編集]

プログラミング言語の完全な分類法は存在しない(前述の、COBOLは事務計算用途向け、FORTRANが科学技術計算用途向けといったような、ある程度の方向性はあるが)。あるプログラミング言語には大抵複数の起源(影響を与えた言語)がある。言語は一般に複数の既存言語の要素と新たなアイデアを組み合わせて生み出される。ある言語を起源とするアイデアはその系統の言語群に広まっていき、あるときギャップを飛び越えて全く別の系統の言語で使われるようになる。

さらに事を複雑にするのは、言語は様々な観点から分類可能という点である。例えば、Javaはオブジェクト指向言語であると同時に、並行性言語でもある(言語仕様としてスレッドを複数並行して生成可能であるため)。Python はオブジェクト指向言語であると同時に、スクリプト言語でもある。

プログラミング言語の大まかな分類として、プログラミングパラダイムによる分類と想定している利用分野や用途による分類がある。パラダイムには、手続き型プログラミングオブジェクト指向プログラミング関数型プログラミング論理プログラミングなどがある。言語によっては2つのパラダイムの性格を併せ持つこともあるし、マルチパラダイムの場合もある。アセンブリ言語は、マシンのアーキテクチャを直接モデル化したものであるため、パラダイムとは言わない。用途による分類では、汎用、システムプログラミング言語、スクリプト言語、ドメイン固有言語、並行/分散言語(あるいはこれらの混合)などがある[28]。汎用言語の一部は教育目的で設計されている[29]

プログラミングパラダイムとは無関係なパラメータで分類されることもある。例えば、多くのプログラミング言語は英語のキーワードを使っているが、ごく一部の言語はそうではない。また、難解かそうでないかという分類もある。

低水準言語と高水準言語[編集]

機械語アセンブラ言語は、よりハードウェアに近い言語であり、このようなプログラミング言語を低水準言語という。また、それ以外の言語は、機械語と一対一で対応せず、より人間に近い言語であり、高水準言語という。

脚注・出典[編集]

[ヘルプ]
  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日閲覧。). AdaUNCOLも同様の初期目標を持っていた。
  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. ^ 自然言語では Colorless green ideas sleep furiously. という例文がある。
  9. ^ a b c d e Andrew Cooke. “An Introduction to Programming Languages”. 2006年6月30日閲覧。
  10. ^ Milner, R.; M. Tofte, R. Harper and D. MacQueen. (1997年). The Definition of Standard ML (Revised). MIT Press. ISBN 0-262-63181-4. 
  11. ^ Kelsey, Richard; William Clinger and Jonathan Rees (1998年2月). “Section 7.2 Formal semantics”. Revised5 Report on the Algorithmic Language Scheme. 2006年6月9日閲覧。
  12. ^ ANSI — Programming Language Rexx, X3-274.1996
  13. ^ The Encyclopedia of Computer Languages (Murdoch University、オーストラリア
  14. ^ ACM SIGPLAN (2003年). “Bylaws of the Special Interest Group on Programming Languages of the Association for Computing Machinery”. 2006年6月19日閲覧。, The scope of SIGPLAN is the theory, design, implementation, description, and application of computer programming languages - languages that permit the specification of a variety of different computations, thereby providing the user with significant control (immediate or delayed) over the computer's operation.
  15. ^ Dean, Tom (2002年). “Programming Robots”. Building Intelligent Robots. Brown University Department of Computer Science. 2006年9月23日閲覧。
  16. ^ 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. 
  17. ^ a b O'Reilly Media. “History of programming languages”. 2006年10月5日閲覧。
  18. ^ Frank da Cruz. IBM Punch Cards Columbia University Computing History.
  19. ^ Richard L. Wexelblat: History of Programming Languages, Academic Press, 1981, chapter XIV.
  20. ^ François Labelle. “Programming Language Usage Graph”. Sourceforge. 2006年6月21日閲覧。. Sorceforge でのプロジェクト群で使われている言語の統計をとった結果である。C言語はよく使われているが、2006年には Java に抜かれている。ただし、C++を含めると一番多く使われていることになる。
  21. ^ Hayes, Brian (2006年). “The Semicolon Wars”. American Scientist 94 (4): pp. 299-303. 
  22. ^ 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日閲覧。. 
  23. ^ Tetsuro Fujise, Takashi Chikayama, Kazuaki Rokusawa, Akihiko Nakase (December 1994). "KLIC: A Portable Implementation of KL1" Proc. of FGCS '94, ICOT Tokyo, December 1994. 第五世代コンピュータ・プロジェクト・アーカイブ
  24. ^ Jim Bender (2004年3月15日). “Mini-Bibliography on Modules for Functional Programming Languages”. ReadScheme.org. 2006年9月27日閲覧。
  25. ^ Survey of Job advertisements mentioning a given language
  26. ^ Counting programming languages by book sales
  27. ^ 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
  28. ^ TUNES: Programming Languages”. 2008年2月29日閲覧。
  29. ^ Wirth, Niklaus (1993年). “Recollections about the development of Pascal”. Proc. 2nd ACM SIGPLAN conference on history of programming languages: 333–342. http://portal.acm.org/citation.cfm?id=155378 2006年6月30日閲覧。. 

参考文献[編集]

  • 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.

外部リンク[編集]