Diomidis Spinellis, Georgios Gousios編「ビューティフルアーキテクチャ」オライリージャパン 久野禎子・久野靖訳 3

出現時には難しいと考えられていた革新的なアイデアが、教育者がその説明方法を開発するにつれて、主流にとけ込んで行く可能性はあります。
　　――13章　ソフトウェアアーキテクチャ：オブジェクト指向対関数型(バートランド・メイヤー)

　Diomidis Spinellis, Georgios Gousios編「ビューティフルアーキテクチャ」オライリージャパン 久野禎子・久野靖訳 2 から続く。

【９章　JPC：ピュアJavaのx86PCエミュレータ(ロシ・ニューマン，クリストファー・デニス)】

このプロジェクト全体を通じて50万行以上のコードが書かれてきました。このうち、現在も残っているのはわずか８万５千行です。

　Ｊａｖａ で x86 PC をエミュレートしましょう、という無謀な計画のお話(→Wikipedia)。なんでJavaかというと、CやC++だと、新しいCPUやOSが出てきたらコンパイルし直さなきゃいけないけど、JavaならVMさえありゃイケるじゃん、と。あとエミュレータにセキュリティ・ホールがあったら怖いし。JavaならVMがガードしてくれるよね。

　多くの人がまず考えるのは、「遅くて使い物にならないんじゃね？」って事。そんなわけで、紙面の多くを「いかに Java で高速化するか」に割いているため、速度を追及する Java プログラマには嬉しい章だろう。

　そこで参考になるのが、まずは簡単な「おもちゃCPU」を作り、性能を試している点。C言語を gcc でコンパイルし作ったプログラムと比べ、最初は約千倍の遅れをとっていたのが、最適化で同等の性能に引き上げている。こういう「封筒裏の計算」的な作業って、大事だよね。

　クラス構成はご想像のとおり、「ハードウェア仕様とJavaクラスの間で１：１に対応して」るんだけど、やはりCPUが問題。特にプロテクト・モードには苦労したようで。

　肝心の高速化じゃ、ガベージ・コレクタが最初に挙がってて、「オブジェクト生成はよくない」ときた。だってガベージ・コレクタが動き出したら止まっちゃうし。

　メソッド検索も狙いどころで、interface より instanceof のが速い。instanceof は配列参照だけど、interface は配列の探索だとか。同じ理由で、メソッドはなるたけ static に。つかメソッドの探索なんて、コンパイル時に解決するんだと思ってた。あと、実行時最適化はメソッド単位なんで、メソッドッはなるたけ小さくしましょう。

　実はクラスもガベージ・コレクトの対象なんだけど、変なクセがある。ゴミ集めはクラスローダ単位なのだ。そのクラスローダがロードしたクラスのインスタンスが全部ゴミになるまで、そのクラス全部がメモリに留まる。ってんで、クラスローダがロードするクラスの数を減らしましたとさ。

　switch 文も tableswitch はいいけど lookupswitch は困るとか。これも配列の参照でイケるか、それとも探索せにゃならんかの違い。

　意外なのが例外を使うよう薦めてる点。例外が起きた時は遅くなるけど、起きなきゃ速い。だから、滅多に例外が起きないなら、例外で対処した方が速いそうな。

【10章　Jikes RVM：メタサーキュラーな仮想マシンの威力(イアン・ロオジャーズ，デイブ・グローブ)】

Jikes RVM はJavaアプリケーションを実行するための仮想マシンであり、Javaで書かれています。

　JavaでJITコンパイラ(→Wikipedia)とJavaVMを作る話。ここでも実行速度が大きな話題で。

　なるほど、と思ったのが、「実行時じゃないと最適化できない所もあるよ」って話。最適して効果があるのは、頻繁に走るコード。でも頻繁に走るかどうかは、走らせてみないとわからない。だったら走らせながら使われ方を見て、よく使う所を自動的に最適化すりゃいいじゃん、と。

　Jikes RVM だと、まずお馬鹿なコンパイラが直訳風にコンパイルする。最初はコンパイル速度を節約するわけ。で、何度も使われるようなら、じっくり時間かけて最適化してく。

　この動きを外から見ると、作業に慣れるに従って、最初はトロトロしてたのが、だんだん手早くできるようになる、みたく見えるんだよなあ。JavaでAIを作ったら、そういう人間臭い性質を持つようになるんだろうか。

