Viscuitのここが嫌いだ（1）

誰かに言われる前に自分で書きます．

子供にこれが動かないと言われたとき，そのいくつかはViscuitの仕様と言う名のバグです．言われる都度，ご免なさいと思いつつ，「ああ，それ出来ないんだよね」と言ってごまかしてます．僕自身，ビジュアルプログラミング言語をViscuitの前からずっと研究してきていて，まあビジュアルプログラミング言語おたくです．

嫌いというより，TODOみたいなものですが，いつまでたっても短くなりません．

＊動かしたくないのに，動いちゃう．

絵を左右に行ったり来たりさせたいときに，壁を作って，その壁にぶつかったら跳ね返る，というプログラムを作ったりします．結構，発見されます．ところが，壁にぶつかる判定を緩くやっているので（そうしないと，壁をすり抜けることがあるから），結構手前でぶつかったことになってしまいます．

ビスケットの書き換えの特徴は，柔らかいマッチングと柔らかい書き換えです．「A を B に書き換える」があったときAに近い　A' は B ではなくてBに近い B' に書き換えられます．このAとA'の差分が B と B'の差分として反映されるようにしているために，書き換えが非常に面白い動きになります．で，このために壁も動いてしまうのでした．

もうちょっと書き換えルールの解釈を変えて，差分の反映はメガネの左右の差分の影響を受ける，という感じで，つまり跳ね返る絵の方はがらっと変化しているから，大きな影響を受けて，壁の方は，左右でまったく同じ位置にあるので，AとA'の差分の影響は受けない，という計算方法にすれば良さそうです．これもやってみましたが，今度は発散することがあって，A'が大きくズレたときのB'の位置が直観と合わない感じになったように記憶してますが，もう忘れてしまいました．

いまは，この二つの計算の中間でやっているはずです．で，それだけだと動いちゃうので，メガネの左右で絵が動いていないときだけは特例として別に計算させてます．非常に僕的には恥ずかしい実装です．

正しくは，それらが滑らかにつながっているような書き換え方法であるべきで，まだその方法は開発されてません．それが見つかったとしても，今のビスケットと互換性が無くなってしまうので，つまり，微妙な調整で動いているプログラムたちは全部調整が狂ってしまうので，Viscuit2 みたいな形で出すときにやるしかないです．だいぶ変わると思います．

＊まっすぐ動かしたいのに，曲がっちゃう．
ほんのちょっとでもルールの中の絵が回転していたらすぐに回転してしまいます．これを直すのはほぼ無理なので，壊して作り直しをしてもらいます．まあ反論というか言い訳もあって，世の中で自然なものでまっすぐなものって珍しくて，大抵は曲がってたりします．目をつぶって歩いても普通は曲がります．ロボットも左右のタイヤを独立に動かしてフィードバックが無ければまっすぐ進むのは難しいです．なので，まっすぐ動くのが簡単にできるコンピュータとか機械の方が珍しいのだと思いますが．でも，作っている人の思いはまっすぐなのにまっすぐ進まない，というのは何かやりようがありそうですね．

＊「待つ」という機能のダメダメさ
メガネの右側に「1秒」または時計のアイコンを入れると，書き換えが終わってから，それらが次に書き換えの対象になるまでにある時間待つ，と言う機能があります．たとえばこのように使います．

これは，三角からミサイルが発射して，そのミサイルは飛んで行く．発射のところに時計が置いてあるのでその時間だけ待って，また発射されます．このプログラムで待って欲しいのはミサイルの発射であって，ミサイル自身は出たらすぐに飛び立って欲しいわけです．しかし，今の仕様では，ミサイルも動き出す前に待ってしまいます．書き換えのタイミングはそれぞれの絵で管理しているので，たとえば三角だけ書き換えを遅らせるということにすればよくて，時計を三角に重ねる用に置くと三角だけ次の書き換えまで待つ，という仕様にしてもよさそうなんですが，それはちょっと難しくなって，さらにバグの元になりそうなので．

本当は

