プログラミング言語

チェック済み
ページは変更保留のため保護されています

C言語で書かれたコンピュータプログラムのソースコード。灰色の線は、人間向けにプログラムを説明するコメントです。コンパイルし実行すると、「 Hello, world! 」という出力が得られます。

プログラミング言語は、コンピュータプログラムを表現するために設計された言語です。[ 1 ]

プログラミング言語を使用すると、通常、ソフトウェアを人間が読める形式で記述できます。

プログラムの実行には実装が必要です。プログラミング言語の実装には主に2つのアプローチがあります。1つはコンパイルで、プログラムは事前に機械語にコンパイルされます。もう1つは解釈で、プログラムは直接実行されます。これら2つの極端なアプローチに加えて、ジャストインタイムコンパイルバイトコードインタープリタなどのハイブリッドなアプローチを採用する実装もあります。 [ 2 ]

プログラミング言語の設計はコンピュータアーキテクチャに強く影響されており、ほとんどの命令型言語は広く普及しているフォン・ノイマン・アーキテクチャに基づいて設計されています。[ 3 ]初期のプログラミング言語はハードウェアと密接に結びついていましたが、現代の言語では、より少ない労力でより良いソフトウェアを実現するために、 抽象化によってハードウェアの詳細を隠すことがよくあります。

プログラミング言語は、人間同士のアイデアの伝達を可能にするという点で、自然言語とある程度の類似点があります。つまり、プログラムは一般的に人間が読めるものであり、複雑なアイデアを表現することができます。しかし、プログラミング言語が表現できるアイデアの種類は、最終的には計算の領域に限定されます。[ 4 ]

コンピュータ言語という用語は、プログラミング言語と互換的に使用されることがある[ 5 ]が、これらは異なる概念であると主張する人もいる。プログラミング言語はコンピュータ言語のサブセットであると主張する人もいる[ 6 ] 。コンピュータ言語という言葉を、プログラミング言語とはみなされないコンピューティングで使用される言語の分類に使用する人もいる。プログラミング言語を抽象機械をプログラミングするための理論的構成と見なし、コンピュータ言語を、有限のハードウェアリソースを持つ物理的なコンピュータ上で実行されるそのサブセットと見なす人もいる[ 7 ] 。

ジョン・C・レイノルズは、形式仕様言語は実行を目的とした言語であると同時にプログラミング言語でもあると強調する。彼は、コンピュータの動作に影響を与えるテキストやグラフィカルな入力形式は、チューリング完全ではないことが多いにもかかわらず、プログラミング言語であると主張し、プログラミング言語の概念に関する無知が入力形式における多くの欠陥の原因であると指摘している。[ 8 ]

歴史

初期の開発

最初のプログラム可能なコンピュータは1940年代に発明され、同時に最初のプログラミング言語も発明されました。[ 9 ]初期のコンピュータは、第一世代プログラミング言語(1GL)、すなわち機械語(プロセッサが直接実行できる単純な命令)でプログラムされていました。このコードはデバッグが非常に難しく、異なるコンピュータシステム間での移植性もありませんでした。 [ 10 ]プログラミングの容易さを向上させるために、アセンブリ言語(または第二世代プログラミング言語、 2GL)が発明されました。これは機械語から派生したもので、人間にとってプログラムをより理解しやすいように設計されていましたが、移植性は向上しませんでした。[ 11 ]

当初、ハードウェア資源は希少かつ高価でしたが、人的資源は安価でした。そのため、扱いにくく、時間はかかりますが、ハードウェアに近いため効率が高い言語が好まれました。[ 12 ]高級プログラミング言語第3世代プログラミング言語、 3GL)の導入はプログラミングに革命をもたらしました。これらの言語はハードウェアの詳細を抽象化し、代わりに人間がより簡単に理解できるアルゴリズムを表現できるように設計されました。たとえば、算術式を記号表記で記述し、後でハードウェアが実行できるマシンコードに変換できるようになりました。[ 11 ] 1957年、Fortran(FORmula TRANslation)が発明されました。最初のコンパイル型高級プログラミング言語と見なされることが多い[ 11 ] [ 13 ] Fortranは21世紀になっても使用され続けています。[ 14 ]

1960年代と1970年代

1957年、浮動小数点演算をサポートした最初のハードウェアであるIBM 704メインフレームを使用している2人。Fortranこのマシン用に設計されました。[ 15 ] [ 14 ]

1960年頃、最初のメインフレーム(汎用コンピュータ)が開発されましたが、専門家しか操作できず、非常に高価でした。データと命令はパンチカードで入力されたため、プログラムの実行中は入力できませんでした。そのため、当時開発された言語は最小限のインタラクションで設計されています。[ 16 ]マイクロプロセッサの発明後、1970年代のコンピュータは劇的に安価になりました。[ 17 ]新しいコンピュータはより多くのユーザーインタラクションを可能にし、これは新しいプログラミング言語によってサポートされました。[ 18 ]

1958年に実装されたLispは、最初の関数型プログラミング言語でした。[ 19 ] Fortranとは異なり、再帰条件式をサポートし、[ 20 ]ヒープ上の動的メモリ管理と自動ガベージコレクションも導入しました。[ 21 ]その後数十年間、Lispは人工知能アプリケーションを支配しました。[ 22 ] 1978年には、別の関数型言語であるMLが推論型と多態的パラメータを導入しました。[ 18 ] [ 23 ]

ALGOL (ALGOrithmic Language) は 1958 年と 1960 年に発表されて以来、 [ 24 ]アルゴリズムを記述するためのコンピューティング文献の標準となった。商業的成功は限られていたが、CPascalAdaC++JavaC#などのほとんどの人気の命令型言語は、直接的または間接的に ALGOL 60 から派生している。[ 25 ] [ 14 ]後のプログラミング言語に採用された ALGOL の革新の中には、移植性の向上と文脈自由 BNF 文法の初の使用があった。[ 26 ]オブジェクト指向プログラミング(サブタイプ動的ディスパッチ継承を含む)をサポートした最初の言語である Simulaも ALGOL から派生し、商業的成功を収めた。[ 27 ] ALGOL の別の派生言語である C は、21 世紀になっても人気が続いている。柔軟なポインタ操作によってもたらされるそのパワーと効率性は、正しいコードを書くのをより困難にするという代償を伴います。[ 18 ]

