■ 1. プログラミング言語構文と自然言語
- 問題提起: プログラミング言語の構文はしばしば自然言語（特に英語）に似せられるが、これは必ずしも合理的な設計ではない。
- 暗黙の仮定: 「自然言語のように読める構文が良い構文である」という暗黙の仮定が存在するが、この妥当性を考察する必要がある。
■ 2. 構文の合理性を測る基準
- import文の語順:
- 論点:
import以外のキーワードで始まる構文は不便か。- 例: Pythonの
from ... import ...や、Haskellのimport qualified ...の語順は、慣れていないと不便に感じられることがある。- 合理性:
- 視認性:
importキーワードと対象の名前が近い方が読みやすい。- 編集の利便性: テキストエディタのソート機能で簡単に並び替えができるよう、先頭にキーワードが来る方が良い。
- 頭でっかち構文の是非:
- 論点: 重要な要素が長い修飾子によって後回しにされる構文は読みづらいか。
- 例: C/C++における長い返り値の型定義、Haskellにおける長い型制約。
- 合理性:
- 可読性: 関数の名前など、重要度の高い部分が先に来る方が、コードを読み進めやすい。
- 対策: C++11の
autoや、Rust/Swiftのwhere節のように、重要度の低い部分を後置にできる構文がより合理的である。- 前置キーワードの必要性:
- 論点:
ifやtryのような構文を示すキーワードが、対象の式の前にあった方が良いか。- 例: PerlやRubyの後置if文、Pythonのif式は賛否が分かれる。Standard MLの
handle式のように前置キーワードがない構文は失敗だったと筆者は考えている。- 合理性:
- 可読性: 構文の種類を示すキーワードが先頭にある方が、コードの構造を素早く理解できる。
- 例外: Lisp/SchemeのS式は前置キーワードの原則を徹底しているが、必ずしも広く普及しているわけではない。
■ 3. 自然言語とプログラミング言語の違い
- 大きな構造: プログラムはモジュールやクラス、関数といった構造を持ち、必要な部分だけを把握して読めることが重要である。
- 記号の活用: プログラミング言語では記号を多用するため、スマホのキーボードや音声入力には不向きである。また、記号が多すぎるとコードが暗号化する問題もある。
- インデントの活用: プログラミングではインデントで構造の深さを明示する。固定幅のインデントが一般的なエディタでうまく機能するよう、言語設計を工夫することが望ましい。
- 規則性: 自然言語には例外が多いが、プログラミング言語は学習コストの観点から、例外を減らして規則的であるべきである。
- 表現の多様性: 自然言語では同じ内容を別の言い方で表現するが、プログラミング言語では一つの内容に対する書き方は一つに定まっている方が、定型的に読み書きできて望ましい。
■ 4. 結論
- 多様な合理性: プログラミング言語の合理性は、「人間が書く・読む」「コンパイラが処理する」「シンプルなエディタやIDEで編集する」など、様々な観点から議論できる。
- 自然言語との距離: プログラミング言語と自然言語は異なる媒体であるため、自然言語に似せた構文が無条件に優れているとは言えない。