Skip to content

ScratchとMOONBlock(前田ブロック)はどう違うの?

さてさて、世の中にはビジュアル言語と呼ばれるものが既にいくつか存在している。

最も有名なのは、アラン・ケイ博士が開発したSqueakと、それをもとにMITのミッチェル・レズニック教授が開発したScratchだろう。

そして最近、enchant.jsベースのビジュアル言語である前田ブロック(MOONBlockはenchantMOONでの呼び方)、そして同じくMITが開発に関わっているLEGO Mindstormsがある。他にもゲームではカルネージハートのようにビジュアルプログラミングそのものが遊びになっているものもあるし、DelphiやInterface Builder(およびObjective-C)のようにユーザーインターフェースの定義をビジュアル的に行うものなど、様々なビジュアル開発環境がある。

 

ここでは特にプログラムの論理構造(ロジック)をビジュアルブロックで表現するものに限定して、それぞれの特徴と違いを紹介したいと思う。

 

ビジュアル言語は、その性質からいって、非常に見た目が似ている。従って、すぐには区別がつかない。端から見ると同じものに見えてしまう。しかしそれは、同じ漢字を使っているからといって日本語と中国語に互換性があると考えるくらい間違ったことだ。ほとんど同じアルファベットでも、フランス語とドイツ語は文法からなにからぜんぜん違うし、英語とは似ても似つかない。

 

プログラミング言語で例えるなら、PHPとJavaScriptは文法は似てる(ともにC言語系列の括弧を採用)しているけれども、PHPが言語の内部構造をC言語由来の手続き型に特化しているのに対し、JavaScriptはLisp由来の関数型傾向の言語(厳密にはLispも手続き型言語)を指向しているという違いなどがある。

 

たとえば、PHPで100個のフィボナッチ数列を表示するプログラムは以下のようになる

$a = 1;$b = 0;
echo "1,1,";
for($i=0 ; $i<100 ;$i++){
       $r = $a+$b;
       $a = $b;
       $b = $r;
       echo $r.",";
}

 同じ処理だが、JavaScriptで書くと以下のようになる

var result = "1,1,",a=1,b=1;
for(var i=0;i<100;i++){
     r = a + b;
     a = b;
     b = r;
     result += r+",";
}
alert(result);

 よりJavaScriptらしく無名関数で再帰で書くと以下のようになる

alert((function(n){ 
                    return "1,"+(f = function(a,b,n){
                                                  if(n==0){return "";}
                                                  return a+","+f(a+b,a,n-1);
                                        })(1,1,n);})(100));

 これに「f 5」とやると6番目のフィボナッチ数を求めることが出来る(0から始まるため)。
 どれがエレガントか、という問題ではなく、考え方が根本的に違う。

 最初の例のような書き方は、フィボナッチ数列という考え方に対して非常にシンプルだ。「一つの前の数字を足したものが次の数字になる」という定義に忠実であると言える。また、必要な数値が100だから、forループで100回、というのも解りやすい。

 それに対して、再帰を使った書き方はややトリッキーに見える。
 しかし考え方によってはこちらのほうがよりシンプルであるとも言える。こちらは再帰でひたすらスタックを積んで行き、最後に一気に文字列を生成する。

 上の二つにくらべると、純粋関数型言語であるHaskellの書き方はとてもシンプルで、かつ実利的だ。
 