　ここでもガベージコレクトは大事で、複数の方法を用意してる。基本はマーク＆スイープ(→Wikipedia)だけど、きっと整数や文字とかの小さくてサイズが決まったモノは、別の方法なんだろう。

【11章　GNU Emacs：斬進的機能追加方式が持つ力(ジム・ブランディ)】

誹謗中傷する人たちは、Emacs はわかりにくく、複雑で、Microsoft Visual Stdio などのより広く使われている開発環境に比べて時代遅れだと言います。熱狂的支持者たちでさえ、自分たちの手首の損傷は手をひねらなければならないようなコマンド群のせいだと言っています。

　そりゃ META キーなんか使うのは Emacs ぐらいだしｗ　ということで、vim と終わりなき戦いを続ける巨大エディタ Emacs(→Wikipedia) のお話。いきなしニール・スティーヴンスンなんて名前が出てくて、「あれ？何のほんだっけ？」と驚き、続いて Emacs の悪口が出てきてニヤリとする章。

　巨大なだけに起動も思いのが難点。それは著者もわかってて。

Emacs はあなたが仕事をはじめるときに１回起動し、その後ずっと実行したままにしておくというものなのです。

　と、有り難いアドバイスをくれる。まあ言われなくても、暫く使えば、自然とそういう使い方になるんだけど。

　Emacs の最大の特徴は、その機能の大半が Emacs LISP によって書かれている点。極論すると、Emacs は Emacs LISP のインタプリタだったりする。お陰で、使う人も勝手に機能をすげ替えたり追加したりできる。欲しい機能を Emacs LISP で書けばいいのだ。

　こういう「専用インタプリタを用意して、機能を増やしたかったら後で書けばいいじゃん」的な発想、私は大好きなんだけど、あなたどうですか？もちろん、文法は LISP で。

　驚いたのが、「Emacs LISP にはプログラムをモジュール化する方法がありません」って話。じゃ名前が衝突しちゃいそうなもんだが、「その代わり、名前の付け方が確立」している、と。言語仕様で縛るんじゃなく、運用ルールで避けるわけ。きっとRMS(→Wikipedia)の趣味なんだろうなあ。

【12章　バザールが伽藍の建築に乗り出す時(ティム・アダム，ミルコ・バーム)】

一部の開発者たちは、大部分の操作が、たとえばネットワーク経由でマウントされたファイルシステムから読むなどの、CPU上で行うどのような操作より数千倍遅い操作でさえ、同期的に実行しても構わないくらい高速だと考えているように思えます。

　簡単に使えるモノは、中身も簡単だと思っちゃうんだよね、人間って。マウスカーソルを表示して、マウスの動きに合わせてカーソルを動かすってだけでも、実は相当に高度な技術と計算量を費やしてるんだけど。

　この章は、主に X Window System で動くデスクトップ環境 KDE(→Wikipedia)がテーマ。タイトルは有名な「伽藍とバザール」のモジリ。これでわかるように、内容の多くは開発者同士の調整をどうするか、みないな話に費やしてる。曰く…

巨大なフリーウェアプロジェクトに関して一層やる気をくじくのは、社会的かつ調整的な側面です。

　システムとしては PIM(Personal Information Management，個人情報管理→Wikipedia)。メールやスケジュール表やアドレス帳を含む雑多なシロモノ。世間じゃ IMAP(→Wikipedia)や LDAP(→Wikipedia)や maildir(→Wikipedia)など新しいプロトコルやサービスやデータ構造が登場し、またメールもテキストのみから HTML や暗号化など要求が増えるばかり。

　これに対応する過程で、コードは魑魅魍魎が潜む腐海と化してゆく。そんな所に道案内もなく踏み込む無謀な者はいなくなり、残るは古参の勇者ばかり。不快な開発は開発者の機嫌も損ね、開発コミュニティは殺伐とした雰囲気が漂い、開発も停滞ぎみとなり…

　ってな状況を、いかに健全な方向に変えたか、みたいな話が語られてゆく。

　ネックの一つは巨大に膨れ上がったアドレス帳。これを昔はプロセスごとにロードしてたんで、無駄にメモリを食ってた。「サーバ・クライアント型にすりゃいいじゃん」と思うんだが、そうするとロックや競合の問題が出てくる。

