MENU

プログラミング言語を見直す：特定目的の抽象化という視点とは？

I. 序論：プログラミング言語の本質としての「特定目的の抽象化」

プログラミング言語は、人間がコンピュータに指示を与えるための主要な手段であり、現代社会のあらゆる側面に深く浸透している 1。その本質を捉える上で、「プログラミング言語は特定目的の抽象化された言語である」という命題は、重要な示唆を与える。本稿では、この命題を基軸とし、プログラミング言語の定義、抽象化の役割、目的の多様性、設計思想、そして進化の歴史と未来展望を学術的観点から詳細に分析する。プログラミング言語が、いかにして特定の計算タスクや問題解決という「目的」のために、現実世界の複雑さや機械レベルの詳細を「抽象化」し、効率的かつ効果的な記述を可能にする「言語」として機能してきたかを探求する。この分析を通じて、プログラミング言語の設計と利用における「目的」と「抽象化」の間の根源的かつ共進化的な関係性を明らかにし、今後の言語設計やソフトウェア開発に対する洞察を得ることを目指す。

II. プログラミング言語の定義と「抽象化」の役割

プログラミング言語の理解には、まずその基本的な定義と、その中核をなす「抽象化」という概念の役割を明確にすることが不可欠である。

A. プログラミング言語の定義

プログラミング言語とは、主に人間がコンピュータプログラムを記述、編集するために用いられる人工言語である 1。コンピュータは、人間が日常的に使用する自然言語を直接理解することはできないため、コンピュータが解釈し実行可能な形式で指示を伝えるための専用の言語が必要となる 3。これらの言語は、語彙、文法、記法などが自然言語よりも厳密に定義されており、記述されたソースコードはソフトウェアによって自動的に解析、処理、変換されることが可能である 1。

作成されたプログラムは、最終的には機械語（マシン語）による記述に変換された後、コンピュータのCPUによって実行される 1。この変換プロセスには、主にコンパイル方式とインタプリタ方式の二つが存在する。コンパイル方式では、プログラム全体を事前に一括して機械語に変換し（この処理をコンパイル、変換ソフトウェアをコンパイラと呼ぶ）、インタプリタ方式では、プログラムの実行時に命令を逐次解釈しながら機械語に変換し実行する 1。

プログラミング言語の基本的な目的は、人間がコンピュータとコミュニケーションを取り、ソフトウェア、ウェブサイト、アプリケーション、その他の技術を創造することを可能にすることである 2。これにより、タスクの自動化、計算、大量データの迅速かつ効率的な処理が実現される 4。

B. コンピュータプログラミングにおける「抽象化」

コンピュータプログラミングにおける「抽象化（Abstraction）」とは、複雑なソフトウェアシステムにおいて、その複雑さを軽減し、効率的な設計と実装を可能にするための手法である 5。具体的には、システムの技術的な複雑さをAPI（Application Programming Interface）の背後に隠蔽したり、複雑なコードを簡潔化し、重要な情報だけに焦点を当てて、それ以外の詳細な部分を隠すことを指す 5。

抽象化は、ある目的にとって重要な側面を分離抽出し、重要でない側面を捨て去るプロセスとも言える 8。この「目的」に応じて、何が重要で何が重要でないかが決定されるため、同じ対象に対しても目的に応じて多様な抽象化が可能となる 8。例えば、プログラミングで頻繁に用いられる「関数」も抽象化の一種であり、一連の命令をまとめて名前を付け、特定の入力（引数）から出力（戻り値）を計算する手順を表現する 7。

抽象化には、主にデータ抽象化と制御抽象化の二つのタイプが存在する 9。

  • データ抽象化: データの詳細な内部構造や実装を隠蔽し、データに対する操作のみをインターフェースとして提供する。これにより、ユーザーはデータの複雑な詳細を知ることなくデータを利用できる 5。例えば、クラスを用いてデータメンバーをカプセル化し、公開メソッドを通じてのみアクセスを許可することがこれにあたる 5。
  • 制御抽象化: 特定のタスクを実行するための一連の処理（制御フロー）をカプセル化し、その詳細な実装を隠蔽する。関数やサブルーチンがこの典型例であり、コードの再利用性やモジュール性を高める 9。例えば、ヘッダーファイル内の関数を利用する際、ユーザーはその関数の内部アルゴリズムを知る必要はない 10。

プログラミング言語自体が、機械語に対する抽象化の層を提供していると見なすことができる 13。言語の進化の歴史は、より高度な抽象化を求める過程でもあった 14。

C. 抽象化の利点

抽象化は、ソフトウェア開発において多くの利点をもたらす。

  • 複雑性の低減: 複雑なシステムをより単純で理解しやすいコンポーネントに分割することで、開発者が一度に扱うべき情報の量を減らす 5。
  • 再利用性の向上: 抽象化されたコンポーネント（関数やクラスなど）は、異なる箇所やプロジェクトで再利用しやすくなり、コードの重複を避けることができる 5。これは「Don’t Repeat Yourself (DRY)」原則にも通じる 12。
  • 保守性の向上: 内部実装の変更が外部に影響を与えにくくなるため、システムの修正や機能追加が容易になる 5。これは、抽象化のレベルを適切に保つことで、変更理由がより高い抽象レベルで決定されるため、保守がしやすくなることに関連する 16。
  • セキュリティの向上: 重要な詳細情報のみをユーザーに提供し、内部実装を隠蔽することで、不正なアクセスや意図しない操作からシステムを保護するのに役立つ 5。
  • 生産性の向上: 開発者は低レベルの詳細に煩わされることなく、より本質的な問題解決に集中できるため、開発効率が向上する 5。

D. 抽象化の階層：高水準言語と低水準言語

プログラミング言語は、人間にとっての理解のしやすさや機械語に対する抽象度の高さによって分類されることがある 1。この抽象度の違いによって、主に高水準言語（高級言語）と低水準言語（低級言語）に分けられる 1。

  • 低水準言語 (Low-level language):
  • コンピュータのハードウェアに近い、あるいは機械語に直接的な対応関係を持つ言語 1。
  • CPUの命令セットに一対一で対応する命令語を用いるアセンブリ言語や、コンピュータが直接実行する機械語自体が代表例である 1。
  • ハードウェアに対する非常に細かい制御が可能であるが、その分、記述が複雑で人間には理解しにくい 4。
  • 学習曲線は急であり、深い理解が求められる 17。
  • 直接ハードウェアを制御できるため、特定の状況下では高いパフォーマンスを発揮できる 17。
  • 高水準言語 (High-level language):
  • 人間が使用する自然言語に近い語彙や文法構造を持ち、人間にとって理解しやすく記述しやすいように設計された言語 1。
  • ハードウェアの具体的な詳細や複雑な機械語の命令を隠蔽し、プログラマがより問題の本質やビジネスロジックに集中できるようにする 17。
  • Python, Java, Rubyなどが代表例である 4。
  • 一般的に、低水準言語に比べて短いコードで多くの機能を実装できる 17。
  • 抽象度が高いため、ハードウェアに対する直接的な制御の精度は低くなることがあるが、効率的なコンパイラやインタプリタによって十分なパフォーマンスを提供できる場合も多い 17。

C言語は、メモリの直接操作など低水準の操作を可能にしつつ、ある程度の抽象化も提供するため、低水準言語と高水準言語の中間に位置するとされることが多い 17。

