"言語設計者たちが考えること" Federico Biancuzzi, Shane Warden 編

おいらは、プログラマでもなければ数学者でもない。なのに、プログラミング言語も数学もちょっとかじる。どちらも便利な道具だから。プログラム用法には、文章用法が少なからず影響を受けているのだろう。どうりで千鳥足の彷徨者は、テーマから酷く逸脱した、冗長したスパゲッティ文章を量産するわけよ。
「設計や実装のシンプルさという価値を過小評価してはいけない。複雑さはいつでも追加することができる。達人はそういったものを取り除くのだ。」
巷では、プログラマに数学の知識は必要か？という議論がある。コンピュータが数学的に設計されている以上、黎明期は数学者やコンピュータ科学者の影響力が強かった。ここに登場する言語設計者たちも、数理論理学、情報工学、計算機科学などを専攻する人が多数派で、数学は必要だとする意見が多い。確かにクラス型は、群、体、環、あるいは線形空間といった代数的構造に対応する。
しかし一方で、プログラムを意味的に捉えれば、極めて言語学に近い。自然言語もプログラミング言語も、人間の思考や行動の表記法として君臨するのだから。少数派ではあるが、文学修士号を取得する者、芸術団体の理事や音楽家の経歴を持つ者、あるいは趣味を開花した者まで登場する。そして、数学が苦手だと公言する人がいれば励まされる。彼らの表記法へのこだわりが、プログラミング言語を人間味ある表現に近づけ、より庶民的にしてきたのは確かだ。現実に、数学と縁遠いとされる社会学や経済学にも便利な道具として重宝され、文系出身のプログラマもわんさといる。高度な数学の知識を隠蔽するという意味では、言語文化にオブジェクト指向が根付いていると言えよう。とはいえ、数学の知識があるに越したことはない。それが学問の幅というものであろうから。
...数学落伍者の嘆きより。

本書は、C++, Python, APL, Forth, BASIC, AWK, Lua, Haskell, ML, SQL, Objective-C, Java, C#, UML, Perl, PostScript, Eiffel, Ruby に携わった27人の言語設計者たちのインタビュー集である。彼らに共通していることは、既存の言語に囚われない柔軟な発想の持つ主であること、そして、なによりも情熱の塊のような連中だということである。
「情熱を持って好奇心を追求する。素晴らしい創造や発見の多くは、適切な答えを導き出す準備が整った状況で、適切な時に、適切な場所に誰かが居合わせた場合にのみ生み出される。」
プログラミング言語は、どれをとっても長所と短所があり、万能なものなど存在しない。そして、極めて文化的で宗教的なところがある。数学者や科学者でさえ愛用言語への思いは強く、互いの短所を罵り合う様相はケインズが揶揄した美人投票にも似たり。プログラミング言語の優位性は、企業の圧力や宣伝力に左右されることが多く、科学的に評価されることは少ないようだ。
人間の思考は、人体という構造体によって支えらえる。その構造体は、細胞、特定の機能を持つ器官、更にある目的を果たすために互いの器官が連携し合う組織系によって構成される。その上に、精神なる得体の知れないものがあるとされるが、どこまでを実体と言うかは知らん。個体が形成されるまでに様々な構成段階があるのは、まさにオブジェクトクラス。プラトン式イデアという純粋なデータ構造に、ダーウィニズムというある種の時間の概念が加わると、エントロピーの原理がごとく複雑系へと進化する。過去の抽象化の流れは、未来の抽象化の姿を見せ続けるであろう。

