もともとこの日記は自分用のメモで、決して人に読ませるブログなのでは無くて、ばれるまでは匿名を守ってた程ですけど。特に今日のは他の人には全く意味を成さないので自分用メモとわざわざ書きます。だから面白く無いなんて言わないで。
SqueakFest で感じたのは、やっぱ eToys ムズイという事だ。特にランディ・カートンさんの本格的なシミュレーションなんか、ただレンガを積み上げたように見えて何が何だか分からない。きっと eToys の設計上のミスなんじゃないか？
どこかまずいか考える。eToys タイルスクリプトには視覚的な配慮があまり無い。視覚的配慮とは、ループにおけるインデントのように、プログラムの内容を読まなくても何らかの意味を想像させるような物だ。画面に映した。または印刷したプログラムを眺める時に、ぼんやりと薄目で見てみる。すると文字の部分がぼやけてだんだん大局的な構造が現れる。
絵を描く為の最も重要な技術に、ぼんやりと物を見るという事がある。対極的な画面構造を捉えるためには、いきなり細部を観察してはならない。細かい部分はあってるけど全体的にちぐはぐな絵が出来てしまう。全体の明暗と、あと構図の段階でのシルエットの決定が大きな意味を持つ。中身が何も無くても、シルエットだけで何が描いてあるのか分かるようにしておかないと、後でどれだけ努力しようと無駄になる。
プログラミングでも同じ事が言える。特に他の人が書いたプログラムを読む際は、それぞれのコマンドが全体的な文脈でどのような意味を持つのかが分からないと非常に読みづらい。全体の文脈を捉えるために重要なのが、プログラムのシルエットだ。プログラムのシルエットには、本当に見た目に関する事。特にインデントと、抽象的な事。クラス階層構造や型の構成などがある。eToys タイルスクリプトは、条件文でインデントが使われる以外はフラットな構造で、機械語のように画一的なのでシルエットの特徴が非常に乏しい。
もっと構造化プログラミング的な eToys を提案するという方法もあると思うけど、例えばデータフローについて考える。ランディさんのプレゼンの中で、シミュレーションを書くコツの一つに、X と Y を完全に分けて考えるという話があった。例えば重力に関するシミュレーションを書く際、X と Y の双方いっぺんに考えるとややこしくなるから、別々に考えて後で合体させるという物。しかし出来上がったプログラムはとても難しくて、どこで X と Y が分かれているのか分からなかった。
データフローを使うとこの問題を解決できる。eToys は基本的に処理フローを上から下に書いてゆく伝統的な手法だが、処理ではなくてデータの依存関係を記述して行く方法がある。Excel なんかのスプレッドシートでやるやり方だ。これでプログラムを書くと、例えば左上から右下に落下して行くバナナの放物線なんか描く時に、はっきりと X 成分と Y 成分が分離している事をシルエットから判断できる。
データフローは、Joy 等のスタック言語からそのまま生成出来るので Joy の知見を行かせると思っていたが、問題は、データフロー言語で伝統的な箱と線を使った記法で条件文なんかを書くとどんどん図がややこしくなる事と、あとforward by のような複雑な副作用を持つものをどのように表現するかだ。
