タイルスクリプト進捗

今日は大島さんの赤ちゃんに会う事が出来ました。ちっこくて可愛かったです。

さておき、煮詰まってきたところで進捗を纏める。最大の問題点は、論文でタイルスクリプトは初心者に簡単と書いてあるのに、このタイルスクリプトは全然簡単では無いという点。その原因は、etoys や scratch のスクリプトが何故簡単なのかの分析が足りて無いからなので、それについてまず考える。

何故 etoys が簡単なのか。

etoys の売り文句は、どのようにタイルをドラッグしても文法エラーになる組み合わせが発生しないという点だ。エラーを起こさないために次の工夫がしてある。

• 型チェック: etoys は文字列、数値、色、などなど細かい型が沢山あって、間違った場所にタイルが入らないようになっている。
• 単純な文法と構文チェック: etoys には、数値や文字列等の値と、コマンドや代入などの文(行)の違いがあって、数値を文の場所にドラッグする事は出来ない。また、値と文の違いしか無いので実装が簡単。

また、文法から離れて UI の観点から考えると、etoys はキーボードの代わりにビューワやパーツビンから部品を組み合わせて作るという事になっている。これは、何も無い所から命令を伝えるより、選択肢から選んでもらう方が簡単と言う一般論で説明出来る。つまり、

• 説明を読まなくても、表示された中から選んで取り出す事で etoys に命令出来る。

タイルスクリプトの問題点

タイルスクリプトの問題点はこれを全く裏返した形になる。

• javascript には型情報が無いので、特に変数の型チェックを行う事が出来ない。リテラルについては、数値のリテラルには数値しか入らないように出来ると思う。
• javascript の文は etoys より複雑で、配列、複文、メソッド呼び出し、関数呼び出し、変数アクセスなど、多くの構文要素がある。多くの構文要素があるという事はチェック出来るチャンスが多いという事だけど、出来ていない。
• ビューワやパーツビンに相当する物が無いので、ユーザに何が出来るかの手がかりが全く無い。

あと単なる技術的な問題も忘れないように書いておく。

• タイルをスクリプトから削除出来ない。
• 文を後で追加したり削除出来ない。
• パーツビンやビューワが無いのでゼロからスクリプトを組み立てられない。
• 数値や文字列リテラルの変更が出来ない。
• 変換出来るソースコードに複文と単文の違いがあり、複文は {} で囲まなければならない。

ウェブブラウザの利用について

実は、現在のタイルスクリプトを作る前に、Squeak 内で作っていて、この時上のような問題は分かっていた。しかも難しいだろうなと思っていた。なぜかと言うと etoys の親しみやすさは単なる言語レベルの物で無く、環境と特殊な構文を含めた物だから。etoys と Smalltalk が変換不可能であるというのは、論文が想定する文法レベルの問題だけでなく、環境も含めた部分に原因がある。もっと言うと etoys は「言語」では無い。これは、javascript とタイルを一対一対応させるというこのプロジェクトの技術的解法では解決出来ない物だ。しかしもう論文は出してしまったので、出来るだけ論文に書いてある通りに技術的目標を満足させつつ実現可能な範囲の事として、次の二つの決定を行った。

• Squeak では無く、ウェブブラウザを使う: Squeak上の javascript 実装は大変デバッグが難しく、作者が興味を失ってしまったので。
• 画面に自由に配置するのでは無く、文章のような構成: ブラウザの利点を出すために、etoys では難しい文章のような構成を試した。

つまり、etoys のようなマルチメディア記述環境よりも、プログラム自体に焦点があうような構成にした。etoys のようなビューワや Smalltalk のようなコードブラウザが無いので、作ったプログラムを見えない場所に格納する事が出来ない。つまりコードは画面上のどこかに存在しなくてはならない。これは。例えばプログラムのアルゴリズムを解説するようなコンテンツについては逆に利点となる。

必ず画面のどこかにソースがある事が保証されているので、スクロールすればヒントがどこかにはある。謎は一つも無い。etoys でプログラム自体をテーマにした作品を作ろうとすると、画面中一杯にスクリプタが散乱する事になってしまうが、スクロールする事の出来るブラウザではその心配が無い。

タイルスクリプトに出来る事？

最初に挙げた問題があるので、etoys のような簡単さを求めるのは難しい。まず、編集機能の貧弱さからタイルでプログラムを書く事は出来ないし、それを来週の発表までに全部実装する時間も無い。そこで、今の考えとしては、タイルはプログラムの作成ではなく、コンテンツの読者が理解を確認するために、パラメータの調整など、プログラムの修正だけに使う事を考えている。それだと残り実装すべき機能はリテラルの編集だけになる。

HyperCard にはユーザレベルの概念があって、何でも編集出来るレベルから見るだけのレベルまでいくつかの階段がある。同じように、タイルスクリプトはいわばソースコードを編集する事は出来ないがパラメータの修正だけは出来るレベルと考えられる。アルゴリズムの理解は、ただプログラムを読むだけでなく、部分的に変更して変更点を確認する作業が必須だ。この作業を支援する物として使えるのでは無いかと思う。

どうでも良い余談だが、この変更と確認が必須という概念は『俺アフォーダンス理論』の骨子となる物なのでまたあとで書く。これは師である音楽家鈴木昭男の「投げかけ - たどり」からインスパイヤされた物である。

このプロジェクトについて

こう書くとまるで俺が自分で考えてやってるみたいだが、このプロジェクトの一番重要な部分はアレックスによる仕事で、俺の努力は彼の仕事をいかにサポートするかという一念でやっているという事を記しておく。