1972年に設計されたPrologは、形式論理記法を使用してコンピュータと通信する最初の論理プログラミング言語でした。 [ 28 ] [ 29 ]論理プログラミングでは、プログラマーは望ましい結果を指定し、インタープリターがそれを達成する方法を決定できるようにします。[ 30 ] [ 29 ]

1980年代から2000年代

プログラミング言語の教科書の小セレクション

1980年代には、パーソナルコンピュータの発明により、プログラミング言語の役割が一変しました。[ 31 ] 1980年代に導入された新しい言語には、 Cのプログラムをコンパイルできるだけでなく、クラス継承もサポートするCのスーパーセットであるC++が含まれていました。[ 32 ] Adaやその他の新しい言語では、並行性のサポートが導入されました。[ 33 ]日本政府は、論理プログラミング構造に並行性のサポートを追加した、いわゆる第5世代言語に多額の投資を行いましたが、これらの言語は、並行性をサポートする他の言語よりも性能が劣っていました。[ 34 ] [ 35 ]

1990年代のインターネットワールドワイドウェブの急速な成長により、ウェブページネットワークをサポートする新しいプログラミング言語が導入されました。[ 36 ] C++をベースにシステム間の移植性とセキュリティの向上を目的として設計されたJavaは、これらの機能が多くのインターネットアプリケーションに不可欠であったため、大きな成功を収めました。[ 37 ] [ 38 ]もう1つの発展は、既存のアプリケーションを調整する小さなプログラムを迅速に作成するために設計された動的型付けスクリプト言語PythonJavaScriptPHPRuby)でした。HTMLの統合により、サーバー上でホストされるウェブページの構築にも使用されています。[ 39 ] [ 40 ]

2000年代から現在

2000年代には、広く普及した新しいプログラミング言語の開発が減速しました。[ 41 ]イノベーションの1つはサービス指向プログラミングで、コンポーネントがネットワークで接続された分散システムを活用するように設計されました。サービスはオブジェクト指向プログラミングのオブジェクトに似ていますが、別のプロセスで実行されます。[ 42 ] C#F#は、命令型プログラミングと関数型プログラミングのアイデアを相互に取り入れました。 [ 43 ] 2010年以降、RustGoSwiftZigCarbon などのいくつかの新しい言語が、歴史的にCが使用されてきたパフォーマンスクリティカルなソフトウェアをめぐって競争しました。[ 44 ]新しいプログラミング言語のほとんどは静的型付けを使用していますが、 Juliaなどのいくつかの新しい言語は動的型付けを使用しています。[ 45 ]

新しいプログラミング言語の中には、ScratchLabVIEWのようにビジュアルプログラミング言語に分類されるものもあります。また、 Ballerinaのようにテキストプログラミングとビジュアルプログラミングの両方の用途を持つ言語もあります。[ 46 ] [ 47 ] [ 48 ]また、この傾向は、 GoogleBlocklyのような新しいVPLの開発を支援するプロジェクトの開発にもつながっています。[ 49 ] UnrealUnityのような多くのゲームエンジンもビジュアルスクリプティングのサポートを追加しました。[ 50 ] [ 51 ]

意味

言語は構文(形式) とセマンティクス(意味) の観点から定義することができ、多くの場合、正式な言語仕様を通じて定義されます。

構文

インセットトークン化によるPython コード解析ツリー
構文のハイライト表示は、プログラマーがソースコードの要素を認識するのを支援するためによく使用されます。上記の言語はPythonです。

プログラミング言語の表面的な形式は、構文と呼ばれます。ほとんどのプログラミング言語は純粋にテキストベースで、自然言語の書き言葉のように、単語、数字、句読点を含むテキストのシーケンスを使用します。一方、一部のプログラミング言語はグラフィカルで、記号間の視覚的な関係性を用いてプログラムを記述します。

言語の構文は、構文的に正しいプログラムを構成する記号の可能な組み合わせを記述します。記号の組み合わせに与えられる意味は、セマンティクス(形式的なもの、またはリファレンス実装にハードコードされたもの)によって処理されます。ほとんどの言語はテキスト形式であるため、この記事ではテキスト構文について説明します。

プログラミング言語の構文は通常、正規表現語彙構造)とバッカス・ナウア記法文法構造)の組み合わせで定義されます。以下はLispに基づく簡単な文法です。

::=アトム | リスト アトム ::=数値 | シンボル 数値 ::= [+-]?['0'-'9']+ シンボル ::= ['A'-'Z''a'-'z'].* リスト ::= '(' 式* ')' 

この文法では次のことを指定します。

  • アトムまたはリストのいずれかです。
  • 原子数字または記号のいずれかです。
  • 数値1 つ以上の 10 進数字の連続であり、オプションで先頭にプラス記号またはマイナス記号が付きます。
  • シンボルは、文字の後に0個以上の任意のアルファベット文字(空白を除く)が続くものです。
  • リスト、内部に0 個以上のが含まれる、対応する括弧のペアです。

以下は、この文法における 適切なトークン シーケンスの例です12345()(a b c232 (1))

構文的に正しいプログラムがすべて意味的に正しいわけではありません。構文的に正しいプログラムであっても、言語の規則に照らして不完全な形式になっているものが多く、言語仕様や実装の健全性によっては、翻訳時または実行時にエラーが発生する可能性があります。場合によっては、そのようなプログラムは未定義の動作を示すこともあります。ある言語においてプログラムが適切に定義されている場合でも、それを書いた人が意図しない意味を持つことがあります。

自然言語を例に挙げると、文法的に正しい文に意味を割り当てることができない場合や、文が間違っている場合があります。

  • 無色の緑のアイデアが激しく眠る。」は文法的には正しいが、一般的に受け入れられている意味はありません。
  • 「ジョンは既婚の独身者です。」は文法的には正しいが、真実ではない意味を表現している。

次のC 言語フラグメントは構文的には正しいですが、意味的に定義されていない操作を実行します (この操作は、*p >> 4複合型の値に対しては意味がなく、の値がNULL ポインターであるp->imため定義されていません)。 p

複素数* p = NULL ;複素数abs_p = sqrt ( * p >> 4 + p -> im );

最初の行の型宣言を省略すると、pコンパイル時に未定義変数のエラーが発生します。ただし、型宣言は意味情報のみを提供するため、プログラムは構文的には正しいままです。

