プログラミング言語

プログラミング言語（プログラミングげんご、英語: programming language）とは、コンピュータに対して命令を行うために考案された、正確に定義された記号と規則からなるコンピュータ言語である^[1]。以前は、しばしばプログラム言語と表記された。プログラミング言語を使って行う作業のことを「プログラミング」といい、プログラミングをする人（あるいはそれを職業にしている人）のことを「プログラマ」という。

プログラミング言語には、関数名や構文名などに既存の自然言語（英語やフランス語など）の語彙・文法を流用している「アポステリオリ言語」と、それらを一切流用せずに完全オリジナルな語彙・文法だけで作られた「アプリオリ言語」の2種類が存在する。アプリオリ言語は狭義の人工言語であり、そのプログラマがどの自然言語を母語としているかによって習得に有利不利が生じることがないという特徴を持っている。（#その他の分類法）

プログラミング言語が記述されたもののことを総称して「ソースコード」といい、ソースコードをコンパイルしてできたもののことを「プログラム」という。ソースコードは、原則として文字列や文章の形式を取る（#構文）。

プログラミング言語は、情報を組織し処理するタスクについての理解を容易にし、アルゴリズムを正確に表現することができる。特に、チューリング完全であることが特徴である^[2]。

言語仕様とプログラムとその入力データの組合せで、そのプログラムを実行したときの結果（外部から観測される振る舞い）が完全に指定できなければならない。

プログラミング言語は構文規則（自然言語に関する言語学で言う統語論の規則に類似したもの）と意味規則（自然言語の意味論に類似した規則）で定義される。形式的ないし非形式的（自然言語による）な仕様が（構文規則は形式的で、意味規則はそうでない、というものが多い）実装とは独立した文書で示される言語もあれば、実装のみの言語もある。

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

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

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

過去のプログラミング言語のなかの欠点と見なされた部分を解消するために、新たなプログラミング言語が構想され、作られてきた歴史がある。また多様なプログラミング言語が生み出される背景には、さまざまな事情があり、ハードウェアが時代とともに変化してきたことや、プログラミング言語というテクノロジーやコンピュータサイエンスの発展も影響しており、下のような諸事情もある。

• プログラムと言っても、個人が自分だけのために趣味で書く数行から数十行程度の短いプログラム（やスクリプト）から、数百人のプログラマが協働して企業の大規模なシステムのために書く長大なプログラムまで、様々なプログラムがある。
• プログラミング言語の記述に簡潔さを求め、可読性が高いことを求め、バグが入り込みにくい記述を好むプログラマの方が多く、世の中では一般的である（特に、業務として、ミスの少ないプロの仕事としてプログラミングを行わなければいけない職業的プログラマで多い）一方で、ごちゃごちゃして難読で、一名で書くならともかく複数名でプログラムを書くと高頻度で誤読やバグを招きがちな記述でもあまり気にしなかったり面白がる趣味的なプログラマも一部にいる。
• プログラムが搭載されるシステムも多様で、マイクロコントローラ、組み込みシステムから汎用デスクトップPC、GPUそしてスーパーコンピュータまで様々あり、それぞれのシステムのハードウェアの特性や制約に合ったプログラムやプログラミング言語がある。
• もともとプログラミング言語はもっぱら大学のコンピュータサイエンスの研究室や大手企業の研究所などの奥深くばかりで開発されていたのだが、ここ数十年では個人が趣味的に新しいプログラミング言語を構想しそのコンパイラを自分で書くための書籍なども時折出版されるようになり、つまり世の中の普通の人が新たなプログラミング言語を独自に作成するためのノウハウも広まってハードルが次第に下がってきている。

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

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

ひとつの分類法としては（そして計算機科学や情報処理技術者などの教科書で、まっさきに一種の定番のように挙げてある分類方法としては）、機械寄り（CPU寄り）か人間（の思考）寄りか、で分類する方法であり、低水準言語 / 高水準言語 と分類する方法である。低級言語 / 高級言語 ともいう。

低水準言語の例としては、機械語の「命令コード」^{[注釈 2]}と1対1に対応する「命令語」^{[注釈 3]}を用いてプログラミングを行うアセンブリ言語がある（機械語も低水準言語のひとつに数える場合もある。）。

対比される高水準言語の例としてはPerl、Visual Basic、LISP、PHP、Java、Pythonなどを挙げることができる（なお、境界はやや曖昧で、C言語はかつては「高水準言語」と見なされていたが、その後それよりもレベルの高い高水準言語が多数登場したので、今日ではメモリ管理すらしないC言語は「低水準言語」に分類されることもある。）。

他の分類法としては、実行方法によってプログラミング言語を分類する方法もあり、インタプリタ方式言語（英: interpreted language） / コンパイラ方式言語（コンパイル方式言語、英: compiled language）と分類する方法である。

インタプリタ方式言語の例としてはPHPやRubyを挙げることができる。コンパイラ方式言語の例としてはC言語、C++、Erlang、Haskell、Rust、Go、FORTRAN、COBOLなどを挙げることができる。なお言語によってはインタプリタ方式で実行でき、かつコンパイル方式で実行することができるものもある。そして「一応、どちらの方法でも実行できるが、基本はコンパイル方式」などという場合もあるので、やや分類が曖昧になる場合がある。コンパイル方式でしか実行できない言語をわざわざ指さなければならない場合に「純コンパイル方式言語（英: pure compiled language）」などと分類する人もいる^[5]。