この抽象化の階層は、プログラマがどのレベルでコンピュータと対話し、問題を解決するかを選択する際の重要な指標となる。高水準言語は、より複雑な計算や大規模なデータ処理を伴うタスクにしばしば用いられる一方、低水準言語はコンピュータのハードウェアに対する高度な制御が求められるタスクに利用される 4。

III. 「特定目的」のスペクトラム：ドメイン固有言語（DSL）と汎用プログラミング言語（GPL）

プログラミング言語の「特定目的」という側面は、その言語が設計された対象領域や解決しようとする問題の範囲によって、明確な特化型から広範な汎用型まで、連続的なスペクトラム上に位置づけられる。このスペクトラムの両極として、ドメイン固有言語（DSL）と汎用プログラミング言語（GPL）が存在する。

A. ドメイン固有言語（DSL）：明確な特定目的

1. DSLの定義と特徴

ドメイン固有言語（Domain-Specific Language, DSL）とは、特定のアプリケーションドメインや問題領域に特化して設計されたコンピュータ言語である 18。これは、広範なドメインに適用可能な汎用プログラミング言語（GPL）とは対照的である 18。DSLは、特定の種類の問題や解決策を、既存の言語よりも明確に表現できる場合に作成する価値があるとされる 18。

DSLの主な特徴は以下の通りである。

  • 限定された表現力: DSLは特定のドメインの問題解決に特化しており、そのドメイン外の問題を解決することは意図されていない（技術的に可能であっても） 18。
  • 高い表現効率: 対象ドメインにおいては、GPLよりも簡潔かつ直感的に問題を記述できる 18。これにより、ドメインエキスパート自身がDSLプログラムを理解、検証、修正、さらには開発することさえ可能になる場合がある 18。
  • ドメインレベルでの検証: 言語構成要素が安全であれば、それらを用いて書かれた文は安全と見なせるため、ドメインレベルでの検証が可能となる 18。
  • 学習の容易さ: スコープが限定されているため、一般的にGPLよりも学習が容易である 18。
  • 作業効率の向上: 特定の言語と変換エンジンがあれば、DSLが対象とするソフトウェア開発の側面で面倒な手作業を削減できる 19。コード自体がドキュメントの役割を果たすこともある 19。

DSLは、小さなプログラミング言語とスクリプト言語の中間的な存在と見なされることもあり、しばしばプログラミングライブラリと同様の方法で使用される 18。多くの場合、ファイルシステムアクセスやプロセス間制御といった、本格的なプログラミング言語が持つ低レベル機能を欠いている 18。

2. DSLの分類と具体例

DSLは、その実装方法やホスト言語との関係性によって、主に外部DSLと内部DSLの二つに分類される 19。

  • 外部DSL (External DSL):
  • 汎用プログラミング言語とは全く異なる独自の構文を持ち、独立して定義・処理される 19。
  • 独自のパーサーやインタプリタ、コンパイラを必要とする。
  • 例：
  • SQL (Structured Query Language): リレーショナルデータベースの管理・操作に特化したデータベース言語 19。データの検索、追加、削除、更新などの指示に使用される 19。
  • HTML (HyperText Markup Language): ウェブページの構造を記述するためのマークアップ言語 21。
  • CSS (Cascading Style Sheets): ウェブページのスタイル（見た目）を指定するための言語 21。
  • 正規表現: テキスト内のパターンマッチングを行うための構文 18。
  • Makefile: ビルドプロセスを自動化するためのルールを記述する言語。
  • Verilog, VHDL: ハードウェア記述言語 21。
  • 内部DSL (Internal DSL / Embedded DSL):
  • 既存の汎用プログラミング言語の構文や機能を活用し、その上で特定のドメインの語彙や構造を提供する 19。
  • ホスト言語のパーサーや実行環境をそのまま利用できる。
  • 例：
  • Ruby on RailsのActive Record: Ruby言語内でデータベース操作を直感的に記述できるようにしたDSL。
  • jQuery: JavaScriptライブラリであり、DOM操作やイベント処理を簡潔に記述するためのDSL的側面を持つ。
  • Gradleのビルドスクリプト: GroovyやKotlinといったGPLをベースに、ビルドタスクを宣言的に記述するDSL。
  • 多くのテストフレームワーク（例：RSpec for Ruby, JUnit for Java）は、テストケースを記述するための内部DSLを提供する。

その他の具体例:

  • VBA (Visual Basic for Applications): Microsoft Office製品の機能をカスタマイズ・拡張するためのプログラミング言語 19。
  • XML (Extensible Markup Language): データ構造や内容を示すためのマークアップ言語仕様 19。
  • MATLAB: 数値計算、特に科学技術計算に特化した言語環境 23。
  • Solidity: ブロックチェーン（特にEthereum）上でスマートコントラクトを記述するための言語 21。

3. DSLの設計思想と利点・欠点

DSLの設計思想は、特定のドメインにおける表現力と生産性を最大化することにある 18。GPLが広範な問題に対処できる汎用性を持つのに対し、DSLは意図的にその適用範囲を限定することで、そのドメインにおける「語彙」と「文法」を最適化する 18。

利点:

  • 生産性の向上: ドメイン固有の抽象化により、定型的なコードの記述量が減り、開発が迅速になる 20。
  • 可読性と保守性の向上: ドメインの専門家にとって理解しやすい構文となるため、コードの意図が明確になり、保守が容易になる 22。
  • ドメインエキスパートとの連携: ドメインの概念を直接的に表現できるため、プログラマとドメインエキスパート間のコミュニケーションが円滑になる 18。ユビキタス言語の構築にも寄与する 25。
  • エラーの削減: 言語仕様がドメインに特化しているため、ドメインロジックに反するような誤りを記述しにくくなる 18。
  • 抽象化による複雑性の隠蔽: 実装の詳細を隠蔽し、本質的なドメインの問題に集中できる 20。

欠点:

  • 学習コスト: 新しいDSLを学ぶ必要がある 18。
  • 限定的な適用範囲: 特定のドメイン以外では役に立たないか、非常に使いにくい 18。
  • ツールサポートの不足: 汎用言語ほど豊富な開発ツール（IDE、デバッガなど）が存在しない場合がある 20。
  • 統合の難しさ: 他のシステムやGPLで書かれたコードとの連携が複雑になることがある 22。
  • 設計と実装のコスト: 新しいDSLを設計し、その処理系（パーサー、コンパイラ、インタプリタなど）を開発するには相応のコストがかかる 18。

DSLは、その「特定目的」に深く根ざした抽象化を提供することで、特定の分野におけるソフトウェア開発の効率と品質を劇的に向上させる可能性を秘めている。しかし、その特化性が故の制約も理解した上で、適用を検討する必要がある。

B. 汎用プログラミング言語（GPL）：広範な目的と設計思想

1. GPLの定義と特徴

汎用プログラミング言語（General-Purpose Language, GPL）は、特定のアプリケーションドメインに限定されず、広範な種類の問題解決やソフトウェア開発に使用できるように設計されたコンピュータ言語である 18。これは、特定のタスクに特化したドメイン固有言語（DSL）とは対照的な概念である 18。