プログラミング言語を指定するのに必要な文法は、チョムスキー階層における位置によって分類できる。ほとんどのプログラミング言語の構文はタイプ2文法、すなわち文脈自由文法を用いて指定できる。[ 52 ] PerlやLispなどの一部の言語には、構文解析段階での実行を可能にする構文要素が含まれている。プログラマがパーサの動作を変更できる構文要素を持つ言語では、構文解析は決定不能な問題となり、構文解析と実行の区別があいまいになることが多い。[ 53 ]一般的な計算を含む可能性のあるLispのマクロシステムやPerlのブロックとは対照的にBEGIN、Cのマクロは単なる文字列の置換であり、コードの実行を必要としない。[ 54 ]

セマンティクス

セマンティクスとは、言語の構文に準拠したコンテンツの意味を指します。

静的セマンティクス

静的意味論は、標準的な構文形式では表現が困難または不可能な、有効なテキストの構造に対する制約を定義します。[ 55 ]コンパイル言語の場合、静的意味論には基本的にコンパイル時にチェックできる意味規則が含まれます。例としては、すべての識別子が使用前に宣言されているかどうか(そのような宣言を必要とする言語の場合)や、 case文の分岐のラベルが異なっているかどうかのチェックなどがあります。[ 56 ]識別子が適切なコンテキストで使用されているかどうか(関数名に整数を追加しないなど)や、サブルーチン呼び出しの引数の数と型が適切かどうかのチェックなど、このタイプの多くの重要な制約は、型システムと呼ばれるロジックで規則として定義することで強制できます。データフロー解析などの他の形式の静的解析も、静的意味論の一部となる場合があります。JavaやC#などのプログラミング言語にはそれぞれの静的意味論の一部として、データフロー解析の一種である確定代入解析があります。 [ 57 ]

動的セマンティクス

データが指定されると、機械はデータに対する操作を実行するように指示されなければならない。例えば、意味論は式が値に評価される戦略や、制御構造が条件付きで文を実行する方法を定義することができる。言語の動的意味論(実行意味論とも呼ばれる)は、言語の様々な構成要素がいつどのようにプログラムの動作を生成するかを定義する。実行意味論を定義する方法は多数ある。自然言語は、実際によく使われる言語の実行意味論を指定するためによく使われる。かなりの学術研究がプログラミング言語の形式意味論に費やされており、これにより実行意味論を形式的に指定することができる。この研究分野の成果は、学術界以外ではプログラミング言語の設計と実装への応用は限られている。[ 57 ]

特徴

言語は、プログラマーがソフトウェアを開発するための機能を提供します。以下に、注目すべき機能をいくつか説明します。

型システム

データとは、許容される値と、それらの値に対して実行できる演算のセットです。[ 58 ]各プログラミング言語の型システムは、どのようなデータ型が存在するか、の型、そしてその言語における型の等価性型の互換性がどのように機能するかを定義します。 [ 59 ]

型理論によれば、すべての演算の仕様がその演算を適用できるデータの型を定義している場合、その言語は完全に型付けされているとされる。[ 60 ]一方、ほとんどのアセンブリ言語などの型付けされていない言語では、任意のデータ(一般的には様々な長さのビットのシーケンス)に対して任意の演算を実行できる。[ 60 ]実際には、完全に型付けされている言語は少ないが、ほとんどの言語はある程度の型付けを提供している。[ 60 ]

異なる型(整数浮動小数点数など)はそれぞれ異なる値を表現するため、ある型が期待されるときに別の型を使用すると、予期しない結果が発生します。型チェックでは、通常コンパイル時にこのエラーがフラグ付けされます(実行時の型チェックはよりコストがかかります)。[ 61 ]強い型付けでは、変数が明示的に別の型にキャストされない限り、型エラーは常に検出されます。弱い型付けは、言語が暗黙的なキャストを許可している場合に発生します。たとえば、プログラマが明示的に型変換を行わなくても、異なる型の変数間で操作できるようにする場合などです。この型強制が許容されるケースが多ければ多いほど、検出される型エラーは少なくなります。[ 62 ]

一般的にサポートされているタイプ

初期のプログラミング言語では、整数(符号付きと符号なし)や浮動小数点数(整数以外の実数の演算をサポートするため)などの組み込みの数値型のみをサポートしていることが多かった。ほとんどのプログラミング言語は、プログラマが必要とするサイズと精度に応じて、複数のサイズの浮動小数点数(floatおよびdouble と呼ばれることが多い)と整数をサポートしている。整数を、それを表すには小さすぎる型に格納すると、整数オーバーフローが発生する。符号付き型で負の数を表す最も一般的な方法は2 の補数であるが、1 の補数も使用される。[ 63 ]その他の一般的な型には、ブール型(真または偽)や文字型(伝統的に 1バイトで、すべてのASCII文字を表すのに十分)がある。[ 64 ]

配列は、多くの言語において、要素が単一の固定長型で構成されている必要があるデータ型です。他の言語では、配列は他の場所に格納されているデータへの参照として定義され、さまざまな型の要素をサポートします。[ 65 ]プログラミング言語によっては、文字と呼ばれる複数の文字のシーケンスが、文字の配列または独自のプリミティブ型としてサポートされる場合があります。[ 66 ]文字列は固定長または可変長にすることができ、柔軟性が向上しますが、ストレージスペースの増加と複雑さが増します。[ 67 ]サポートされる可能性のあるその他のデータ型には、リスト[ 68 ]キーを介してアクセスされる連想配列(順序なし)[ 69 ] データが順序付けられた構造内の名前にマッピングされるレコード、 [ 70 ]タプル(レコードに似ていますが、データフィールドに名前がありません)などがあります。[ 71 ]ポインタはメモリアドレスを格納し、通常はヒープ上の他のデータが格納されている場所を参照します。[ 72 ]

最も単純なユーザー定義型順序型(列挙型とも呼ばれる)で、その値は正の整数の集合にマッピングできます。[ 73 ] 1980年代半ば以降、ほとんどのプログラミング言語は抽象データ型もサポートしています。抽象データ型では、データの表現と操作はユーザーから隠されており、ユーザーはインターフェースにのみアクセスできます。[ 74 ]データ抽象化の利点には、信頼性の向上、複雑さの軽減、名前の衝突の可能性の低減、クライアントがコードを変更することなく基礎となるデータ構造を変更できることなどがあります。[ 75 ]

静的型付けと動的型付け

静的型付けでは、すべての式の型はプログラムの実行前、通常はコンパイル時に決定されます。[ 60 ]広く使用されている静的型付けプログラミング言語のほとんどは、変数の型を明示的に指定する必要があります。一部の言語では型は暗黙的です。その1つの形態として、コンパイラがコンテキストに基づいて型を推論できます。暗黙的な型付けの欠点は、エラーが検出されない可能性があることです。[ 76 ]完全な型推論は、伝統的にHaskellMLなどの関数型言語に関連付けられてきました。[ 77 ]

