Scratchはすでに広く評価されているものですから，「嫌いだ」というタイトルで半分釣りみたいに書きました．
MoonBlockは出たばっかりだし，日本で生まれたものですから，応援する気持ちの方が強いです．
ということで，少し表現を和らげて「こうなったらいいのに」にしました．でも，きっちり批判します．
こういうものは，思想が大事ですから．
この記事とか「ScratchとMOONBlock(前田ブロック)はどう違うの?」
http://wise9.jp/archives/8264
良いと思います．僕がScratchを批判している部分と同じようなことを言ってますね．
特に，ループとか配列とかより結果だろう，というのはまさにその通り．
一番よいのは，Javascriptが生成されるということでしょうか．これは僕もやりたいと常々思っていて．さすがだなと思いました．
プログラミングが，一枚のシート上に作られるという設計もよいです．Scratchだといろんなところにコードが分散して，オブジェクト指向はみんなそうですけど，そのオブジェクト指向の嫌な部分をそのまま持ってきてます．MoonBlockは一望できるのがよいですね．
コードを編集しても，画面に反映しないというのは，僕はちょっと戸惑いました．上記記事では「アプリを単独で動かせるため」と言っていますが，そうならば，実行時にコードエリアは編集禁止にしても良いんじゃないか．もしくは，編集を始めたら即座に現在の実行を停止して，適当に待って，勝手に実行してくれるとか．
ビスケットの場合は，実行モードが2種類あって．入門用で使っているのは，実行という概念がなくて，常にプログラムが動きつつ，編集もできるというやつ．もう一つは，「置いた位置を覚える」というモードで，ステージに置いた部品の位置を記録しておいて，プログラムの編集が終わったら，即座に記録した位置から再スタートするモード．こっちは，自分の画面で作品を作り込むときに使います．やってて画面が崩れないので．
ブロックのデザインですが，Scratchというかフローチャートというかを連想してしまうので，このデザインは良くないと思います．基本はパペットかテキストで，大きな枠を作って，その中に，そいつの振る舞いを手続き的ではなくて宣言的に指定してゆく，ということになりますが．たとえば，くまの出現と動きとイベントの条件などは，ここに置く順序は関係ないわけです(この言語の意味を調べるのにJavascriptのコードを直接読めばよいというのは，すごくわかりやすいです）．これは小さい意味の集合で記述しているので，ここのデザインは列っぽくしないで，集合っぽくすべきです．後に，式と文も出てくるので，なおさらです．
ブロックたちが，まだ整理しきれていない感じがします．たとえば，リアクションの「時間が進んだとき」は，いろんな項目がメニューに含まれてますけれど．一方で，変数のカテゴリには確率とか文字列とか独立したブロックになっていて．「もし．．なら」の条件のところはブロックじゃなくてメニューの方がいいんじゃないかとか．
「ビヘイビア追加」がおもしろい．で，こういうのがあると，「ビヘイビア削除」は無いのか，って思ってしまうのですが．じゃあ，矛盾するビヘイビアを追加したらどうなるのか調べてみると，元々の動きに時計回りの回転を入れておいて，ビヘイビア追加で，反時計回りの回転を注入すると，ちゃんと回転が止まりました．すごい．回転には回転速度のパラメータがないので，ためしに，反時計回りの回転を二つ注入してみると，一組だけ打ち消し合って，ちゃんと反時計回りになりました．ジグザグに移動も増やすとジグザグが激しくなりますね．
ビヘイビアの加算は，面白い仕様だと思いました．僕はこういう仕様すきです．
ビスケットで，音が出るんですが，猫の鳴き声がでるアイコンを2つメガネに入れると，2倍の音の大きさになるんですね．で，ある子供が，救急車が近づいてくるのを表現したくて，近づくと音がどんどん大きくなるように猫の鳴き声をならして，サイレンっぽくした，というのがありました．僕は，そういう想定で作っていなくて，単に16音くらいが同時になるってだけなんですが，同じ波形を同時に鳴らしたので，音が2倍になったと．こういう設計者が想像しない使い方に，どう応えられるかって結構大変ですが，やられるとうれしいです．
ビスケットとの比較ではなくて，一般的なプログラミング言語としてですが，例えばいろんなブロックに数字を入れられる場所がいくつかありますが，そこに式のブロックを入れられるようにした方がよいです．Scratchはそのあたりは完璧にきちんと作られています．そういうことをやらないならやらないと決めるのも潔くてよいのですが，代入とか演算のブロックがあったりなので，これから整理に期待ですか．
パペットとテキストはトップレベルで別物であるのがよいのかどうか．ほとんど同じで，表示属性が違うだけなんじゃないでしょうか．どういう表示にするというのもブロックでも良いんじゃないでしょうか．そしたら，たとえば熊の画像と，「くま」というテキストを同時に指定したら，文字付きオブジェクトになるとか．画像の合成とかもできますよね．
動きが何種類かしか用意されていないのはどうなんでしょうか．
研究所のオープンハウスで僕がビスケットのデモ展示をしていたとき，ある技術者が質問してきたのですが「この中には何種類の動きが入っているのですか」という．最初，この質問がまったく理解できなかったのですが，どうやら，彼はコンピュータが生成する動きというのは，何パターンか用意されていて，ビスケットのメガネを書いたときにそれをパターン認識して，これは上に動け，これは下に動けという判定をして，動きのルーチンを呼び出すんだ，という実装だと思ったみたいです．で，そんな作り方はまったくしていなくて，すべてのステップで，最適と思う図形の配置の書き換えをしている，というのを高速で繰り返しているだけなんですが．その解説はまったく彼には通じなかったようです．たぶん，コンピュータの技術者というよりは，何かの技術者でコンピュータはその道具として使っているだけの方なんでしょうけれど，そういうコンピュータ観を持たれる方がいらっしゃるということにびっくりしました．
で，このMoonBlockのビヘイビアが，まさにそれなんですね．あらかじめ用意された動きを呼び出しているだけです．
ところが可能性もあって，動きの演算ですごい動きのプログラミングを極めるのも面白いかと思いました．今は，ビヘイビアは集合なので（要素が重複してもよいからマルチセット），置く順序は関係ありませんが，回転とジグザグを同時に置いたとき，その順序で動きが変わる方がよいです．回転を先に置くと，ギザギザの軸が回転するので，画面では星形のような動きになります．ギザギザを先に置くと先にギザギザの座標が決まって，そのローカルな座標内で回転するから，今の動きのようになる．これは，座標変換のマトリックスの合成に順序が重要というのと同じなんですが，そのあたりをもっと整理して．それからゲームでよく使われるような動きじゃなくて，動きのプリミティブとしてあった方がよいものを用意して，それらを合成して新しい動きが作れる，と言う感じにすれば，僕には面白いです．
文部科学省のプログラミンも動きをあらかじめ用意してある側ですが，あれは合成ができないので，全然ダメです．
ビジュアルプログラミングなんで，もっと画面の座標とか方向とか文字や数字を使わないで指定する方向にはならないのでしょうか．そういう意味で，画面のレイアウトデザインを完全に捨ててしまっているのはもったいない．
プログラミングって，コードとデータのどっちに意味を持たせるか，というのがあると思いますが．たとえば，ビスケットでオルゴールのプログラムを書くことができて，赤にぶつかったらドの音，青にぶつかったらレの音というのを作っておいて，画面に赤や青を並べると曲がつくれるわけですね．この場合，プログラムは自動演奏をする部分だけ，曲はデータで表現しています．そうやって分けて記述した方が再利用性がすごく高くなる．
ビスケットを教えてて，「こうすればよい」という答えが，聞かなければ絶対にわからないようなものは出来るだけ少なくしたいと思いました．どういうことかというと，すでに教えていたことの中にヒントは沢山入っていて，そのことに気づいて自分で工夫さえすれば，大人に聞かなくてもわかったかもしれないというのを増やしたかった．尺取り虫が頭としっぽをそろえたらしゃきっと動いて見えるというのはそれですし，メガネに絵を二つ入れたら衝突判定になるというところもです．機能を探しても見つからないと思います．自分で工夫してやらなければいけないので．
MoonBlockは出たばっかりだし，日本で生まれたものですから，応援する気持ちの方が強いです．
ということで，少し表現を和らげて「こうなったらいいのに」にしました．でも，きっちり批判します．
こういうものは，思想が大事ですから．
この記事とか「ScratchとMOONBlock(前田ブロック)はどう違うの?」
http://wise9.jp/archives/8264
良いと思います．僕がScratchを批判している部分と同じようなことを言ってますね．
特に，ループとか配列とかより結果だろう，というのはまさにその通り．
一番よいのは，Javascriptが生成されるということでしょうか．これは僕もやりたいと常々思っていて．さすがだなと思いました．
プログラミングが，一枚のシート上に作られるという設計もよいです．Scratchだといろんなところにコードが分散して，オブジェクト指向はみんなそうですけど，そのオブジェクト指向の嫌な部分をそのまま持ってきてます．MoonBlockは一望できるのがよいですね．
コードを編集しても，画面に反映しないというのは，僕はちょっと戸惑いました．上記記事では「アプリを単独で動かせるため」と言っていますが，そうならば，実行時にコードエリアは編集禁止にしても良いんじゃないか．もしくは，編集を始めたら即座に現在の実行を停止して，適当に待って，勝手に実行してくれるとか．
ビスケットの場合は，実行モードが2種類あって．入門用で使っているのは，実行という概念がなくて，常にプログラムが動きつつ，編集もできるというやつ．もう一つは，「置いた位置を覚える」というモードで，ステージに置いた部品の位置を記録しておいて，プログラムの編集が終わったら，即座に記録した位置から再スタートするモード．こっちは，自分の画面で作品を作り込むときに使います．やってて画面が崩れないので．
ブロックのデザインですが，Scratchというかフローチャートというかを連想してしまうので，このデザインは良くないと思います．基本はパペットかテキストで，大きな枠を作って，その中に，そいつの振る舞いを手続き的ではなくて宣言的に指定してゆく，ということになりますが．たとえば，くまの出現と動きとイベントの条件などは，ここに置く順序は関係ないわけです(この言語の意味を調べるのにJavascriptのコードを直接読めばよいというのは，すごくわかりやすいです）．これは小さい意味の集合で記述しているので，ここのデザインは列っぽくしないで，集合っぽくすべきです．後に，式と文も出てくるので，なおさらです．
ブロックたちが，まだ整理しきれていない感じがします．たとえば，リアクションの「時間が進んだとき」は，いろんな項目がメニューに含まれてますけれど．一方で，変数のカテゴリには確率とか文字列とか独立したブロックになっていて．「もし．．なら」の条件のところはブロックじゃなくてメニューの方がいいんじゃないかとか．
「ビヘイビア追加」がおもしろい．で，こういうのがあると，「ビヘイビア削除」は無いのか，って思ってしまうのですが．じゃあ，矛盾するビヘイビアを追加したらどうなるのか調べてみると，元々の動きに時計回りの回転を入れておいて，ビヘイビア追加で，反時計回りの回転を注入すると，ちゃんと回転が止まりました．すごい．回転には回転速度のパラメータがないので，ためしに，反時計回りの回転を二つ注入してみると，一組だけ打ち消し合って，ちゃんと反時計回りになりました．ジグザグに移動も増やすとジグザグが激しくなりますね．
ビヘイビアの加算は，面白い仕様だと思いました．僕はこういう仕様すきです．
ビスケットで，音が出るんですが，猫の鳴き声がでるアイコンを2つメガネに入れると，2倍の音の大きさになるんですね．で，ある子供が，救急車が近づいてくるのを表現したくて，近づくと音がどんどん大きくなるように猫の鳴き声をならして，サイレンっぽくした，というのがありました．僕は，そういう想定で作っていなくて，単に16音くらいが同時になるってだけなんですが，同じ波形を同時に鳴らしたので，音が2倍になったと．こういう設計者が想像しない使い方に，どう応えられるかって結構大変ですが，やられるとうれしいです．
ビスケットとの比較ではなくて，一般的なプログラミング言語としてですが，例えばいろんなブロックに数字を入れられる場所がいくつかありますが，そこに式のブロックを入れられるようにした方がよいです．Scratchはそのあたりは完璧にきちんと作られています．そういうことをやらないならやらないと決めるのも潔くてよいのですが，代入とか演算のブロックがあったりなので，これから整理に期待ですか．
パペットとテキストはトップレベルで別物であるのがよいのかどうか．ほとんど同じで，表示属性が違うだけなんじゃないでしょうか．どういう表示にするというのもブロックでも良いんじゃないでしょうか．そしたら，たとえば熊の画像と，「くま」というテキストを同時に指定したら，文字付きオブジェクトになるとか．画像の合成とかもできますよね．
動きが何種類かしか用意されていないのはどうなんでしょうか．
研究所のオープンハウスで僕がビスケットのデモ展示をしていたとき，ある技術者が質問してきたのですが「この中には何種類の動きが入っているのですか」という．最初，この質問がまったく理解できなかったのですが，どうやら，彼はコンピュータが生成する動きというのは，何パターンか用意されていて，ビスケットのメガネを書いたときにそれをパターン認識して，これは上に動け，これは下に動けという判定をして，動きのルーチンを呼び出すんだ，という実装だと思ったみたいです．で，そんな作り方はまったくしていなくて，すべてのステップで，最適と思う図形の配置の書き換えをしている，というのを高速で繰り返しているだけなんですが．その解説はまったく彼には通じなかったようです．たぶん，コンピュータの技術者というよりは，何かの技術者でコンピュータはその道具として使っているだけの方なんでしょうけれど，そういうコンピュータ観を持たれる方がいらっしゃるということにびっくりしました．
で，このMoonBlockのビヘイビアが，まさにそれなんですね．あらかじめ用意された動きを呼び出しているだけです．
ところが可能性もあって，動きの演算ですごい動きのプログラミングを極めるのも面白いかと思いました．今は，ビヘイビアは集合なので（要素が重複してもよいからマルチセット），置く順序は関係ありませんが，回転とジグザグを同時に置いたとき，その順序で動きが変わる方がよいです．回転を先に置くと，ギザギザの軸が回転するので，画面では星形のような動きになります．ギザギザを先に置くと先にギザギザの座標が決まって，そのローカルな座標内で回転するから，今の動きのようになる．これは，座標変換のマトリックスの合成に順序が重要というのと同じなんですが，そのあたりをもっと整理して．それからゲームでよく使われるような動きじゃなくて，動きのプリミティブとしてあった方がよいものを用意して，それらを合成して新しい動きが作れる，と言う感じにすれば，僕には面白いです．
文部科学省のプログラミンも動きをあらかじめ用意してある側ですが，あれは合成ができないので，全然ダメです．
ビジュアルプログラミングなんで，もっと画面の座標とか方向とか文字や数字を使わないで指定する方向にはならないのでしょうか．そういう意味で，画面のレイアウトデザインを完全に捨ててしまっているのはもったいない．
プログラミングって，コードとデータのどっちに意味を持たせるか，というのがあると思いますが．たとえば，ビスケットでオルゴールのプログラムを書くことができて，赤にぶつかったらドの音，青にぶつかったらレの音というのを作っておいて，画面に赤や青を並べると曲がつくれるわけですね．この場合，プログラムは自動演奏をする部分だけ，曲はデータで表現しています．そうやって分けて記述した方が再利用性がすごく高くなる．
ビスケットを教えてて，「こうすればよい」という答えが，聞かなければ絶対にわからないようなものは出来るだけ少なくしたいと思いました．どういうことかというと，すでに教えていたことの中にヒントは沢山入っていて，そのことに気づいて自分で工夫さえすれば，大人に聞かなくてもわかったかもしれないというのを増やしたかった．尺取り虫が頭としっぽをそろえたらしゃきっと動いて見えるというのはそれですし，メガネに絵を二つ入れたら衝突判定になるというところもです．機能を探しても見つからないと思います．自分で工夫してやらなければいけないので．