　色々あって、PostgreSQL(→Wikipedia)やライバル GNOME(→Wikipedia)の Evolution(→Wikipedia)が新しい風を吹き込むあたりが楽しい。にしても BLOB(→Wikipedia)かあ。今なら XML データベースを検討するんじゃないかなあ。

【13章　ソフトウェアアーキテクチャ：オブジェクト指向対関数型(バートランド・メイヤー)】

　以下ではオブジェクト指向と関数型の２つのアプローチを、先に概要を挙げたソフトウェアアーキテクチャの評価基準に基づいて、比較します。その結果としては、両者のアプローチは相補的だとわかります。

　ということで、オブジェクト指向 vs 関数型という、野次馬が集まりそうな話題。ちなみに筆者はややオブジェクト指向より。なんたってオブジェクト指向側の代表が Eiffel(→Wikipedia)ってのがマニアック。

　いずれにせよ、取り組んでる問題は同じだ。ｎ種類のデータ構造に対し操作がｍ個必要なら、プログラムはｎ×ｍ個必要になる。システムが大きくなると、必要なプログラムの数は凄まじい勢いで増えてゆく上に、ちょっとした変更や機能追加も大きな手間になる。これをどう解決するか、って問題。

　ここで型に注目したのがオブジェクト指向で、操作(関数)に注目したのが関数型。はいそこの君、「じゃCLOS(→Wikipedia)最強じゃん」とか身もふたもない事を言わないように。いずれにせよ共通してるのは、「コピペは悪」って思想。だって元にバグがあったらコピペ先も直さなきゃいけないし。

　なお、この章と次の章では、デザインパターン(→Wikipedia)が重要な基礎になっているので、GoF本(→Wikipedia)を予習しておこう。

【14章　古典再読(パナギオティス・ロウリーダス)】

(フランク・ロイド・)ライトの晩年の偉業であり、AIAの人気投票で「アメリカ建築の空前の傑作」に輝いた、ペンシルバニアの落水荘(→Wikipedia)は、その名に恥じず、漏水が悩みの種です。漏水で窓と石壁の美しさは台無し、構造コンクリートも劣化しています。(略)
本当にゴージャスで影響力のある建物ですが、住めないのです。

　古典本の紹介かと思ったら、なんと Smalltalk および現代に蘇った実装 Squeak(→Wikipedia)の話。当時はセレクタとかメソッドとか聞いても何の事かわかんなかったけど、これ読んで少しわかったような気が。

　LISP が「すべてはリスト」であるように、Smalltalk は「すべてはオブジェクト」。当然、クラスもオブジェクトなわけで、じゃクラスのクラスは何かというと…みたいな問題が出てきて、その辺を Smalltalk がどう解決してるかってグラフが出てるんだが、これが実に入り組んでてややこしい。

　表向きは綺麗なんだけど、その裏側じゃ綺麗さを保つために大変な事をやってるわけ。それでもちゃんと動いて使えるから大したもんだけど、残念な事に閉じた世界に引きこもってたからなあ。

【おわりに】

　最後は、最終章にあった耳に痛い引用で〆よう。歯ごたえはあるが、相応しい中身を伴った本だった。

実際、デザイン手法を研究していて、デザインの実装を同時に行っていない人は、ほとんど常に、ものを形作る熱い気持ちを失い(ないし持ったことがなく)、活力のない、屈折したデザイナーです。

【関連記事】

• Diomidis Spinellis, Georgios Gousios編「ビューティフルアーキテクチャ」オライリージャパン 久野禎子・久野靖訳 1
• Diomidis Spinellis, Georgios Gousios編「ビューティフルアーキテクチャ」オライリージャパン 久野禎子・久野靖訳 2
• 高林哲,鵜飼文敏,佐藤裕介,浜地慎一郎,首藤一幸「BINARY HACKS ハッカー秘伝のテクニック100選」オライリージャパン
• デイヴィッド・ダンマー/ティム・スラッキン「液晶の歴史」朝日新聞出版 鳥山和久訳
• ヘンリー・ペトロスキー「フォークの歯はなぜ四本になったか 実用品の進化論」平凡社ライブラリー 忠平美幸訳
• ブライアン･クリスチャン「機械より人間らしくなれるか？ AIとの対話が、人間でいることの意味を教えてくれる」草思社 吉田晋治訳
• 書評一覧：科学/技術