OOPSLA

Brian Foote曰く"Intellectual Jackal with good taste and caring"のMartin Fowlerのキーノート。最初は動物の鳴き声ごっこ大会から始まったのだが、だんだんまじめな話になっていった(が、主に「逸話的」なので「ふーん」と思って終わる話でもあった。途中から集中力が切れてきたので、以下はほんのちょっとだけ。

Kent Beckが彼に言ったこととして、冗長で同じことをするコードを避けろ、あるいは今で言うDRY原則があった。最初に聞いたときは、「まあそりゃそうだけど、別にそんなに重要と言うほどのことでもないんじゃない？」と思った。人生のほかのことと同じで、私はしばしば重要なことほど、最初は見逃してしまう癖がある。その後良く考えていくと、この原則は非常に大事だと思うようになった。この原則は、それに反したコードを見つけるのが容易である、という特徴がある。

UIのコードは他のものと分離しろ、という原則も重要だと思う。

というような話。データベースにイベントが到達してくる、というモデルを、ステージの上を駆け回ってイベントを表している椅子を並べ替えたりして体を張って話していた。

Q&Aでは、「もともとのwater fallモデル開発は、カードデッキを作って、念入りにデバッグしてからバッチ投入する、というプログラムの実行形態が主流だったからで、対話型開発ができるようになったことが開発モデルの変更を呼んだのではないか」という質問。当然ながら答えはyesで、「SmalltalkからXPのプラクティスが生まれてきたのは偶然ではない」という答え。UIを分離するとしばしば同じようなことをするコードがたくさんかかれる元にもなりうるのでは、という質問に対しては、それもそうだが、ちゃんとわけないとSqueakのMorphicのようになりがちではある、という答えもあった。

First Formalization of Java RMI。地味だが重要、ともいえる。

Lifting Sequential Graph Algorithms for Distributed-Memory Parallel Computation。逐次的に書かれたアルゴリズムのそこかしこを抽象化してテンプレートを作って、並列版データ構造で具象化しなおして並列化すると結構うまくいく、という話。こういうのはスイートスポットがどこにあるのかということを理解できるようになるのが重要なのだろうが、なかなかそこのところは難しそうである。

Safe Future for Java。future構文をJavaに入れて、楽観的実行をしてコンフリクトがあったらロールバックして一貫性を保つ、という話。俺としてはかなり不満。そもそも例題として使っている例が、そもそも完全に逐次的実行を期待しているのに、とりあえずfutureを入れてみました、という例であるし、Argusから始まる(のかな?)トランザクション付き言語の話がないし、言語のコンストラクトとして考えた場合には避けて通れないはずの入れ子の話を単純に将来課題にしてしまっているし。

Anchored Exception Declaration。一つ一つのメソッドシグネチャに明示的にExceptionの名前を指定するのではなく、"like"といって、このメソッドと同じExceptionを投げますよ、と宣言できるようにする。Java界としては便利になるかも、ということはわかった。

Incrementalization Across Object Abstraction。Annie Liuの論文は、関数型言語でやっているときに読んだこともあったが、いわば普通に書かれた計算を、微分形式に書き換える、とでもいうもの。ある合成関数の値を、関数の入力となっている要素を変えたりしたときにすべてを再計算するのではなく、その要素の変更の関数となるように自動的に書き換える。関数型でなくオブジェクト指向では、カプセル化されているオブジェクトの境界があるのだが、それをまたいでやる。このやり方が生かされるスイートスポットがあるはずだとは思う。

PolyD。Javaのディスパッチルールを(メソッドごとに)変更できるようにする。またか。上のトランザクションの話もそうだが、「Javaでやり直す」という研究にはつらく当たってしまう私である。

最後は、Grady Boochのキーノート。面白かった。最初の15回位のOOPSLAには来ていたが、その後Software Architectureというちょっと違うことをしていた。

ジョークは皮肉のあることをよく言う人である。IBM所属だがMacを使ってプレゼンしていることに触れて、「PowerPCを使ったコンピュータで、本物のOSを入れているんだ」とか。OOPSLAの隣のホールでは創造論者の集会をしていたのだが、それに触れたり(なんといったのか忘れたが)。

ソフトウェア・アーキテクチャというのは多くの分野をまたいだソフトウェアで、共通して現れる構成方法。実際の建物は、がっしりとして機能を具象化したようなペンタゴンや、(7人の小人が屋根を支えている)DisneyのHead Quarterのように、その建物の哲学を反映したものになる。(FEMAのHQはこんなかんじ、といって倒れかけた家の写真をだしたり)。

Frank Gehryが書いたDisney Symphony Hallの最初の絵はとても抽象的な線画だったが、物理世界の制約やお約束やグループの人の頭の中だけにある知識などがいろいろあるので、形になる。それよりも、隣のおうちを建てる時のような基礎的な建築の約束事として、ソフトウェア界にどのようなものがあるのか調べたい。

初期のピラミッドのような建築物は、theoryはなくてただひたすらとてつもない労力を持って作った。"Style"というものが産まれてきて、"French country style"と言えば、依頼主にも建築家にも共通の認識ができるようになる。建築では、過去の建物をじっくり見て勉強する、というクラスが欠かせないが、ソフトウェアの場合は過去に書かれた実際のコードを読む、ということは学校ではめったに教わらない。

"How Buildings Learn"という、年月を経た建物がどのような状態にあるかを調べた本がある。どのような建て方が有効であるかを教えてくれる。今では、建築だけではなく、分子生物学でも、いろいろなパターンを集めた本があって、同じ分野の人が意思疎通するのに役立っている。

Web開発のことを考えると、最初のAmazon.comのスクリーンショットはこのようにほとんどテキストだけのものだった。第二世代のWebページは色付きになって飾りが付いて、第三世代ではちょっとしたJavaScriptなどが付いて、第四世代では.NetやWebSphereのようなミドルウェアが使われるようになって、第五世代ではMVCパターンを使ったフレームワークが現れ、第六世代ではAjaxのような動的なフレームワークと、コンポーネントをつなげるSOAのようなものが出てきている。次の世代は、Semantic Webで、XML + XML Schema + RDF + RDF Schema + OWLで結局は世界的なOOデータベースのようになるだろう。ただ、一世代は2、3年かかり、数世代分の技術は共存して使われ続ける。

彼のやっているArchitectureと、複数の視点という概念を取り込んだ図の話。

Software Architectureのことを考えると、多くの意思決定の結果が人々の記憶の中だけにある。ドキュメントはしばしばうその上塗りしたものにすぎない。異なる利害関係者はことなる視点を持っている。アーキテクチャの中には多くのパターンが使われていることが多い。結局ソースやドキュメントから暗黙知を再現するのは簡単ではない。

Software Architectという専門職ができつつある。が、まだしっかりした記述方法で、ちゃんと使えることが実証されたものはない。
Photoshopは、ILMの地下室で生まれたプロジェクトで、いろいろのいきさつがあってAdobeが権利を買って商品化した。一千万行くらいのプログラムで、どういじったらよいか誰もわからないコードも多い。が、一番重要なコアは20くらいのクラスにあって、「その20くらいのクラスを変更したら、それはすでにフォトショップではない」というものがある。

ソフトウェア考古学。「スタイル」とはシステムアーキテクチャの分類をしたもの。

今のところ、Architecture Handbookという本を書いている。100くらいのシステムを研究して、エッセンスを抜き出すのが目的である。オリンピックのソフトや、カナダ航空局の管制システムや、The SimsやMars Pathfinderなどを調べている。GoogleのアーキテクチャやPageRankに関する情報も、Stanfordのサイトにはいろいろと置かれている。自然言語の壁や、知的所有権の問題があるのでなかなか調査が思ったように進まないことも多い。

Eclipseは2年くらい経ったプロジェクトで、アーキテクトとも話せるしコードもある。抽象的なPowerPointの説明はたくさんあるし、コードはもちろんあるが、その中間部分の、使われているパターンなどのドキュメントはほとんどない。それを発掘しなくてはいけない。

Computer History Museumと話をしている。ENIACや360などがあるが、ソフトウェアのアーカイブを作ろうとしている。Bill AtkinsonとAndy HertzfeldとAppleの協力・行為により、MacPaintのコードを保存することが決まっている。Edgar Dijkstraとも話をしたのだが、2週間後に彼は亡くなってしまった。時間は我々の側にない。(田中さんが、「でもまだちゃんと展示されるところまで行っていないんだよね、確か」と指摘していた。さすが。)

オリンピックの運営ソフトも、IBMがしばらく運営した後、ATS Origin(?)という会社に移管された。その後、もともとの知識がどのように生き延びているのかを調べたいので話を聞きに行こうとしたのだが、「なぜIBMの人と話をしなくてはいけないのか?」といわれてなかなか相手してもらえない。

とにかく、そういうことなので協力したい人はよろしく。

Q&A。すばらしいシステムのソースコードを読むコースが必要である。Smalltalkのカーネルとか(そのとおり)。HOPL-IIIが2007年にSan Diegoで開かれる。失敗したシステムの教訓を集めるのはどうか(別の人がやるべき)。などなど。

アイスクリームを食べて、OOPSLAは終わり。いろいろな人に会って話ができるのだが、なんとなく違和感は感じつつもある最近のOOPSLAではある。

帰り道は、Carlsbadのアウトレットモールによって、そこから他車を撃墜しつつGlendaleまで帰投。