do
   let f 0 = 1
       f 1 = 1
       f n = f(n-1) + f(n-2)
   map fib [1..100]

 fに0が渡されたら(1番目なので)1、1が渡されたら(2番目なので)1、そしてそれ以外の自然数nが渡されたらf(n-1)とf(n-2)を足す、という、フィボナッチ数列本来の定義を書いているだけで、再帰が行われて自然に答えが求まる。数学的な問題を扱うのにHaskellは向いている。ただし、このプログラムは上記のものに比べて絶望的に実行速度が遅い。

 なぜかというと、ひとつの数値を求めるごとに全部のループが再帰で回るからだ。
 ちなみにHaskellでも高速に計算する方法はある

 let fibs@(_:fibs') = 1 : 1 : zipWith (+) fibs fibs' in take 100 fibs

 再帰的にリストを追加していくことで処理コストがPHPやJavaScriptと等価になる。ただしこれはパッと見て慣れてないと何が置きてるのかわからないという欠点がある。

take 100 $ map fst $ iterate (\(x, y) -> (y, x + y)) (1, 1) 

 こうも書ける(by 坂口和彦)。

 しかしここでの問題はどの書き方が優れているとか、どの書き方がエレガントであるとか、性能または美学、そのどちらでもなく、言語によってそういう書き方の違いがある、ということが重要なのだ。書きたいものが根本的に違うのだ。

 ある言語で書けるロジックが、他の言語で出来ないことは原則的にほとんどあり得ない。だからある言語を使ってあることができないということは原理的にはあり得ない。

 しかしブラウザで表示するUIを作るときにはJavaScriptではなくPHPを使うべき理由は特にないし、サーバで動くプログラムを作るときにPHPではなくJavaScriptを使う場合はNodeJSを使いたい場合などに限られる。

 プログラミング言語にはそれぞれ目的があり、目的が変化すれば当然、プログラミング言語も変化するのである。PHPはWebサーバの記述用、JavaScriptはWebブラウザのクライアント用という目的の違いがある。

 今回議論する二つビジュアルプログラミング言語もそれぞれ異なる目的で作られている。Scratchはロジックの教育、前田ブロック(MOONBlock)はスマートフォン/タブレットで動作するゲームやツールの開発、ちなみにLEGO Mindstormはレゴブロックの制御という目的の違いがある。

 まず最も普及していると思われるScratchから見てみよう。
 Scratchでは、WebサービスでScratchのアカウントを作るとすぐに開発を始めることが出来る。

 新しいプロジェクトを作ると、猫が表示される。

スクリーンショット 2013-06-13 14.39.48

 この猫がマウスポインターを追いかけるようにするには、右側部分にタイルを並べてプログラムを書く。

 緑の旗がクリックされたとき、「ずっと」の中に「マウスポインタへ行く」というブロックを置く

スクリーンショット 2013-06-13 14.49.39

 こうすると、緑の旗(たいていはスタートの合図として使われる)をクリックすると、以後、ずっと猫がマウスポインタに貼り付くことになる。

 次に、スプライトとしてりんごを追加する。

スクリーンショット 2013-06-13 14.44.52

 このりんごを、画面上にランダムに配置するには、以下のようにする。

スクリーンショット 2013-06-13 16.03.49

 なるほど、解りやすい気がする

 さらに、猫がりんごに当たったらりんごが回転するようにしてみよう。

スクリーンショット 2013-06-13 16.05.25

 猫の名前はデフォルトで「Sprite1」なので、それにあたったら回転させることにしよう。

 ところが実際にこれでやってみると・・・

スクリーンショット 2013-06-13 16.05.35

 猫がりんごに当たった時に回転するのはどれか一つだけになってしまう。
 実はこのやりかただと、毎回旗をクリックする度にクローンではない本体が移動することになる。

 そこでどうするかというと、「クローンされたとき」というブロックを上手く使わなければならない。

スクリーンショット 2013-06-13 16.11.28

 このようにする。
 すると、りんごの本体は常にどこかにひとつだけ存在していて、動的にコピーされたクローンだけが座標を変化することになる。

 ところがこのScratchという環境では、インスタンスがずっと連続しているので、ただ停止してもパラメータ類がリセットされない。
 いわば一時停止なのだ。

 これは連続性をもたせたほうが少年少女の教育には適しているというポリシーから来るものだろう。
 しかしプログラミングの感覚としては、起動するたびに全てのパラメータは初期値に戻って欲しい。とも思う。繰り返すが、これは「どっちがより優れているか」ではなく、その言語がどのような目的で設計されたか、ということの一つの例に過ぎない。

 では、同じことを前田ブロック(MOONBlock)でやるときにはどうするか。

スクリーンショット 2013-06-13 14.54.01

 こうなる。
 前田ブロックが前提としているのは、作られたプログラムがスタンドアローンのアプリとなって動作することだ。
 また、プログラム全体を一度に見渡すことができるように、それぞれのイベントによってブロックが離れたりはしない。

 Scratchの場合、クラス(スプライト)によって作業ペインが切り替わる。
 そのぶん、論理の構築を自然に学ぶことができると言えるだろう。

 しかし前田ブロックでは、論理を構築する、という前提を敢えて置かないようにした。
 それは、条件分岐(もし〜ならば〜)やループ(繰り返し)を教えるのが、若年層のみならず中高年に対するプログラミング教育で障害になるということが事前の臨床研究で解ったからだ。

 我々は前田ブロックを設計する前段階として、プログラミング経験ゼロの東大生8人にプログラミングを教えたり、プログラミング経験ゼロの社会人(電通マン)延べ40人にプログラミングを教えるなどのフィールドワークを一年に渡って行って来た。

 すると、既に教育を受けてしまった多くの人がつまずくポイントは、(1)A=A+1など変数が変化する代入式(数学的な等式としては矛盾してるように見える)を受け入れられない (2){}や[]などの対応関係がすんなり入力できない。全角半角の区別がつけられない (3)条件分岐やループなどの概念は理解できるがどのように使えばいいのかわからない (4)配列を理解するのに時間がかかる ということが解った。

 (1)(2)の部分はビジュアル言語を使えば回避できる。そこでビジュアル言語を導入することにした。しかし問題は(3)(4)である。
 Scratchでは(4)は存在はするものの、かなり後ろの方に追いやられている。知らなくてもある程度は大丈夫なようになっているのだ。

 しかし、Scratchでは、(3)ループと条件分岐については、それを知らなければゲームらしきものを作ることは100%できないようになっている。

 さて、ではプログラミングをより広く多くの人に解りやすく使えるようにしていくために我々がやるべきことはなんだろうか。
 条件分岐とループは、もちろん必須の概念だが、ケータイのGPS地図を使うのに相対性理論を先に理解する必要がないのと同じように、まずは結果を先に見れるようにしてやるべきではないだろうか。

 私個人の長年のソフトウェア開発経験と、ソフトウェア開発に関わる人材の育成経験から言って、画面遷移図を作れる人や、アニメーションの指示書を作れる人は数居れど、それをフローチャートに落とし込める人はかなり希少だ。

 もちろん誰もがフローチャートくらいは作れるようになるべきだ、という主張にも賛同するものの、フローチャート的に物事を考えるようになるには多少の訓練が必要である。

 問題は学習をスタートしてから、それを継続するモチベーションをどのように設計するかということで、その意味では条件分岐とループ、および配列は明らかに初心者のプログラミング学習の継続意欲を奪うものであることは実験によって確かめることができた。

 そこで、たとえばcode.9leapでは条件分岐やループよりも先にイベント駆動のプログラミングを教えているし、enchant.js自体が配列とループを学習しなくてもゲーム開発ができるよう、コレクションを持つように改良されている。

 前田ブロック(MOONBlock)の目的とするプログラミングとは、仕様をビジュアル的に定義すると実現するプログラムであり、隠蔽できる部分はできるだけかりそめの隠蔽を行う、というものだ。ただし、中身を見ようと思えばいくらでも見ることが出来るようにもなっている。

 
 その意味では前田ブロックは見た目はSqueakの流れを汲んではいるものの、その精神としてはUMLのクラス図に近い。

 その結果、条件分岐やループといった初心者に理解が難しい概念を用いなくても簡易なシューティングゲームを作ることができるようになっている。
 もちろん条件分岐もループも内部的には用意されているのでそれを使って自由にプログラミングすることができる。

 前田ブロックはまだ発展途上の言語のため、改良の余地は多々ある。
 しかしそれは、決してScratchやSqueakのデッドコピーを作るためのものではなく、あくまでも、「仕様からロジックに至る」というアプローチに忠実なまま、より高度なプログラム表現を可能にするためである。

 Scratch、およびSqueakは、前田ブロックのアプローチと比較すると、フローチャートをビジュアル化したものにより近いものであると言える。
 それは「論理の構築」というプログラミングの一つの側面を教育する用途には適していると言えるが、論理の構築よりも仕様の定義を先に教える前田ブロックとはアプローチが逆である。

 Scratchはボトムアップ型、前田ブロックはトップダウン型の構築を目指していると言っても良いだろう。
 また、Scratchには2.0からクローン機能が搭載されたとはいえ、「本体」というイデアが別に存在するのに対し、前田ブロックはより現状の主流となっているプログラミング言語に近いパラダイムである「クラス」を定義し、「インスタンス」が生成されるという仕組みを導入していることも大きな違いの一つであると言える。

 もともと「前田ブロック」を着想したのは、この名前の元になっている前田さん(タミヤでレーサーミニ四駆の企画を担当)にenchant.jsを学ばせようとしたときに、「if文のところまでやりましたがfor文がちょっと難しいですね」とenchant.js以前のところでつまづいていたからだ。また、「子供にもプログラミングをやらせる」ということは、同時に「その子の親にも理解させる」ということであり、若年層へのプログラミング教育は、同時にその親世代への教育も含まれる。親や先生が理解できないものを子供に教えることはできないからだ。

 だからいつまでたっても学校のプログラミングの授業は効果を発揮できないのではないかと思う。
 また、例が退屈で、ゲームらしきものに到達するまでにかなりのルールや論理構造を覚えなければならない。

 よくScratch陣営の人は「それはScratchでもできる」と言うが、それができるのは一体人口の上位何パーセントの頭脳を持つ人なのか。
 たとえばScratchに充分習熟した子供は、縦スクロールシューティングゲームやオセロゲームが作れるという。しかしそれを作るのに何年掛かるのか、ということがむしろ問題なのだ。

 誰かにプログラミングを教えようというとき、その動機はさまざまだと思うが、たとえば「ゲームをつくる」ということをフックに教える場合、彼らが「ゲームだ」と明らかにイメージできるような例、つまりモグラ叩きや縦スクロールシューティングゲームをできるだけ早い段階で実現できるように持って行くことが大切だ。

 イメージしたものを形にする段階を経験すれば、次に「もっとこうしたい」という欲望が湧いて来る。
 鍵盤に触る前に音楽理論から教えるような教育ではだめだ。まずは鍵盤を叩かせてみて、次に運指を教えてみて、楽しさが充分解るようになってから音楽理論に入って行かなければならない。

 また、前田ブロックはビジュアルプログラミングがプロの世界でも通用するようになることを最終目標としている。単に教育に特化した用途ではなく、プロが最初から前田ブロックでプロトタイプを作り、前田ブロックで細部を仕上げて行くような言語構造の構築を目指しているのである。その意味でScratchと前田ブロックは決定的に違う。

 Scratchで作られた家庭用ゲームは存在しないし、これからも存在しないだろう。作ることは不可能ではないが、それが主流になる可能性は限りなく低い。しかし近い将来、前田ブロックで作られた家庭用ゲームが登場するだろう。前田ブロックの内部はenchant.jsであり、既にenchant.jsで作られたゲームは家庭用ゲーム機で何の問題もなく動作している。enchant.jsで作られたiOSアプリやAndroidアプリがAppStoreに並んでいる以上、これは決して戯れ言ではない。プロというと、プログラミングのプロを連想するかもしれないが、前田ブロックによってプロの定義を広げることが出来る。それまでFlashのアニメーションしか作ってこなかったような人たちが前田ブロックによってプログラマーになれる可能性があるのだ。

 Scratchは、安全で、子供が遊ぶのに最適化された砂場であり、前田ブロックは、新時代の思考表現のための道具となることを目指している。ビジュアルプログラミングは、単に教育目的のためのオモチャや教材ではなく、プログラミングという概念全てを進化させる次なる形態だという信念が、前田ブロックの根底にはあるのだ。

 以上、これは前田ブロック側からみたScratchとの比較であるが、Scratch陣営から何か反論があればお聞きしたい。

このエントリーをはてなブックマークに追加
はてなブックマーク - ScratchとMOONBlock(前田ブロック)はどう違うの?
Post to Google Buzz
Share on GREE

Related posts:

  1. 必見!9leap投稿ゲームプログラムの作り方!
  2. JavaScriptでMMOGをつくってみよう その7 JSON-RPC風通信

Facebook comments:

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*