動的型付けでは、変数に型が付与されるのではなく、変数にエンコードされた値のみが付与されます。単一の変数を異なる型の値に再利用できます。これによりプログラマーの柔軟性は高まりますが、信頼性が低下し、プログラミング言語のエラーチェック能力も低下します。[ 78 ]一部の言語では、通常の静的型付け規則の例外として、任意の型の値を代入できる共用型の変数が認められています。[ 79 ]

同時実行性

コンピューティングでは、複数の命令を同時に実行することができます。多くのプログラミング言語は、命令レベルおよびサブプログラムレベルの並行性をサポートしています。[ 80 ] 21世紀になると、コンピュータの処理能力はプロセッサの追加によって向上することが多くなり、プログラマはパフォーマンスを向上させるために複数のプロセッサを同時に使用するソフトウェアを設計する必要が生じました。[ 81 ] PythonRubyなどのインタープリタ型言語は、複数のプロセッサの同時使用をサポートしていません。[ 82 ]他のプログラミング言語では、セマフォを使用して主要な命令の実行順序を制御したり、モニターを介して共有データへのアクセスを制御したり、スレッド間でメッセージパッシングを有効にしたりすることで、異なるスレッド間で共有されるデータの管理をサポートしています。[ 83 ]

例外処理

多くのプログラミング言語には例外ハンドラが含まれています。これは実行時エラーによってトリガーされるコードの一部で、主に2つの方法でエラーに対処できます。[ 84 ]

一部のプログラミング言語では、例外が発生したかどうかに関係なく、コードブロックを実行することをサポートしています。これはファイナライズと呼ばれます。[ 85 ]

例外処理能力の向上とパフォーマンスの低下の間にはトレードオフがあります。[ 86 ]例えば、配列のインデックスエラーは一般的ですが、[ 87 ] C言語ではパフォーマンス上の理由からそれらのエラーはチェックされません。[ 86 ]プログラマーはユーザー定義の例外をキャッチするコードを書くことができますが、プログラムが煩雑になる可能性があります。C言語などの一部の言語の標準ライブラリは、例外を示すために戻り値を使用します。[ 88 ]一部の言語とそのコンパイラーには、エラー処理機能を一時的または永続的にオン/オフにするオプションがあります。[ 89 ]

設計と実装

プログラミング言語の設計に最も大きな影響を与えたものの一つは、コンピュータアーキテクチャです。最も一般的に使用されている命令型言語は、最も一般的なデジタルコンピュータアーキテクチャであるフォン・ノイマン・アーキテクチャ上で良好なパフォーマンスを発揮するように設計されました。 [ 90 ]フォン・ノイマン・アーキテクチャでは、メモリはデータと命令の両方を格納しますが、データに対する命令を実行するCPUは別個に存在し、データはCPUとの間でパイプ処理されます。これらの言語の中心的な要素は、変数、代入、そして反復処理です。反復処理は、これらのマシンでは再帰よりも効率的です。 [ 91 ]

多くのプログラミング言語は、ゼロから設計され、新たなニーズに合わせて変更され、他の言語と統合されてきました。そして、最終的に使われなくなったものも多くあります。1950年代のプログラミング言語の誕生は、あらゆるマシンと用途に適した汎用プログラミング言語を作りたいという願望によって促進され、異なるコンピュータごとにコードを書く必要性を回避しました。[ 92 ] 1960年代初頭までに、コードが書かれる様々な目的に応じて異なる要件が課せられたため、汎用言語という概念は否定されました。[ 93 ]

トレードオフ

プログラミング言語に求められる特性としては、読みやすさ、書きやすさ、信頼性などが挙げられる。[ 94 ]これらの特性により、プログラマーの言語トレーニングにかかる​​コスト、その言語でプログラムを作成して保守するために必要な時間、コードのコンパイルにかかるコストを削減し、実行時のパフォーマンスを向上させることができる。[ 95 ]

  • 初期のプログラミング言語では、可読性よりも効率性が優先されることが多かったが、1970年代以降、可読性は重要性を増した。同じ結果を得るために複数の演算を行うことは、可読性を損なう可能性がある。また、演算子のオーバーロードによって同じ演算子が複数の意味を持つことも、可読性を損なう可能性がある。[ 96 ]可読性にとって重要なもう一つの特徴は、プログラマが学習しなければならない構文の数を制限する直交性である。 [ 97 ]理解しやすい構文構造と、すぐに理解できる特別な単語も、可読性を支える。[ 98 ]
  • 書きやすさとは、目的の問題を解決するためのコードを書く際の使いやすさのことです。読みやすさに不可欠な機能に加えて、[ 99 ]抽象化(クライアントから詳細を隠すことができるインターフェース)と表現力(より簡潔なプログラムを可能にする)は、プログラマーがコードを書くのに役立ちます。[ 100 ]初期のプログラミング言語はコンピューターの基盤となるハードウェアに非常に密接に結びついていましたが、時間の経過とともに抽象化のサポートが増加し、プログラマーは基盤となるハードウェア命令への単純な翻訳からより離れたアイデアを表現できるようになりました。プログラマーはコンピューターの複雑さにあまり縛られなくなるため、プログラマーの労力は少なく、プログラムはより多くの計算を行うことができます。[ 101 ]ほ​​とんどのプログラミング言語には、よく使用される関数の標準ライブラリが付属しています。[ 102 ]
  • 信頼性とは、プログラムがさまざまな状況で仕様どおりに動作することを意味します。[ 103 ]型チェック例外処理、制限付きエイリアシング(複数の変数名が同じメモリ領域にアクセスする)はすべて、プログラムの信頼性を向上させることができます。[ 104 ]

プログラミング言語の設計にはトレードオフが伴うことが多い。[ 105 ]例えば、信頼性を向上させる機能は通常、パフォーマンスを犠牲にする。[ 106 ]多数の演算子による表現力の向上はコードの記述を容易にするが、可読性を犠牲にする。[ 106 ]

自然言語プログラミングは、プログラミングに専門言語を必要としない方法として提案されてきました。しかし、この目標の実現は未だ遠く、その利点については議論の余地があります。エドガー・W・ダイクストラは、意味のない構造の導入を防ぐためには形式言語の使用が不可欠であるという立場をとりました。[ 107 ]アラン・パーリスも同様にこの考えを否定しました。[ 108 ]

