13章はC#を設計したアンダース・ヘルスバーグさんインタビュー。

C#もすでに名をあげた言語のはずですが。
この人のインタビューは刺激的ですな。

それもほとんど概念的な話はせずに、
使いやすい言語を世に出して広めていくにはどうしたらいいのか、
という観点で話が進んでいきます。

ほかの言語と比べても、進化を強く目指しているように思えます。
言語の進化は積み重ねていってある一線を越えると、
言語をとても醜く使いにくいものにしてしまう、
ということはたいていの言語設計者にはわかっていることのようで、
それには気を付けています。

C#の場合はそれにとどまらず、
言語の機能があふれて寿命を迎えることをできるだけ先に延ばしつつ、
それでいて進化を続けるにはどうしたらよいか、
ということを考えて言語を作っていっているようです。

できるだけシンプルで、かついろんな用途に使える汎用的な機能を追加するようにする。
確かにLINQはすごかったですねえ。

あと方向性としては宣言的に記述できるようにすること。
たしかに、そういう方向性が強くなっているようで、大変使いやすくなっています。
その方向で使いこなすことが正しい方向だと思ってよいようですね。

今後の進化の方向性としては、並列性を重視する方向に進むようです。
確かにC#5の発表を見ると、その方向性に進んでいるようでしたね。
ただ、インタビューで言っているほどの進歩を達成できた、
もしくは達成するための一歩となる進化かというとどうなのでしょうか。
結局うまくいかなかったのかな。私の思い違いだとよいのですが。
12章はJavaを設計したジェイムズ・ゴスリングさんインタビュー。

この人は最近Javaをやめたみたいですけど、
インタビューはそれ以前のものでしょう。

ということで完全に現役の言語設計者へのインタビューです。

Pythonもそうでしたが。
実際に成功中の人で、かつ成熟期の言語を主導している人ですから、
夢を語るわけでもなし、
といってこの人の意見が今の常識に大きく影響を与える人なわけで、
常識と違ったことを言うわけでもなし。
全般的に無難なインタビューになってしまっています。

せいぜい、実行時性能でもJavaは優秀なんだといっているくらいですかねえ。
並列性についても語っていますが、放っておいても簡単にできてしまう、
というくらいであまり意見というほどのことはなし。
ほか、完全なウォーターフォールは大規模開発では無理だと言っているとか。

まあやっぱり地味ですな。
普通にしていて世界を先導している人は、かっこいいことを言う必要がないのかもしれません。
11章はObjective-Cを設計したブラッド・コックスさんとトム・ラブさんインタビュー。

これは少し人選を間違えてますかね。
Objective-Cは最近注目されていますが、
それはAppleの技術者が広めているのであって、
最初にObjective-Cを作った人はすでに関係ないようです。

インタビュー中でもそう書かれていますね。

だから、この章は言語設計者へのインタビューというより、
昔、言語設計も行ったような優秀なアプリケーション開発者へのインタビュー、
という形になっています。
ほかの章とはちょっと内容の趣が違いますね。

今やっていることはそれぞれ、レガシーコードの置き換えとSOA技術開発、なのかな。
それぞれに興味深いインタビューにはなっていますが、
言語設計に絡められることはあまり見当たらないようです。

一つ言えることは、言語設計で起こっていたことが、
今はSOAなどでも起こっているということですかね。
いろいろなレベルで、部品を組み合わせていろいろやる方法はあり、
それぞれ別の技術とはいえ関わり合いはあるわけです。

まあ私がこの本を読んでいるのも、
ライブラリ作成において、隣の分野にあたる言語設計が大変役に立つから、ですしね。
10章はSQLを設計したドン・チェンバレンさんのインタビュー。

ほかのインタビューと比べて、
理念や夢を語るのではなく、
非常に現実的に言語使用を組み立てていった様子が書かれています。

SQLに関しては、
夢を組み立てたのはあくまでリレーショナルモデルを考案したコッドさんで、
言語は単にそれに対するクエリの記述を工夫していっただけ、だからなのでしょう。

SQLとにかくクエリ言語としては今でもなお最高に近いものとなっています。
たとえば宣言型の言語であることもそうですし、ほかにもいろいろ完全な機能がそろっています。
.NETのLINQが出た時も、結局文法はほぼSQLのままとなっていました。
検索を指定する方法としてはそれ以上のものが存在しないのでしょう。

