火山 ２進法のカウンター

ビスケットで２進法を教える，簡単なやりかたができたので紹介します．この作業だけだったら小学生でもできます．ただ，ここで起きていることの説明を理解するのは難しいかなと思います．高校で２進法を習うそうですが，それの導入などに使えると思います．


まず準備としてですが，ビスケットのHPから「すごいゲームセンター」の「やってみる」を開きます．
歯車のボタンを押して設定画面を開きまして，

「滑らかななうごき」のチェックをはずします．


煙の絵を描きます．このとき，太いペンで，半透明の色で描いてください．好きな色で，丸く塗りつぶせばよいです．


煙が上に動く，というのを作ります．動く速度は，ちょうど煙の大きさ一つ分くらい（よりちょっと離れててもよい．近いのはダメ）．


次に，火山の絵を描きます．これはなんでもいいです．


画面には煙の部品が置かれているとおもいますが，それを全部片付けて，火山を一つだけ入れます．


メガネの左右の同じ位置に，火山をぴったりいれます．ぴったりなので火山は動きません．


火山のメガネの右側に，煙を一つおきます．これで，「火山からは煙がでる」ということを延々と続けて動くことになります．それでまっすぐ上に繋がった煙が見えるとお思います．

ここでは，煙が生成されるのと，煙が上がるという組み合わせでこのように見えますが，煙が上がるというメガネを壊すと，火山の真上に煙が生成し続けます．煙は半透明で描かれているので，煙が重なってどんどん濃くなって行く様子が観れると思います．


煙が生成されるのが早すぎるので，火山のメガネの右側に大きな時計をいれて，ゆっくり動くようにします．煙が時々現れてそれが上に上がって行きます．

これだと単調に煙が上がって行く，のどかな感じですが．変わった上がりかたをやってみます．


煙のメガネの左側にもう一つ煙を重ねていれます．ここでは分かりやすいように煙をずらして入れてますが，ぴったり重ねていれてください．

さてどうなるでしょうか．










動画はこちらです．


煙が二つ重なると，一つになって上に上がってます．

数を数えながらこのアニメーションを見るのがよいと思います．どの数の時に煙は上に上がるでしょうか（これでもまだ動きが早すぎる場合は大きな時計を２つ３つメガネの中にいれてください）．

２，４，８，１６と２倍ずつで煙が上に上がっていきます．煙の並びのパターンと，何回目かというのは１対１に対応しているので，パターンから数へ，数からパターンを当てる遊びができるはずです．おはじきやコインをつかって，煙のパターンをつくって当て合う遊びができるでしょう．

このとき，大事なのは煙が繋がっていないとき，そこに空白がありますがその空白の距離が重要だということですね．何マス分離れているかを間違えると，数との対応も間違ってしまいます．たとえば

これは２マス空いてますが，

こっちは３マス空いています．なかなか区別は難しいですね．

そこで空白のマスがわかるように，小さな煙を追加します．

めがねはこのように変わります．
１）煙と煙が重なると，煙が一つ上に上がって，空いたところに小さな煙になる
２）もうひとつは，煙とちいさな煙が重なると，ちいさな煙は消える．

これで動かすと

のようになり，マスの数を間違えることはなくなります．

煙を１として小さい煙を０として横に並べると二進数になります．

二進法の基本は
　２つが重なると，１つに合わさって１つずれる．
　空白の数が重要なので，小さい煙や０をを使う．
たったこれだけなのでした．

ビジュアルプログラミング言語の可能性

さっそくなんで，まず文字のプログラミング言語とビジュアルプログラミング言語の違いから見て行きましょう．

有名なScratchですが，これはビジュアルプログラミング言語というより，文字のプログラミング言語のGUI版と捉えるべきものです．ブロックがあって，どのブロックとどのブロックが繋がるか繋がらないかというのは，つなぎ目の形でわかるようになっている．

文字の言語は，適当に文字を並べても正しいプログラムにはならずに，ある決まった規則にしたがって作らなければならない．それが文法ということですが，文法に従って文字を入力するのはなかなか難しいのです．「,」 と「.」が違っててもエラーですから．それをScratchはGUI上の制約として表現することで，誰でも簡単に文法に従ったプログラムを作ることができるようになりました．

逆にScratchのプログラムと同じ動きをする文字のプログラムとの関係を比べて見ると，文字の言語がどういうものなのかがわかると思います．で，そういうのにピッタリのツールが高尾さんが作っている Smalruby というルビーのScratch版ですね．ブロックを並べて Ruby というボタンを押すと，そのブロックの並びに対応したRubyのプログラムを見ることができます．

