前回 STEPS プロジェクトについて書いてから二年になるので、また書きます。
概要
STEPS (STEPS Toward Expressive Programming Systems) というのはアラン・ケイが率いる NPO 研究組織の Viewpoints Research Institute (VPRI) が進めているプロジェクトで、私も 5 年程前から参加しています。プロジェクトの目的は、パーソナルコンピューターの実装に必要な機能の全てを 20,000 行という短いサイズで記述しようという物です。システムには OS から言語、オフィス風アプリケーション、インターネット環境などを含みます。成果物は、Squeak のように普通の Windows や Mac の上バーチャル環境として提供されます。
目的
なぜプログラムの短さが重要なのでしょうか？私たちが日常的に使っているパソコンを動かすためには大量のソースコードが使われています。例えば Windows XP では 40,000,000 行が使われていて、ソフトウェアは更に大きくなる一方です。このような巨大なソースコードを一人の人間が把握する事は出来ません。大きなシステムは開発者に負担をかけるだけでなく、将来維持していくための大きなリスクになります。STEPS プロジェクトの目的は、より複雑なソフトウェアを人間に理解出来る形で簡潔に表現する方法を探す事です。
手法
本質的に巨大なシステムを簡潔に表現する事など出来るのでしょうか？ヒントは建築にあります。ギザのピラミッドは大量の石を積んで作られ、高さ 134 メートルで 600万トン程の重さがあります。もしも構造を工夫してアーチやトラスを使えばどうなるでしょう。半分の重さで高さ 300 m 長さ 4 km の明石海峡大橋を作る事が出来ます(鋼材 20 万トン、コンクリート 1,420,000 立方メートル)。規模が大きくなると構造が重要になるのです。
このような巨大なシステムを可能にする構造を探すために、私たちは言語に着目しています。一つの言語で全てを記述するのではなく、ある問題に特化した言語 (Problem Oriented Language - POL) を採用する事で簡潔な記述が可能になると考えています。もしかすると、沢山の言語を覚えなくてはならない事を心配される方がいらっしゃるかも知れません。これは単一の言語で多くのコードを書くか、複数の特化した言語で簡潔に書くかのトレードオフになります。このバランスについてはまた後に議論される事になるでしょう。
このアイデアは極めて大胆で実用性に乏しいと思われるかも知れません、しかし私たちはこの実用性を測るために、Frank というソフトウェアを作り上げました。Frank は Microsoft Office のような外見をしており、一般的なアプリケーションと同じように使えます。しかしその内部は Frank は STEPS の様々なアイデアをパッチワークのように繋ぎあわせて作られた物で、フランケンシュタインの怪物のようにギクシャクしながらもとにかく動くという所から名付けられました。
何の役に立つのか？
開発者の方には POL を使って簡潔なプログラムを書く価値は言うまでも無いと思います。それでは、一般のユーザにはどのような意味があるでしょう。私たちの 20,000行という目標には、プログラムが一冊の本に書かれ、専門家だけでなく誰にでも読めるようにという願いが込められています。私たちの生活の隅々にコンピュータが入り込むこれからの世の中で、一般市民にとってプログラムの基本原理の理解は必須教養になるでしょう。それだけでなく、文字の発明が物の考え方を変えたように、プログラムは人の考え方を変える物になります。
その未来を占う一つの実験として、Active Essay が書かれています。Active Essay とは文章の中にプログラムが埋め込まれた物で、文章を読みながらプログラムを実行する事が出来ます。例えば Frank のサンプルにある「How To Make A Text Field From Ants」では、蟻が食料を集めるシミュレーションをメタファにして、文字列を画面にレイアウトする方法について語っています。STEPS のソースコードは全てこのようなエッセイとして書かれるのが理想です。
この例はまだアルゴリズムの説明なのですが、Active Essay の考え方が本当に直接私たちの生活にどんな影響を与えるかはまだ分かりません。私も沢山アイデアが有るのですが、他の人に納得出来るような形になってないです。
現在の STEPS
STEPS は 5 年計画として始まりましたが、もう一年延長が決まっています。現在は Frank の開発を通じてアイデアを実装して行っている段階です。
現在の Frank は主に Squeak Smalltalk で実装されていて、画像処理の部分だけ Nile と言うレンダリング用のストリーム型言語で記述されています。Nile 自体は OMeta という文法記述言語と C で書かれています。これが現在の状況です。
あとは Smalltalk の部分を POL に置き換えていくという流れになります。例えばテキストレイアウトも Nile で書く実験が進められています。一番大きな問題は Smalltalk 自体を置き換える事が出来る程の汎用言語の開発です。システムレベル、すなわち C レベルの粒度の実験として、Nothing や Maru という複数の計画が進んでいます。もう一つはアプリケーションレベル、すなわちマクロやタイルスクリプトの粒度ですが、ここは文法以前にプログラミングモデルが重要になります。ここでも幾つかの実験が行われています。
まずプログラミングにおいて、副作用が問題になる事がよくあります。メモリの状態を変更する事が思わぬ結果を産んでしまうのです。これを避けるために関数型プログラミングというのがあるのですが、STEPS では別に副作用の影響範囲を閉じ込めるための Worlds という仕組みを使うアプローチを取っています。Worlds を使うと、例えばシミュレーションに色々なデータを入れて並べて見比べるというような事が簡単に出来ます。
もう一つはスプレッドシート型データ構造の活用です。これは古いアイデアですが、スプレッドシートのような見通しの良い仕組みをシステム全体で応用しようという物です。
詳しくはもうすぐ公開される VPRI 年次レポートで紹介されます。というか、締め切りが終わったので自分へのメモとしてこれを書いています。
おまけ、自分がやった事。
私は今年はわりと裏方に徹して、Frank で使われる文書ファイルの保存や Open Document Format インポータを作ってました。特に、アラン・ケイのプレゼンは出来るだけパワーポイントを使わないで自分たちで作ったプレゼンツールを使うのですが、スライドの作成に OpenOffice を使いデータを Frank に読み込んで Frank ネイティブなコンテンツと合成するというような事をやっていました。
これは特にベンチマーク・テストとして便利です。というのは、画像コンテンツを作るツールというのは難しくて後回しになりがちなのですが、そうするとなかなか複雑な画像を表示するテストが出来ません。OpenOffice などの外部ツールを使うと容赦なく複雑で大量のデータを簡単に生成できるので、随分 Frank のストレステストになりました。というわけで、もうちょっとだけ続くんじゃ。