なおJavaはバイトコードにコンパイルをしてから実行するので、一応「コンパイル方式」に分類することも可能ではある。しかしJavaは、実行時コンパイラ (JIT) とJava仮想マシンを使用するので、しばしば「コンパイル方式とインタープリタ方式の中間的な方式」と指摘され、曖昧な位置づけである。

この他にも、以下のような分類法が存在する。

• アポステリオリ言語 / アプリオリ言語

アプリオリ言語の代表例は、APL、Brainfuck、Emojicode、G（英語版）、Hoon（英語版）、J、Light Pattern、Mouse（英語版）、Piet、プランカルキュール、Whitespaceなど。

• 汎用プログラミング言語 / 事務計算用プログラミング言語 / 科学技術計算用プログラミング言語

汎用プログラミング言語の代表例は、Java、C Sharp、Python^[6]、Visual Basic、Rubyなど。

• 手続き型言語 / 非手続き型言語

手続き型言語の代表例は、FORTRAN、ALGOL、C言語、COBOL、BASIC、Pascalなど。

• オブジェクト指向言語 / 非オブジェクト指向言語

• 構造化プログラミング言語 / 非構造化プログラミング言語

• 並行言語 / 非並行言語

スレッドを同時に複数個生成・管理できる言語を並行言語（もしくは並行性言語）、そうでない言語を非並行言語（もしくは非並行性言語）という。

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

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

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

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

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

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

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

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

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

• APL - 配列プログラミングを導入した言語。関数型プログラミングにも影響を与えた^[9]。
• PL/I (NPL) - FORTRANとCOBOLの長所を取り入れて1960年代初期に設計された。
• Simula - 世界初（1960年代）のオブジェクト指向プログラミングを採用した言語。1970年代中頃には純粋なオブジェクト指向言語であるSmalltalkが登場した。
• C言語 - 1969年から1973年にかけてシステムプログラミング言語として開発され、現在でもよく使われている^[10]。
• Prolog - 1972年に設計された論理プログラミング言語。
• ML - 1978年に開発された言語で、LISPをベースとした静的型付け関数型言語の先駆けとなった。

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

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

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

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

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

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

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

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

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

下記はLISPの構文の一部分である。

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

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

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

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

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

以下のLISPのコード断片は構文上は正しいが、意味的には問題がある。変数 employees には従業員データのリストを入れるべきものであるが、employees は実際には空（nil）なので、employees がリストであることを前提に、employees の後続部分を求める式 (cdr employees) は評価できずエラーになる。

(let ((employees nil))   (cdr employees)) 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

形式意味論（プログラム意味論の記事も参照）で意味論を記述した例として Standard ML^[18] や Scheme^[19] がある。

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

• その言語の処理系のリファレンス実装やモデル実装として示されているもの
  • その言語のコンパイラ（FORTRAN）
  • その言語のインタプリタ（Ruby（cruby、ただしRubyの標準化以前の場合））
  • 対象言語自身で書かれることもある（例えば、LISP や Prolog や ANSI REXX^[20]）en:Meta-circular evaluator も参照のこと。

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

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

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

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

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

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

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

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

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

• TIOBE Index

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

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

このあたりの歴史的に錯綜した議論は、結局のところ「コンピュータを活用するにはプログラミングが必要であり、プログラミングはプログラミング言語で行われる」というある種の教条（ドグマ）が、次の2つの事象に分解されることで無意味な議論になった。すなわち「コンピュータをほどほどに活用する程度のことならば、各種アプリケーションソフトウェアや自然言語認識や自然言語処理技術の活用など（スマートスピーカーなど）により、利用者が自分でプログラミングすることは必ずしも必要ではなくなった」ということと「コンピュータのより徹底した活用、具体的にはそういった自然言語認識や自然言語処理のシステムそのものを作るには、プログラミングが必要ということは全く相変わらずであり、プログラミング言語の重要性は増えこそすれ、減りはしない」ということである。

自然言語との違い

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

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

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

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

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

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

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

なおプログラミングへの応用も想定して設計されたロジバンのように、人間の言語とプログラミング言語の中間に位置するものがある。

古い規格ではあるが日本産業規格の JIS X 3000 シリーズの規格名称では、全て「プログラム言語」になっている（例： JIS X 3001 プログラム言語 Fortran、JIS X 3014 プログラム言語 C++）ため、それに合わせてプログラム言語と表記されることもあるが、英語では programming language であるため、それに合わせればプログラミング言語となり、近年ではプログラミング言語と表記されることが多い。^{[注釈 9]}

なお言語名が「C」や「D」のように1文字の名称の場合、そのままの表記では文章中に埋没してしまい直接読んでいる利用者にとっては判別しづらいなどの不都合がある。それを事前に防ぐために、たとえ登録されている正式名称があくまで「C」などと一文字であっても、通常の文章中で表記および執筆するまたは校正時に、技術書なども含めて、しばしば「C言語」などと文字の後ろに「言語」を添えて表記される^[26]。

出典は列挙するだけでなく、脚注などを用いてどの記述の情報源であるかを明記してください。 記事の信頼性向上にご協力をお願いいたします。（2021年4月）

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

• プログラミング言語一覧

ウィキメディア・コモンズには、プログラミング言語に関するメディアがあります。

• TIOBE Index - プログラミング言語の番付け
• 99 Bottles of Beer 同じプログラムを多数の言語で実装したコードを公開
• Computer Languages History graphical chart
• Dictionary of Programming Languages
• History of Programming Languages（HOPL）
• Open Directory - Computer Programming Languages
• Syntax Patterns for Various Languages
• The Evolution of Programming Languages by Peter Grogono
• JIS（日本産業規格）X3（プログラム言語）
• 『プログラミング言語』 - コトバンク