仕様

プログラミング言語の仕様は、言語のユーザー実装者が、ソース コードがその言語で有効なプログラムであるかどうか、また有効なプログラムである場合はどのような動作をするかを合意するために使用できる成果物です。

プログラミング言語の仕様には、次のようないくつかの形式があります。

実装

プログラミング言語の実装とは、プログラムをハードウェアで実行できる機械語に変換することです。この機械語はオペレーティングシステムの助けを借りて実行できます。[ 112 ]製品コードにおける最も一般的な解釈形式はコンパイラによるもので、コンパイラはソースコードを中間レベル言語を経由して実行可能ファイルと呼ばれる機械語に変換します。コンパイルされたプログラムは、他の実装方法よりも高速に実行されます。[ 113 ]一部のコンパイラは、実行可能ファイルの実行時にメモリや計算使用量を削減するためのさらなる最適化を提供できますが、コンパイル時間は長くなります。[ 114 ]

もう1つの実装方法は、プログラムをインタープリタで実行することです。インタープリタは、実行直前にソフトウェアの各行を機械語に変換します。デバッグは容易になりますが、インタープリタの欠点は、コンパイルされた実行ファイルよりも10~100倍遅くなることです。[ 115 ]ハイブリッドインタープリタ方式は、コンパイルの利点とインタープリタの利点を部分コンパイルによって組み合わせたものです。その1つの形態はジャストインタイムコンパイルで、ソフトウェアは事前に中間言語にコンパイルされ、実行直前に機械語に変換されます。[ 116 ]

独自の言語

最も一般的に使用されているプログラミング言語のほとんどは、仕様と実装が完全にオープンであるにもかかわらず、多くのプログラミング言語はプロプライエタリプログラミング言語としてのみ存在し、その実装は単一のベンダーからのみ入手可能です。ベンダーは、そのようなプロプライエタリ言語を自社の知的財産であると主張する場合があります。プロプライエタリプログラミング言語は、通常、ドメイン固有言語または単一製品の内部スクリプト言語です。プロプライエタリ言語の中には、ベンダー内部でのみ使用されるものもあれば、外部ユーザーが利用できるものもあります。

いくつかのプログラミング言語は、プロプライエタリとオープンの境界上に存在します。例えば、オラクル社はJavaプログラミング言語の一部に独自の権利を主張しており、[ 117 ]マイクロソフト社C#プログラミング言語はシステムのほとんどの部分がオープン実装ですが、共通言語ランタイム(CLR)はクローズド環境として存在します。[ 118 ]

多くのプロプライエタリ言語は、そのプロプライエタリな性質にもかかわらず、広く使用されています。例としては、 MATLABVBScriptWolfram Languageなどが挙げられます。一部の言語はクローズドからオープンへと移行することもあります。例えば、Erlangは元々Ericssonの社内用プログラミング言語でした。[ 119 ]

オープンソースプログラミング言語は、オープンサイエンスアプリケーションに特に役立ち、複製とコード共有の能力を高めます。 [ 120 ]

使用

数千種類のプログラミング言語が、主にコンピューティング分野で開発されてきました。[ 121 ] 個々のソフトウェアプロジェクトでは、5つ以上のプログラミング言語が使用されるのが一般的です。[ 122 ]

プログラミング言語は、他のほとんどの人間による表現形式とは異なり、より高い精度と完全性を求めます。自然言語を用いて他者とコミュニケーションをとる場合、人間の書き手や話し手は曖昧な表現や小さな誤りがあっても、意図が理解されることを期待できます。しかし、比喩的に言えば、コンピュータは「指示された通りに行動する」ものであり、プログラマーが意図したコードを「理解」することはできません。言語定義、プログラム、そしてプログラムへの入力の組み合わせは、プログラムの実行時に発生する外部的な動作を、そのプログラムの制御領域内で完全に規定する必要があります。一方、アルゴリズムに関するアイデアは、自然言語とプログラミング言語で記述されたコードを交互に組み合わせた 擬似コードを用いることで、実行に必要な精度を必要とせずに人間に伝えることができます。

プログラミング言語は、データの構成要素と、そのデータに対して自動的に実行される演算や変換を定義するための構造化されたメカニズムを提供します。プログラマーは、言語に存在する抽象化を用いて、計算に関わる概念を表現します。これらの概念は、利用可能な最も単純な要素(プリミティブと呼ばれる)の集合として表現されます。[ 123 ]プログラミングとは、プログラマーがこれらのプリミティブを組み合わせて新しいプログラムを作成したり、既存のプログラムを新しい用途や変化する環境に適応させたりするプロセスです。

コンピュータプログラムは、人間の介入なしにバッチプロセス実行される場合もあれば、ユーザーがインタープリタ対話型セッションコマンドを入力する場合もあります。この場合、「コマンド」とは単にプログラムであり、その実行は連鎖的に行われます。ある言語が、コンパイルすることなくインタープリタ( Unixシェルやその他のコマンドラインインターフェースなど)を介してコマンドを実行できる場合、その言語はスクリプト言語と呼ばれます。[ 124 ]

言語使用の測定

最も広く使用されているプログラミング言語を特定することは困難です。なぜなら、使用法の定義は状況によって異なるからです。ある言語はプログラマーの時間を最も多く占め、別の言語はコード行数が多く、3 つ目の言語は CPU 時間を最も多く消費するかもしれません。一部の言語は特定の種類のアプリケーションで非常に人気があります。たとえば、COBOLは企業のデータ センター、特に大型メインフレームで今でも強い人気があります。[ 125 ] [ 126 ] Fortranは科学技術アプリケーション、Adaは航空宇宙、輸送、軍事、リアルタイム、組み込みアプリケーション、Cは組み込みアプリケーションとオペレーティング システムで使用されています。他の言語も、さまざまな種類のアプリケーションの作成に定期的に使用されています。

言語の人気度を測定するさまざまな方法が提案されていますが、それぞれ測定対象に対する偏りが異なります。

  • 言語に言及している求人広告の数を数える[ 127 ]
  • 言語を教えたり説明したりする書籍の販売数[ 128 ]
  • 当該言語で書かれた既存のコード行数の推定値。公開検索ではあまり見つからない言語については過小評価される可能性がある[ 129 ]
  • Web 検索エンジンを使用して見つかった言語参照 (つまり、言語の名前) の数。

stackify.comは、様々なインターネットサイトからの情報を組み合わせて平均化し、最も人気のある10のプログラミング言語(人気順)を報告しました:JavaCC++PythonC#JavaScriptVB.NETRPHPMATLAB[ 130 ]