さて、言語にまつわる泥酔者軍団の仕事環境を、ざっと紹介してみよう。...
だいたい5,6人のチームで、おいらはプロジェクトリーダをすることが多い。歳のせいかは知らん。分野で言えばデジタル回路設計となるのだが、ここ十年は検証環境ばかり面倒を見ている。デバッグ作業は大嫌いだが、検証環境を構築するのは嫌いではない。それに、実装の制約に囚われず、自由におまけ機能が搭載できるし、使用言語もそこそこ自由。回路設計といってもソフトウェアとの境界はますます曖昧になり、回路部をHDL(ハードウェア記述言語)で書き、その周辺を様々な言語で書いて協調させる。回路に実装する機能はプロセッサや信号処理アルゴリズムなどで、その検証用の等価モデルをプログラミングする。モデリングでは、C か C++ で要求されることが多い。数学的な要素が強い部分では、Octave(数値演算言語)を組み合わせることもしばしば。
実験的に使い捨てコードを書くことが多いので動的言語を使いたいが、渋い顔をされる。パフォーマンスを理由にされても、大差ないのだけど。統合的な実行環境では、shellやTcl/Tkなどを用い、awk, sort, sed, grep, diff といったunix系コマンド群をいまだに重宝している。方針としては、なるべくスクリプト言語を使い、assertion機能を駆使するといった感じであろうか。
ちなみに、Anders Hejlsberg は、中心的なデバッグツールは、Console.Writelineメソッドだと言っている。要するに、ちょっとしたステートメントを埋め込むだけで、かなりの問題を探り当てることができるというわけだ。多くのプログラマにとって、それが実態であろう。達人がこういう発言をしてくれるのは救われる。複雑なケースにおいては、スタックトレースや局所変数などの監視が必要になるのだけど。だからというわけでもないが、Ruby がお気に入り。なかなか認めてくれないから、趣味で導入しているけど。
操作性を、GUI環境にしろ！という話もあるが、却下！却下！お偉いさんは見た目がお好きなようで、担当者の誰もそんなことは言わない。画像処理系では絵を直接見たいという要求があり、Gnuplot, LibTIFF, ImageMagick と協調させると喜ばれる。これも趣味だけど。統計情報やログ管理では、Perl で要求されることが多い。趣味で Ruby を使うけど。確かに、Perl は文字列操作が強力だ。そして、正規表現を埋め込むとますます暗号文っぽくなりやがる。ちなみに、Perlファンは、"Pathologically Eclectic Rubbish Lister"(病的折衷主義のガラクタ出力機)と呼ぶそうな。自虐楽観主義とでも言っておこうか。こんな楽しみ方があってもいい。
...てなわけで、おいらのプログラミング言語への思いは趣味ぐらいなものである。ソフトウェア工学なんて学んだこともない。最近、教育の依頼を受けることがあるが、教えられるものなど何もない。使えないと思ったら見捨ててもらって結構だ。技術を学びたければ、気に入った師匠を見つけて弟子入りすればいい。師匠が書籍であってもいいではないか。有名な講義がネット経由で受講できる時代、わざわざこちらから教育方針を打ち出す必要もない思うが、組織となるとそうもいかないらしい。とりあえず、コードレビューが重要だということは言っておこうか。哲学的な意識合わせが目的で、書き方を規定するものではない。メンバーが固定化するとやらなくなるけど。
言語がいくら汎用的に設計されても、すべての機能を喧嘩させずに共存させることは難しい。したがって、特定用途向けの言語を組み合わせることは合理性に適っている。動的言語が流行るおかげで、他言語へのハードルを低くしてくれるのもありがたい。そして、各々の言語システムを組み合わせながら、ユーザ独自の統合環境を構築することになろう。問題を一番理解しているのは、その問題に直面している連中であろうから、そこに独自の表記法が生まれても不思議はない。クラス群の名詞とメソッド群の動詞を特化した言葉で抽象化するだけでも、立派な言語システムに見えるだろう。アプリケーションを作るとは、ある種の言語を作ると言うことができるかもしれない。
あらゆる学問で、専門用語や独自の表記法が編み出される。自然言語においても、日本語や英語などの大きな枠組みがあるにせよ、独自の解釈とニュアンスの下で単語が用いられ、誰一人として同じ言葉を喋っちゃいない。言語が精神と結びつくならば、本質的に多様性を内包することになるだろう。