が、その辺もRDBの構想あってのものということなのでしょうか。
宣言的記法はかなり先進的だったはずですが、にしてもLispあたりもそうだったわけで、
オリジナルというわけではありません。

非常に使いやすいツールを実直に作った人、と解釈すればよいのでしょう。
その後もXQueryなどを作っているようです。

ただ一つ当時の夢に関係することも答えていました。
Googleの検索システムをかなり評価しているようで。

コンピュータに蓄えられた大量のデータを、素人でも簡単に取り出せるようにすることが、
SQLを作った当時目指していたことのようです。
SQLは結局素人が使えるようなものにはならなかったのですが、
Googleはそれをついに実現したと。

一般人が見るとSQLとGoogleは全然違うもののように見えますが、
大局的にみると同じカテゴリのものだったのですね。
その辺はやはりさすがだと思いました。
9章はMLを設計したロビン・ミルナーさんのインタビュー。

Haskellの人たちもかなり数学的な考え方をしていましたが、
この人はもっと数学的です。

関数型言語というのはそういうものなのでしょうか。
今一つ人口に膾炙しないのはそのせいかもしれません。

ただ、数学的といっても美しい数字の世界にこもっているという感じではないです。
最近ユビキタスの設計を仕事にしているらしく、
その例も盛んにあげています。
つまり、現実世界を論理的に解釈するための数学ということになります。
あくまで数学ですが、実際のプログラム分野に応用できます。
それでいて数学であり完全に論理的なのです。

そういうものをプログラムの世界に取り入れた。
プログラムの世界は職人芸でもやっていけますが、
論理の世界をその中に持ち込むこともまた可能です。
関数型言語は、
そういうことを積極的にやっているから、
常に最先端といわれるのでしょうね。
8章はHaskellを設計したサイモン・ペイトン・ジョーンズさん、ポール・ヒューダックさん、フィリップ・ワドラーさん、ジョン・ヒューズさんのインタビュー。

関数型言語の利点としては、関数型であることそのものによる利点だけでなく、
関数型言語業界に広まっている、先進的な記法をどん欲に取り入れる文化、
にあると思います。

インタビュー中でも、関数型言語の利点は非関数型言語にどんどん取り入れられている、と書いてありますが、
非関数型言語で実装できるのなら、それは関数型言語の利点ではないと思います。

ただ、関数型言語はそれらとの機能との相性は良いそうです。
変数の変更と遅延実行を同時に取り入れた場合、ひどいバグの原因となりやすいなどという例が挙げられています。
LINQなんかはその辺うまく融合させたそうですが。
うまくやる必要はあるということですね。

その辺の相性が良くなりやすいことが、関数型言語の本質的な利点なのでしょう。

変数の値をどんどん変えていくというのは、ノイマン型コンピュータとの相性は良かったのでしょうが、
人間の思考法としては実はけっこう不自然なのではないでしょうか。

インタビューなどから感じましたが、
特に論理的思考との相性は、見るからに関数型言語のほうがよさそうです。

昨今、関数型言語は並列処理に向いているなどと言って注目を集めているようですが、
その利点は一過性のもので、本当の利点はもっと長年積み重ねられている中にあるのでしょうね。

ただ現実は必ずしも論理的ではない分相性が合わない面も、
現在の関数型言語を扱っていると感じるような気がしますが。
論理的だけれど直観的ではない感触がしますね。
7章はLuaを設計したルイス・エンリケ・デ・フィゲイレードさん、ロベルト・イエルサリムスキーさんのインタビュー。

これも小さな言語を作った人たちです。
数行のプログラム用というわけではないようですけど、
その代わり組み込み機器でも問題なく動くスクリプティング言語。

言語に盛り込める要素が有限であることを意識して、
簡単な機能でもじっくり検討してからではないと機能追加しなかったようです。

クロージャなんかも使えるようになっているようですし、
決して古い機能しか使えないというわけではないのですが。
少数の機能が吟味されているというわけですね。

そして細部にわたるまで完成された機能を作ったのでもう機能追加はしない予定だそうです。
便利なソフトウェアというものがどういうものか、考えさせられる話です。