GPLの主な特徴は以下の通りである。

  • 広範な適用性: ウェブ開発、システムプログラミング、アプリケーション開発、データサイエンス、ゲーム開発など、多岐にわたる分野で使用される 26。
  • チューリング完全性: ほとんどのGPLはチューリング完全であり、理論上はあらゆる計算可能な問題を解くことができる 26。
  • 豊富な機能セット: 多様なデータ構造、制御構文、ライブラリなどを提供し、複雑なロジックや大規模なシステムを構築する能力を持つ 1。
  • 抽象化メカニズム: 手続き、関数、クラス、モジュールなど、様々なレベルの抽象化をサポートし、コードの構造化や再利用を促進する 13。
  • 大規模なコミュニティとエコシステム: 多くのGPLは、活発な開発者コミュニティ、豊富なドキュメント、多数のサードパーティライブラリやフレームワークに支えられている 30。

代表的なGPLには、Java, Python, C++, C#, JavaScript, Ruby, Goなどがある 4。これらの言語は、それぞれ異なる設計思想や得意分野を持ちつつも、その汎用性から多くの開発者に利用されている。

2. GPLの設計思想と「暗黙の目的」

GPLは「汎用」と名付けられているものの、完全に無目的、無思想で設計されるわけではない。各GPLには、その設計者が意図した特定のプログラミングスタイル（パラダイム）、解決すべき問題クラスへの適性、あるいは開発者の生産性向上といった「暗黙の目的」や設計哲学が込められていることが多い。

  • パラダイムの重視:
  • オブジェクト指向: JavaやC#は、オブジェクト指向プログラミング（OOP）を中核に据えて設計され、カプセル化、継承、ポリモーフィズムといった概念を通じて、大規模で複雑なシステムの構築を容易にすることを目的としている 4。
  • 関数型プログラミング: HaskellやLISP（初期は記号処理という特定目的だったがGPLに進化した 26）は、副作用を排し、数学的な関数の評価として計算を捉えることで、コードの簡潔性、可読性、並行処理の安全性を高めることを目指している 14。
  • 手続き型プログラミング: C言語は、ハードウェアに近い操作を効率的に行いつつ、構造化プログラミングを可能にすることを目的として設計された 17。
  • マルチパラダイム: PythonやJavaScript、Scalaなどは、複数のプログラミングパラダイムをサポートし、開発者が問題に応じて最適なアプローチを選択できる柔軟性を提供することを目的としている 30。
  • 特定の実行環境やプラットフォームへの最適化:
  • Javaの「Write Once, Run Anywhere (WORA)」という思想は、プラットフォーム非依存のアプリケーション開発を目的としている 34。
  • SwiftはAppleのiOSおよびmacOSエコシステムでの開発効率と安全性を高める目的で設計された 30。
  • Go言語は、Googleにおいて大規模なネットワークサービスや並行処理を効率的に扱う目的で開発された 21。
  • 開発者の体験や生産性への配慮:
  • Pythonは、コードの可読性と簡潔な構文を重視し、初心者にも学びやすく、迅速な開発を可能にすることを目的の一つとしている 26。
  • Rubyは、「プログラマの幸せ」を重視し、直感的で表現力豊かな構文を提供することを目指している。

これらの「暗黙の目的」は、言語の構文、標準ライブラリ、エコシステム、そしてコミュニティの文化に影響を与え、結果として特定の種類のタスクや開発スタイルに対して、他のGPLよりも適性が高くなる傾向を生み出す。C.A.R. Hoareは、プログラミング言語の主目的はプログラマの技術実践を助けることであるべきだと述べており、これはGPLの設計においても重要な指針となる 35。

3. GPLにおける抽象化の柔軟性と課題

GPLは、その汎用性を実現するために、多様な抽象化メカニズムを提供する。これにより、開発者は問題の性質や規模に応じて、適切なレベルの抽象化を選択し、適用することができる。

  • データ抽象化: 構造体、クラス、インターフェースなどを通じて、複雑なデータをカプセル化し、その操作を定義する。
  • 制御抽象化: 関数、プロシージャ、メソッド、コルーチン、スレッドなどを通じて、処理の流れをモジュール化し、再利用可能にする。
  • モジュール化: 名前空間、パッケージ、モジュールシステムなどを通じて、大規模なプログラムを独立したコンポーネントに分割し、管理を容易にする。

この柔軟性はGPLの大きな強みであるが、同時に課題も生じさせる。

  • 過剰な抽象化の危険性: 不必要に複雑な抽象化レイヤーを導入してしまうと、かえってコードの理解を妨げたり、パフォーマンスを低下させたりする可能性がある 12。
  • 抽象化レベルの不一致: プロジェクト内で抽象化のレベルが統一されていないと、コードの可読性や保守性が損なわれることがある 16。
  • 「漏れのある抽象化 (Leaky Abstraction)」: 完全に下位レイヤーの詳細を隠蔽できず、予期せぬ挙動や問題を引き起こすことがある 13。Fred Brooksが指摘するように、ソフトウェアの本質的な複雑性は抽象化によって完全には取り除けない 37。

GPLの設計と利用においては、問題領域に対して「ちょうど良い抽象度の言葉を考える」ことが重要となる 39。これは、問題の本質を捉え、解決策を簡潔かつ明確に表現できるような抽象化レベルを見極めることを意味する。

C. DSLとGPLの比較と相互関係

DSLとGPLは対照的な特性を持つが、互いに排他的なものではなく、むしろ補完的な関係にある。

特性ドメイン固有言語 (DSL)汎用プログラミング言語 (GPL)
目的特定のドメイン、タスクに特化 18広範なドメイン、多様なタスクに対応 18
表現力対象ドメイン内で高い表現力と簡潔性 18一般的な計算処理に対して高い表現力、ドメイン固有の表現は冗長になりがち 26
複雑性一般的にGPLより単純 19多機能で複雑になる傾向 19
学習コストスコープが狭いため比較的低い 18機能が多いため比較的高く、習熟に時間がかかる 41
ツールサポート限定的な場合がある 20豊富なIDE、デバッガ、ライブラリが存在 30
適用範囲狭い 18広い 26
主な利用者ドメインエキスパートも含む 18主にプログラマ、ソフトウェアエンジニア

相互関係:

  • GPLからDSLへの進化: 一部のGPLは、元々は特定の目的（例えばLISPの記号処理、FORTRANの数値計算）のためにDSLとして開発されたが、後に機能が拡張されGPLへと進化した例がある 26。PHPも同様の経緯を辿った 19。
  • GPL内での内部DSLの構築: GPLの柔軟な構文やメタプログラミング機能を活用して、特定のタスクをより宣言的かつ簡潔に記述するための内部DSLが構築されることがよくある 20。これにより、GPLの汎用性を保ちつつ、DSLの表現力を部分的に取り込むことができる。
  • DSLとGPLの連携: 多くのシステムでは、DSLで記述されたロジックがGPLで書かれたコアシステムと連携して動作する。例えば、SQLクエリ（DSL）がJavaアプリケーション（GPL）から実行されるケースなどである。
  • ライブラリとしてのDSL: GPLのライブラリやフレームワークが、実質的に特定のタスクセットに対するDSLとして機能することがある。例えば、PythonのデータサイエンスライブラリであるPandasやNumPyは、データ操作や数値計算のための高度に抽象化されたインターフェースを提供する。

DSLとGPLの選択は、解決すべき問題の性質、開発チームのスキル、必要なパフォーマンス、保守性、エコシステムの成熟度などを総合的に考慮して行われるべきである 22。特定の問題領域に対してはDSLが圧倒的な生産性をもたらす一方、未知の課題や広範な機能が求められる場合はGPLの柔軟性が不可欠となる。ソフトウェア開発の現場では、これらの言語がそれぞれの「特定目的」に応じて使い分けられ、時には組み合わせて利用されることで、より効果的なソリューションが生み出されている。

