ビスケットの設計方針

ビスケットを作ろうと思ったのが2002年末頃で，それから数ヶ月後にはほぼ今と変わらない設計ができていた．その設計の話．

子どもや，コンピュータが苦手だと思っている人に，プログラミングの楽しさを知ってもらいたい．こういった動機は，プログラミンなど，初心者向けプログラミング言語に共通していると思う．ただし，僕は数学が苦手な人でも，プログラミングの楽しさを知ってもらいたいと思っている．コンピュータと数学は密接に関連してるようだけれども，基本的な部分はそれほどでもない．できるだけ数学の香りがしないようなプログラミングにしたかった．

プログラミングを教えるといったとき，いったい何を教えたら，プログラミングを教えたことになるのか．逆に，何は教えたくなかったのか．そこが重要である．

僕は大学でもいろんなプログラミング言語に接してきたし，自分で非常に変わったプログラミング言語を作ったりもしてきたので，広い視点でそれを考えることができた．

変わった言語の代表としてPrologというのがある．実行の順序が決まっていないし，変数はあるけど一度値が決まってしまったら変更することができないし．僕が昔遊んでたのは，Prologに2進数を教えて，足し算を教えたら，自動的に引き算を計算してくれる．足し算を計算の手順としてではなく，計算の関係として表現する．手順ではなく関係で表現されているので，関係を逆にたどることもできて，引き算になったりするのである．そんな不思議な性質がある．FPという言語は実際の計算はしないで，計算式を計算の対象にする．計算式を入力したら，別の計算式が出力される．コンパイラみたいなものだ．

プログラミング言語というのは，今の時代に使われいるものよりも，ずっと広い．変わった種類のものが沢山ある．いろんなプログラミング言語の歴史の中で，オブジェクト指向は比較的最後の方に出てきて，複雑なシステムを作りやすいという理由で，それが今のメインストリームとなったわけだ．

オブジェクト指向は実用にはすごく役立つのだけれど，最初から教えるのはどうかと思っている．というのは，オブジェクト指向のありがたみは，ある程度複雑なプログラムにならないとわからないからである．まずは，オブジェクト指向を使わないでプログラムを書いてみて，プログラムが大きくなるとぐちゃぐちゃになる体験をして，それからオブジェクト指向のすばらしさに触れるべきだと思う．

話は脱線したが，そういう多様なプログラミング言語があるなかで，何を教えるのがよいのか，何は教えたくないのかをエイヤと決めるのがデザインである．

＊変数，レジスター，状態
値が格納される場所である．普通は数値が格納されるけれど，数値以外に文字やもっと複雑なデータを格納することもできる．変数は数学では中１で習ったと思うけど，結構難しい概念だと思う．ほとんどの言語に変数があるので，これがコンピュータの基本だと思っている人もいるかもしれないが，実は必須ではない．変数の無い言語もけっこうある．

プログラミンにも変数は無いようだ．プログラミンとビスケットに共通しているのは，画面に絵を配置して，状態を表現しているということである．状態の違いは絵の配置で表現されるので，人間が見ただけで今の状態がわかる．

Scot Kimが提唱したVisibilityという考え方がある．コンピュータと人間のインタラクションをわかりやすくするために，コンピュータの内部状態をすべて人間が見える形で表現して，その表現上で計算をすべきである，というもの．僕はその影響を受けたシステムやプログラミング言語をいくつか作ってきた．ビスケットもその流れである．プログラミンも一部そうであるが，旗という大域的な状態が一つあって，それがオブジェクト間の通信にもなっていたりするので，厳密なVisibilityではない．人間からは今どの旗なのか見えない．

Visibilityに従ったシステムでは人間に隠された状態（つまり変数）はなくて，メモリーは画面の絵の配置のみ，ということになる．

＊繰り返し，制御構造
これもまったく必須ではない．BASICなどの影響で，繰り返しや制御構造を教えることが，プログラミングの基礎だと思われているかもしれないが，それがない言語も沢山ある．フローチャートに毒された考え方で，僕は教えたくない．このシーケンスを教えてしまうと，同時に動くものが表現しにくくなる．Visibility的に言うと，いまどこを実行しているかという印（プログラムカウンタ）を想像して追っかけてゆく，ということをやらなければならない．複数動く，その印が複数いろんなところにあるので，余計わかりにくくなる．プログラミングやデバッグにはそういう見えないものを追っかけてゆくセンスが必要であるけど，それは入門用には見せたくない．

じゃあ後はいったい何が残るのか．というと，
プログラムとは微少変化の記述の集まりである，
ということになるか．微少変化とは，単純な機能と言い換えてもよい．

そもそも，コンピュータの基本である機械語の命令の一つ一つは，短い時間でレジスターやメモリーの値を変化させる，ということしかできない．微少変化である．その変化を並べて順に実行させることで複雑な計算になる．逆に言うと，プログラミングというのは，やって欲しいことを，微少変化に分解して，記述する，ということである．その分解こそがプログラミングに必要なセンスであり，その上で組み合わせによってどんどん複雑な動きが作れるという体験をさせたいのである．

情報機器を使いこなすセンスというのも，言ってみれば，やりたいことを限られた機能に分解して実行できるかどうか，なのかもしれない．その最も基本的な能力を特訓することがプログラミングなのかもしれない．

逆にこれだけはやりたくないこと．それは，機能をなんでも探してしまうことである．プリミティブの組み合わせでできた複合的な機能なのに，組み合わせて作ろうとせずに，単体でその機能を探してしまう．組み合わせのすごさを知って欲しいのに，逆効果である．

まとめると，プリミティブの数は極力少なく，組み合わせ能力は非常に高く，ということであろう．このあたり，実用をある程度犠牲にしてもよい，教育用言語だからでもある．