また、その少ない機能の一つ一つについて、パフォーマンスを意識しているとのこと。
常にハードウェアリソースがほとんど使えない状況を意識して、開発を行っているようですね。

VMを採用したにもかかわらず、レジスタベースのものにしているそうですし。

新しく派手な開発も良いものですが、
地味で多少古くても、
はっきりとぶれないコンセプトをもって、
それを追い求めていくのは、美しい開発であると思いました。

6章はAWKを設計したアルフレッド・エイホさん、ピーター・ワインバーガーさん、ブライアン・カーニハンさんのインタビュー。

数行までの便利なプログラムを書くことに最適化された言語です。
3人ともがきちんとその目的を把握していたようです。
だからぶれずに言語設計ができた。

当時AWKでアセンブラを書こうとした人がいて、
あきれ返ったなんて話も出ています。

また、当時から自動テストを当たり前に行っていたそうな。

いろいろな設計の話を見ても、大変論理的に明晰な発言が多いです。

昔、しかも実装もこなしつつ確約した人たちなのに、
今でも明晰に正しいと思えることを言っています。
やはりかしこい人は賢いものです。
5章はBASICを設計したトーマス・E・カーツさんのインタビュー。

これだけ初期の言語にもかかわらず、
学習しやすくなるようにされた配慮の質については、
称賛に値しますね。

不便なところも、当時の状況を考えれば仕方ない面もあり。
構造化が広まってない状況では行番号は確かに最適解ですよね。
今では最適解ではないことは、インタビューでも発言されていますし。

プログラムに、数学の美しさにも似た整合性を求めるよりも、
人間から見た分かりやすさを求める傾向は、最近特に出てきたものだと思っていましたが。
時代を先取りしていますな。
まあCOBOLもそうだったのかもしれませんが。


ただ、理解していないことに関して否定しているのは少し残念でしたね。
おもにオブジェクト指向の話ですが。

まあいっていることはそんなに間違ってないんですが。
カプセル化が重要であって、継承やポリモーフィズムはそんなに重要じゃないというのも確かですし。
カプセル化だけならオブジェクト指向とか言わなくてもいいのも確か。
でも使ってみると結構便利で、さらに設計との連携ができるのですごく便利なのですが。
それがわかったうえで批判しているようには見えませんでした。

あと、FORTRANのカンマで宇宙船が落ちたというのは都市伝説だったはず。
ここでもよく調べずに批判していることになりますな。

ちょっと残念です。
4章はForthを設計したチャールズ・H・ムーアさんのインタビュー。

こんな言語があったとは。
プログラム言語の主要な歴史の流れからは外れていますが、
単独の言語としては大変すばらしいものです。

Cより低レベルな記述を前提としながら、
それを組み合わせることによりかなり高レベルな記述もできる。
まあそれはCの関数もそうなのですが。
文法がかなりシンプルであるため、うまく作れば自然言語に近い記述ができ、
そういう点ではRubyなど高レベル記述に向いた言語と同じようなことができるという。

ただし、インタビューを見ると、
相当天才的な思考が必要であるようですが。
作者が、プログラムは集中して十何時間連続で行うものとか、
チーム開発は無理とか言っているところを見ると、
その人が作った言語も、そういう運用を前提としているのでしょう。

1kB以下のメモリしか持たないようなプロセッサを極めてたくさん並列で動かすようなシステムに最適、
とか設計者の方が言ってます。
実際そういうプロセッサの制作からやっているらしい。
Pentiumへの移植には苦労したとも語ってますが、それはまあそうでしょうねえ。
前提とする使用環境がかなり違ってますから。

設計者の方によると、OSなんて必要ないものを売りつけているビル・ゲイツは詐欺師だそうです。
ハードウェアリソースの管理なんてのは、自分で関数呼び出せば済むことだから、だそうで。

どうも世界の認識が一般人とはずれているようで、
この世界での普及活動は難しいでしょう。
残念なことです。

でもそれにふさわしい実行環境が世の中に存在することも確か。
ハードウェアもユーザーも設計者の思い通りという組み合わせは、世の中に確実に存在しています。
そういう環境に限るとはいえ、非常に美しくプログラムができる方法を作り上げたことは、
素直に賞賛に値すると思います。