IV. プログラミング言語の設計思想と「目的・抽象化」の具現化

プログラミング言語の設計は、単なる構文や機能の集合体の創造ではなく、特定の計算モデル、問題解決のアプローチ、さらにはプログラマの思考様式を方向付ける「設計思想」の具現化である。この設計思想が、言語の「目的」と、その目的を達成するための「抽象化」のあり方を深く規定する。

A. 設計思想が言語の「目的」と「抽象化」をどう方向付けるか

プログラミング言語の設計思想は、その言語がどのような問題を、どのように解決するために最適化されるべきかという「目的」を明確にする。そして、その目的を達成するために、どのような「抽象化」のメカニズム（データ構造、制御構造、モジュール化など）を提供すべきかを決定する。

例えば、C.A.R. Hoareは、プログラミング言語の設計における最も重要な原則として、プログラマの仕事、すなわちプログラムの設計、文書化、デバッグを支援することを挙げている 35。この思想に基づけば、言語はプログラムの意図を明確に表現できる抽象化を提供し、可読性の高いコードを奨励し、エラーの早期発見を助けるべきである。

Bertrand Meyerは、言語設計における「一貫性」と「独自性」の原則を提唱している 43。一貫性とは、少数の強力なアイデアに忠実であることであり、独自性とは、関心のあるすべての操作に対して一つの良い表現方法を提供することである。これらの原則は、言語が特定の設計目標（例えば、契約による設計の支援）に対して、明確で無駄のない抽象化を提供することを促す。

Fred Brooksは、「銀の弾丸などない」と述べ、ソフトウェアの本質的な複雑性は避けられないと指摘する一方で、高水準言語が偶発的な複雑性（機械語の詳細など）を取り除く上で大きな進歩をもたらしたことを認めている 37。これは、高水準言語の設計思想が、機械の詳細からの「抽象化」を通じて、プログラマが問題の本質に集中するという「目的」を支援したことを示している。

言語設計者は、対象とするユーザー（初心者、専門家など）、実行環境（組み込みシステム、ウェブサーバーなど）、解決すべき問題の性質（数値計算、記号処理、並行処理など）を考慮し、それらに最適な抽象化レベルと言語機能を選択する 44。この選択プロセス自体が、言語の「特定目的」を反映していると言える。例えば、Julia言語は、技術計算における演算子の複雑性とコードの特殊化という課題に対処するため、ジェネリック関数とデータフロー型推論を統合するという設計思想を採用している 45。

B. 主要なプログラミングパラダイムと「目的・抽象化」

プログラミングパラダイムとは、プログラムをどのように捉え、構築していくかに関する一定の設計思想やルール群であり、言語の分類基準ともなる 1。各パラダイムは、問題解決に対する異なるアプローチと、それに伴う特有の「目的」と「抽象化」のスタイルを持つ。

  • 命令型プログラミング (Imperative Programming):
  • 目的: プログラムの状態を変化させる一連の命令（ステートメント）を記述することで、計算を逐次的に実行する 31。コンピュータのフォン・ノイマンアーキテクチャに近く、ハードウェアの動作を直接的にモデル化しやすい 15。
  • 抽象化: 変数（メモリ位置の抽象化）、代入（状態変更の抽象化）、ループや条件分岐（制御フローの抽象化）が中心となる 15。手続き型プログラミングは、命令型をベースに、処理をプロシージャ（関数、サブルーチン）としてまとめることで、より高度な制御抽象化とモジュール化を導入する 1。C言語やPascalが代表例である 31。
  • オブジェクト指向プログラミング (Object-Oriented Programming, OOP):
  • 目的: 現実世界のエンティティや概念を「オブジェクト」としてモデル化し、オブジェクト間の相互作用としてプログラムを構築する 4。データのカプセル化、継承、ポリモーフィズムを通じて、コードの再利用性、保守性、拡張性を高めることを目指す 4。
  • 抽象化: クラス（オブジェクトの設計図）、オブジェクト（データと振る舞いのカプセル化）、メソッド（オブジェクトの操作）、継承（is-a関係の表現）、ポリモーフィズム（多様な振る舞いの実現）といった抽象化メカニズムを提供する 4。Java, C++, Python, Smalltalkなどが代表例である 4。
  • 関数型プログラミング (Functional Programming):
  • 目的: 計算を数学的な関数の評価として扱い、状態変化や副作用を極力排除する 31。プログラムの正当性証明を容易にし、並行処理の安全性を高め、宣言的な記述を促進する。
  • 抽象化: 関数を第一級オブジェクト（値として扱える）とし、高階関数（関数を引数に取ったり返したりする関数）、純粋関数（副作用がない）、再帰、遅延評価、不変データ構造といった抽象化を用いる 31。LISP, Haskell, ML, Scalaなどが代表例である 30。
  • 論理プログラミング (Logic Programming):
  • 目的: 事実と規則の集合としてプログラムを記述し、質問（クエリ）に対して論理的な推論によって答えを導き出す 15。
  • 抽象化: 述語論理に基づいた宣言的な記述が中心。Prologが代表例である 46。
  • 宣言型プログラミング (Declarative Programming):
  • 目的: プログラムが「何を」達成すべきかを記述し、「どのように」達成するかは言語処理系に委ねる 31。命令型とは対照的に、制御フローを明示的に記述しない。
  • 抽象化: 問題領域の構造や関係性を直接的に表現する。SQL（データベースクエリ）、HTML（ウェブページの構造記述）、正規表現などがこのパラダイムに含まれる。関数型プログラミングや論理プログラミングも広義の宣言型に含まれることがある。

多くの現代のGPLは、複数のパラダイムをサポートするマルチパラダイム言語として設計されており、開発者は問題の性質に応じて適切なパラダイムや抽象化手法を選択できる柔軟性を持つ 1。この柔軟性自体が、現代GPLの重要な「目的」の一つとなっている。

C. 影響力のある言語設計者とその思想における「目的・抽象化」