のようにして，メガネの矢印に時計を置いた方がよくて，書き換えは瞬時じゃなくてゆっくり行われる，という意味にした方がよいです．この方が誤解が少ないと思います．そもそもメガネの右側に時計を入れるというのも不自然で，よく左側に入れる（これは何の意味も無い）間違えも見ます．ところが，これは実装がまた面倒で，書き換えが一瞬で終わらないということは，書き換え対象を書き換えが終了するまでロックして他の書き換えの対象にされないようにするとか．だけど，反射させる壁のような絵は，次々来る絵にマッチしなきゃならないので，待たせるわけにはいかないとか．
メガネにリードオンリーの属性をつければロックはいらないとか，複雑にすれば方法はあるんですが，なかなか良いアイデアが浮かばないです．

＊メガネの編集のダメダメさ
メガネはすぐに壊れます．持つところを間違うと，中の部品を出してしまったり，部品を上のメガネに入れたつもりが，下のメガネに入ってしまったり．触っててイライラします．もう少し真面目に作れば，すかっとするのになりそうですが．いま，メガネにはロック機能があって，ロックしている間は中は編集禁止にできます．あとは，メガネを重ねたとき，下になったメガネは自動的にロックされるようにして，ロックされたメガネの上に部品を置こうとしたら，置けないで逃げるとか戻るといった仕様にすればいいかな．早くやれよ，です．

＊スクロール
昔はスクロールバーが嫌いでした．スクロールさせたい方向と逆に動かさなきゃないとか．あとペンコンピュータでスクロールバーをいじるのって結構大変で．その時代に作ったものだから，スクロールしません．ところが，iPad的な操作が今は主流になって，無地の部分をドラッグすればその方向にスクロールする，っていうインタフェースが発明されているのですよね．とっとと対応すべきです．何の言い訳にもなりませんが，今のFlashで書かれたビスケットは2008年に作ったものをだましだまし拡張しているもので，いろいろ古いです．

＊XXXX
セキュリティに関係するので書けません．

＊ファイルが消える
ブラウザをリロードすると消えます．バックボタンでも消えます．Flashでもローカルにデータを保存する機能があるから，それを使えば消えないようにできるのですが，やってません．

ほんとはまだまだあるんですが．最後に．

＊新バージョン
新バージョンを作ってます．新バージョンは欲張らずに，上の問題だけ解決すれば良さそうなものなのに，その3倍くらい欲張っているので，まったく出来そうにありません．そんな感じで作りかけのものはいくつか転がってます．でも結局いま動いているやつをやっつけで修正して寿命を延ばしてしまっているのです．恥ずかしくてコードは見せられません．

MoonBlockはこうなったらいいのに

Scratchはすでに広く評価されているものですから，「嫌いだ」というタイトルで半分釣りみたいに書きました．

MoonBlockは出たばっかりだし，日本で生まれたものですから，応援する気持ちの方が強いです．
ということで，少し表現を和らげて「こうなったらいいのに」にしました．でも，きっちり批判します．

こういうものは，思想が大事ですから．
この記事とか「ScratchとMOONBlock(前田ブロック)はどう違うの?」
http://wise9.jp/archives/8264
良いと思います．僕がScratchを批判している部分と同じようなことを言ってますね．
特に，ループとか配列とかより結果だろう，というのはまさにその通り．

一番よいのは，Javascriptが生成されるということでしょうか．これは僕もやりたいと常々思っていて．さすがだなと思いました．

プログラミングが，一枚のシート上に作られるという設計もよいです．Scratchだといろんなところにコードが分散して，オブジェクト指向はみんなそうですけど，そのオブジェクト指向の嫌な部分をそのまま持ってきてます．MoonBlockは一望できるのがよいですね．

コードを編集しても，画面に反映しないというのは，僕はちょっと戸惑いました．上記記事では「アプリを単独で動かせるため」と言っていますが，そうならば，実行時にコードエリアは編集禁止にしても良いんじゃないか．もしくは，編集を始めたら即座に現在の実行を停止して，適当に待って，勝手に実行してくれるとか．

