自動車は人間の足の拡張，ラジオは耳の拡張，テレビやカメラは目の拡張と言われています．同じような意味でコンピュータは脳の拡張であると言ってもよいでしょう．たとえば，電子辞書やWikipediaその他インターネット検索というのは脳の記憶の能力をはるかに越えて補ってくれています．それ自体はとてもすごいことですが，元々あった本や百科事典をコンピュータに載せただけとも言えますから，紙や印刷技術の発明のインパクトの強さにかすんでしまいます．
同様に，コンピュータの日本語は計算機と言いますが，高速で計算する機械の視点でみても，そろばんや手回し計算機という発明が既にあったわけですから，それが高速で正確になったというすごさ以上のものでもありません．
本当の意味で「コンピュータは脳の拡張」と言ってよいのは，コンピュータシミュレーションのことではないでしょうか．コンピュータシミュレーションというのは，実際に実験をやるかわりにコンピュータの中で計算で実験をしてみようというものです．条件を変えて何度でも実験できますから，その効果は絶大です．そのときどうやって計算する方法をコンピュータに教えるかというと，それがまさにプログラムなわけです．
ビスケットでも，単純なシミュレーションであれば実に簡単にプログラムできます．たとえば，風邪の感染のシミュレーションはたった4つのメガネだけで，感染の広がり方や治り方を色々な条件を変えて試すことができます．このシミュレーションは実際の病気の予測などにはまったく役には立ちませんが，感染という計算が持っている性質を直感的に理解するには非常に強力です．
感染の次にやるのが，ジャンケンのシミュレーションです．3つの絵が3すくみのルールによってお互いにバランスをとるように作られています．ところが，このシミュレーションは「バランスを保ち続ける」という大方の予想に反して，どれか一つの絵に収束してしまいます．このジャンケンのシミュレーションを色々な大人に見せて予想をしてもらったところ，正しく予想できた人は人工知能研究者だけでした．僕も間違えました．しかし，この結果を元にして，もう一度3すくみのルールを考えてみると，しごく当たり前の結果であることがわかります．3つの種があるうちはバランスがよいけれども，もし1つの種が滅んでしまって，世の中には2つの種だけになってしまうと，勝ち負けは一方的になり，一方は滅んでしまいます．たとえば，パーが頑張ってグーを滅ぼしてしまうと，チョキとパーだけになるので，パーも滅んでしまいます．最初に勝ってしまった種が次に滅んでしまうというのは皮肉なことですね．
人間の先入観というのはまったく当てにならないものです．ところがこうやってシミュレーションで結果を見せられると，考えを変えざるを得ません．人間は理解を切り替えられるくらいな柔軟性も持っているんですね．
我々の生活において先入観で失敗することは多々あります．たった数円安い買い物のために交通費と時間を無駄にしてしまう話．宝くじの共同購入に騙される人．住宅ローンや生命保険の計算も直感的ではないので，判断を間違えやすいですね．これらはシミュレーションをやってより懸命な判断ができるようになりましょう．何度もシミュレーションをすることで，その領域への直感も鍛えられ，先入観があてにできるようになるでしょう．
コンピュータによるシミュレーションのもう一つの良さは，難しい数学を使わなくてよいということです．これまで数学が発展したのはコンピュータが無かったからです．年利2パーセントのローンを10年借りると，利息はいくらになるかといった計算は，指数関数で計算できます．一方で，コンピュータシミュレーションでこの計算をすると，かけ算と足し算を沢山繰り返す，ということでもできます．力学の運動だって，コンピュータを使わなければ微分方程式を解かなければなりませんが，コンピュータシミュレーションでは足し算とかけ算を繰り返すだけです．この意味は，プログラムは実はすごく簡単だということです．
プログラムを自分で書くということも重要です．自分で書くから，意外な結果にも納得できるのです．観光バスに乗って観光スポットに勝手に連れて行ってくれることよりも，レンタカーを借りて自分で運転して観光をした方が，自動車は人間の足の拡張っぽいですよね．同じように，自分でプログラムを書いて，その動きに納得して，そして意外な結果を受け入れる，これが「コンピュータは人間の脳の拡張」なのです．
同様に，コンピュータの日本語は計算機と言いますが，高速で計算する機械の視点でみても，そろばんや手回し計算機という発明が既にあったわけですから，それが高速で正確になったというすごさ以上のものでもありません．
本当の意味で「コンピュータは脳の拡張」と言ってよいのは，コンピュータシミュレーションのことではないでしょうか．コンピュータシミュレーションというのは，実際に実験をやるかわりにコンピュータの中で計算で実験をしてみようというものです．条件を変えて何度でも実験できますから，その効果は絶大です．そのときどうやって計算する方法をコンピュータに教えるかというと，それがまさにプログラムなわけです．
ビスケットでも，単純なシミュレーションであれば実に簡単にプログラムできます．たとえば，風邪の感染のシミュレーションはたった4つのメガネだけで，感染の広がり方や治り方を色々な条件を変えて試すことができます．このシミュレーションは実際の病気の予測などにはまったく役には立ちませんが，感染という計算が持っている性質を直感的に理解するには非常に強力です．
感染の次にやるのが，ジャンケンのシミュレーションです．3つの絵が3すくみのルールによってお互いにバランスをとるように作られています．ところが，このシミュレーションは「バランスを保ち続ける」という大方の予想に反して，どれか一つの絵に収束してしまいます．このジャンケンのシミュレーションを色々な大人に見せて予想をしてもらったところ，正しく予想できた人は人工知能研究者だけでした．僕も間違えました．しかし，この結果を元にして，もう一度3すくみのルールを考えてみると，しごく当たり前の結果であることがわかります．3つの種があるうちはバランスがよいけれども，もし1つの種が滅んでしまって，世の中には2つの種だけになってしまうと，勝ち負けは一方的になり，一方は滅んでしまいます．たとえば，パーが頑張ってグーを滅ぼしてしまうと，チョキとパーだけになるので，パーも滅んでしまいます．最初に勝ってしまった種が次に滅んでしまうというのは皮肉なことですね．
人間の先入観というのはまったく当てにならないものです．ところがこうやってシミュレーションで結果を見せられると，考えを変えざるを得ません．人間は理解を切り替えられるくらいな柔軟性も持っているんですね．
我々の生活において先入観で失敗することは多々あります．たった数円安い買い物のために交通費と時間を無駄にしてしまう話．宝くじの共同購入に騙される人．住宅ローンや生命保険の計算も直感的ではないので，判断を間違えやすいですね．これらはシミュレーションをやってより懸命な判断ができるようになりましょう．何度もシミュレーションをすることで，その領域への直感も鍛えられ，先入観があてにできるようになるでしょう．
コンピュータによるシミュレーションのもう一つの良さは，難しい数学を使わなくてよいということです．これまで数学が発展したのはコンピュータが無かったからです．年利2パーセントのローンを10年借りると，利息はいくらになるかといった計算は，指数関数で計算できます．一方で，コンピュータシミュレーションでこの計算をすると，かけ算と足し算を沢山繰り返す，ということでもできます．力学の運動だって，コンピュータを使わなければ微分方程式を解かなければなりませんが，コンピュータシミュレーションでは足し算とかけ算を繰り返すだけです．この意味は，プログラムは実はすごく簡単だということです．
プログラムを自分で書くということも重要です．自分で書くから，意外な結果にも納得できるのです．観光バスに乗って観光スポットに勝手に連れて行ってくれることよりも，レンタカーを借りて自分で運転して観光をした方が，自動車は人間の足の拡張っぽいですよね．同じように，自分でプログラムを書いて，その動きに納得して，そして意外な結果を受け入れる，これが「コンピュータは人間の脳の拡張」なのです．
個人に対するプログラミング教育のモチベーションは，他人よりも人生において優位にたちたい・幸せになりたいということでしょうから，それはそれでどんな理由でもよいと思います．大事なことです．
それに対して，義務教育でのプログラミング教育の意味はまったく違ってます．義務教育のきちんとした定義はあるんでしょうが，僕が一番大事だと思っているのは，社会全体での共通理解を底上げする，ということです．ついでに，僕自身ずっと言っているのは，これは子供の教育だけの話ではないですよ．大人もちゃんと理解しておいてほしいことですよ，ということです．社会全体での共通理解の底上げが大事です．
たとえば，先日起きた人工衛星の「ひとみ」の事故の話です．
http://jbpress.ismedia.jp/articles/-/46999
この記事では，もはやものづくりそのものの考え方が古くなっているということが書かれています．この人工衛星の製作にあたった方々はみなさん理工系でコンピュータを普段から活用されていらっしゃるのでしょう．そんな方々でも，コンピュータのさらに専門的なことに関しては認識を誤ってしまうのです．彼ら自身が新しいコンピュータ（たとえば，100万台で一部が壊れても動くといった）に対する理解を深めなければいろいろと立ち行かなくなってきているのです．これは拡張すると，社会全体が古いコンピュータへの認識のままだと，日本の将来は本当にやばい．子供達の未来を考えるなんてこと自体が無意味になってしまうかもしれません．
いま，プログラミング教育というと，コンピュータを自分で動かす経験という点に重点を置いています．導入はそれでもいいですが，最終的に社会全体にどんな共通認識を持ってもらいたいか．これはいろんな意見があると思います．僕もその一部しか思いつきませんが，書いてみます．
１）分量が半端ないこと．
コンピュータが高速で，大容量ということは知識としては知っていますが，それが本当にどれくらいすごい高速で，どれくらい大容量かということを数字じゃなくて体で知ってほしい．数字だとゼロが１０個増えただけで実感できません．僕は昔，自分のパソコンのメモリーが16kBだったのを32kBに拡張したとき，メモリーを順番に画面に流して見ててすごい時間がかかったのを今でも覚えています．たった32kBですよ．メモリーってすごい広いんだと思ってました．これが年々増えていて，いまはその時の１００万倍ですよね．物としてあればある種の恐怖を感じられたりしますが，コンピュータは見えないので何も感じられらないのです．
２）脆弱なこと．
人間だと，同じ作業を繰り返された時途中で気づいて，なにか反応します．手順をまとめたり入れ替えたり，その作業をより効率よくする方法を考えたりします．人間はそういうメタ的な視点を持っているので，計算能力や記憶能力が貧弱でもすごいことができるのです．コンピュータは真逆で，言われた通りどんなことでも疑問を感じずに黙々とやります．それが利点でもありますが，アクシデントに全く対応できません．もちろんソフトウェアですからあらかじめ想定できるアクシデントがわかっていれば，そう動くように作れば動くのですが．未知のアクシデントには対応できません．そして本当に頭の悪い動きを繰り返して自分が壊れちゃうのです．
この１）と２）を合わせて「コンピュータはバカだけどすごい」ということになります．
こんなことは，専門家だけがやればよいではないし，知識として知っていれば良いのでもダメです．たとえば，横幅５０cmの板の上をまっすぐ３m歩くというのを考えましょう．こんなの楽勝ですよね．ところが，この板が地上50mにあったらどうでしょうか．いまは無風なので，地面に板を置いたのと同じくらい安全に渡れます．でもこの板を渡れと言われて渡れますか？10万円あげるからと言われたらやる人がいるかもしれませんね．なぜ，この板の上を渡るのは怖いのでしょうか？それは高さに対する直感があって，落ちたら死ぬというのが，感覚としてしみ込んでいるからでしょう．遺伝子なのか経験なのか．これからのコンピュータとうまく付き合って行くのは，この「落ちたら死ぬ」的な感覚をコンピュータに対しても持たなければならないのだと思います．
３）情報の複製の怖さ．
ある情報を二つに複製するプログラムがあったとします．一度動かすと情報が二つになります．これをたくさんのコンピュータで動かした時，その情報は一気に広がります．ビスケットの「感染」のデモで説明していることですね．最初はゆっくり増えますが，途中からすごい勢いで増えてゆきます．このような指数関数的な現象は自然界にもあるのですが，人間にはその直感はありません．これがコンピュータウィルスの拡散の速さでもあるし，バズることの広がりの原理でもあります．
４）コンピュータの上にコンピュータを作れる
プログラミング言語を新しく作るというのは，コンピュータの上に新しい（ある種の理想の）コンピュータを作るということでもあります．たとえば，機械語とかC言語ではポインタが大活躍します．メモリーには数字による番地が付けられていて，メモリーに格納されているいろんな大きさのデータをその先頭の番地で代表して参照するという仕組みです．この素晴らしい仕組みのおかげで複雑なデータを扱うことができるようになりました．その番地によるメモリーとポインタというのはコンピュータハードウェアの動作そのものですから動く効率はすごく高いのですが，一方でプログラムの上でのミスもやまのようにありました．それに対して，LISPからスタートした言語ではメモリーとポインタをプログラムから見えなくして，ポインタ操作の間違えの元が起きないようにしたわけですね．こんな感じで，よりよい「計算する機械」を作るためにプログラミング言語はどんどん進化してます．それは，理想のコンピュータとはなにか，ということを追求する行為でもあります．僕はこんな細かい話まで，社会全体での共通理解を求めてはいませんが，その大元の考えである「コンピュータの上にコンピュータを作れる」ということだけは知ってほしいと思っています．シリコンチップの発明がコンピュータをここまで凄くしてきた片方の理由だとすると，このコンピュータの上にコンピュータを作れる，別の言い方をするとプログラミング言語の階層，という発明が，膨大で複雑なプログラミングを可能にした理由です．たとえば「核分裂」というのをどれくらいの人が知っているかわかりませんが，それと同じくらい重要な考え方だと思います．
プログラミング教育の先というのは，こういったコンピュータを中心とした社会の原理を知識としてではなく，体験として，体で怖さと凄さを感じられるようにすべきということです．
それに対して，義務教育でのプログラミング教育の意味はまったく違ってます．義務教育のきちんとした定義はあるんでしょうが，僕が一番大事だと思っているのは，社会全体での共通理解を底上げする，ということです．ついでに，僕自身ずっと言っているのは，これは子供の教育だけの話ではないですよ．大人もちゃんと理解しておいてほしいことですよ，ということです．社会全体での共通理解の底上げが大事です．
たとえば，先日起きた人工衛星の「ひとみ」の事故の話です．
http://jbpress.ismedia.jp/articles/-/46999
この記事では，もはやものづくりそのものの考え方が古くなっているということが書かれています．この人工衛星の製作にあたった方々はみなさん理工系でコンピュータを普段から活用されていらっしゃるのでしょう．そんな方々でも，コンピュータのさらに専門的なことに関しては認識を誤ってしまうのです．彼ら自身が新しいコンピュータ（たとえば，100万台で一部が壊れても動くといった）に対する理解を深めなければいろいろと立ち行かなくなってきているのです．これは拡張すると，社会全体が古いコンピュータへの認識のままだと，日本の将来は本当にやばい．子供達の未来を考えるなんてこと自体が無意味になってしまうかもしれません．
いま，プログラミング教育というと，コンピュータを自分で動かす経験という点に重点を置いています．導入はそれでもいいですが，最終的に社会全体にどんな共通認識を持ってもらいたいか．これはいろんな意見があると思います．僕もその一部しか思いつきませんが，書いてみます．
１）分量が半端ないこと．
コンピュータが高速で，大容量ということは知識としては知っていますが，それが本当にどれくらいすごい高速で，どれくらい大容量かということを数字じゃなくて体で知ってほしい．数字だとゼロが１０個増えただけで実感できません．僕は昔，自分のパソコンのメモリーが16kBだったのを32kBに拡張したとき，メモリーを順番に画面に流して見ててすごい時間がかかったのを今でも覚えています．たった32kBですよ．メモリーってすごい広いんだと思ってました．これが年々増えていて，いまはその時の１００万倍ですよね．物としてあればある種の恐怖を感じられたりしますが，コンピュータは見えないので何も感じられらないのです．
２）脆弱なこと．
人間だと，同じ作業を繰り返された時途中で気づいて，なにか反応します．手順をまとめたり入れ替えたり，その作業をより効率よくする方法を考えたりします．人間はそういうメタ的な視点を持っているので，計算能力や記憶能力が貧弱でもすごいことができるのです．コンピュータは真逆で，言われた通りどんなことでも疑問を感じずに黙々とやります．それが利点でもありますが，アクシデントに全く対応できません．もちろんソフトウェアですからあらかじめ想定できるアクシデントがわかっていれば，そう動くように作れば動くのですが．未知のアクシデントには対応できません．そして本当に頭の悪い動きを繰り返して自分が壊れちゃうのです．
この１）と２）を合わせて「コンピュータはバカだけどすごい」ということになります．
こんなことは，専門家だけがやればよいではないし，知識として知っていれば良いのでもダメです．たとえば，横幅５０cmの板の上をまっすぐ３m歩くというのを考えましょう．こんなの楽勝ですよね．ところが，この板が地上50mにあったらどうでしょうか．いまは無風なので，地面に板を置いたのと同じくらい安全に渡れます．でもこの板を渡れと言われて渡れますか？10万円あげるからと言われたらやる人がいるかもしれませんね．なぜ，この板の上を渡るのは怖いのでしょうか？それは高さに対する直感があって，落ちたら死ぬというのが，感覚としてしみ込んでいるからでしょう．遺伝子なのか経験なのか．これからのコンピュータとうまく付き合って行くのは，この「落ちたら死ぬ」的な感覚をコンピュータに対しても持たなければならないのだと思います．
３）情報の複製の怖さ．
ある情報を二つに複製するプログラムがあったとします．一度動かすと情報が二つになります．これをたくさんのコンピュータで動かした時，その情報は一気に広がります．ビスケットの「感染」のデモで説明していることですね．最初はゆっくり増えますが，途中からすごい勢いで増えてゆきます．このような指数関数的な現象は自然界にもあるのですが，人間にはその直感はありません．これがコンピュータウィルスの拡散の速さでもあるし，バズることの広がりの原理でもあります．
４）コンピュータの上にコンピュータを作れる
プログラミング言語を新しく作るというのは，コンピュータの上に新しい（ある種の理想の）コンピュータを作るということでもあります．たとえば，機械語とかC言語ではポインタが大活躍します．メモリーには数字による番地が付けられていて，メモリーに格納されているいろんな大きさのデータをその先頭の番地で代表して参照するという仕組みです．この素晴らしい仕組みのおかげで複雑なデータを扱うことができるようになりました．その番地によるメモリーとポインタというのはコンピュータハードウェアの動作そのものですから動く効率はすごく高いのですが，一方でプログラムの上でのミスもやまのようにありました．それに対して，LISPからスタートした言語ではメモリーとポインタをプログラムから見えなくして，ポインタ操作の間違えの元が起きないようにしたわけですね．こんな感じで，よりよい「計算する機械」を作るためにプログラミング言語はどんどん進化してます．それは，理想のコンピュータとはなにか，ということを追求する行為でもあります．僕はこんな細かい話まで，社会全体での共通理解を求めてはいませんが，その大元の考えである「コンピュータの上にコンピュータを作れる」ということだけは知ってほしいと思っています．シリコンチップの発明がコンピュータをここまで凄くしてきた片方の理由だとすると，このコンピュータの上にコンピュータを作れる，別の言い方をするとプログラミング言語の階層，という発明が，膨大で複雑なプログラミングを可能にした理由です．たとえば「核分裂」というのをどれくらいの人が知っているかわかりませんが，それと同じくらい重要な考え方だと思います．
プログラミング教育の先というのは，こういったコンピュータを中心とした社会の原理を知識としてではなく，体験として，体で怖さと凄さを感じられるようにすべきということです．
オブジェクト指向プログラミングを神格化するような記事が流れてきたので，僕が知っている問題点について書いてみたいと思います．僕がまだ学生だったころは，オブジェクト指向の評価もまだそれほど定まっていなくて，オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが，ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか．僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて，ここまで使われてる理由は，現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています．オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです．
以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されていなければあまり意味がないので，問題点として指摘させていただきました．論文じゃないので，軽い気持ちで読んでいただければと思います．
１）メッセージの流れが見えない
オブジェクト指向においてメッセージのやり取りほど重要なものはないのに，そのやり取りの様子がプログラム上で表現できていません．メッセージの送信は，繰り返しや条件分岐などの制御文によって作られた関数呼び出しの副作用として間接的に表現されます．一方受信の方はもっと見えなくて，例えばその時のオブジェクトの内部状態によって受信できるメッセージの種類が変わるはずなのに，そういった制御や抽象化ができません．最初に初期化のメッセージを受信した後，処理のメッセージをいくつか受信して，終了のメッセージを受信する，といったプロトコル的な記述もできません．
２）オブジェクトのつながり具合が手続きでしか表現できない
次に大事なのがオブジェクトのつながり具合です．たとえばＭＶＣという３つのオブジェクトの集まりで一つの部品を作るような場合があります．プログラムは，Ｍ，Ｖ，Ｃそれぞれが同じ相手とつながっていることが前提でつくられます（たとえば，Ｍが知っているＶと，Ｃが知っているＶは同じものである，といったことです）．しかし，このつながり具合が正しいかどうかを保証する方法がありません．木構造をオブジェクトで作るとき，自分の子供は全員自分を親として見ているか．こういったつながりを手続きで頑張って作るので，間違えが入る可能性があります．間違えをできるだけ入らないようにするために，オブジェクトの外側からは内側を触れないようにカプセル化しますが，そういう制約はオブジェクト指向自身が自由度が高すぎる，逆に言うと何も保証しない貧弱であるから必要なのです．
３）ユーザレベルでの部品化再利用に全然なっていない
僕が素晴らしいプログラムの部品化再利用の例だと思っているのがＵＮＩＸのパイプラインです．これが通じる人はどれくらいいるのかな．コマンドの出力が次のコマンドの入力になるようにパイプでつないで表現するものです．パイプが人間にとってすごく使いやすい理由は，そこを流れるデータが人間に見える形式だったからです．見えるから次のコマンドにどんな処理をさせればよいか考えやすくなります．何か動きがおかしければ，途中に流れている文字列を見ればわかります．典型的な入力データをエディタで作ってもよいですし，途中の処理が特殊すぎてわざわざプログラムで処理しなくてもよいような場合，人間がエディタ上で手作業で編集してもよいわけです．テキストデータという共通のデータ形式の上で人間とコンピュータが協調して問題を解いていたという感覚がありました．
こんな素晴らしい仕掛けが使われた時代はそんなにコンピュータが速かったわけではありません．それでもバイナリーではなくテキストの10進表記で数を表すという，実に無駄な方法が人間の利便性を優先して使われていたということに敬意を表します．
1次元にコマンドを並べて処理を順に行うような単純な処理だけですむ時代は終わりました．パイプに代わるもっと複雑なコマンドの組み合わせ方を発明しなければなりません．パイプは一方向の情報の流れでしたが，情報は双方向の流れを許すべきです．
僕はUNIXにX-Windowというウインドウシステムが入ってきたとき，次世代のパイプが発明されるのかとワクワクしてましたが，結局まだ誰もそれを発明できていません（僕が知らないだけであるのかもしれません）．部品化はオブジェクト指向にとってかわられ，プログラムの中は閉ざされ，人間は遠ざけられました．
北大の田中先生のIntelligentPadにその可能性を感じましたが，結局はオブジェクトの合成という非常に難しい問題がその前に立ちはだかりました．
そうこうしているうちに，WWWの大爆発が起こって全部吹っ飛びました．
４）知識表現が手続き側に偏っている
プログラミングという処理っぽい呼び方ではなく，もう少し広い意味を込めて知識表現と呼ぶことにします．プログラムはもちろん知識表現の一部です．たとえば，EXCELの表も知識表現ですし，構造をもったデータは知識表現です．オブジェクト指向の何が悲しいかというと，構造をもったデータを直接作り出すことはできないということです．手続きを使って変換するしかありません．たとえばLISPではコンピュータが処理するデータ構造を人間が直接入力することができます．そういう人間とコンピュータの仲の良い関係がオブジェクト指向では消えてしまってます．
５）オブジェクト指向は人間をだましている
オブジェクト指向で作られた典型的なグラフィカルなプログラムを考えましょう．オブジェクトには内部状態があります．その内部状態を更新させることが唯一の計算です．その内部状態を人間にみせるためのプログラムと，人間が見ているもの（画面）に対するマウスやタッチの操作を解釈して内部状態を更新するためのプログラムがあります．これは上の例ででてきたＭＶＣということなんですが．だましているといったのは，Ｍは内部に存在しますけれども，Ｖがどう作られたかで見え方が違ってきます．同じ見え方でもＭの中身が違っていたり，同じ中身でも見え方が違っていたり，ということが平気で起きます．真逆はLISPです．LISPはコンピュータが見ているメモリーの構造と人間が見ているＳ式とが1対1の関係になるので，つまり人間とコンピュータが同じものを見ているという安心感があります．オブジェクト指向はコンピュータと人間が同じものを見ている感がしません．コンピュータがすごく頑張って人間にすごいものを見せている（もしくはだましている）という感じです．
こうなっちゃった理由は，コンピュータに課せられた役割が，これまでプログラムを作る人と使う人とが一体となっていた時代から，作る人と使う人とが明確に分かれた時代に変わってきたということなのかもしれません．UNIXのテキストは人間にわかりやすいといっても，ビットマップのテキストよりは見栄えがしないわけで，作る人と使う人が一緒なら我慢もできましょうが．逆に，使うだけの人にとっては，上手にだましてもらったほうがいいわけですし，よりかっこよくだました方がお金が儲かるという事情もあったのでしょう．
６）オブジェクト指向は貧乏
オブジェクト指向が活躍した時代はメモリーが非常に少なくどう節約するかが重要でした．なのでよく使われていた例は，列というものがあって，その列をどのように扱いたいかによって実行の効率が変わるので，使用法に適した実装を選んで効率をよくすることができる．しかしアルゴリズムはそのデータ構造の影響を受けないように計算方法だけ書けばよい．そんなことが言われていた時代でした．つまり，一度書いたアルゴリズムはいろんなデータ構造に対して，効率の良い実行ができるというものです．
しかし今は，メモリーもふんだんにあって実行速度の差もそれほど重要ではなくなってきたので，そんな実装方法に依存しないアルゴリズムという貧乏なことを言わなくてもよくなりました．万能なデータ構造を一つ決めて，アルゴリズムは全部その構造に対して作ってしまえばよいのです．LISPみたいなものです．ただし，LISPの時代から何が変わったかというと，扱うデータが木構造のように単純ではなく，グラフ構造になったこと．一つのスレッドではなくマルチスレッドでかつ分散になったこと．オブジェクトが複雑に参照しあっているようなグラフ構造をLISPのS式のようなシンプルで汎用性のある記法で記述しなければならないということです．なのでS式的な今風の拡張が求められています．
７）関係を記述できない
メッセージは単項演算なので，複数のオブジェクト間の関係を表現するのが苦手です．ある一つのオブジェクトに，起きろ，歩け，といった命令をするだけなら簡単です．それに対して，二つのオブジェクトが関係する命令，たとえば二人に対して，ぶつかれ，ならべ，という命令が苦手です．通常のオブジェクト指向では，関係するオブジェクトのどれか一つを特別に選んで，それに対するメッセージとして表現します．他のオブジェクトはそのメッセージの引数として渡されます．２）で言ったようなつながり具合を表現したければ，メッセージの受信側に選ばれたオブジェクトが責任をもって引数で渡されたほかのオブジェクトどうしをつながなければなりません．
Prologは関係を表現できます．というか関係しか表現できません．たとえば，Ａ＋Ｂ＝Ｃという式があったとします．普通の言語ではＡ＋Ｂの計算をして，Ｃのメモリーにその値を書き込むという解釈をします．ＡとＢの値が決まっていてＣは未定義だったり，Ｃの新しい値としてこういう計算をしました．それに対して，ここで表現した式は計算の方法ではなくあくまでも式というか変数同士の数学的な関係を表していると解釈できます，たとえばこの式があったとき，Prologでは「Ｂが２０，Ｃが５０のときＡは何でしょう」という聞き方にもこたえることができるのです．
計算の方向まであとで決められるくらいの自由度はともかく，オブジェクト指向がメッセージのやりとりにこだわっていると，関係を表現するのがすごく大変ということはわかっていただけたでしょうか．
オブジェクト指向の問題点のうち，ごく一部はビスケットの設計方針に影響を与えています．たとえば，コンピュータが裏で人間のために頑張るというのではなく，コンピュータと人間が同じものを見ている感というのを大事にしている部分などですが．人間とコンピュータの関係がどうあってほしいかといった思いも込められています．
以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されていなければあまり意味がないので，問題点として指摘させていただきました．論文じゃないので，軽い気持ちで読んでいただければと思います．
１）メッセージの流れが見えない
オブジェクト指向においてメッセージのやり取りほど重要なものはないのに，そのやり取りの様子がプログラム上で表現できていません．メッセージの送信は，繰り返しや条件分岐などの制御文によって作られた関数呼び出しの副作用として間接的に表現されます．一方受信の方はもっと見えなくて，例えばその時のオブジェクトの内部状態によって受信できるメッセージの種類が変わるはずなのに，そういった制御や抽象化ができません．最初に初期化のメッセージを受信した後，処理のメッセージをいくつか受信して，終了のメッセージを受信する，といったプロトコル的な記述もできません．
２）オブジェクトのつながり具合が手続きでしか表現できない
次に大事なのがオブジェクトのつながり具合です．たとえばＭＶＣという３つのオブジェクトの集まりで一つの部品を作るような場合があります．プログラムは，Ｍ，Ｖ，Ｃそれぞれが同じ相手とつながっていることが前提でつくられます（たとえば，Ｍが知っているＶと，Ｃが知っているＶは同じものである，といったことです）．しかし，このつながり具合が正しいかどうかを保証する方法がありません．木構造をオブジェクトで作るとき，自分の子供は全員自分を親として見ているか．こういったつながりを手続きで頑張って作るので，間違えが入る可能性があります．間違えをできるだけ入らないようにするために，オブジェクトの外側からは内側を触れないようにカプセル化しますが，そういう制約はオブジェクト指向自身が自由度が高すぎる，逆に言うと何も保証しない貧弱であるから必要なのです．
３）ユーザレベルでの部品化再利用に全然なっていない
僕が素晴らしいプログラムの部品化再利用の例だと思っているのがＵＮＩＸのパイプラインです．これが通じる人はどれくらいいるのかな．コマンドの出力が次のコマンドの入力になるようにパイプでつないで表現するものです．パイプが人間にとってすごく使いやすい理由は，そこを流れるデータが人間に見える形式だったからです．見えるから次のコマンドにどんな処理をさせればよいか考えやすくなります．何か動きがおかしければ，途中に流れている文字列を見ればわかります．典型的な入力データをエディタで作ってもよいですし，途中の処理が特殊すぎてわざわざプログラムで処理しなくてもよいような場合，人間がエディタ上で手作業で編集してもよいわけです．テキストデータという共通のデータ形式の上で人間とコンピュータが協調して問題を解いていたという感覚がありました．
こんな素晴らしい仕掛けが使われた時代はそんなにコンピュータが速かったわけではありません．それでもバイナリーではなくテキストの10進表記で数を表すという，実に無駄な方法が人間の利便性を優先して使われていたということに敬意を表します．
1次元にコマンドを並べて処理を順に行うような単純な処理だけですむ時代は終わりました．パイプに代わるもっと複雑なコマンドの組み合わせ方を発明しなければなりません．パイプは一方向の情報の流れでしたが，情報は双方向の流れを許すべきです．
僕はUNIXにX-Windowというウインドウシステムが入ってきたとき，次世代のパイプが発明されるのかとワクワクしてましたが，結局まだ誰もそれを発明できていません（僕が知らないだけであるのかもしれません）．部品化はオブジェクト指向にとってかわられ，プログラムの中は閉ざされ，人間は遠ざけられました．
北大の田中先生のIntelligentPadにその可能性を感じましたが，結局はオブジェクトの合成という非常に難しい問題がその前に立ちはだかりました．
そうこうしているうちに，WWWの大爆発が起こって全部吹っ飛びました．
４）知識表現が手続き側に偏っている
プログラミングという処理っぽい呼び方ではなく，もう少し広い意味を込めて知識表現と呼ぶことにします．プログラムはもちろん知識表現の一部です．たとえば，EXCELの表も知識表現ですし，構造をもったデータは知識表現です．オブジェクト指向の何が悲しいかというと，構造をもったデータを直接作り出すことはできないということです．手続きを使って変換するしかありません．たとえばLISPではコンピュータが処理するデータ構造を人間が直接入力することができます．そういう人間とコンピュータの仲の良い関係がオブジェクト指向では消えてしまってます．
５）オブジェクト指向は人間をだましている
オブジェクト指向で作られた典型的なグラフィカルなプログラムを考えましょう．オブジェクトには内部状態があります．その内部状態を更新させることが唯一の計算です．その内部状態を人間にみせるためのプログラムと，人間が見ているもの（画面）に対するマウスやタッチの操作を解釈して内部状態を更新するためのプログラムがあります．これは上の例ででてきたＭＶＣということなんですが．だましているといったのは，Ｍは内部に存在しますけれども，Ｖがどう作られたかで見え方が違ってきます．同じ見え方でもＭの中身が違っていたり，同じ中身でも見え方が違っていたり，ということが平気で起きます．真逆はLISPです．LISPはコンピュータが見ているメモリーの構造と人間が見ているＳ式とが1対1の関係になるので，つまり人間とコンピュータが同じものを見ているという安心感があります．オブジェクト指向はコンピュータと人間が同じものを見ている感がしません．コンピュータがすごく頑張って人間にすごいものを見せている（もしくはだましている）という感じです．
こうなっちゃった理由は，コンピュータに課せられた役割が，これまでプログラムを作る人と使う人とが一体となっていた時代から，作る人と使う人とが明確に分かれた時代に変わってきたということなのかもしれません．UNIXのテキストは人間にわかりやすいといっても，ビットマップのテキストよりは見栄えがしないわけで，作る人と使う人が一緒なら我慢もできましょうが．逆に，使うだけの人にとっては，上手にだましてもらったほうがいいわけですし，よりかっこよくだました方がお金が儲かるという事情もあったのでしょう．
６）オブジェクト指向は貧乏
オブジェクト指向が活躍した時代はメモリーが非常に少なくどう節約するかが重要でした．なのでよく使われていた例は，列というものがあって，その列をどのように扱いたいかによって実行の効率が変わるので，使用法に適した実装を選んで効率をよくすることができる．しかしアルゴリズムはそのデータ構造の影響を受けないように計算方法だけ書けばよい．そんなことが言われていた時代でした．つまり，一度書いたアルゴリズムはいろんなデータ構造に対して，効率の良い実行ができるというものです．
しかし今は，メモリーもふんだんにあって実行速度の差もそれほど重要ではなくなってきたので，そんな実装方法に依存しないアルゴリズムという貧乏なことを言わなくてもよくなりました．万能なデータ構造を一つ決めて，アルゴリズムは全部その構造に対して作ってしまえばよいのです．LISPみたいなものです．ただし，LISPの時代から何が変わったかというと，扱うデータが木構造のように単純ではなく，グラフ構造になったこと．一つのスレッドではなくマルチスレッドでかつ分散になったこと．オブジェクトが複雑に参照しあっているようなグラフ構造をLISPのS式のようなシンプルで汎用性のある記法で記述しなければならないということです．なのでS式的な今風の拡張が求められています．
７）関係を記述できない
メッセージは単項演算なので，複数のオブジェクト間の関係を表現するのが苦手です．ある一つのオブジェクトに，起きろ，歩け，といった命令をするだけなら簡単です．それに対して，二つのオブジェクトが関係する命令，たとえば二人に対して，ぶつかれ，ならべ，という命令が苦手です．通常のオブジェクト指向では，関係するオブジェクトのどれか一つを特別に選んで，それに対するメッセージとして表現します．他のオブジェクトはそのメッセージの引数として渡されます．２）で言ったようなつながり具合を表現したければ，メッセージの受信側に選ばれたオブジェクトが責任をもって引数で渡されたほかのオブジェクトどうしをつながなければなりません．
Prologは関係を表現できます．というか関係しか表現できません．たとえば，Ａ＋Ｂ＝Ｃという式があったとします．普通の言語ではＡ＋Ｂの計算をして，Ｃのメモリーにその値を書き込むという解釈をします．ＡとＢの値が決まっていてＣは未定義だったり，Ｃの新しい値としてこういう計算をしました．それに対して，ここで表現した式は計算の方法ではなくあくまでも式というか変数同士の数学的な関係を表していると解釈できます，たとえばこの式があったとき，Prologでは「Ｂが２０，Ｃが５０のときＡは何でしょう」という聞き方にもこたえることができるのです．
計算の方向まであとで決められるくらいの自由度はともかく，オブジェクト指向がメッセージのやりとりにこだわっていると，関係を表現するのがすごく大変ということはわかっていただけたでしょうか．
オブジェクト指向の問題点のうち，ごく一部はビスケットの設計方針に影響を与えています．たとえば，コンピュータが裏で人間のために頑張るというのではなく，コンピュータと人間が同じものを見ている感というのを大事にしている部分などですが．人間とコンピュータの関係がどうあってほしいかといった思いも込められています．
Twitterで住井さんと山口さんがプログラミングの興味深い議論をしてまして．その議論をきちんと追えてはいないんですが，ビスケットについても語られていた部分があったので，ちょっと考えてみました．
もともとは，数学とプログラミングの違いからはじまり，プログラミングの本質はどこにあるのかから，逐次実行，分岐，反復は基本だよね，といった流れのようです．
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
Scratchを始め，ほとんどのプログラミング言語には，明確に逐次実行，分岐，反復が言語の構成要素として現れています．これらを組み合わせることでプログラムを作りますから，当然これらの構成要素を強く意識します．ビスケットとはいろいろと違うのですが，一番大きな違いは「いまどの命令を実行しているのか」という概念がそれらの言語にはあるということです．この「どの命令を実行しているのか」はCPUのレベルではプログラムカウンタという言い方をしてます．命令がメモリーに順番に並んでいて，その順番通り実行すればよいので，基本的には数が１つずつ繰り上がることから，「カウンタ」という呼び名になっています．もっと上の言語になると命令の列をメモリーとして意識しないのでカウンタと呼ぶのは変ですが．なんというんでしょうね．明確な呼び名がすぐに思いつかないのは，その概念が（ブロックのような）プログラムの構成要素としては出てこないからでしょうか．そのプログラムカウンタのようなものが，現在実行しているブロックを指し示していて，指し示すブロックが変わってゆくことが逐次実行，分岐，反復を表現しているわけです．
それに対して，ビスケットにはどの命令を実行しているのかという概念がそもそも存在しません．存在していないので，逐次実行，分岐，反復といった概念も明確に理解することには繋がらないですし．ではどんなことを学んでいるのでしょうか？
ビスケットの教え方を順を追って見てみましょう．この過程で，子供達のコンピュータの理解はどのように変化しているのかを推測してみます．
１）メガネの左右に同じ絵を入れて，その絵を動かす．メガネの中の絵の動き方で方向と速度を調整できる．この時点では自分で絵を動かすツールという理解になるでしょう．同じ絵は同じ動きをする．メガネの中を変えると，同じ絵は一斉に動きを変えます．メガネが壊れると一斉に動きがとまります．瞬時に変化が全員に伝わるすごさと，一斉に壊れるというコンピュータの脆さも伝わります．ときどき，システムのデザインをやっている大人からは，ここまでの理解だけではメガネに丸が左右にあることは無駄で，方向と速度を示すだけの一つの丸でよいのではないかという質問をもらいます．
２）同じ絵を使ったメガネを二つ用意する．たとえば上に進むメガネと下に進むメガネ．これは新しいビスケットに追加された機能で，２つのメガネがランダムに選ばれて実行します．その結果その絵はゆらゆらと動くことになります．普通のプログラム言語ではランダムな実行というのはかなり上位な概念で作られますが，ビスケットではそれが組み込みの機能として入っています．このとき，子供達には，メガネは命令というよりは，その絵が持っている性質を表しているという印象に変わると思います．我々は「おばけは上に行ったり，下に行ったりする」という言い方をしています．命令ではなく，あるべき性質の一つを定義すると感じです．だいぶ宣言型言語らしくなってきました．
これでもメガネのまるは，まだ一つで十分ですね．
３）２つの絵で，パクパクするアニメーションを作る．このとき初めて，メガネの左側の意味がでてきます．メガネはある絵をある絵に変える（位置関係も含めて）という説明をします．いままではたまたまメガネの左右に同じ絵が入っていたから動いて見えているだけでした．絵を変えるということができるとわかると，たとえば絵を１０個書いて，１０個のメガネで順に変化させるといった実験もできるようになります．２コマから１０コマに変わるという理解で，逐次実行が理解できたと思ってもよいかもしれません．途中で同じ絵から始まるメガネを複数つくると，「赤いボールは，青くなったり，黄色くなったりする」といったことにもなります．これは状態遷移図につながります．ある絵で動きが止まってしまうことがありますが，それはその絵から始まるメガネを作っていないからです．これで反復が明確に見えてきます．それから最初にある絵を置いたとしても，そのあとその絵が出てくることがないということがある場合は，その絵が右側（結果）にはいっているようなメガネを作っていないということです．これらを通じて，プログラムが止まらずに動き続けるにはどうしたらよいか，という重要な概念を学ぶことができると思います．
つぎにやっと条件が分岐が入ってきます．
４）メガネの左側に２つの絵をいれます．この絵とこの絵がぶつかったら，という言い方をします．いままでは絵の単独の性質を記述していましたが，二つの絵の衝突を導入することで，その絵の位置関係を使ってある条件を表すことができるわけです．一番単純なのは「尺取り虫がボールにぶつかったらボールをける」というメガネですね．絵の配置だけを変化させています．もう少し複雑になると，「健康な人と風邪をひいた人がぶつかったら，風邪がうつる」というメガネで，２つの絵がぶつかると，片方の絵の種類が変化する，ということが表現できます．これを動かすと絵の数が変化する様子が見れるので，一つの箱庭のシステムとしてものをみることができるようになります．ここから，指数関数的な広がりの理解などに繋げられます．
こうしてみると，ビスケットでは逐次実行，分岐，反復にだけ特化しているというよりは，もっといろいろなシステム全体の動きを総合的に理解して，その中の一つに，逐次実行，分岐，反復が現れている，と考えることができるように思います．実際にはその３つだけが自然界で重要であるとは思えないですよね．たまたま，コンピュータのハードウェアが採用していたというだけであって．
それよりも，ビスケットが重視しているのは，「一つの命令は小さい変化しか起こせない」ということです．逐次実行，分岐，反復も小さい変化を組み合わせて作られてますし，それ以外にも小さい変化で作れるものはたくさんあります．つまり，プログラミングのもっとも基本的な考えは「小さい変化を組み合わせて複雑なことを実現している」ということであって，そこから上位の概念を教えるのがよいだろうと思います．
もともとは，数学とプログラミングの違いからはじまり，プログラミングの本質はどこにあるのかから，逐次実行，分岐，反復は基本だよね，といった流れのようです．
「右に動き続ける」と「「右に少し動く」を繰り返す」の間には認知的にはギャップがあるはずで、Scratchを使うと「「「右に少し動く」を繰り返す」→「右に動き続ける」」が学べるように思えるけれど、Viscuitで学べるかはよく分からない。
— Ryusei Yamaguchi (@mandel59) 2016年5月7日
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
Scratchを始め，ほとんどのプログラミング言語には，明確に逐次実行，分岐，反復が言語の構成要素として現れています．これらを組み合わせることでプログラムを作りますから，当然これらの構成要素を強く意識します．ビスケットとはいろいろと違うのですが，一番大きな違いは「いまどの命令を実行しているのか」という概念がそれらの言語にはあるということです．この「どの命令を実行しているのか」はCPUのレベルではプログラムカウンタという言い方をしてます．命令がメモリーに順番に並んでいて，その順番通り実行すればよいので，基本的には数が１つずつ繰り上がることから，「カウンタ」という呼び名になっています．もっと上の言語になると命令の列をメモリーとして意識しないのでカウンタと呼ぶのは変ですが．なんというんでしょうね．明確な呼び名がすぐに思いつかないのは，その概念が（ブロックのような）プログラムの構成要素としては出てこないからでしょうか．そのプログラムカウンタのようなものが，現在実行しているブロックを指し示していて，指し示すブロックが変わってゆくことが逐次実行，分岐，反復を表現しているわけです．
それに対して，ビスケットにはどの命令を実行しているのかという概念がそもそも存在しません．存在していないので，逐次実行，分岐，反復といった概念も明確に理解することには繋がらないですし．ではどんなことを学んでいるのでしょうか？
ビスケットの教え方を順を追って見てみましょう．この過程で，子供達のコンピュータの理解はどのように変化しているのかを推測してみます．
１）メガネの左右に同じ絵を入れて，その絵を動かす．メガネの中の絵の動き方で方向と速度を調整できる．この時点では自分で絵を動かすツールという理解になるでしょう．同じ絵は同じ動きをする．メガネの中を変えると，同じ絵は一斉に動きを変えます．メガネが壊れると一斉に動きがとまります．瞬時に変化が全員に伝わるすごさと，一斉に壊れるというコンピュータの脆さも伝わります．ときどき，システムのデザインをやっている大人からは，ここまでの理解だけではメガネに丸が左右にあることは無駄で，方向と速度を示すだけの一つの丸でよいのではないかという質問をもらいます．
２）同じ絵を使ったメガネを二つ用意する．たとえば上に進むメガネと下に進むメガネ．これは新しいビスケットに追加された機能で，２つのメガネがランダムに選ばれて実行します．その結果その絵はゆらゆらと動くことになります．普通のプログラム言語ではランダムな実行というのはかなり上位な概念で作られますが，ビスケットではそれが組み込みの機能として入っています．このとき，子供達には，メガネは命令というよりは，その絵が持っている性質を表しているという印象に変わると思います．我々は「おばけは上に行ったり，下に行ったりする」という言い方をしています．命令ではなく，あるべき性質の一つを定義すると感じです．だいぶ宣言型言語らしくなってきました．
これでもメガネのまるは，まだ一つで十分ですね．
３）２つの絵で，パクパクするアニメーションを作る．このとき初めて，メガネの左側の意味がでてきます．メガネはある絵をある絵に変える（位置関係も含めて）という説明をします．いままではたまたまメガネの左右に同じ絵が入っていたから動いて見えているだけでした．絵を変えるということができるとわかると，たとえば絵を１０個書いて，１０個のメガネで順に変化させるといった実験もできるようになります．２コマから１０コマに変わるという理解で，逐次実行が理解できたと思ってもよいかもしれません．途中で同じ絵から始まるメガネを複数つくると，「赤いボールは，青くなったり，黄色くなったりする」といったことにもなります．これは状態遷移図につながります．ある絵で動きが止まってしまうことがありますが，それはその絵から始まるメガネを作っていないからです．これで反復が明確に見えてきます．それから最初にある絵を置いたとしても，そのあとその絵が出てくることがないということがある場合は，その絵が右側（結果）にはいっているようなメガネを作っていないということです．これらを通じて，プログラムが止まらずに動き続けるにはどうしたらよいか，という重要な概念を学ぶことができると思います．
つぎにやっと条件が分岐が入ってきます．
４）メガネの左側に２つの絵をいれます．この絵とこの絵がぶつかったら，という言い方をします．いままでは絵の単独の性質を記述していましたが，二つの絵の衝突を導入することで，その絵の位置関係を使ってある条件を表すことができるわけです．一番単純なのは「尺取り虫がボールにぶつかったらボールをける」というメガネですね．絵の配置だけを変化させています．もう少し複雑になると，「健康な人と風邪をひいた人がぶつかったら，風邪がうつる」というメガネで，２つの絵がぶつかると，片方の絵の種類が変化する，ということが表現できます．これを動かすと絵の数が変化する様子が見れるので，一つの箱庭のシステムとしてものをみることができるようになります．ここから，指数関数的な広がりの理解などに繋げられます．
こうしてみると，ビスケットでは逐次実行，分岐，反復にだけ特化しているというよりは，もっといろいろなシステム全体の動きを総合的に理解して，その中の一つに，逐次実行，分岐，反復が現れている，と考えることができるように思います．実際にはその３つだけが自然界で重要であるとは思えないですよね．たまたま，コンピュータのハードウェアが採用していたというだけであって．
それよりも，ビスケットが重視しているのは，「一つの命令は小さい変化しか起こせない」ということです．逐次実行，分岐，反復も小さい変化を組み合わせて作られてますし，それ以外にも小さい変化で作れるものはたくさんあります．つまり，プログラミングのもっとも基本的な考えは「小さい変化を組み合わせて複雑なことを実現している」ということであって，そこから上位の概念を教えるのがよいだろうと思います．