プログラミング言語の歴史には、その設計思想を通じて「目的」と「抽象化」のあり方に大きな影響を与えた設計者たちが存在する。

  • John McCarthy (LISP):
  • 目的: LISPは当初、記号処理、特に人工知能（AI）研究におけるリスト処理を効率的に行うという特定の目的のために設計された 14。
  • 抽象化: LISPの核心的な抽象化は、コードとデータが同じS式（Symbolic Expression）というリスト構造で表現される点にある（同図像性） 32。これにより、プログラムがプログラム自身をデータとして操作するメタプログラミングが容易になり、強力なマクロシステムによる言語拡張が可能となった。関数を第一級オブジェクトとして扱うことで、高階関数による抽象化も初期からサポートしていた。
  • John Backus (FORTRAN, FP):
  • FORTRANの目的: FORTRANは、科学技術計算を、人間が理解しやすい数式に近い形で記述し、かつ機械語に近い効率で実行させることを目的として開発された最初の高水準言語の一つである 14。これにより、コンピュータの専門家でない科学者や技術者もプログラミングを行えるようになった。
  • 抽象化 (FORTRAN): 数式、配列、サブルーチンといった、当時の科学技術計算に必要な基本的な抽象化を提供した。
  • FP (Functional Programming) とフォン・ノイマン型からの脱却: 後年、Backusはチューリング賞受賞講演「プログラミングはフォン・ノイマン様式から解放されうるか？関数型スタイルとそのプログラム代数」において、従来の命令型言語（彼自身が開発したFORTRANも含む）が持つ変数中心の逐次的処理（フォン・ノイマン・ボトルネック）を批判し、より数学的で代数的な操作が可能な関数レベルのプログラミングスタイル（FP）を提唱した 54。これは、計算の「目的」をより抽象的かつ宣言的に記述することを目指す思想であった。
  • Niklaus Wirth (Pascal, Modula):
  • 目的: Pascalは、構造化プログラミングを奨励し、学生が優れたプログラミング習慣を身につけるための教育用言語として、また、効率的で信頼性の高いコンパイラを容易に作成できる言語として設計された 14。彼の設計哲学は「シンプルさ」と「コードの注意深い構成」を重視するものであった 55。
  • 抽象化 (Pascal): ALGOL 60をベースに、強力な型システム、ユーザー定義のデータ型（レコード、列挙型、部分範囲型など）、ネストされた手続き定義といった抽象化メカニズムを提供し、データの構造化とアルゴリズムの明確な記述を支援した 47。Modula-2では、モジュールというより大きな単位での抽象化と情報隠蔽を導入した。
  • Edsger Dijkstra (構造化プログラミング):
  • 目的: Dijkstraは、プログラムの複雑性を管理し、その正当性を論理的に検証可能にすることを目指し、「構造化プログラミング」の概念を提唱した 56。これは、goto文のような無制限な制御フローを避け、順次実行、選択（if-then-else）、反復（whileループ）といった限られた制御構造のみを用いるべきであるという思想である 14。
  • 抽象化: 彼の思想は、プログラムの制御フローをより抽象的かつ規律あるものにすることで、人間の認知限界を超えずに複雑なプログラムを設計・理解できるようにすることを目的としていた。彼は、「我々が用いる道具は、我々の思考習慣、ひいては思考能力に深遠な（そして巧妙な）影響を与える」と述べ、より良いプログラミング言語がより良い思考を促すと考えていた 57。
  • C.A.R. Hoare (公理的意味論、CSP):
  • 目的: Hoareは、プログラムの正しさを数学的に証明するための形式的手法に関心を持ち、プログラミング言語の設計はそのような検証を支援すべきであると考えた 35。彼の「プログラミング言語設計のヒント」では、言語はプログラム設計、文書化、デバッグを助けるべきであり、特にプログラムの意図を明確に表現できることが重要であると論じている 35。
  • 抽象化: 抽象化は、現実世界の類似性に着目し、差異を無視することで本質を捉えるプロセスであるとし、プログラミングもこの抽象化のプロセスに基づくと述べている 58。Communicating Sequential Processes (CSP) は、並行プロセスの相互作用を記述するための抽象的な形式言語である。
  • Peter Landin (ISWIM, SECDマシン):
  • 目的: Landinは、1966年の論文「次の700のプログラミング言語」において、既存の言語の多くがアドホックな機能の寄せ集めであると批判し、ラムダ計算に基づいた統一的な意味論的フレームワーク（ISWIM: If You See What I Mean）を持つ言語ファミリーを提唱した 54。彼の目的は、言語の「本質」と「偶有性」を分離し、よりクリーンで数学的に扱いやすい言語の基礎を築くことであった。
  • 抽象化: ISWIMは、式の評価を中心とし、代入やgotoといった命令型の要素を排除することで、より高レベルな抽象化を目指した。SECDマシンは、そのような関数型言語を効率的に実行するための抽象機械のモデルを提案した 44。

これらの設計者たちの思想は、単に特定の言語機能を生み出しただけでなく、プログラミング言語がどのように「目的」を持ち、どのように「抽象化」を提供すべきかという根本的な問いに対する多様な答えを示しており、現代の言語設計にも影響を与え続けている。

V. プログラミング言語の進化と未来：「特定目的の抽象化」の深化と多様化

プログラミング言語の歴史は、「特定目的」のための「抽象化」が、時代ごとの技術的要請や問題領域の変化に応じて、絶えず深化し、多様化してきた過程として捉えることができる。

A. 歴史的変遷に見る「目的」と「抽象化」の進化

プログラミング言語の進化は、低レベルな機械依存の記述から、より人間が理解しやすく、問題の本質を捉えやすい高レベルな抽象化へと向かう大きな流れと、その中で特定の目的に特化した言語と汎用的な言語が相互に影響し合いながら発展してきた経緯を持つ 14。

  • 初期（1940年代～1950年代）:
  • 目的: 特定の計算機ハードウェアを直接制御し、数値計算や単純なデータ処理を実行する。
  • 抽象化: 機械語やアセンブリ言語が主流であり、抽象化のレベルは非常に低かった 14。プログラマはメモリ管理やレジスタ操作といったハードウェアの詳細を意識する必要があった。Short Codeのような初期の高水準言語の試みは、数式表現の抽象化を目指したが、実行効率に課題があった 14。
  • この段階は、非常に限定された「特定目的」（特定の機械での計算実行）のための、最小限の「抽象化」（ニーモニックなど）と見なせる。
  • 高水準言語の登場（1950年代後半～1960年代）:
  • 目的: FORTRAN（科学技術計算）、COBOL（事務処理）、LISP（記号処理、AI）など、特定の応用分野でのプログラミング効率を向上させる 14。これらは当初DSL的な性格が強かった。
  • 抽象化: 数式、レコード、リストといったデータ構造や、サブルーチン、関数といった制御構造が導入され、機械の詳細が隠蔽された 14。ALGOL 60は、ブロック構造やBNFによる構文定義など、後の言語に大きな影響を与える抽象化の概念を導入した 14。
  • 「特定目的」がより明確な応用分野に向けられ、それに応じた「抽象化」が提供された時代である。
  • パラダイムの確立と多様化（1960年代後半～1970年代）:
  • 目的: 命令型に加え、オブジェクト指向（Simula）、関数型（ML）、論理型（Prolog）など、多様なプログラミングの「考え方（パラダイム）」を具現化し、それぞれのパラダイムが適した問題解決を支援する 14。構造化プログラミングの思想も広まり、プログラムの可読性や保守性の向上という目的が重視された 14。
  • 抽象化: クラス、オブジェクト、高階関数、型システム、モジュールといった、各パラダイム固有の高度な抽象化メカニズムが開発された 14。
  • 「特定目的」が、具体的な応用分野だけでなく、問題解決の「アプローチ」そのものに向けられ、それを支える「抽象化」が深化・多様化した。
  • 統合とインターネット時代（1980年代～1990年代）:
  • 目的: C++のように既存のパラダイムを統合したり（オブジェクト指向とシステムプログラミング）、大規模システム開発のためのモジュール化を強化したり（Ada, Modula-2）する動きが見られた 14。インターネットの普及に伴い、ウェブページ記述（HTML）、クライアントサイドスクリプト（JavaScript）、サーバーサイド処理（Perl, PHP）といった新たな「特定目的」が登場した 14。
  • 抽象化: モジュール、例外処理、ジェネリックプログラミングなどの抽象化が進んだ。スクリプト言語は、迅速な開発を可能にするための高い抽象化レベルと動的な性質を備えていた 4。
  • この時期には、既存のGPLが新たな目的（ウェブなど）に対応するために拡張されたり、新たな目的特化型の言語（スクリプト言語など）が登場したりと、目的と抽象化の再編が進んだ。