ビスケットの場合は，実行モードが2種類あって．入門用で使っているのは，実行という概念がなくて，常にプログラムが動きつつ，編集もできるというやつ．もう一つは，「置いた位置を覚える」というモードで，ステージに置いた部品の位置を記録しておいて，プログラムの編集が終わったら，即座に記録した位置から再スタートするモード．こっちは，自分の画面で作品を作り込むときに使います．やってて画面が崩れないので．

ブロックのデザインですが，Scratchというかフローチャートというかを連想してしまうので，このデザインは良くないと思います．基本はパペットかテキストで，大きな枠を作って，その中に，そいつの振る舞いを手続き的ではなくて宣言的に指定してゆく，ということになりますが．たとえば，くまの出現と動きとイベントの条件などは，ここに置く順序は関係ないわけです(この言語の意味を調べるのにJavascriptのコードを直接読めばよいというのは，すごくわかりやすいです）．これは小さい意味の集合で記述しているので，ここのデザインは列っぽくしないで，集合っぽくすべきです．後に，式と文も出てくるので，なおさらです．

ブロックたちが，まだ整理しきれていない感じがします．たとえば，リアクションの「時間が進んだとき」は，いろんな項目がメニューに含まれてますけれど．一方で，変数のカテゴリには確率とか文字列とか独立したブロックになっていて．「もし．．なら」の条件のところはブロックじゃなくてメニューの方がいいんじゃないかとか．

「ビヘイビア追加」がおもしろい．で，こういうのがあると，「ビヘイビア削除」は無いのか，って思ってしまうのですが．じゃあ，矛盾するビヘイビアを追加したらどうなるのか調べてみると，元々の動きに時計回りの回転を入れておいて，ビヘイビア追加で，反時計回りの回転を注入すると，ちゃんと回転が止まりました．すごい．回転には回転速度のパラメータがないので，ためしに，反時計回りの回転を二つ注入してみると，一組だけ打ち消し合って，ちゃんと反時計回りになりました．ジグザグに移動も増やすとジグザグが激しくなりますね．



ビヘイビアの加算は，面白い仕様だと思いました．僕はこういう仕様すきです．

ビスケットで，音が出るんですが，猫の鳴き声がでるアイコンを2つメガネに入れると，2倍の音の大きさになるんですね．で，ある子供が，救急車が近づいてくるのを表現したくて，近づくと音がどんどん大きくなるように猫の鳴き声をならして，サイレンっぽくした，というのがありました．僕は，そういう想定で作っていなくて，単に16音くらいが同時になるってだけなんですが，同じ波形を同時に鳴らしたので，音が2倍になったと．こういう設計者が想像しない使い方に，どう応えられるかって結構大変ですが，やられるとうれしいです．

ビスケットとの比較ではなくて，一般的なプログラミング言語としてですが，例えばいろんなブロックに数字を入れられる場所がいくつかありますが，そこに式のブロックを入れられるようにした方がよいです．Scratchはそのあたりは完璧にきちんと作られています．そういうことをやらないならやらないと決めるのも潔くてよいのですが，代入とか演算のブロックがあったりなので，これから整理に期待ですか．

パペットとテキストはトップレベルで別物であるのがよいのかどうか．ほとんど同じで，表示属性が違うだけなんじゃないでしょうか．どういう表示にするというのもブロックでも良いんじゃないでしょうか．そしたら，たとえば熊の画像と，「くま」というテキストを同時に指定したら，文字付きオブジェクトになるとか．画像の合成とかもできますよね．

動きが何種類かしか用意されていないのはどうなんでしょうか．

研究所のオープンハウスで僕がビスケットのデモ展示をしていたとき，ある技術者が質問してきたのですが「この中には何種類の動きが入っているのですか」という．最初，この質問がまったく理解できなかったのですが，どうやら，彼はコンピュータが生成する動きというのは，何パターンか用意されていて，ビスケットのメガネを書いたときにそれをパターン認識して，これは上に動け，これは下に動けという判定をして，動きのルーチンを呼び出すんだ，という実装だと思ったみたいです．で，そんな作り方はまったくしていなくて，すべてのステップで，最適と思う図形の配置の書き換えをしている，というのを高速で繰り返しているだけなんですが．その解説はまったく彼には通じなかったようです．たぶん，コンピュータの技術者というよりは，何かの技術者でコンピュータはその道具として使っているだけの方なんでしょうけれど，そういうコンピュータ観を持たれる方がいらっしゃるということにびっくりしました．

で，このMoonBlockのビヘイビアが，まさにそれなんですね．あらかじめ用意された動きを呼び出しているだけです．

ところが可能性もあって，動きの演算ですごい動きのプログラミングを極めるのも面白いかと思いました．今は，ビヘイビアは集合なので（要素が重複してもよいからマルチセット），置く順序は関係ありませんが，回転とジグザグを同時に置いたとき，その順序で動きが変わる方がよいです．回転を先に置くと，ギザギザの軸が回転するので，画面では星形のような動きになります．ギザギザを先に置くと先にギザギザの座標が決まって，そのローカルな座標内で回転するから，今の動きのようになる．これは，座標変換のマトリックスの合成に順序が重要というのと同じなんですが，そのあたりをもっと整理して．それからゲームでよく使われるような動きじゃなくて，動きのプリミティブとしてあった方がよいものを用意して，それらを合成して新しい動きが作れる，と言う感じにすれば，僕には面白いです．

文部科学省のプログラミンも動きをあらかじめ用意してある側ですが，あれは合成ができないので，全然ダメです．

ビジュアルプログラミングなんで，もっと画面の座標とか方向とか文字や数字を使わないで指定する方向にはならないのでしょうか．そういう意味で，画面のレイアウトデザインを完全に捨ててしまっているのはもったいない．

プログラミングって，コードとデータのどっちに意味を持たせるか，というのがあると思いますが．たとえば，ビスケットでオルゴールのプログラムを書くことができて，赤にぶつかったらドの音，青にぶつかったらレの音というのを作っておいて，画面に赤や青を並べると曲がつくれるわけですね．この場合，プログラムは自動演奏をする部分だけ，曲はデータで表現しています．そうやって分けて記述した方が再利用性がすごく高くなる．

ビスケットを教えてて，「こうすればよい」という答えが，聞かなければ絶対にわからないようなものは出来るだけ少なくしたいと思いました．どういうことかというと，すでに教えていたことの中にヒントは沢山入っていて，そのことに気づいて自分で工夫さえすれば，大人に聞かなくてもわかったかもしれないというのを増やしたかった．尺取り虫が頭としっぽをそろえたらしゃきっと動いて見えるというのはそれですし，メガネに絵を二つ入れたら衝突判定になるというところもです．機能を探しても見つからないと思います．自分で工夫してやらなければいけないので．

Scratchのここが嫌いだ(2)

僕が伝えたいメッセージは
　コンピュータは君たちのものだよ
　こんなに可能性があるんだよ
ということ，逆にこれだけは伝えたくないというメッセージは，
　コンピュータはこんなに便利ですよ
でした．

可能性の話をします．音楽で考えてみましょう．音がポーンと一つなったとき，「これが音楽の基本なんだ，ふーん」と思うでしょう．音が二つポンポンとなると，少し印象が変わってきます．悲しく聞こえたり，楽しく聞こえたり．音が三つ四つと増えると，もうメロディと言えそうなものが聞こえてもっと色々な感情が表現できます．音楽ってすごい可能性があるなあと思えるでしょう．逆は，最初からサザンの曲を聴かせても違う意味で音楽の素晴らしさは伝わるかもしれませんが，自分で作ろうとか音楽そのものの可能性とかは伝わらないと思います．

Scratchの画面を見ると，タブで整理されているとはいえ，何か色んなアイコンが大量に並んでいます．まあ，プログラム言語を知っている人なら，こららをさーっと見るだけで大体どれくらいのことが出来そうかわかりますけど．最初からこんなに数があれば，何のすごさを見せたいのか焦点がぼけてしまいませんか．組み合わせることですごいということを伝えるのに不向きだと思いました．

「もし端についたら、跳ね返る」なんて導入するのは，すごく気持ちがわかりますよ．これを入れると便利ですし，特に入門のときにこういうのがあるとすごく教えやすいです．でも，そういう入門用の機能はさりげなくやるべきであって，こんな機能として見せちゃったらダメでしょう．これって，僕がこれだけは伝えたくないメッセージである「コンピュータはこんなに便利ですよ」そのものなんですよね．

ブロックが導入されたのは良かったと思います．だったら，「端についたら跳ね返る」という一つ上のレイヤの機能はそのブロックで作るべきでしょうね．端の判定と180度回転でいいのかな．

Scratchで嫌なのは，オブジェクト指向が中途半端に入っているということでしょうか．スプライトがあって，このスクリプトは選択しているスプライトの中に書かれているものだというモデルですね．ものを制御する，という見せ方がもの凄く全面に出ていると思います．Logoの亀もそうでしたし，ロボットのプログラミングをしてライントレースというのもやられてますけど，全部ひっくるめて，僕は嫌いです．

嫌いである最大の理由は，それがコンピュータらしくないからです．

らしくないのに，それを押し出すものだから，素人さんは「それがコンピュータだ」と思っちゃうじゃないですか．だから嫌なのです．何かを制御するというのは，コンピュータのごく一部です．

僕が考える，コンピュータのすごさは，自分でプログラム言語を作れる，ということです．Viscuitが動くためには，5段階くらいのプログラム言語の階層があります．二つの言語をまたいでいるところにコンパイラがあったり，FlashPlayerがあったり．こういう言語の階層のことをぼんやりでも頭に浮かんで欲しいのですよね．複雑なものには大抵こういう階層構造があります．ビスケットでもプログラミング言語もどきのプログラムを作ることができるんです．突き詰めて言えば，データの並びで何か意味を表現する，ってことですから．

オブジェクト指向も子供にはどうかなと思います．

オブジェクト指向って，プログラミングの中でかなり大人しいというか，優等生というか，まあ，複雑なシステムをどうやって秩序を保つかということですよね．なんでわざわざあるかというと，そうしなければぐちゃぐちゃになるからです．

オブジェクト指向が無い状態で，ぐちゃぐちゃのことを体験しなければ，オブジェクト指向のありがたさはわかりません．子供が何かを学ぶには整理され過ぎているんですよ．しかもそれが必要になるほど複雑なことをさせるわけでもなく．

コスチュームというのも，あれは何なんでしょうね．オブジェクトの一状態ということでしょうけど．スプライトがまずあって，その下に何枚かコスチュームがある．これは難しいと思いますよ．もちろん丁寧に順序立てて教えれば，小さい子でもマスターすると思います．でも，そんなことやってもコンピュータの可能性とか自分のもの感とか生まれるんでしょうか．それなりには獲得するでしょうけど，なんかすごく矮小化されたものになるように思うのですね．

変数とか制御構造とか，非常に古いプログラミング言語の構成要素ですけれど，そういったものが表に出ているのも嫌いです．そういうことを自由自在に使いこなせる人になって欲しいためにやっているんでしょうかね．

ビスケットだとそれなりに苦労しますけど，変数とか繰り返しのようなものはビスケットの構成要素の中で工夫できたりします．先日やったゲームを作るワークショップでも，小学校高学年の子が，弾が二発当たらないとやっつけられないお化けというのを自分で考えて（何もこちらで教えずに）作りました．どうやって作ったかわかりますか？お化けの絵を2種類用意しただけです．一発目が当たるとお化けは口を大きく開けます．口を開けたお化けは弾に当たるとやられます．絵を二枚重ねて，状態を表現している子もいます．これはかなり高度です．

こんな感じで，オブジェクト指向だったら得意なはずの，状態遷移を持つプログラムは，ほんとに普通に作られています．

機能が沢山あると，教えるのも大変だと思います．「もし．．なら．．」って，プログラムをやった人ならわかるでしょうけど，普通の人はこれだけ見てなんだかわからないでしょう．これを教えるのって大変だと思いますよ．大変なのが数が多い．使わないときは隠せるならいいんですが見せちゃうと，子供にこれは何，これは何って全部聞かれてしまうんじゃないでしょうか．

Viscuitのデザインで重視したことで，子供同士での教え合いを促す，というのがあります．言うのは簡単ですが，なかなか難しいです．子供が自分たちの言葉で理解できていないと教えられません．Scratchは中で起こっていることが複雑すぎて無理だと思います．ちなみに，ある小学校では小2の子が新一年生にViscuitの使い方を教える，という光景が普通に見られます．もちろん彼らが理解できる範囲の機能しか見せていないすごくシンプルな画面にしてますが．

新しいScratchになって，クローンというものが導入されたんですね．これはひどい仕様です．Scratchには継承が無いという中途半端さなので，複製されたものにはスクリプトはありません．猫が複製されても，親猫と同じ動きをしません．で，それを解決するために，「クローンされたとき」というのがあって，これは日本語訳が苦しいですね．英語だと「when I start as a clone」で，やった意味が分かったのですが重要なのはwhenじゃなくてIですね．

オブジェクト指向だから，メッセージを受ける人をどうやって指示するか，というのが構文上必要なわけです．ですが，Scratchにはそれが無くて，GUI的に現在選択しているスプライトに対して，という解釈をしているのですが．複製すると，親と子で分かれるので，子に対してどういう動作をさせるか別に指示しなければならない．それで，苦し紛れに「クローンされたとき（when I start as a clone）」が入ったわけですね．旗が押されたらというのが親にだけ動きます．スプライトにローカルな変数は作れるみたいですが，それは複製されないんですね．こういう仕様で複製をきちんと設計するのは難しいとは思いますが．僕だったら，複製したらそれらにもちゃんと名前がついて，スプライト一覧にも表示されるようにするかなぁ．で，子のスクリプトは親のコピーが薄く表示されてて編集はできないようになっているとか．

オブジェクトの複製は，Scratchはまだましな方で，プログラミンや前田ブロックはもっとひどい仕様です．これらは簡易言語ですね．プログラミング言語の土俵にはまだ載せられないです．

少しは言語のことになってきたかな．僕の誤解があればコメントで教えてください．

Scratchのここが嫌いだ(1)

今までは，一般人に対するプログラミング教育の重要性を共に説いて行く仲ということで，表立ってScratchの批判はして来なかったのですが，安倍首相までがプログラミング教育を言い出したので，そろそろ良いかと思って，ちょっと書いておきます．(1)となっているのは，この先何回続くかわからないから．

コンピュータ科学を専攻している人は，この先を読む前に自分でScratchとViscuitを比較してみるのもよいかと思います．良い勉強になるはずです．

まず，こういうツールには（特に子供向けと言っているツール）伝えたいメッセージというのが必須です．

僕はViscuitを作ったときに子供たちに伝えたかったメッセージは
　コンピュータは君たちのものだよ
　こんなに可能性があるんだよ
ということでした．この二つをかけ算すると，この可能性を切り開くのは君たちなんだよ，ということです．

それと，逆にこれだけは伝えたくないというメッセージもあります．それは，
　コンピュータはこんなに便利ですよ
です．なぜこれを伝えたくないかというと，便利なのは誰か大人が作ったコンピュータだからです．「君たちの」とは真逆．それと便利さは教育的にはまずいことも多いです．例えば電子辞書は急いで意味を調べたいときには便利ですけれど，世の中の知の世界の広大さは全く伝わりませんよね．本棚に重くて分厚い全12巻の百科事典があって，そこに書かれていることの多様さに圧倒されたこと．そういう経験をして，10回か100回はその百科事典で調べたいものを調べて，その後じゃないと電子辞書は使ってはいけないと思います．今の大人が考えた「しょぼい便利さ」なんかで発想を狭めてしまわずに，君たちはコンピュータの本質からスタートして，もっとすごい便利なものを発明してもらいたいのです．

こういうことは，まあ文系的なというか素人向けに言ってるんですが，そういうかけ声だけじゃプログラム言語は作れませんよね．ちゃんとコンピュータの専門家向けに分解すると「どういう性質をどのようにして伝えるか」が大事になります．

まず「誰が作っても同じプログラムになるのはいや」でした．同じになっちゃうと，コンピュータは自分のもの感，自分で作った感が大きく損なわれます．

Scratchは最初に猫が出てきますが，まずそこが嫌いです．最初に絵を置きたい気持ちはよくわかるんですが．Viscuitを教えてて，特に高学年の男子に多いのですが，絵を描くのを極端に嫌う子がいます．他人に自分の絵を見られるのが怖いというか．この現象はそのまま大人の男性にまで及ぶのですが．こういう人を育ててしまっているのは美術教育の最大の課題だと思いますが．そういう人のために最初に絵を用意しておくと教えやすいというのは確かにあると思います．それから単に一斉に教えるときの技術的な問題として，時間が短くてロジックを重視して教えたいときには，最初に絵を用意された環境からスタートすることがあります．絵を描く時間は人それぞれまちまちなので，それを最初の方に持ってくると，描くのが遅い人を待たないといけないということです．それで，絵を用意することはあります．だけど，それは特殊なケースであって，基本は絵がないものからスタートします．

動いている絵がそもそも違うので，誰がやっても同じプログラムにはなり様がありません．

動き方の指定もそうです．Viscuitではメガネにいれた部品のずらし方で動きが決まります．その指定がアナログ的なので同じ動きにする方が難しいです．Scratchだと10ステップ前へ動くというやつですが，まず数値で表現しているのもあれですし，初期値として10が入っているというのもあれです．

Viscuitでは初期値に関してはかなり気を配っています．絵を描く画面で実は最初に選択される色はランダムです．もう少し正確に言うと，明度と彩度は0.5から1の間のランダム，色相は360度のランダムです．これらの幅はViscuitの初期設定で変えられることができて，どんな初期値でやればどのように全体の作品が変わるか，ということも実験できるようになっています．ただ24bitの色をランダムに割り振ってだと，こんなに奇麗にはなりません．

なぜそうしたかというと，絵に深い関心のある人は，初期値の色なんて関係なく自分の選びたい色を選ぶのですが，絵にあまり関心の無い人は，最初に選ばれた色を何も考えずに使います．そんな人たちばかりが集まって作品を作ったとき，全体として色のバランスがとれるようになっています．

線の太さは，わざと太めの初期値にしています．幼児がクレヨンで描くくらいの太さです．この太さだと，誰が描いても上手く描けないので，絵の下手さがバレないというのもあります．僕らは普段は線の太さを変える方法をわざと教えていません．太さが嫌な人は，一番最初に線の太さを変える機能を探すことになるのですが，自分で見つけ出す，というのは結構重要で．子供は自由に勝手にやりますけれど，少し大きくなると，言われたことしかやらなくなりますから．必要な機能は自分で探せ，というのはコンピュータに対するもっとも基本的な姿勢ですよね．

自分で作った感を大切にしつつ，出来上がった作品はなんか上手く行った．これが裏で支える技術の重要さってものです．

Scratchはあまりその辺はこだわっていないですよね．だけどできた作品は，もちろん手をかければオリジナルっぽくなりますけど，さらっと作るとみな同じになっちゃいませんか？

プログラミング言語の話なのに，どうしてこんなに絵のことばかりかというと，例えば文字の言語だったらキャメルケース（BlueFishみたいな書き方）かスネークケース(blue_fishみたいな書き方）とか，インデントの段数とか，そういうこだわりに相当すると思ってください．

Scratchの悪口というよりViscuitの宣伝になってしまいそうですが，(2)に続く．