1. 言語選択
当初目をつけていたのは、Python と Objective-C であるが、本書のおかげで APL や Haskell にも興味がわく。
APL は行列代数をうまく扱うという。まさに画像処理の次元空間を扱うのに良さそう。実は、ハードウェア記述と配列記述は相性がいいのではないかと思っている。ただし、表記法は従来の代数表記とは景色が違う。演算の優先順位が右から左、ただそれだけ。なるほど、小学校から馴染んできた四則演算で、加減算より乗除算が優先されるなんて不自然かもしれない。単純に並べ順を変えれば余計な規定は不要というわけか。宇宙人が地球人に接触しようとしないのは、そこに住む知的生命体が奇妙な優先順位に囚われているからであろうか？真理を無視してまで。
Haskell では副作用の制御が強調される。これが関数型言語の長所で、並列化を容易にするという。回路設計と並列化の概念は直結するだろう。
むかーし、言語を選択する基準の一つにデータ型の明確さがあった。BASICのように自動で型変換されることに違和感があった。性格から来るのかは知らんが、コードの間違えはキャストミスから起こることが多い。ただ、厳格過ぎるのも鬱陶しい。近年の動的言語は数値リテラルが厳格など、その按配が肌に合う。Haskell や ML は型推論の機能を備えているそうな。だが、静的な型付けが悪で、動的な型付けが善とも言い切れない。自動化の弊害は、本質的な思考を疎かにさせるところがある。
尚、Dennis M. Ritchie は「C言語は強い型付けと、弱い型チャックを特徴とした言語である。」と述べたという。Tom Love は、Objective-C よりも C++ が使われる理由は「AT&Tの威光があったから」と言い切る。
また、ポインタから逃れるために Delphi や Java を検討した時代もある。結局、C言語を基準とする見方は変わっていない。なんだかんだ言っても、C世代か。ちなみに、学生時代、ある女生徒が「はじめてのC」がいいよ！という発言に、男性諸君は皆振り返ったものだ。
C が常に選択肢として残るのは、やはり安定性であろう。せっかく使う言語がいつのまにか消滅するのではリスクが大きい。ただ、レガシーコードが亡霊のように付きまとい、仕方がない面もある。
近年、オブジェクト指向言語を選択するという流れがある。この用語が過度な熱狂から生じたという見方があるものの、コードと向かい合う考え方が整理できるのは大きな意味がある。ガベージコレクションが搭載されるかどうかも大きな選択肢となろう。実行速度を犠牲にすることも否めないが、動的なメモリ管理を酔っ払いはできるだけ避けたい。この機能をオブジェクト指向の概念に含むかどうかは、意見の分かれそうなところか。
ところで、入門言語は何がいいか？とお聞かれると、Rubyがいい！と即答していた時期があった。だが、微妙かもしれない。便利なものに慣らされて、面倒な知識を後付けする方がずっと辛いから。この考えはプログラマとはだいぶ違うかもしれない。今日の回路設計者はトランジスタが何であるかなど漠然としか知らなくて済む。だが、CPUの構造ぐらいは知っておくべきだろう。ポインタは嫌われ者だが、実装上のメリットも大きい。アセンブラから学べとまでは言わないにしても、アキュムレータ周りの振る舞いぐらい知っておいて損はない。
ちなみに、真の数学を記述するならアラビア語を学べ！という意見も耳にするが、真理の探求が人間の発明した言語に依存するとも思えない。なんにせよ、あまり手段にこだわることもあるまい。どんな言語を使うにしても、物理的な構造をどこかで意識している方がいい。社会が仮想化へと邁進するからこそ、実体という視点を見失しなわないようにしたい。

2. オブジェクト指向とパラダイム設計
初めてオブジェクト指向に触れたのは20年以上前か。当時、講座や書籍を漁ったが、真新しいものに映らなかった。カプセル化の概念は古くからあるし、現場ではクラスもどきの抽象的方策を用いていた。Thomas E. Kurtz に至っては「コンピュータ業界における最大の詐欺！」とまで言っている。とはいえ、再利用や拡張性は誰もが抱える問題で、オブジェクト指向もこれを念頭に置いている。ただ、再利用性と言っても、立場によって微妙にニュアンスが違うようだ。その違いは、データ構造、ライブラリ、コンポーネントに現われる。配列や連結リスト、スタックやキューなどの構成において。
カプセル化については全般的に異論はないようだ。やはりこの概念は本質であろうか。ただ、C++ では、必ずしもメソッドを経由する必要はなく、データ型に直接アクセスできる柔軟性がオーバーヘッドを抑制するとしている。そして、ジェネリック性を重視する立場から Java を攻撃している。
最も毛嫌いしている概念は、継承だ！多重継承ともなると泥酔者の頭は Kernel Panic!
Objective-C が多重継承を禁止しているのは、Smalltalk の直系の子孫だからだという。再考するのであれば、単一継承すら取り除くかもしれない、とまで言っている。そうだろう！そうだろう！
しかーし、Eiffel では多重継承を主軸に位置づけている。継承にアレルギーがあるのは、すっきりした事例を見たことがないだけのことかもしれない。尚、Eiffel の契約の概念は良く、再利用には欠かせない発想だ。
今、政治的に再利用するように仕向けられたモジュールがある。ドキュメントもない。黒幕の住処？その名はブラックボックスと呼ばれる。お偉いさんが口にする「実績がある！」ってどういう意味だ？再利用性のあるコードを書くにしても熟練が必要で、安易な考えで取り組むと、却って冗長となりバグ要因を増やす。お偉いさんには、再利用の裏に潜む「日程短縮」という言葉がよほど心地よく響くらしい。だが、この手の癒し系の言葉は、ヘタするとたちまち悪魔へ変貌する。おいらは小悪魔にしか興味がないので付き合いは勘弁願いたい。
さて、オブジェクト指向は薬なのか？毒なのか？という議論は絶えない。これはソフトウェア固有の概念とは思わない。ハードにせよソフトにせよ、モジュール設計には哲学や思想が重要である。モジュールの再利用では、全体的な設計方針やシステム思想に沿っているかが鍵となる。したがって、ドキュメントには、コードの説明よりも意図する事やテスト思想の方が重要となるはず。プリミティブな領域を超えて、万能なモジュールを設計するなど不可能であろうから。システム設計とは、パラダイム設計であると言うことができるだろう。