この歴史的変遷は、初期の極めて特定的な目的と低い抽象化から、一度汎用化と抽象化レベルの向上へと進み、その後、新たな問題領域やプログラミング思想の登場に応じて、再び多様な特定目的と、それに対応する高度な抽象化が追求されるという、螺旋的な発展を示している。これは、常に変化する計算のニーズに対して、より効果的で効率的な「特定目的の抽象化された言語」を求める人間の探求の現れと言える。

B. 現代のトレンドにおける「目的」と「抽象化」

現代のプログラミング言語のトレンドは、これまでの進化の延長線上にありつつ、クラウドコンピューティング、ビッグデータ、AI、モバイルコンピューティングといった新たな技術的・社会的要請に応える形で、「特定目的の抽象化」がさらに先鋭化、多様化している。

  • マルチパラダイムGPLの成熟:
  • Python, JavaScript, Java, C#, Swiftといった主要なGPLは、オブジェクト指向、関数型、命令型など複数のプログラミングパラダイムをサポートし、開発者が特定のタスクや問題の側面に応じて最適な抽象化を選択できる柔軟性を提供している 33。この「柔軟性」自体が、現代GPLの重要な「目的」の一つであり、多様な特定目的のタスクを一つの言語エコシステム内で効率的に扱うことを可能にしている。
  • DSLsの再興と洗練:
  • 特定の産業や問題領域に特化したDSLへの関心が高まっている 21。
  • AI/ML分野: TensorFlowやPyTorchのようなライブラリは、Python内で高度に最適化された内部DSLとして機能し、ニューラルネットワークの構築や学習といった「特定目的」の記述を大幅に簡略化している 23。
  • データベース: SQLは依然としてリレーショナルデータベース操作の標準DSLである 19。NoSQLデータベースも独自のクエリ言語（DSL）を持つことが多い。
  • スマートコントラクト: Solidityのような言語は、ブロックチェーン上で契約を自動実行するという「特定目的」のために設計された 21。
  • 構成管理: Ansible, Chef, Puppetなどのツールは、インフラ構成を記述するための宣言的なDSLを提供する。
  • これらのDSLは、それぞれのドメインにおける抽象化レベルを極限まで高め、生産性を向上させることを「目的」としている。
  • 関数型プログラミングの影響力増大:
  • イミュータビリティ（不変性）、純粋関数、高階関数といった関数型プログラミングの概念が、多くの主流言語に取り入れられている 23。これは、コードの品質向上、副作用の抑制による予測可能性の向上、そして特に並行・並列処理の安全かつ効率的な記述という「目的」に貢献している。
  • 並行・並列処理のための言語設計:
  • マルチコアプロセッサの普及と分散システムの一般化に伴い、並行処理や並列処理を効率的かつ安全に扱うという「特定目的」に特化した言語設計が注目されている。Go言語のゴルーチンやチャネル、Rustの所有権システムと安全性保証などがその例である 21。これらは、複雑な同期処理やデータ競合の問題を言語レベルで抽象化し、開発者の負担を軽減する。
  • 安全性とセキュリティへの注力:
  • メモリ安全性や型安全性をコンパイル時や実行時に保証することで、バグの混入を防ぎ、より堅牢でセキュアなシステムを構築するという「目的」が重視されている。Rustはその代表例であり、C/C++が抱えていたメモリ関連の脆弱性を言語機能によって排除することを目指している 21。
  • AI駆動開発 (AI-Driven Development):
  • AIは、プログラミング言語が対象とするドメイン（AIアプリケーション開発）であると同時に、プログラミング言語の設計や利用方法自体に影響を与えるツールともなっている 21。GitHub CopilotのようなAIペアプログラマは、コード生成、バグ修正、リファクタリングなどを支援し、開発の「目的」である生産性向上に貢献する。将来的には、AIがより高度な抽象化レベルで人間と対話し、要求仕様から直接コードを生成するような言語や開発環境が登場する可能性もある。

これらのトレンドは、プログラミング言語が常に特定の「目的」を追求し、その目的達成に最適な「抽象化」を提供する方向へと進化し続けていることを示している。現代においては、その「目的」がより多様化し、専門化する傾向と、汎用言語がそれらの多様な目的に柔軟に対応できるよう進化する傾向が同時に進行している。

C. 将来の展望

プログラミング言語の未来は、現在のトレンドをさらに推し進め、新たな計算パラダイムや社会的要求に応じた「特定目的の抽象化」がより一層深化し、多様化することが予想される。

  • さらに専門化されたDSLの隆盛:
  • ソフトウェア開発がより専門化・細分化するにつれて、特定のニッチなドメインや業界に最適化されたDSLが数多く登場し、活用されるようになるだろう 21。これらのDSLは、そのドメインにおける生産性と表現力を極限まで高めることを「目的」とし、非常に高いレベルの「抽象化」を提供する。
  • 新たな計算パラダイムのための言語:
  • 量子コンピューティング: 量子コンピュータの実用化が進むにつれて、量子アルゴリズムの記述や量子プロセッサの制御という特異な「目的」に特化した新しいプログラミング言語（例：Q#, Quipper, Silq）が不可欠となる 21。これらの言語は、重ね合わせや量子もつれといった量子力学特有の現象を扱うための、従来とは全く異なる「抽象化」を提供する。
  • AIネイティブ言語: 現在のAI開発は主に既存GPL上のライブラリに依存しているが、将来的にはAIの概念（ニューラルネットワークの構造、学習プロセス、推論メカニズムなど）を言語の基本構成要素として組み込み、より直感的かつ効率的にAIモデルを設計・開発できる「AIネイティブ」な言語が登場する可能性がある 21。その「目的」は、AI開発のさらなる加速と高度化であり、そのための新たな「抽象化」が追求される。
  • 抽象化と自動化のさらなる進展:
  • ローコード／ノーコードプラットフォームは、プログラミングの知識がないユーザーでもアプリケーションを開発できるようにすることを「目的」とした、非常に高いレベルの「抽象化」を提供する 21。これらのプラットフォーム自体は、強力なGPLや専門的な言語を用いて構築される。
  • AIによるコード生成技術はさらに進化し、人間がより抽象的なレベルで要件を指示するだけで、具体的なコードが自動生成される範囲が拡大するだろう。これにより、従来のプログラミング言語の「目的」が、これらの高レベル抽象化プラットフォームを構築するためのツールへとシフトする可能性も考えられる。プログラマの役割も、直接的なコーディングから、これらのプラットフォームやAIツールの設計・管理、あるいはAIが生成したコードの検証・監督へと変化していくかもしれない。
  • WebAssembly (Wasm)による言語選択の多様化:
  • WebAssemblyは、ウェブブラウザ上でJavaScript以外の多様な言語（C++, Rust, Goなど）で書かれたコードを高性能に実行可能にする 21。これにより、ウェブ開発における言語選択の幅が広がり、フロントエンドとバックエンドの境界が曖昧になる可能性がある。パフォーマンスや特定の機能要件といった「特定目的」に応じて、最適な言語をより自由に選択できるようになるだろう。
  • 「グリーンコーディング」への意識の高まり:
  • 環境負荷低減への関心の高まりから、エネルギー効率や持続可能なコンピューティングを優先する「グリーンコーディング」という「目的」が、言語設計やフレームワーク選択において重要性を増す可能性がある 23。実行効率が高く、リソース消費の少ない言語やライブラリが評価されるようになるかもしれない。
  • 意味論と語用論の共進化:
  • 特にAIエージェントが言語を学習しコミュニケーションを行うようになると、言語の「意味（セマンティクス）」と「使用（プラグマティクス）」が、人間の言語とは異なる形で共進化する可能性がある 63。これにより、機械が生成または媒介する言語における「目的」の概念自体が、新たな解釈を得るかもしれない。

