プログラミング言語
プログラミング言語(プログラミングげんご、英語: programming language)とは、プログラムを記述するための人工言語。コンピュータプログラムを書くために考案された、正確に定義された記号と規則のしくみ。以前は、しばしばプログラム言語と表記された。
また、プログラミング言語にも同様に流行があり、もともとの言語仕様では規定が無かったような一種の「誤用」に、後から仕様が定められる、といったことも必ずしも珍しくはない。
人間がふだん使っている日本語などの自然言語を使ってコンピュータに指示することができるのが理想ではある、と空想する者もいる。しかし、自然言語はあまりにも複雑で曖昧で変則的なので、それを機械語にコンパイルできるようなプログラムを作成することはとても難しい(コンパイルできるできないの問題ではなく、そもそもその意味が「複雑で曖昧で変則的」であること自体が問題なのだが、それを理解できない者が冒頭のように空想するのである)。そのような研究も進められているが、未だに汎用で実用になるプログラムは作成されたことがない。
そこで、自然言語よりも制限が強く、単純で厳密で規則的な人工言語を作って代用する。これがプログラミング言語である。プログラミング言語は自然言語よりもいくらか人間には扱いづらいが、機械語よりは遥かに親しみやすく、人間の指示の手間を軽減している。ちなみにコンピュータ向けの形式性と人間向けの柔軟性を兼ね備えるロジバンなど、本来の開発目的が違えど潜在的に一つのプログラミング言語として機能しうるものもある。
大部分のプログラミング言語は、基本的には概ね文脈自由文法に沿っているが、プログラミング言語における文法的な制限は必ずしも全て文脈自由文法で表現できるとは限らず、文脈自由文法より制限されていることもあれば文脈自由文法より拡張されていることもあり、多くの場合は文脈自由文法には完全には沿っていない。
なおプログラミングへの応用も想定して設計されたロジバンのように、人間の言語とプログラミング言語の中間に位置するものがある。
手続き型言語の例としてはFORTRAN、ALGOL、C言語、COBOL、BASIC、Pascalなどを挙げることができる。
オブジェクト指向プログラミングに適したしくみを備えているか否かで、オブジェクト指向言語 / 非オブジェクト指向言語 と分類されることもある。
構造化プログラミングに適した仕様になっているか否かで判断して、適したものだけを構造化プログラミング言語と分類する方法もある。
スレッドを複数個生成・管理できるか否か、で並行言語 / 非並行言語 と分類する方法もある。
なお1950年代(や1960年代)計算理論をチョムスキー階層という構想や理論が発表された時代には、計算表現能力に基づいてコンピュータの言語を、抽象的に、「タイプ0 / タイプ1 / タイプ2 / タイプ3」などに分類しようとしていたこともあった。ただし近年ではそのような分類法は滅多に持ち出されない。世の中のプログラミング言語のユーザーたちや言語開発者たちの関心は、すでに別のレベルに移っているからである。
(他の分野でもありがちなことなのだが)プログラミング言語も分類法があまりに多数あるので、混乱しがちな分類法を整理整頓しようと「分類法の分類」をする人も出てくる。たとえば高級言語の分類方法について「プログラミングパラダイムによる分類法 / そうでない分類法」という分類ができる、などと言う人も出てくる。
「ライブラリ」は、プログラムを書いたり使用する上での、補助的なルーチン群である。多くのプログラミング言語には、言語仕様の一部、あるいは言語本体の仕様とは独立していることもあるが、標準ライブラリの仕様もほぼ必ず存在し、その言語の実装には標準ライブラリの実装もほぼ必ず付属する。標準ライブラリには、典型的なアルゴリズム、データ構造、入出力機構などが含まれることが多い。
ユーザーから見れば、標準ライブラリも言語の一部だが、設計者から見れば別の実体である。言語仕様には必ず実装しなければならない部分が定義されており、標準化された言語の場合、それには標準ライブラリも含まれる。言語とその標準ライブラリの境界は、言語によって様々である。実際、言語によっては一部の言語機能が標準ライブラリなしでは使えないこともある(たとえば累乗の演算子がある言語があるが、それのコンパイル結果はその言語の多くの処理系で関数呼出であろう。それが、言語仕様として標準ライブラリの該当する関数を呼び出すよう決められているような場合は「一部の言語機能が標準ライブラリなしでは使えない」ということになる)。
マクロもライブラリに含まれることも多い。たとえばC言語の標準には、いくつかの名前が関数ではなくマクロで提供されるかもしれない、といったような規定などがある。またLisp系の言語では、いわゆる特殊形式の多くが言語組込ではなくマクロでも実装可能であり、ifとcondのようにどちらか片方は必要だが、片方があればもう片方はマクロにできる、といったようなものもある。Schemeの標準規格は、どれを言語組込とし、どれをマクロとするか、ほとんどを処理系実装者の自由に任せている。
プログラミング言語の実装は、プログラミング言語処理系と呼ばれる。コンパイラは、ソースコードなどの入力を中間表現などの、より解釈実行しやすい表現に変換する処理系である。また、インタプリタは、入力されたプログラムを解釈実行する処理系である(ハードウェアのプロセッサは、機械語を解釈実行するインタプリタである、と見ることができる)。
コンパイラとインタプリタの関係は、理論的には二村射影により定式化されている。
なお、「大きく分けて2つの方法がある。コンパイラとインタプリタである。一般にある言語をコンパイラとインタプリタの両方で実装することが可能である。」などといったように(従来書かれた通俗的解説書などには大変多いが)理解していると、Javaなど近年の多くの言語処理系のスタイルが全くわからない、ということになる。
(機械語にまで変換するもののみを指してコンパイラと呼びたがる向きが一部にあり、その立場にもある程度は理もあるのだが、そうするとJavaの一般的な実装を指す用語が無くなる)
「コンパイラの出力したものをインタプリタで実行する方式は、コンパイラとインタプリタの区別が曖昧な場合もある。」などという変な説明をする者もいるが、前述したように、そもそも間違った2分法で考えているから、そのような変な考え方になるのである。
一般に、機械語に変換したもの(実行ファイル)を直接ハードウェアで実行する方が、インタプリタで実行するよりもずっと高速である。インタプリタでの実行を改善する技法として、実行時コンパイラなどの動的コンパイル手法がある。
新たなプログラミング言語が開発される度に機能が追加され、プログラマはハードウェアの命令からより遠い形でアイデアを表現できるようになっていった。プログラミングをハードウェアから分離することで、プログラマの生産性は向上する。
毎年のように新たなプログラミング言語が作り出されている。2008年2月時点で、「コンピュータ言語辞典」には8,152種のプログラミング言語が記載されていた。
過去のプログラミング言語のなかの欠点と見なされた部分を解消するために、新たなプログラミング言語が構想され、作られてきた歴史がある。また多様なプログラミング言語が生み出される背景には、さまざまな事情があり、ハードウェアが時代とともに変化してきたことや、プログラミング言語というテクノロジーやコンピュータサイエンスの発展も影響しており、下のような諸事情もある。
プログラムと言っても、個人が自分だけのために趣味で書く数行から数十行程度の短いプログラム(やスクリプト)から、数百人のプログラマが協働して企業の大規模なシステムのために書く長大なプログラムまで、様々なプログラムがある。