プログラミング言語は、さまざまなソフトウェアを創造するための最も基本的な道具である。
コンピュータサイエンスに限らず、私はどんな分野でも道具や素材が大好きだ。それ自身は人を喜ばせたり感動させたりするためのものではないのに−あるいはないからこそ−、想像力と創造力をかきたててくれる。
我が家の書棚にも色々な素材の本が並ぶ。本稿は真面目な話で終わりたいので、まず脱線話をしてしまおう。
文章表現のための素材集は辞書である。辞書をリファレンスとして使うだけではもったいない。引いたときにはなるべく寄り道をする。意外な発見がある。電子化した辞書では同じような寄り道ができるだろうかと心配になるが、電子化辞書ならではの寄り道をブラウザが支援してくれると面白い。
音楽演奏のためのソフトウェア素材は楽譜である。いいなあと思う曲があると、五線譜の上ではどう書かれているだろうかと気になってくる。その結果、自分では弾けもしない難曲の楽譜が電子ピアノの下にずらり並ぶ。が、どんな難曲でも、まったく弾けないということはない。少し練習すれば、数小節のモチーフぐらいはどうにかなる。複雑巨大なシステムプログラムのソースコードを前に、最初は全然歯が立たないと思っても、しばらく眺めていると部分的にわかってくるのと似ている。
工作のための道具や素材が豊富な店といったら、何といっても東急ハンズである。この店は半日いても飽きないが、その東急ハンズが出している
「創造素材カタログ'95」、東急ハンズ、1995も私の愛読書の一つである。
料理もなかなか楽しい。日曜の夕食を作るのはなかなか良い気分転換法だが、スーパーマーケットでの買物もまた楽しい（市場はもっと楽しいだろうが、残念ながら自宅近辺にない）。もちろん、ブラウジングの対象は素材であって、決して惣菜コーナーではない。同じ素材でも、なるべく人間の手の入っていないものが良い。魚ならば切身よりは尾頭つき。肉の場合はなかなか尾頭つきというわけにはいかないが、先日は豚舌がブロックで置いてあったので、１本買ってきて、醤油と八角で煮込んだ。目分量の調理だったが、軟らかく上品な味に仕上がって嬉しかった。カレーライスも、玉葱炒めから始める。料理とは食の世界でのプログラミングではないかという気がしてくる。
たしかに、レシピはプログラムにほかならない。bit記事に料理本をたくさん挙げるわけにもいかないので、１冊だけ、
竹下ワサナ、大江フミ「ワサナのタイ料理」、文化出版局、1993をお勧めする。文化出版局の料理の本は、写真がとてもおいしそうに撮れているのが特長である。
レシピがプログラムならば、料理素材はデータだろうか。
「食材図典」、小学館、1995は発刊当時、売切大増刷になるほど評判となった本で、小生も愛用している。
旅の楽しみは、その計画立案（プログラミング）、旅の実施（プログラムの実行）、旅先で起きるハプニング（例外処理）、そして旅先での発見にある。自らプログラムした旅と、他人にプログラムしてもらい、連れていってもらった旅とでは、旅先での感動が質的に大きく異なるような気がする。
旅の計画と実施のための情報素材は時刻表と地図である。旅行ガイドブックも役には立つが、これはあくまで本物の旅行の補助であって、それ自体読んで楽しいというものではない。一方、生データである時刻表と地図があると、机上で楽しい仮想旅行（これはシミュレーションごっこか）までできてしまうのである。データマイニングやデータベースからの知識発見技術が注目を集めているが、生データを眺める楽しみは、まさにデータベースからの知識発見の楽しみである。生データで飽き足りない向きには、生（オリジナル）のルールベースも出版されていて、たとえば国鉄の
「旅客営業規則、旅客営業取扱基準規程」、交友社、1974もかつての愛読書であった。規則規程の改定のたびに該当ページを差し替える加除式で、JR発足直前までアップデートを続けた。
昨今ではホームページ作成のための「素材集」も売られているが、私はこれは素材よりは惣菜に近いものではないかと思う。素材集を買わなくても、Adobe Photoshop（のほうが桁違いに高価だが）の機能を使うと壁紙のテキスチャくらいは自作できる、ということが、たとえば韓国の鄭碩奎氏による
鄭 碩奎(Jung Suk Kyu)「デザイナーのためのPhotoshopアートワーク」、ビー・エヌ・エヌ、1997を読むとわかる。ノイズパターンの生成加工変形でこれだけのものが作れるというのは驚きであるが、考えてみるとこれは、画像という領域で、関数型プログラムを人手で実行しているようなものである。
かくのごとく、素材主義ないしは素材趣味は、プログラミングやプログラミング言語とあい通ずるところが多い。
コンピュータサイエンスにおけるプログラミングやプログラミング言語の重要性が、相対的に低下してきているという声がよく聞かれる。たしかに、API (application programming interface)、デザインパターン、コンポーネントなど、世の中の関心は、ある程度高位の部品をいかにうまく組み合わせてソフトウェアを構築するかという点に移りつつある。それはそれでとても大事なことで、そのような技術を知らずに、2ヶ月後に納期の迫った大規模ソフトウェアの作り方を語ることはできない。しかし同時に、小規模であっても珠玉のように輝き、10年以上にもわたって磨きがかかりながら使われるようなソフトウェアもある。前者と後者の違いは、「製品」と「作品」の違いであろう。
「作品」やソフトウェア文化に果たすプログラミング言語の役割は、依然としてとても大きいと思う。言葉を大切にしないコミュニティに豊かな文化が育つとは思えないし、文化を担うものであるからこそ、異なるプログラミング言語コミュニティの間の議論は、1980年前後の Lisp 対 Prolog 論争に代表されるように、時に宗教戦争のような様相を呈したりもする。
「製品」としてのソフトウェアの開発においても、プログラミング言語はもっと重視されてよいと思う。どんな言語で書いてもそこそこの工数で開発できてしまうようなソフトウェアはともかく、本当に高度なソフトウェアやソフトウェア部品の設計開発が、Ｃ言語だけですむとは思えない。たとえば、某社では、知識処理ソフトウェアの記述言語をある時期にLispからＣに置き換えた。色々なプラットフォームで動かなければならないという要請からだが、
「それで、生産性は落ちませんでしたか？」と尋ねると、果たして
「落ちました ...」との返答。学生諸君を見ていても、どんなプログラミングの課題も、一番書き慣れたＣ言語で書いてしまおうとする人が多い。とっかかりは早いのだが、ネットワークプログラミングやアニメーションなど、少し課題が高度になってくると、いつまでもソフトウェアが安定して動かず苦労しているようである。
関数型、論理型などの非手続き型のプログラミング言語の海外の研究者とゆっくり話す機会があると、たいがい「どうやったら非手続き型言語が(もっと)主流になれるだろうか」の議論が始まる。あるとき、並行制約プログラミングの提唱者として知られるAT&TのVijay Saraswat氏とこの話をしていて
大規模なソフトウェアを構築するのには、コンポーネントという抽象化が重要な役割を演ずる。が、質的に難しいソフトウェアを構築しようとしたら、プログラミング言語や、その基礎になっている計算モデルがどのような強力な概念を提供してくれるかが、決定的に重要であるような気がする。豊かなソフトウェア文化を構築しようとしたら、そのために使う言葉を大切にし、よく学ばなければならない。
外国語でも、とりあえず相手に通じればよいというレベルと、美しく正確な言葉で話せるというレベルがあるが、高等教育の目標はむろん後者である。人のプログラムの真似をしつつ、処理系にわかってもらえるプログラムが書ければよい、というレベルを越えるためには、プログラミング言語自身について学を修めなければならないであろう。英会話（プログラミングの勉強）と英文法（言語の勉強）、どちらも必要なのだ。
プログラミング言語の道に入るのは、ある程度プログラムが書けるようになって、言葉自体に興味がわいてきてからであろう。
大学でも、プログラミング入門のあとで、データ構造、制御構造、抽象化、型システムをはじめとするさまざまな基礎概念を学び、同時に構文（シンタックス）や意味（セマンティクス）を厳密に定義する方法の初歩を学ぶ。また、言語の実装の基本を学ぶ。手続き型言語、関数型言語などの基礎をなす計算モデルについても学ぶ。
これらは情報系のすべての学生にほぼ必須であるが、考えてみると「真面目な」「学科目としての」「一般論の」勉強である。本当の意味で「プログラミング言語の道」に入るには、具体的なプログラミング言語の言語仕様を端から端まで熟読するという経験が重要ではないかと思う。それも、いくつもの言語仕様に接することによって、鋭敏な言語感覚が磨かれてゆくように思う。海外旅行によってものの見方が広がるのと同じように、色々なプログラミング言語に接することは、異文化に接することでもある。
振り返ると、私はそのような経験を何度か積んできた。序章で述べたように、自分の使う道具には凝る方であるから、自分が道具として使うプログラミング言語の仕様書も、すみずみまで読んでおかないと気が済まない。また、プログラミング言語の仕様書はそれ自体が一つの作品であり、今でも、新しい言語のオリジナルの仕様書に接するときには胸が踊る。
仕様書は読みにくいという人がいるかも知れないが、その言語の基本概念やプログラミングを入門的文献などで押さえたあとは、最も厳密に書かれているはずの原典にあたるのが、細部を正確に知るには最も早道であり、仕様の書き方の勉強にもなる。
仕様書は分量が多くて大変だと思う人もいるかも知れないが、そういう人は、まずは簡潔な言語の簡潔な仕様を読んでみるとよいであろう。同じ言語でも、生まれてから国際規格に成長する過程で仕様書が分厚くなってゆくのが普通である。そのような言語は若い時代の仕様書を読む方が、設計者の考えがよく見える分だけ、仕様としての完成度は低くても読み物として楽しいかもしれない。個人的には、大きな言語であっても、そこから新たな概念や強烈な思想を読み取ることのできるものであれば、読んでいて楽しい。反対に、概念や思想が希薄なプログラミング言語の仕様書を読むのは時間の無駄である。
以下では、そのようにして読んだ言語仕様書関係の本のうちのいくつかを、感謝の気持ちも込めつつ紹介したい。現時点での読書ガイドとして通用するかどうかは意見の分かれるところかもしれないが、すぐに陳腐化してしまう普通の情報関係書籍と比べたら、これらの本が現在持っている資料価値は驚くほど高いのではないだろうか。Original work とderived workの重みの差である。
私が最初に接したプログラミング言語の書籍は
森口繁一「JIS FORTRAN入門[上・下]」第2版、東京大学出版会、1973であった。この本でプログラミングを学んだ人の数はどのくらいになるだろうか。森口先生ならではの教育的配慮が随所に散りばめられた本で、いま読み返しても、その配慮には教えられることが多い。初版は1968年、現在も1984年刊の第3版が現役で、驚くほど長寿の本である。
西村恕彦「JIS FORTRAN全釈」オーム社、1974も読んだ。自然言語で定義されたプログラミング言語仕様に対し、徹底的な検討を加えて解釈や批判を行なった本である。これを読んだのは修士課程在学中だったろうか、そのときすでにFORTRAN言語自身に対する興味はなくなっていたが、それでも西村先生の言語考究の厳しさに接するために飽きることなく読み進んだものである。
筆者が大学院に進学した1978年は、日本でもPascalが教育の現場で普通に使われるようになった時期である。Pascal自身で書かれたコンパイラのソースコードにアクセスでき、言語自身とその実装の勉強を同時に進められたことはきわめて有益であった。コンパイラが全部で6,000行くらいであり、頑張れば読破できる分量であったのも良かった。豊富なデータ型機能にも開眼させられた。
大規模ソフトウェア構築に対する配慮がなかったことなどから、1990年代に入ると、日本では実践ばかりでなく教育の場からも引退が始まったが、その大幅な拡張であるObject Pascalが、開発環境Delphiの核言語として踏ん張ってくれているのは嬉しい。 Pascalはたくさんの教科書が出たが、オリジナルの
K. Jensen and N. Wirth, PASCAL User Manual and Report, Springer-Verlag, 1974が読み易く、これと和田英一先生のbit連載
和田英一 プログラム言語Pascal、bit、Vol.10、1〜10月号、1978における詳細な仕様検討は熟読し、かつ研究室の人とよく議論もした。
Algol 60は、その完全な実装がきわめて困難で、不完全な実装ですら日本では利用が容易でなかったにもかかわらず、プログラミング言語を学ぶ学生にとっては重要な古典でありつづけた。私も、
米田信夫、野下浩平「Algol 60 講義」、共立出版、1979で勉強した。この著作に示された解釈・批評も実に厳しいものである。上述の「JIS FORTRAN全釈」「プログラム言語Pascal」とこの「Algol 60 講義」の三著作から、言語設計の微妙な側面と言語仕様記述とに関して学んだものは計り知れない。
Algol 68も読んだ。
A. van Wijngaarden et al. (eds.), Revised Report on the Algotithmic Language ALGOL 68, Acta Informatica, Vol. 5, pp. 1-236, 1975２段階文法による静的意味論の記述を特徴とするものだが、評判通りなかなか手強いレポートであった。
PascalやAlgol 68とともにAlgol 60の後継を争った国産言語Algol Nもここに記しておかねばなるまい。設計者の一人、故・島内剛一先生による
島内剛一「プログラム言語論 −ALGOL 60からALGOL Nへ−」、共立出版、1972にその思想や仕様が書かれている。最近でもRWCP (新情報処理開発機構)のMPC++など、拡張機能をもった言語が提案されているが、国産言語ALGOL Nが拡張可能言語のはしりでもあったことは、ここに記す価値があろう。
今日の読者諸氏にはほとんど想像できないことであろうが、1980年頃、世界中で最も注目を浴びた新しい手続き型言語はAdaであった（Ｃ言語がポピュラーになったのはその後のことである）。米国国防総省が出した高水準言語に関する要求仕様(STEELMAN)に従って競作された言語仕様の中から、フランスのJean Ichbiahたちの言語が採択されてAdaと名付けられたものである。Pascalの次の高級言語ということで、日本でも東大の米田研、和田研などを中心に精力的に勉強会を開き、言語仕様の詳細検討を徹底的に行なった。その原典は
「プログラム言語Ada基準文法書(英文)」、bit別冊、共立出版、1981であり、おそらくこれは、あらゆるコンピュータサイエンス関係書の中で、私がこれまでで最も深く読んだ文献であろう。その詳細検討の結果は、解説書
米田信夫編「プログラム言語Ada」、bit臨時増刊、共立出版、1981として出版され、当時博士2年であった私も40ページほど執筆させていただいた。その内容を英訳して設計者に送ったりもした。それが現在のAdaの仕様に何らかの形で活かされたかどうかは知らないが、当時あれだけ脚光を浴びた言語が、今となっては、ほとんど注目を浴びることがなくなってしまった。
個人的には、このときの努力と苦労を転機に、大きく複雑なプログラミング言語から離れ、簡潔な言語の追求を強く指向することになる。
Lispに最初に接したのは1976年度の後藤英一先生の講義であった。原典と呼べる
J. McCarthy et al., Lisp 1.5 Programmer's Manual (2nd ed.), The MIT Press, 1965は、学部学生だった私には、言語自体が不思議である以上に摩訶不思議なマニュアルだった（いま見てもそう思う）が、図書館の本をコピーして、わかるところだけ読んだ。
その後もいくつものLisp方言のマニュアルを目にしたが、Lispの発展と肥大化に反比例して、言語仕様自身に関する興味は薄れていってしまった。ただ一つの例外はSchemeである。
W. Clinger and J. Rees (eds.), Revised^4 Report on the Algorithmic Language Scheme, ACM Lisp Pointers, Vol.4, No.3, pp.1--55, 1991. （http://www-swiss.ai.mit.edu/scheme-home.htmlから入手可能）この文書は、その薄さや、言語仕様記述における厳密さと簡明さのバランスなど、いろいろな意味で仕様書の理想であると思う。プログラミング言語を志す学生にはぜひ一読してほしい文書である。
ところで、このSchemeの仕様書のタイトルには“Dedicated to the Memory of ALGOL 60”と添え書きされている。実際、その第１ページの体裁などは、Algol 60の仕様書を忠実に模したものでほほえましい。
Schemeのもう一つの特徴は、プログラミングやプログラミング言語論についての優れた教科書がいくつもあることである。
D. P. Friedman, M. Wand and C. T. Hayes, Essentials of Programming Languages, The MIT Press, 1992.
H. Abelson and G. J. Sussman with J. Sussman, Structure and Interpretation of Computer Programs, 2nd ed., The MIT Press, 1996.
Lisp関係といえば、やはりλ計算の原典も挙げておきたい。
A. Church, The Calculus of Lambda-Conversion, Princeton University Press, 1941 (reprinted in 1985).この薄い本（77ページ）は、10年くらい前だったろうか、復刻版が出たのを洋書案内カタログで見つけて入手した。
1980年代前半から、Prologや論理プログラミングが世界的に注目を集めることになったのには、日本の第五世代コンピュータプロジェクト(1982-1993)が大きく貢献している。私も第五世代プロジェクトには深くかかわったが、実は、Prologに関する書籍を深く読んだことはない。自分の専門分野に近いことほど自分や周囲の人の頭の中に入っているし、考えればわかることも多いから、一冊の書籍をじっくりと通読する機会を失ってしまうものである。
ともかく、Prologの世界では、Edinburgh PrologないしはDEC-10 Prologと呼ばれるシステムが長らくデファクトスタンダードをつとめた。その原典と呼べる文書は、
D. L. Bowen (ed.), DECSystem-10 PROLOG User's Manual Dept. of Artificial Intelligence, Univ. of Edinburgh, 1983である。Prologの標準化に関する仕事は、
P. Deransart, A. A. Ed-Dbali and L. Cervoni, Prolog: The Standard. Springer-Verlag, 1996に詳述されている。
論理プログラミングの一般化である制約論理プログラミング、あるいは（さらに一般に）制約プログラミングは、宣言型プログラミングの中で大きく進展しつつある分野である。この分野はこれまで、多数の論文が出版されてきたにもかかわらず適当な教科書がなかったが、ようやく
K. Marriott and P. J. Stuckey, Programming with Constraints, An Introduction, The MIT Press, 1998が出版されるはこびになった。読むのが楽しみである。
第五世代コンピュータプロジェクトの並列核言語(KL1)の設計目標の一つは、計算の粒度を規定しないプログラム記述にあった。これを追求した結果、GHC (Guarded Horn Clauses)という、並行並列処理の記述言語としては非常に単純な枠組みを得ることができ、並列核言語の土台とすることができた。単純さに徹底的にこだわったのは、そうしておかないと並行並列プログラミングの概念的な複雑さに対処できないだろうと考えたからでもあり、自分の過去の研究からの反動でもあった。
GHCの基本概念を記した本は、
淵一博監修、古川康一、溝口文雄共編「並列論理型言語GHCとその応用」、共立出版、1987であり、言語の基本概念や当時の実装の解説をはじめ、いくつかの章を執筆させていただいた。GHCについての英語の本も出版する約束を交わしたのだが、予定を10年以上過ぎた今も果たせないでおり、もしかすると出版業界のブラックリストに名前が載ってしまっているかもしれない。
KL1を核とした並列処理や知識情報処理の多様な研究成果は、
瀧 和男編「第五世代コンピュータの並列処理」、bit別冊、共立出版、1993によくまとまっている。
手続き型言語の世界でも、最近ようやくスレッドプログラミングが普通のものになってきたが、そこで用いられている並行処理記述の道具を見ると、古典に舞い戻ったような印象すら受ける。
ことほどさように多くの言語に接してきたにもかかわらず、私とＣ言語との付合いはきわめてあっさりとしたものである。それでも、湯淺太一先生が設計した超並列言語NCXの理解のために、
B. W. カーニハン/D. M. リッチー著、石田晴久訳 「プログラミング言語Ｃ 第２版」、共立出版、1989は、1993年になって隅々まで呼んだ。原文自体のせいか翻訳のせいか、この訳本には意味の了解できない表現が大変多く、読みながら不明箇所に貼っていった付箋紙は数十枚に及んだ。研究室の同書には、そのときの付箋紙がそのままになっている。共立出版創立以来のベストセラーであり、しかもこれだけ主流になった言語の原典であることを考えると、いささか残念な気がしたものである。果たしてその翌年、
B. W. カーニハン/D. M. リッチー著、石田晴久訳 「プログラミング言語Ｃ 第２版（訳書訂正版）」、共立出版、1994が出版された。こちらは通読していないが、翻訳に起因する問題点はいくぶん改善されたようである。しかし、国際規格に基づいてJIS規格ができた言語の詳細を知るならば、
「JISハンドブック 情報処理 プログラム言語編」、日本規格協会、1997を一冊備えて読むのが、翻訳の質の点でも確実と言える。
C++の仕様書はきちんと読んだことがない。私にはこの言語は複雑すぎる。こういう言語とは要領よく付き合えばよいのだと
梅村恭司「C++プログラミングの急所とスタイル」共立出版、1995を著した梅村恭司君がアドバイスしてくれたが、なかなかそれができない。
ときには風変わりな言語に接するのも楽しい。たとえば文字列操作言語SNOBOL4の原典
R. E. Griswold, J. F. Poage and I. P. Polonsky, The SNOBOL4 Programming Language (2nd ed.), Prentice-Hall Inc., 1971も修士課程のときに通読した。独自のパターンマッチングをはじめとし、実にユニークな制御構造をもった言語であった。処理系も手近にあって楽しめた。
COBOLも、情報科学を専攻する学生にとってみれば風変わりな言語であり、好奇心から同じころ勉強し、プログラムも書いてみた。
ところで私が最近数年間、どんな言語でよくプログラムを書いてきたかというと、
D. E. Knuth: The TeXbook, Addison-Wesley, 1984は、頭から1/3位まで通読したところで中断してしまったが、Knuth先生の蘊蓄と細部への徹底的なこだわりに接することができ、読んでいて実に楽しい。プログラミング言語としてみると何ともすごい設計であるが、plain TeXは（標準的でないフォントを使わない限り）大変にソフトウェアの移植性の高い言語である。私自身もplain TeXだけで国際会議投稿論文の採点集計プログラムなどを書いたことがある。
PostScriptも、レベル１だった時代にReference Manualを読み、いろいろプログラムを書いて楽しんだ。PostScriptのコードなど手で書くものではないと思っている人が大多数らしいが、こんなにいろいろなグラフィックス概念を提供してくれている言語のプログラム作成を、機械だけに楽しませておく手はない。手書きの方が、はるかに簡潔な記述で高品質な出力を得ることができる。グラフィカルな描画ツール類の存在意義は認めるが、それらは、そのような手書き品質のPostScriptコードを生成するためのユーザインタフェースとして設計すべきだと思う。
最近のPostScriptプリンタに内蔵されているPostScriptレベル２の仕様書を読む前にレベル３が出てきてしまったが、いま時間ができたら読みたいと思っているのは、PDF (Portable Document Format)の仕様書
T. Bienz, R. Cohn and J. R. Meehan, Portable Document Format Reference Manual, Version 1.2, Adobe Systems Inc., 1996. （http://www.adobe.com/supportservice/devrelations/PDFS/TN/PDFSPEC.PDFから入手可能）である。私は、情報関係（に限ることもないのだが）の学術論文誌は、あと数年のうちに出版形態が大幅に電子化されるのではないか、そうならなければならないのではないかと考えている(実際ACMがその方向に動きはじめ、論文誌のPDFによる電子配布を開始した)。その意味で、PDFは大変重要な言語になってくると思われる。
このほかにも
書店での情報関連書籍の陳列スペースは、他の分野をどんどん侵食する勢いである。しかし、刊行点数の増加はそれ以上であり、
最も難しいのは最新の動向を書いた本であり、急いで書かれた本は、整理が不十分で難解であることが多い。最近は歳をとったせいか図々しくなって、読んでわからなかったら半分は著者の責任だと思うことができるようになり、少し楽になった。問題は、大学などの図書館の体制が、内容の陳腐化の速い専門書籍の存在に対処できていない点で、このままでゆくと開架の書籍の玉石混淆比、つまりは学生諸君がすぐれた書籍に出会うチャンスが、急速に低下してしまうのではないかと大変恐れている。実際、コンピュータサイエンスの知識など学術書から学ぶものではないと思っている学生が、かなり多いのである。
私は自衛手段として、自分の眼で選んだ専門書を自分のオフィスに並べ、学生諸君が自由に出入りしてそれらをブラウジングすることを強く推奨している。良い本に出会うチャンスを増やすにはこれが最善と思うからであるが、良い書籍に対して敬意をもって接するようになってほしいという気持ちからでもある。そのような敬意を育てるために、出版社も、良い本をやすやすと絶版にしたりしないように努めてほしいと思う。また、次々と新たなシリーズ物を企画するのではなく、一度出した良いシリーズ物−たとえば『岩波講座ソフトウェア科学』のような−をup-to-dateに保つ努力をしてほしいと思う。それは著者の苦労に報いることにもつながる。
私は、本を眺めたり買ったりするのは好きだが、いいかげんに読むことができないという性格が災いしてか、買った本のほとんどを読めずにいる。だが、こうして振り返ってみると、プログラミング言語の仕様書だけはけっこう読んできたようだ。
プログラミング言語の設計は、理論的な美しさ、実装への配慮、応用プログラムの記述性の三者間の微妙なバランスをとらなければならない。設計する言語の目的によって、どの面に力点を置くかは当然異なってくるが、デザインスペースの全体を理解した上での設計とそうでない設計とでは深みが違う。プログラミング言語やプログラム理論の論文を読んでいて、「これはセンスがいいなあ」とうならせるのは、理論もできるしプログラムも書けるという文武両道の人の論文である。そのようなセンスを多くの人に身につけてほしいと思う。
コンピュータの世界は、アーキテクチャにせよ、オペレーティングシステムにせよ、プログラミング言語にせよ、（偶然に、あるいは巧みな戦略によって）主流となったものが寡占状態を作ってしまう世界である。しかし、市場占有率と技術的な面白さとはほとんど独立である。多数派の陰に隠れた少数派の中からも、せめて技術的に面白い点だけは学びとって正当に評価し、後世に受け継いでゆきたいものである。そのような努力と多様性の維持は、分野の健全な発展にも不可欠なものと思う。