これらの展望は、プログラミング言語が常に特定の「目的」を追求し、その達成のために最適な「抽象化」を提供するという基本的な方向性を維持しつつ、その対象となる「目的」がより高度化、専門化、あるいは新たな次元へと拡大していくことを示唆している。

VI. 結論：「特定目的の抽象化」の妥当性と今後の展望

本稿で展開してきた分析を通じて、「プログラミング言語は特定目的の抽象化された言語である」という当初の命題は、その核心において妥当であり、プログラミング言語の本質を鋭く捉えていることが確認された。プログラミング言語は、その誕生から現代に至るまで、そして未来においても、何らかの「目的」を達成するための手段として存在し、その目的を効率的かつ効果的に実現するために、現実世界の複雑さや機械レベルの詳細を「抽象化」する役割を一貫して担ってきた。

ドメイン固有言語（DSL）は、この命題の最も明確な具現化である。SQLがデータベース操作、HTMLがウェブページ構造記述というように、極めて特定の目的に特化し、そのための高度な抽象化を提供することで、対象領域における圧倒的な生産性と表現力を実現している。

一方、汎用プログラミング言語（GPL）についても、一見すると「特定目的」という言葉が当てはまらないように思えるかもしれない。しかし、詳細に検討すると、各GPLもまた、その設計思想や重視するプログラミングパラダイム（オブジェクト指向、関数型など）、ターゲットとする実行環境や開発者コミュニティのニーズといった背景から生まれる「暗黙の目的」や方向性を持っている。例えば、C言語はシステムプログラミングという目的に、Pythonは迅速な開発と可読性という目的に、Javaはプラットフォーム非依存性という目的に、それぞれ重点を置いて設計され、そのための抽象化メカニズムが提供されている。現代のGPLがマルチパラダイム化している傾向も、多様な「特定目的」のタスクに一つの言語で柔軟に対応するという、より高次の「目的」の現れと解釈できる。

プログラミング言語の歴史は、この「目的」と「抽象化」が相互に影響し合い、共進化してきた過程である。初期の機械語がハードウェア制御という直接的な目的のために最小限の抽象化しか持たなかったのに対し、高水準言語は人間による問題記述の容易性という目的のために機械の詳細を抽象化した。その後、オブジェクト指向や関数型といった新たなプログラミング思想（目的）が、クラスや高階関数といった新たな抽象化を生み出した。そして現代では、AI、量子コンピューティング、ウェブの進化といった新たな「目的」が、さらに高度で専門化された「抽象化」を伴う新しい言語や言語機能を必要としている。C.A.R. Hoareが述べたように、抽象化とはある目的に対して重要な側面を分離抽出し、重要でない側面を捨て去ることであり、言語はこのプロセスを支援するものでなければならない 58。

この「特定目的の抽象化」という視点は、単なる定義に留まらず、新しいプログラミング言語を学ぶ際や、既存の言語を評価する際の強力な分析ツールとなり得る。ある言語に接したとき、「この言語の主要な目的は何か？」「その目的を達成するために、どのような独自の抽象化が提供されているのか？」と問うことは、その言語の設計思想、長所、短所、そして適切な利用場面を深く理解する上で極めて有効である。

さらに広範な視点に立てば、プログラミング言語における「特定目的の抽象化」への絶え間ない追求は、人間が複雑性を管理し、特定の目標を達成するために専門的なツールや概念的枠組みを創造するという、より普遍的な人間の認知活動の一つの現れと見なすことができる。ハンマーが釘を打つという特定目的のために、ドライバーがネジを回すという特定目的のために設計されるように、プログラミング言語もまた、計算という広大な領域における様々な「特定目的」のための、知的な道具なのである。

今後のプログラミング言語の進化も、この「特定目的の抽象化」という基本原理に導かれ続けるだろう。AIによるコード生成、ローコード／ノーコードプラットフォームの普及、量子言語の登場といった動きはすべて、人間がより高度なレベルで、あるいは全く新しい種類の「目的」をコンピュータに伝え、実現させるための、新たな「抽象化」の探求に他ならない。プログラミング言語の設計と進化は、計算の可能性を拡張し、人間の創造性を解き放つための、終わりのない旅であると言えるだろう。研究論文「An Abstract, Reusable, and Extensible Programming Language Design Architecture」44が示すように、言語設計自体が、望ましい特徴を持つ言語実装を生成するための、抽象的かつ目的志向的な活動なのである。