3. OSとCPU、そして言語マシン
近年、OSは必要か？という議論をよく見かける。OSってやつはユーザを圧倒するほど複雑だ。組み込み系ではユーザに意識させないように慎ましく存在するが、パソコンではアプリケーションを脇に追いやってまで主役であろうとする。こいつがいったい何をやってくれるというのか？起動で思いっきり待たせるだけか？まるで政治家のような存在よ。
Forthマシンを設計した Charles H. Moore はこう述べている。
「Bill Gates 氏が、OSという考え方を世界に浸透させたのは素晴らしいことです。しかし、これはおそらく史上初の、そして世界最大の詐欺だと言えるでしょう。」
Javaマシンが公開されたのは、いつ頃だったか。当時、仮想マシンという見方よりは、なぜ、CPUの命令セットが言語のシンタックスを直接搭載しないのか？などと、ぼんやりと考えたものである。言語の柔軟性をハードウェアで束縛するのはアホのすること、と笑われたものだけど。
Forth にはシンタックスがほとんどないという。シンタックスよりもセマンティクスを重視すると。Lisp もそうだが、関数型言語の特徴がそういうものなのかもしれない。
それはさておき、互いに異なる言語を搭載したCPUが、マルチコアと結びつけばどうだろうか？ML のような関数型言語を搭載した自動定理証明マシンなんてものがあってもよさそう。今までハードウェアがソフトウェア化する傾向にあったが、今後は逆の流れがあっても良さそうな気がする。FPGAの大規模化にともない、CPUの物理構造を動的にすることもそう難しくはない。ユーザがOSに囚われる必要がないように、言語システムがCPUの命令セットに囚われる必要もないだろう。

4. プログラミング病理学とコンピュータ科学
Brad Cox が、virtualschool.edu に投稿した一節を紹介してくれる。
「ゆえにコンピュータ科学は死んでいない。そもそも一度も存在したことがないのだから。私が現在執筆中の書籍で扱おうとしている新たなパラダイムの中核は、我々がソフトウェア危機と呼ぶ症状を引き起こしている疾病原因となるウィルスが、原子ではなくビットで構成された物質を取り扱うことにより、自然に発生するのではなく、人間が生み出しているというところにある。
しかし、この物質は質量保存の法則に従わないため、鉛筆や手荷物コンベヤを製造する人々に対する報酬という動機付けを生み出すような商業メカニズムが完全に崩壊するのだ。商業がなければ、高度な社会秩序へと進化することができず、すべてのものを一から作り出す愚かな人たちしかいない原始的な状態の泥沼から抜け出せなくなってしまうのだ。
こうなると、あらゆるものは他の類を見ない固有のものとなり、実証的な研究を保証するための整合性あるものは何一つなくなってしまう。これが、コンピュータ科学というものが存在しない理由である。」

5. ビジュアルモデリングとドキュメント
UML は本書の中でもちょいと異質か。おいらの視点もかなり異質だけど。ソフトウェア工学というより、システム工学に分類すべきだと思っている。アーキテクチャの可視化という意味では、プログラムと密接に関わるのだけど。
ドキュメント管理という観点からすると、これに近い考え方をやっている。ただし、言語ではなく図形ツールを使っているところに問題がある。非常にメンテナンス性が悪い。仕様は日々生き物のようにうごめく。プロジェクトも、モジュールも、日程も、何もかも...ドキュメントは、常に最新版に保たれるからこそ威力を発揮する。メンバーの誰もがより最適な方向へ進もうとし、その歩みを止めるわけにはいかない。そして、プロマネはドキュメントの修正に睡眠時間を削られるのよ。
そして、ドキュメントを一人で管理すべきか？という問題がある。うちのような小規模なプロジェクトでは一人でやるべきであるが、大規模なプロジェクトではそうもいかないだろう。そこで、図面を言語で作成するという発想は素晴らしい。言語記述による統合化と分散化という観点から注目したのだった。
だが、、むかーしちょっとかじって、リファレンスも埃をかぶったまま。UML は難しすぎると、設計者が言ってくれるのは救われる。20%未満の機能で十分であると。特に、UML2.0 はあまりにも多くの方法論を取り込んだために、セマンティクスが明確に定義できなくなったという。もっとも敷居を高くしてしまったのは、UML から実装コードまで生成するというアイデアである。もはやプログラミング言語を求めているのか？James Rumbaugh は醜い！と吐き捨てる。UML にそんな魔法の力はないと。そして、OMGの標準化プロセスを非難している。おかげで、頭をリセットして読み直す気になれる。
ちなみに、 Ivar Jacobson は、ソフトウェア業界の人々は本やマニュアルを読まないと指摘している。忙しいこともあろうが、にわかに信じ難い。周りのソフト屋さんはいつも専門書と睨めっこしていて、刺激を受ける。凝り固まった本ばかり読むという意味もあるかもしれない。