2024年6月現在、TIOBEインデックスで測定された上位5つのプログラミング言語は、 PythonC++CJavaC#です。TIOBEは人気度に応じて上位100のプログラミング言語のリストを提供しており、このリストは毎月更新されています。[ 131 ]

IEEE Spectrumのスタッフによると、AIの仕組みによって、現在最も人気のあるプログラミング言語が今後も主流であり続ける可能性があるという。その結果、プログラマーが新しい言語でプログラムを書かなくなるため、新しい言語の人気は高まりにくくなるだろう。[ 132 ]

方言、フレーバー、実装

プログラミング言語やデータ交換言語の方言は、言語の(比較的小さな)バリエーションまたは拡張であり、その本質は変わりません。SchemeForthなどの言語では、実装者により標準が不十分、不適切、または非合法であると見なされることがあるため、標準から逸脱し、新しい方言が作られることがよくあります。他の場合には、方言はドメイン固有言語(多くの場合サブセット)で使用するために作成されます。 Lisp の世界では、基本的なS 式の構文と Lisp のようなセマンティクスを使用するほとんどの言語はLisp の方言と見なされますが、RacketClojureのように方言も大きく異なります。 1 つの言語に複数の方言があることは一般的であるため、経験の浅いプログラマが適切なドキュメントを見つけるのは非常に困難になることがあります。BASIC言語には多くの 方言があります。

分類

プログラミング言語は、以下のような高レベルだが重複する分類に従って説明することができる。[ 133 ]

命令形

命令型プログラミング言語は、順序付けられた一連の操作としてエンコードされたロジックの実装をサポートします。最も広く使用されている言語は命令型に分類されます。[ 134 ]

機能的

関数型プログラミング言語は、与えられたパラメータに関数を逐次適用することをサポートします。その簡潔さと洗練さは多くの研究者に高く評価されていますが、効率性の問題から広く採用されていません。[ 135 ]

論理

論理型プログラミング言語は、プログラマーではなくソフトウェアが命令の実行順序を決定するように設計されています。[ 136 ]

オブジェクト指向

オブジェクト指向プログラミング(OOP)は、データ抽象化継承動的ディスパッチなどの機能によって特徴付けられます。OOPは、ほとんどの一般的な命令型言語と一部の関数型言語でサポートされています。[ 134 ]

マークアップ

マークアップ言語自体はプログラミング言語ではありませんが、プログラミング言語との統合をサポートする場合があります。

特別

他のプログラミング言語と簡単に比較できない特殊用途の言語があります。[ 137 ]

参照