Rubyの面白さは，簡単に文法を拡張できるような仕掛けにあります．それがRubyが広く愛されている理由だと思いますが．Smalruby もその仕掛けをさらっと使って，RubyをScratchを動かすために専用に作られた言語っぽく見せています．Scratchがどういう言語なのかを知るためには，Smalrubyの中身を見るのがよいかもしれません（もちろん，Smalrubyが現在開発中であり，この先どこまで Scratchとの一致路線に突き進むのかは分らないので，本当のところは不明です）.

これらの画面上のプログラムと文字の言語によるプログラムをつなぐものが，構文木という構造です．構文木がどういうものかは検索してみて下さい．いい解説がいっぱいあります．文は主語と述語に分かれて，主語は名詞句と助詞に分かれて，といった木を逆さまにした形のものですで，Scratchのようなビジュアルプログラミング言語は画面上のブロックの並びから構文木を直接つくってしまうのです.

なんでこんな話をしているかというと，ビスケットは構文木を使わないプログラミング言語だからです．構文がまったくないわけではないので「使わない」という言い方は正確ではないですが，構文木の表現を超えたところにいろんな意味を含ませているという感じですかね．

そもそもプログラミング言語というのは，人間とコンピュータとの間で考えとか知識とかを共有するためのものです．人間がコンピュータに一方的に命令するため，というのは狭くて，コンピュータが自分がこれから行おうとしていることをプログラムで表現してそれを人間に見てもらう，という使い方もできるわけです（コンピュータが自分でプログラムを生成するというのもアリです）．人間同士の共有にも使えます．何かが表現されていて，それを解釈する方法が定義されていればよいのです．その定義も厳密じゃなきゃいけないということはありません．用途によっては曖昧な解釈をする方が好まれる場合もあるのです．

英語圏の人たちがプログラミング言語を設計したので，プログラミング言語がどんどん英語に似て，文法について厳密になって来た，という部分はあるでしょう．日本語だったらここまで厳密じゃないですからね．自然言語だけじゃなく，図や絵でも音楽でも考えや知識を表現することができます．それらの表現にもある種の構造はあるでしょうけれども，英語やプログラミング言語のように厳密に文法は決まってはいません．どちらかというと表現されたものから，状況によって構造を読み解いて意味を解釈する，というものです．

つまり，ビジュアルプログラミング言語の可能性というのは，表現と解釈をどう定義するか，というところまで広げることができるのです．ビスケットは表現の部分でアナログ的な情報を許して，解釈の部分で曖昧性を許しました．ビスケットが作るアニメーションは見ていて飽きないのはそこから自然と生まれてくるカオス的な現象があるからです．

では，次回はビスケットが生まれる前にいろいろと研究されていた構文木がない表現の世界の説明をします．

プログラミング言語を作るということ

ビスケットが作られて12年になるわけですが，ビスケットを脅かすような面白い言語はなかなか登場しないなぁと，寂しい想いもあります．昔はいっぱい登場した気がするんですが．

昨日，研究者の人たちに僕のビジュアル言語の新作とか見せてたときに，どうやって作っているのかわからないと言われまして．彼はコンピュータの専門家ではないけれども，研究で普通にプログラムは書いているレベルですが．

考えてみると，プログラミング言語って作るのは結構むずかしいんですよね．普通のプログラムより1ランク上のむずかしさがあります．それでも文字の言語に関しては，作るためのツールもよい本も昔からあって，作り方は知りたい人が知れる状態にはなっていると思います．逆に文字の言語は歴史が古すぎて新しいものを思いつく方がむずかしい．

それに対して，ビジュアルプログラミング言語ってすごい可能性があるんですよね．文字の言語には到底出来ないようなことが，簡単にできてしまう．これからはビジュアルプログラミングの時代だと僕が思ったのは20年くらい前なんですが（笑）．

一方で，ビジュアルプログラミング言語の作り方って全然情報がないですね．僕は誰かに教わったとかじゃなく，独自に作って来たのですが．そんなにむずかしくはないです．ゆっくりと世の中が進んでいた時代ではそういう勉強の仕方でもよかったのでしょうが．いま，情報に満ちあふれて，ちょっと検索すればいろんなノウハウが簡単に手に入る時代に，ビジュアルプログラミング言語を作る方法だけ独自であみ出せって言われても，それは無茶な話なのかもしれません．

というわけで，ビジュアルプログラミング言語の作り方というか，僕がもっているノウハウをこれからどんどん書いて行くことにしました．もちろんビスケットの中身の話もあるでしょうが，僕自身他にもいろんなビジュアルプログラミング言語を作っているので，もっと範囲は広くなります．

という，自分に対する決意表明でした．忙しいので，ゆっくりやります．