引用文献

  1. プログラミング言語とは？意味を分かりやすく解説 – IT用語辞典 e … https://e-words.jp/w/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E.html
  2. www.lenovo.com https://www.lenovo.com/us/en/glossary/computer-history-programming-languages/#:~:text=Programming%20languages%20are%20languages%20used,technology%20we%20use%20every%20day.
  3. プログラミング言語とは？15種類のプログラミング言語を難易度や職業別に徹底解説 | コラム | 【公式】プログラミング能力検定（プロ検）｜受験者数No.1のプログラミング検定（小学生・中学生・高校生・大学生/専門学校生・社会人対象） https://programming-sc.com/column/column1/
  4. What is a Computer Programming Language? | Lenovo US https://www.lenovo.com/us/en/glossary/computer-history-programming-languages/
  5. Abstraction (抽象化) – MDN Web Docs 用語集: ウェブ関連用語の定義 … https://developer.mozilla.org/ja/docs/Glossary/Abstraction
  6. en.wikipedia.org https://en.wikipedia.org/wiki/Abstraction_(computer_science)#:~:text=In%20software%20engineering%20and%20computer,on%20details%20of%20greater%20importance.
  7. qiita.com https://qiita.com/as0088to/items/87cf9d0d61e1eb479251#:~:text=%E6%8A%BD%E8%B1%A1%E5%8C%96%E3%81%A8%E3%81%AF%E3%80%81%E3%80%8C%E8%A4%87%E9%9B%91,%E6%89%8B%E9%A0%86%E3%82%92%E8%A1%A8%E7%8F%BE%E3%81%97%E3%81%BE%E3%81%99%E3%80%82
  8. Roots -オブジェクト指向再発見- | オブジェクトの広場 – オージス総研 https://www.ogis-ri.co.jp/otc/hiroba/technical/Roots/roots1_1.html
  9. データサイエンスにおける抽象化とは何か – 統計を簡単に学ぶ https://ja.statisticseasily.com/%E7%94%A8%E8%AA%9E%E9%9B%86/%E3%83%87%E3%83%BC%E3%82%BF%E3%82%B5%E3%82%A4%E3%82%A8%E3%83%B3%E3%82%B9%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E6%8A%BD%E8%B1%A1%E5%8C%96%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B/
  10. Abstraction in C++ | GeeksforGeeks https://www.geeksforgeeks.org/abstraction-in-cpp/
  11. Control Abstraction in Java with Examples | GeeksforGeeks https://www.geeksforgeeks.org/control-abstraction-in-java-with-examples/
  12. Abstraction principle (computer programming) – Wikipedia https://en.wikipedia.org/wiki/Abstraction_principle_(computer_programming)
  13. Abstraction (computer science) – Wikipedia https://en.wikipedia.org/wiki/Abstraction_(computer_science)
  14. History of programming languages – Wikipedia https://en.wikipedia.org/wiki/History_of_programming_languages
  15. Programming language – Wikipedia https://en.wikipedia.org/wiki/Programming_language
  16. 意図によるプログラミング~適切な抽象化で保守しやすいコードを作る~ – Zenn https://zenn.dev/dove/articles/2f0ec6786dba10
  17. メモ 高レベル低レベルについて｜Fuji – note https://note.com/shirotabistudy/n/n625fc6e65f90
  18. Domain-specific language – Wikipedia https://en.wikipedia.org/wiki/Domain-specific_language
  19. ドメイン固有言語（DSL）を理解する！初心者でも分かる分類 … https://anken-hyouban.com/blog/2021/09/13/dsl/
  20. What are Domain-Specific Languages (DSL) | MPS by JetBrains https://www.jetbrains.com/mps/concepts/domain-specific-languages/
  21. The Future of Programming Languages: What to Expect Next … https://www.flowmatters.com/blog/the-future-of-programming-languages-what-to-expect-in-the-next-10-years/
  22. What is DSL in Programming? Unlock Precision in Development https://stepmediasoftware.com/blog/domain-specific-language/
  23. The future of programming languages – WeAreBrain https://wearebrain.com/blog/the-future-of-programming-languages/
  24. (PDF) Impact of Programming Languages on Learning Performance https://www.researchgate.net/publication/390104732_Impact_of_Programming_Languages_on_Learning_Performance
  25. ユビキタス言語策定したらビジネス理解がめっちゃ捗った話 – Zenn https://zenn.dev/leaner_dev/articles/20210922-ubiquitous-language
  26. General-purpose programming language – Wikipedia https://en.wikipedia.org/wiki/General-purpose_programming_language
  27. おすすめのプログラミング言語12選！それぞれの難易度や転職への活かし方も解説 https://www.computerfutures.com/ja-jp/knowledge-hub/programming/top-programming-languages/
  28. オープン系とは？言語一覧やシステム例など汎用系との違いを解説 – Geekly(ギークリー) https://www.geekly.co.jp/column/cat-technology/1909_021/
  29. Introduction to Programming Languages | GeeksforGeeks https://www.geeksforgeeks.org/introduction-to-programming-languages/
  30. The Impact of Programming Languages on Modern Software … https://www.techtics.ai/programming-languages-on-software-development/
  31. Programming Paradigms: Your Key to Smarter Software Development https://fullscale.io/blog/programming-paradigms/
  32. Lisp (programming language) – Wikipedia https://en.wikipedia.org/wiki/Lisp_(programming_language)
  33. プログラミング言語の進化と現代ソフトウェア開発への影響 … – note https://note.com/techlabnote/n/n412549eb02b2
  34. Which programming language is the most flexible | Sololearn: Learn to code for FREE! https://www.sololearn.com/en/Discuss/1015997/which-programming-language-is-the-most-flexible
  35. www.cs.yale.edu https://www.cs.yale.edu/flint/cs428/doc/HintsPL.pdf
  36. Why keeping levels of abstraction matters – 8th Light https://8thlight.com/insights/why-keeping-levels-of-abstraction-matters
  37. No Silver Bullet – Wikipedia https://en.wikipedia.org/wiki/No_Silver_Bullet
  38. worrydream.com https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf
  39. プログラム入門：抽象化の話 – なーんだ、ただの水たまりじゃないか https://karino2.github.io/2019/06/12/introabstract.html
  40. DSLとは何か？3分で理解する – Test-Hack https://test-hack.com/domain-specific_language/
  41. プログラミング言語の特徴や用途、種類・分類、年収などをわかりやすく解説 – 株式会社Miraie https://miraie-group.jp/sees/article/detail/programming_gengo_shurui
  42. Choosing the Right Programming Language – DevOps.com https://devops.com/choosing-the-right-programming-language/
  43. se.inf.ethz.ch https://se.inf.ethz.ch/~meyer/publications/hoare/evolution.pdf
  44. (PDF) An Abstract, Reusable, and Extensible Programming … https://www.researchgate.net/publication/259812394_An_Abstract_Reusable_and_Extensible_Programming_Language_Design_Architecture
  45. Abstraction in Technical Computing Jeffrey Werner Bezanson https://worrydream.com/refs/Bezanson_2015_-_Abstraction_in_Technical_Computing.pdf
  46. Programming paradigm – Wikipedia https://en.wikipedia.org/wiki/Programming_paradigm
  47. Pascal (programming language) – Wikipedia https://en.wikipedia.org/wiki/Pascal_(programming_language)
  48. Programming Paradigms: What We’ve Learned Not to Do : r/compsci – Reddit https://www.reddit.com/r/compsci/comments/1kkz43i/programming_paradigms_what_weve_learned_not_to_do/
  49. Levels of Abstraction | Tim’s code stuff https://tgdwyer.github.io/levelsofabstraction/
  50. Homage to John McCarthy, the father of Artificial Intelligence (AI) – Teneo.Ai https://www.teneo.ai/blog/homage-to-john-mccarthy-the-father-of-artificial-intelligence-ai
  51. www.ime.usp.br https://www.ime.usp.br/~alvaroma/ucsp/proglang/book.pdf
  52. www.ebsco.com https://www.ebsco.com/research-starters/history/ibm-develops-fortran-computer-language#:~:text=IBM%20programmer%20John%20Backus%20led,that%20would%20run%20on%20them.
  53. IBM Develops the FORTRAN Computer Language | EBSCO Research Starters https://www.ebsco.com/research-starters/history/ibm-develops-fortran-computer-language
  54. Classic Papers in Programming Languages and Logic https://www.cs.cmu.edu/~crary/819-f09/
  55. Niklaus Wirth | EBSCO Research Starters https://www.ebsco.com/research-starters/biography/niklaus-wirth
  56. en.wikipedia.org https://en.wikipedia.org/wiki/Structured_programming#:~:text=Dijkstra%2C%20who%20coined%20the%20term,handling%20has%20to%20be%20performed.
  57. Edsger Dijkstra and the Invention of Structured Programming – Flatiron School https://flatironschool.com/blog/edsger-dijkstra/
  58. Hoare: Notes on Data Structuring – CS@Cornell https://www.cs.cornell.edu/courses/cs6180/2017fa/notes/week1/lecture2/structured-programming_hoare.pdf
  59. The next 7000 programming languages – Department of Computing https://www.doc.ic.ac.uk/~afd/papers/2019/Next7000.pdf
  60. The next 700 programming languages – Communications of the ACM https://cacm.acm.org/research/the-next-700-programming-languages/
  61. (PDF) Evolution & Trends of Programming Language – ResearchGate https://www.researchgate.net/publication/391627916_Evolution_Trends_of_Programming_Language
  62. プログラミング言語の種類一覧！特徴・用途・難易度を紹介 – SOKUDAN Magazine https://magazine.sokudan.work/post/tips_164
  63. papers.nips.cc https://papers.nips.cc/paper_files/paper/2024/file/2548fbe155ed2405488b7d5373013a64-Paper-Conference.pdf
  64. Bridging semantics and pragmatics in information-theoretic emergent communication | OpenReview https://openreview.net/forum?id=2wlNnIqCb7&referrer=%5Bthe%20profile%20of%20Roger%20P.%20Levy%5D(%2Fprofile%3Fid%3D~Roger_P._Levy1)
コラム