参考文献

  1. ^情報技術 — 語彙
  2. ^ Sebesta, Robert W. (2023). 『プログラミング言語の概念』(第12版). Pearson. pp.  46– 51. ISBN 978-1-292-43682-1
  3. ^ロバート、セベスタ (2022).プログラミング言語の概念: グローバル版(第 12 版、グローバル版)。ハーロウ: ピアソン。 p. 41.ISBN 978-1-292-43682-1
  4. ^ Chauhan, Sharad (2013). 「10.プログラミング言語 - 設計と構成」 University Science Press. p. 235. ISBN 978-93-81159-41-52025年9月10日閲覧自然言語と同様に、プログラミング言語は人間同士の表現とコミュニケーションを促進します。しかし、プログラミング言語は自然言語とは2つの点で異なります。1つは、プログラミング言語は人間と計算機の間でアイデアの伝達も可能にします。2つ目として、プログラミング言語の表現領域は自然言語よりも狭いことです。つまり、プログラミング言語は計算上のアイデアの伝達のみを可能にします。
  5. ^ロバート・A・エドマンズ著『プレンティス・ホール標準コンピュータ用語集』プレンティス・ホール、1985年、91ページ
  6. ^ Pascal Lando、Anne Lapujade、Gilles Kassel、Frédéric Fürst、「 Towards a General Ontology of Computer Programs」、 2015年7月7日アーカイブ ICSOFT 2007、 2010年4月27日アーカイブ、Wayback Machine、pp. 163–170
  7. ^ R. Narasimhan, プログラミング言語とコンピュータ: 統一メタ理論, pp. 189–247 in Franz Alt, Morris Rubinoff (eds.) Advances in Computers, Volume 8, Academic Press, 1994, ISBN 0-12-012108-5、p.215:「[...] コンピュータ言語のモデルは[...] プログラミング言語のモデルと2つの点においてのみ異なります。コンピュータ言語には、有限の数の名前(レジスタ)しか存在せず、それらは有限の数の値(状態)しか取ることができません。そして、これらの状態は他の属性によってさらに区別されることはありません。[著者注] これは自明の理のように聞こえるかもしれませんが、その意味合いは広範囲にわたります。例えば、プログラミング言語のモデルは、特定のパラメータや機能を固定することで、自然にコンピュータ言語のモデルに還元できるはずです。」
  8. ^ John C. Reynolds、「プログラミングとプログラミング言語の教え方に関する考察」、 SIGPLAN Notices、第43巻、第11号、2008年11月、p.109
  9. ^ガッブリエリ&マルティーニ 2023、p. 519.
  10. ^ガッブリエリ&マルティーニ 2023、520–521 ページ。
  11. ^ a b cガッブリエリ&マルティーニ 2023、p. 521。
  12. ^ガッブリエリ&マルティーニ 2023、p. 522.
  13. ^セベスタ 2012、42ページ。
  14. ^ a b cガッブリエリ&マルティーニ 2023、p. 524.
  15. ^セベスタ 2012、42~44頁。
  16. ^ Gabbrielli & Martini 2023、523–524 ページ。
  17. ^ガッブリエリ&マルティーニ 2023、p. 527。
  18. ^ a b cガッブリエリ&マルティーニ 2023、p. 528.
  19. ^ 「Lispはいかにして神自身のプログラミング言語となったのか」 twobithistory.org . 2024年4月10日時点のオリジナルよりアーカイブ。 2024年4月10日閲覧
  20. ^セベスタ 2012、47~48頁。
  21. ^ガッブリエリ&マルティーニ 2023、p. 526.
  22. ^セベスタ 2012、50ページ。
  23. ^ Sebesta 2012、701–703 ページ。
  24. ^ガッブリエリ&マルティーニ 2023、524–525 ページ。
  25. ^セベスタ 2012、56~57頁。
  26. ^ガッブリエリ&マルティーニ 2023、p. 525。
  27. ^ガブリエリ&マルティーニ 2023、526–527 ページ。
  28. ^ガッブリエリ&マルティーニ 2023、p. 531.
  29. ^ a bセベスタ 2012、79ページ。
  30. ^ガッブリエリ&マルティーニ 2023、p. 530。
  31. ^ Gabbrielli & Martini 2023、532–533 ページ。
  32. ^ガッブリエリ&マルティーニ 2023、p. 534.
  33. ^ Gabbrielli & Martini 2023、534–535 ページ。
  34. ^ガッブリエリ&マルティーニ 2023、p. 535.
  35. ^セベスタ 2012、736ページ。
  36. ^ガッブリエリ&マルティーニ 2023、p. 536.
  37. ^ Gabbrielli & Martini 2023、536–537 ページ。
  38. ^セベスタ 2012、91~92頁。
  39. ^ Gabbrielli & Martini 2023、538–539​​ ページ。
  40. ^セベスタ 2012、97~99頁。
  41. ^ガッブリエリ&マルティーニ 2023、p. 542.
  42. ^ Gabbrielli & Martini 2023、474–475、477、542。
  43. ^ Gabbrielli & Martini 2023、542–543 ページ。
  44. ^ガッブリエリ&マルティーニ 2023、p. 544。
  45. ^ Bezanson, Jeff; Karpinski, Stefan; Shah, Viral B.; Edelman, Alan (2012). 「Julia: 技術計算のための高速動的言語」. arXiv : 1209.5145 [ cs.PL ].
  46. ^ Sáez-López, JM, Román-González, M. and Vázquez-Cano, E., 2016. 「小学校のカリキュラム全体へのビジュアルプログラミング言語の統合:5校における「Scratch」を用いた2年間の事例研究」Computers & Education, 97, pp.129-141.
  47. ^ Kodosky, J., 2020. LabVIEW. ACMプログラミング言語論文集、4(HOPL)、pp.1-54。
  48. ^ Fernando, A. および Warusawithana, L., 2020.「バレリーナプログラミング入門:初心者からプロまで」Apress.
  49. ^ Baluprithviraj, KN, Bharathi, KR, Chendhuran, S. and Lokeshwaran, P., 2021年3月. マスク検知機能を備えた人工知能ベースのスマートドア. 2021年人工知能・スマートシステム国際会議 (ICAIS) (pp. 543-548). IEEE.
  50. ^ Sewell, B., 2015. 『ブループリント:Unreal Engine用ビジュアルスクリプティング』Packt Publishing Ltd.
  51. ^ Bertolini, L., 2018. 『コーディング不要のハンズオンゲーム開発:Unityのビジュアルスクリプティングで2Dおよび3Dゲームを作成』Packt Publishing Ltd.
  52. ^マイケル・シップサー(1996).計算理論入門. PWS Publishing. ISBN 978-0-534-94728-6セクション2.2:プッシュダウンオートマトン、pp.101–114。
  53. ^ Jeffrey Kegler、「 Perlと決定不能性」 ( Wayback Machineで2009年8月17日にアーカイブ)、『The Perl Review 』。論文2と3は、それぞれライスの定理と停止問題への直接還元を用いて、Perlプログラムの構文解析は一般に決定不能であることを証明している。
  54. ^ Marty Hall, 1995, Lecture Notes: Macros Archived 6 August 2013 at the Wayback Machine PostScriptArchived 17 August 2000 at the Wayback Machine
  55. ^ Aaby, Anthony (2004). 『プログラミング言語入門』 . 2012年11月8日時点のオリジナルよりアーカイブ。 2012年9月29日閲覧
  56. ^マイケル・リー・スコット著『プログラミング言語語用論』第2版、モーガン・カウフマン、2006年、 ISBN 0-12-633951-1、18~19ページ
  57. ^ a bウィンスケル、グリン(1993年2月5日)『プログラミング言語の形式意味論:入門』 MIT出版。ISBN 978-0-262-73103-4
  58. ^セベスタ 2012、244ページ。
  59. ^セベスタ 2012、245ページ。
  60. ^ a b c d Andrew Cooke. 「コンピュータ言語入門」 . 2012年8月15日時点のオリジナルよりアーカイブ2012年7月13日閲覧。
  61. ^ Sebesta 2012、15、408–409。
  62. ^ Sebesta 2012、303–304 ページ。
  63. ^ Sebesta 2012、246–247 ページ。
  64. ^セベスタ 2012、249ページ。
  65. ^セベスタ 2012、260ページ。
  66. ^セベスタ 2012、250ページ。
  67. ^セベスタ 2012、254ページ。
  68. ^ Sebesta 2012、281–282 ページ。
  69. ^ Sebesta 2012、272–273 ページ。
  70. ^ Sebesta 2012、276–277 ページ。
  71. ^セベスタ 2012、280頁。
  72. ^ Sebesta 2012、289–290 ページ。
  73. ^セベスタ 2012、255ページ。
  74. ^ Sebesta 2012、244–245 ページ。
  75. ^セベスタ 2012、477ページ。
  76. ^セベスタ 2012、211ページ。
  77. ^ Leivant, Daniel (1983).多態的型推論. ACM SIGACT-SIGPLAN シンポジウム プログラミング言語の原理. オースティン, テキサス州: ACM Press. pp.  88– 98. doi : 10.1145/567067.567077 . ISBN 978-0-89791-090-3
  78. ^セベスタ 2012、212–213 ページ。
  79. ^ Sebesta 2012、284–285 ページ。
  80. ^セベスタ 2012、576頁。
  81. ^セベスタ 2012、579ページ。
  82. ^セベスタ 2012、585頁。
  83. ^ Sebesta 2012、585–586 ページ。
  84. ^セベスタ 2012、630、634 ページ。
  85. ^セベスタ 2012、635ページ。
  86. ^ a bセベスタ 2012、631頁。
  87. ^セベスタ 2012、261ページ。
  88. ^セベスタ 2012、632ページ。
  89. ^ Sebesta 2012、631、635–636 ページ。
  90. ^セベスタ 2012、18ページ。
  91. ^セベスタ 2012、19ページ。
  92. ^ノーフレ、プリーストリー、アルバーツ、2014 年、p. 55.
  93. ^ノーフレ、プリーストリー、アルバーツ、2014 年、p. 60.
  94. ^セベスタ 2012、8ページ。
  95. ^セベスタ 2012、16~17頁。
  96. ^セベスタ 2012、8~9頁。
  97. ^セベスタ 2012、9~10頁。
  98. ^セベスタ 2012、12~13頁。
  99. ^セベスタ 2012、13ページ。
  100. ^セベスタ 2012、14~15頁。
  101. ^フレデリック・P・ブルックス・ジュニア著『人月の神話』アディソン・ウェスレー社、1982年、93~94ページ
  102. ^ Busbee, Kenneth Leroy; Braunschweig, Dave (2018年12月15日). 「標準ライブラリ」 .プログラミングの基礎 – モジュール構造化アプローチ. 2024年1月27日閲覧
  103. ^セベスタ 2012、15ページ。
  104. ^セベスタ 2012、8、16頁。
  105. ^セベスタ 2012、18、23頁。
  106. ^ a bセベスタ 2012、p. 23。
  107. ^ Dijkstra, Edsger W.「自然言語プログラミング」の愚かさについて。 2008年1月20日アーカイブ、 Wayback Machine EWD667。
  108. ^ Perlis, Alan (1982年9月). 「プログラミングに関するエピグラム」 . SIGPLAN Notices Vol. 17, No. 9. pp.  7– 13. 1999年1月17日時点のオリジナルよりアーカイブ。
  109. ^ Milner, R. ; M. Tofte ; R. Harper ; D. MacQueen (1997). 『標準MLの定義(改訂版)』 MIT Press. ISBN 978-0-262-63181-5
  110. ^ケルシー、リチャード、ウィリアム・クリンガー、ジョナサン・リース(1998年2月)。「セクション7.2 形式意味論」アルゴリズム言語スキームに関する報告書第5版改訂版2006年7月6日時点のオリジナルよりアーカイブ。
  111. ^ ANSI – プログラミング言語 Rexx、X3-274.1996
  112. ^セベスタ 2012、23~24頁。
  113. ^セベスタ 2012、25~27頁。
  114. ^セベスタ 2012、27ページ。
  115. ^セベスタ 2012、28ページ。
  116. ^セベスタ 2012、29~30頁。
  117. ^参照: Oracle America, Inc. v. Google, Inc.
  118. ^ “Guide to Programming Languages | ComputerScience.org” . ComputerScience.org . 2018年5月13日時点のオリジナルよりアーカイブ2018年5月13日閲覧。
  119. ^ “The basics” . ibm.com . 2011年5月10日. 2018年5月14日時点のオリジナルよりアーカイブ2018年5月13日閲覧。
  120. ^ Abdelaziz, Abdullah I.; Hanson, Kent A.; Gaber, Charles E.; Lee, Todd A. (2023). 「RにおけるParquetファイルを用いた大規模実世界データ分析の最適化:ステップバイステップチュートリアル」 . Pharmacoepidemiology and Drug Safety . 33 (3) e5728. doi : 10.1002/pds.5728 . PMID 37984998 . 
  121. ^ 「HOPL: インタラクティブなプログラミング言語一覧」オーストラリア:マードック大学。 2011年2月20日時点のオリジナルよりアーカイブ2009年6月1日閲覧。このサイトには8512の言語が掲載されている。
  122. ^ Mayer, Philip; Bauer, Alexander (2015). 「オープンソースプロジェクトにおける複数プログラミング言語の利用に関する実証分析」. Proceedings of the 19th International Conference on Evaluation and Assessment in Software Engineering . Proceedings of the 19th International Conference on Evaluation and Assessment in Software Engineering – EASE '15. ニューヨーク、米国: ACM. pp. 4:1–4:10. doi : 10.1145/2745802.2745805 . ISBN 978-1-4503-3350-4結果:(a) プロジェクトあたり平均5言語が使用され、主要汎用言語が明確に支配的であり、5種類のDSLが頻繁に使用されること、(b) プロジェクト規模、コミット数、主要言語が言語数に有意な影響を与える一方で、プロジェクトの年齢や貢献者数は有意な影響を与えないこと、(c) XML、Shell/Make、HTML/CSSを中心とした3つの言語エコシステムが確立されていることが分かりました。結論:多言語プログラミングはオープンソースプロジェクトでは一般的であり、ツール開発やソフトウェアシステムの開発・保守の評価において考慮すべき要素です。
  123. ^ Abelson, Sussman, and Sussman. 「コンピュータプログラムの構造と解釈」 2009年2月26日時点のオリジナルよりアーカイブ2009年3月3日閲覧。{{cite web}}: CS1 maint: 複数の名前: 著者リスト (リンク)
  124. ^ Vicki, Brown; Morin, Rich (1999). 「スクリプト言語」 . MacTech . 2017年12月2日時点のオリジナルよりアーカイブ。
  125. ^ Georgina Swan (2009年9月21日). 「COBOL 50周年」 . Computerworld. 2013年10月19日時点のオリジナルよりアーカイブ2013年10月19日閲覧。
  126. ^ Ed Airey (2012年5月3日). 「COBOLに関する7つの神話を暴く」 developer.com. 2013年10月19日時点のオリジナルよりアーカイブ2013年10月19日閲覧。
  127. ^ Nicholas Enticknap. 「SSL/Computer Weekly IT給与調査:金融ブームがIT関連職の雇用増加を促進」 Computer Weekly . 2011年10月26日時点のオリジナルよりアーカイブ。 2013年6月14日閲覧
  128. ^ 「書籍販売数によるプログラミング言語の集計」 Radar.oreilly.com、2006年8月2日。 2008年5月17日時点のオリジナルよりアーカイブ。
  129. ^ Bieman, JM; Murdock, V.、「ワールドワイドウェブ上のコードの検索:予備調査」、第1回IEEE国際ソースコード分析および操作ワークショップの議事録、2001年
  130. ^ 「2018年の最も人気があり影響力のあるプログラミング言語」 . stackify.com. 2017年12月18日. 2018年8月30日時点のオリジナルよりアーカイブ2018年8月29日閲覧。
  131. ^ 「TIOBE Index」 . 2024年6月24日閲覧
  132. ^ 「IEEE Spectrum」 . 2025年9月25日閲覧
  133. ^セベスタ 2012、21ページ。
  134. ^ a b Sebesta 2012、21–22 ページ。
  135. ^セベスタ 2012、12ページ。
  136. ^セベスタ 2012、22ページ。
  137. ^セベスタ 2012、22~23頁。

さらに読む

「 https://en.wikipedia.org/w/index.php?title=プログラミング言語&oldid=1335277324#Dialects,_flavors_and_implementations 」より取得