Squeakers' Night in 未来パーティ二次会で話した(ある意味失礼な)話の個人的サマリ

お話を伺ったのは主にabeeさんとid:squeakerさんとid:ykouboさんです。
ただ、酔っ払いの聞いた脳内世界の際構築なので、「そんなこと言ってない」「そんなこと聞いてない」という向きにはひらに御容赦を。コメントよろしくです。すぐに修正しますので。

  • Squeakのプロジェクトとしてのゴールは?

Squeakというプロジェクト(もしくはプロダクト)に対してFlorianにどうにも理解できなかったことの一つに、「何を目指してプロジェクトが動いているのか分からない」というのがあります。
確かにアラン・ケイは「教育のため」と明言していますが、その割りにはあちこちに組み込もうという動きがあったり、Squeakを中心においた製品なんて物が有ったりと、今一つフォーカスがぶれているような気がしてならなかったので。
結論として言うと、少なくともメインストリームであるSqueakLandの人達に関しては、「教育のため」というゴールはぶれていないそうです。
ただ、オープンソースプロジェクトとして進めている以上、いろんな人がいろんな思惑でプロジェクトに参加しているため、統一的なプロジェクトゴールは設定できないだろうし、できないということを容認するしかないだろう、とのこと。
なにせ、SqueakFoundationとSqueakLand版のコードですらも相互に機能が分岐しちゃっているぐらいなので、今後、コードに対して「教育のため」というお題目の元での大改編が行われた際には、それぞれの利害がいろいろとからんでめんどうなことになるかもしれないけど、それは、「そういうもの」だよね、と。


言っていることはしごく普通ですが、個人的には大変目からうろこでした。Squeakというプロジェクトがそんなに大きいとは思っていませんでしたし、なんとなくイメージ的に一枚岩で一つのゴールを目指して進めているような印象があったので(これは、「Squeak入門」のアジテーションがうまかったせいだろうなぁ)、個々人の思惑が別の方向を向いているとは思いもしなかったのです。
abeeさん曰く「ゴールについては直接アランにメールで聞けば、詳しく答えてくれると思う」とのことでしたが、とてもじゃないけど言語の壁が高すぎて聞けません(^^;)。Florianの英語力は日常会話をこなすのにちょっと困るくらいのレベルですから、思想や論理を展開するなんて、とてもとても。マニュアルやコメントはいやというほど英語を読むんですけどねぇ。

上記の「ゴール」に付随する話ではあるのですが、SqueakSmalltalkとして作られている理由もいまいち不明でした。
Squeak入門」では「教育システムだからSmalltalkなのは自明」という不思議な論が展開されていましたが*1、あれは単なる「現状肯定」のために書かれたものであって、理由は単に「そこに使えるもの(Apple Smalltalk)があったから」というだけの理由だったのでした(^^;)。あー、確かに「はじめはJavaも検討したんだけど使い物にならなかった」とは書いてありましたね。
Smalltalk使いの人たちが、約束の地の如く(^^;)Squeakに集まっているように見えるのは、たまたま取られている方法論に惹かれているだけで、ゴールに対して興味を抱いて集まっているわけではどうやらないらしい、ということも見えてきました。
これに付随して、TweakというシステムがSmalltalkという枠組みすらも壊してしまいそうな勢いで作られている理由も少し理解出来ました。Smalltalkにこだわっていないのであれば、ゴールを実現するのにもっと適した方法論を使うのは当然のことですね。

  • Tweakについて

でも、Tweakがたいそう重そうな枠組みの割に、今後のSqueakがTweakを中心に置いたものにする予定でいる事も疑問でした。
あまりTweakをきちんと見ていないのですが、Islandの考え方とか、メッセージングが複雑になっているとか、存在の理由はよく分かるのですが、100ドルラップトップのようなかなり制限された環境で使うには向いてないんじゃないのかなぁ、と。
しかし、「TweakはSqueakの上である意味エミュレーションして動いている」という結構衝撃的だった事実を教えて頂きました。Squeakシステムでのエミュレーションを取り払って(今のMorphのクラスとかを捨てて)、直接駆動する形にすると、パフォーマンスはきっと上がるだろう、とTweakの中心に居るアンドレアスさんは言っているとのこと。
実は、Florianは仮想化が進み、レイヤーが厚くなればなるほど、アルゴリズムを実行する際の最適化をシステムがやってくれるので結果的に効率的になるという、ちょっと幻想的な内容を信じています。それは、SmalltalkJavaCLRのような抽象化高めな実行環境で、少なくともプログラムを作る側では思いもよらなかったような最適化をかけて、ネイティブのアプリを直接作るよりも結果的に実行時も、開発時も効率よく進めることが出来る、という幻想です。
もちろん、Squeakの実行環境は、現在決して最適化は進んでいるとは言えませんが、厚くても、機構の行動原理としてシンプルなシステムが中心になるのであれば、パフォーマンスの壁は乗り越えられそうな気が、確かにします。

  • SqueakToysの教育的スコープについて

世界を観察し、なんらかの手段で再現するという科学的手法のうち、特にフォン・ノイマン型コンピュータを使用するものにおいては、「有限状態機械」という考え方が必須だとFlorianは思っています。
これは、フォン・ノイマン型コンピュータ自体が「有限状態機械」という考え方を中心においているためという大変単純な理由です。
翻ってSqueakToys(どうでもいいですけど、関係者はみんな無意識に「イートイ」と今でも呼んでしまうようですね(^^;))を見ると、微分形式での挙動を記述するには大変向いているのですが、少なくとも、状態によって非線形なふるまいを示す有限状態機械としての記述は余り考えられていないように見受けられます。
なので、SqueakToysって自然科学をシミュレートするにはいいソリューションではあるのですが、「フォン・ノイマン型コンピュータ用のプログラムを作る」という事に対する教育には適しないような気がしています。
その辺、SqueakToysの元アイディアを考えた人たちってどのように考えてるんだろうなぁ、という疑問がありました。なにせ、SqueakToysでプログラミングを入門するというような記事ですらも見つかるので。
これも、結論から言うと「そこまで広範囲に考えてはいない」というのが真相のようです。フォン・ノイマン型コンピュータのプログラミングを教育するためにSqueakToysを使うのではなく、SqueakToysプログラムはあくまで「自然科学教育のための手段」として考えているとか。
もちろん、フォン・ノイマン型コンピュータのプログラムを作ることに対して教育するのであれば、別の枠組みを考える必要があるでしょうし、コンピュータを使って「物語」を作るのであれば、今のSqueakToysで無理矢理作るのはあんまり教育的には良くないだろう、というお話でした。この辺が「アニメーション・ブラックホール」の根っこなんだろうなぁ。
ただ、子供達は基本的にコンピュータが好きなので、教育に道具としてのコンピュータを使いたがる傾向もあるとのこと。「物語の作成にSqueakToysを使わせない」という強権的な手段を取ればすべてが解決するわけではないという、微妙に難しい問題もそこにはあるんでしょうね。


ちなみに、酔っ払いには「フォン・ノイマン型コンピュータ」という発音は難しかったです(笑)。もう、何度も噛むの。

*1:と、記憶してるけど、自信ないなぁ。後で読み返します