ビスケットのあれこれ

ビジュアル言語ビスケット(Viscuit)に関するあれこれを書いてゆきます.

オブジェクト指向の問題点

2016-05-10 12:28:06 | 1
オブジェクト指向プログラミングを神格化するような記事が流れてきたので,僕が知っている問題点について書いてみたいと思います.僕がまだ学生だったころは,オブジェクト指向の評価もまだそれほど定まっていなくて,オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが,ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか.僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて,ここまで使われてる理由は,現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています.オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです.

以下で上げる問題点は,個別に解決している研究はあったりしますし,僕も論文を書いたりしましたけど,実際の言語に導入されていなければあまり意味がないので,問題点として指摘させていただきました.論文じゃないので,軽い気持ちで読んでいただければと思います.

1)メッセージの流れが見えない
 オブジェクト指向においてメッセージのやり取りほど重要なものはないのに,そのやり取りの様子がプログラム上で表現できていません.メッセージの送信は,繰り返しや条件分岐などの制御文によって作られた関数呼び出しの副作用として間接的に表現されます.一方受信の方はもっと見えなくて,例えばその時のオブジェクトの内部状態によって受信できるメッセージの種類が変わるはずなのに,そういった制御や抽象化ができません.最初に初期化のメッセージを受信した後,処理のメッセージをいくつか受信して,終了のメッセージを受信する,といったプロトコル的な記述もできません.

2)オブジェクトのつながり具合が手続きでしか表現できない
 次に大事なのがオブジェクトのつながり具合です.たとえばMVCという3つのオブジェクトの集まりで一つの部品を作るような場合があります.プログラムは,M,V,Cそれぞれが同じ相手とつながっていることが前提でつくられます(たとえば,Mが知っているVと,Cが知っているVは同じものである,といったことです).しかし,このつながり具合が正しいかどうかを保証する方法がありません.木構造をオブジェクトで作るとき,自分の子供は全員自分を親として見ているか.こういったつながりを手続きで頑張って作るので,間違えが入る可能性があります.間違えをできるだけ入らないようにするために,オブジェクトの外側からは内側を触れないようにカプセル化しますが,そういう制約はオブジェクト指向自身が自由度が高すぎる,逆に言うと何も保証しない貧弱であるから必要なのです.


3)ユーザレベルでの部品化再利用に全然なっていない
 僕が素晴らしいプログラムの部品化再利用の例だと思っているのがUNIXのパイプラインです.これが通じる人はどれくらいいるのかな.コマンドの出力が次のコマンドの入力になるようにパイプでつないで表現するものです.パイプが人間にとってすごく使いやすい理由は,そこを流れるデータが人間に見える形式だったからです.見えるから次のコマンドにどんな処理をさせればよいか考えやすくなります.何か動きがおかしければ,途中に流れている文字列を見ればわかります.典型的な入力データをエディタで作ってもよいですし,途中の処理が特殊すぎてわざわざプログラムで処理しなくてもよいような場合,人間がエディタ上で手作業で編集してもよいわけです.テキストデータという共通のデータ形式の上で人間とコンピュータが協調して問題を解いていたという感覚がありました.

こんな素晴らしい仕掛けが使われた時代はそんなにコンピュータが速かったわけではありません.それでもバイナリーではなくテキストの10進表記で数を表すという,実に無駄な方法が人間の利便性を優先して使われていたということに敬意を表します.

1次元にコマンドを並べて処理を順に行うような単純な処理だけですむ時代は終わりました.パイプに代わるもっと複雑なコマンドの組み合わせ方を発明しなければなりません.パイプは一方向の情報の流れでしたが,情報は双方向の流れを許すべきです.

僕はUNIXにX-Windowというウインドウシステムが入ってきたとき,次世代のパイプが発明されるのかとワクワクしてましたが,結局まだ誰もそれを発明できていません(僕が知らないだけであるのかもしれません).部品化はオブジェクト指向にとってかわられ,プログラムの中は閉ざされ,人間は遠ざけられました.

北大の田中先生のIntelligentPadにその可能性を感じましたが,結局はオブジェクトの合成という非常に難しい問題がその前に立ちはだかりました.

そうこうしているうちに,WWWの大爆発が起こって全部吹っ飛びました.


4)知識表現が手続き側に偏っている
 プログラミングという処理っぽい呼び方ではなく,もう少し広い意味を込めて知識表現と呼ぶことにします.プログラムはもちろん知識表現の一部です.たとえば,EXCELの表も知識表現ですし,構造をもったデータは知識表現です.オブジェクト指向の何が悲しいかというと,構造をもったデータを直接作り出すことはできないということです.手続きを使って変換するしかありません.たとえばLISPではコンピュータが処理するデータ構造を人間が直接入力することができます.そういう人間とコンピュータの仲の良い関係がオブジェクト指向では消えてしまってます.

5)オブジェクト指向は人間をだましている
 オブジェクト指向で作られた典型的なグラフィカルなプログラムを考えましょう.オブジェクトには内部状態があります.その内部状態を更新させることが唯一の計算です.その内部状態を人間にみせるためのプログラムと,人間が見ているもの(画面)に対するマウスやタッチの操作を解釈して内部状態を更新するためのプログラムがあります.これは上の例ででてきたMVCということなんですが.だましているといったのは,Mは内部に存在しますけれども,Vがどう作られたかで見え方が違ってきます.同じ見え方でもMの中身が違っていたり,同じ中身でも見え方が違っていたり,ということが平気で起きます.真逆はLISPです.LISPはコンピュータが見ているメモリーの構造と人間が見ているS式とが1対1の関係になるので,つまり人間とコンピュータが同じものを見ているという安心感があります.オブジェクト指向はコンピュータと人間が同じものを見ている感がしません.コンピュータがすごく頑張って人間にすごいものを見せている(もしくはだましている)という感じです.

 こうなっちゃった理由は,コンピュータに課せられた役割が,これまでプログラムを作る人と使う人とが一体となっていた時代から,作る人と使う人とが明確に分かれた時代に変わってきたということなのかもしれません.UNIXのテキストは人間にわかりやすいといっても,ビットマップのテキストよりは見栄えがしないわけで,作る人と使う人が一緒なら我慢もできましょうが.逆に,使うだけの人にとっては,上手にだましてもらったほうがいいわけですし,よりかっこよくだました方がお金が儲かるという事情もあったのでしょう.


6)オブジェクト指向は貧乏
 オブジェクト指向が活躍した時代はメモリーが非常に少なくどう節約するかが重要でした.なのでよく使われていた例は,列というものがあって,その列をどのように扱いたいかによって実行の効率が変わるので,使用法に適した実装を選んで効率をよくすることができる.しかしアルゴリズムはそのデータ構造の影響を受けないように計算方法だけ書けばよい.そんなことが言われていた時代でした.つまり,一度書いたアルゴリズムはいろんなデータ構造に対して,効率の良い実行ができるというものです.

しかし今は,メモリーもふんだんにあって実行速度の差もそれほど重要ではなくなってきたので,そんな実装方法に依存しないアルゴリズムという貧乏なことを言わなくてもよくなりました.万能なデータ構造を一つ決めて,アルゴリズムは全部その構造に対して作ってしまえばよいのです.LISPみたいなものです.ただし,LISPの時代から何が変わったかというと,扱うデータが木構造のように単純ではなく,グラフ構造になったこと.一つのスレッドではなくマルチスレッドでかつ分散になったこと.オブジェクトが複雑に参照しあっているようなグラフ構造をLISPのS式のようなシンプルで汎用性のある記法で記述しなければならないということです.なのでS式的な今風の拡張が求められています.

7)関係を記述できない
 メッセージは単項演算なので,複数のオブジェクト間の関係を表現するのが苦手です.ある一つのオブジェクトに,起きろ,歩け,といった命令をするだけなら簡単です.それに対して,二つのオブジェクトが関係する命令,たとえば二人に対して,ぶつかれ,ならべ,という命令が苦手です.通常のオブジェクト指向では,関係するオブジェクトのどれか一つを特別に選んで,それに対するメッセージとして表現します.他のオブジェクトはそのメッセージの引数として渡されます.2)で言ったようなつながり具合を表現したければ,メッセージの受信側に選ばれたオブジェクトが責任をもって引数で渡されたほかのオブジェクトどうしをつながなければなりません.

Prologは関係を表現できます.というか関係しか表現できません.たとえば,A+B=Cという式があったとします.普通の言語ではA+Bの計算をして,Cのメモリーにその値を書き込むという解釈をします.AとBの値が決まっていてCは未定義だったり,Cの新しい値としてこういう計算をしました.それに対して,ここで表現した式は計算の方法ではなくあくまでも式というか変数同士の数学的な関係を表していると解釈できます,たとえばこの式があったとき,Prologでは「Bが20,Cが50のときAは何でしょう」という聞き方にもこたえることができるのです.

計算の方向まであとで決められるくらいの自由度はともかく,オブジェクト指向がメッセージのやりとりにこだわっていると,関係を表現するのがすごく大変ということはわかっていただけたでしょうか.


オブジェクト指向の問題点のうち,ごく一部はビスケットの設計方針に影響を与えています.たとえば,コンピュータが裏で人間のために頑張るというのではなく,コンピュータと人間が同じものを見ている感というのを大事にしている部分などですが.人間とコンピュータの関係がどうあってほしいかといった思いも込められています.
コメント (7)
この記事をはてなブックマークに追加

ビスケットでプログラミングのどんな概念が学べるのか

2016-05-08 10:14:53 | 1
Twitterで住井さんと山口さんがプログラミングの興味深い議論をしてまして.その議論をきちんと追えてはいないんですが,ビスケットについても語られていた部分があったので,ちょっと考えてみました.

もともとは,数学とプログラミングの違いからはじまり,プログラミングの本質はどこにあるのかから,逐次実行,分岐,反復は基本だよね,といった流れのようです.


<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>


Scratchを始め,ほとんどのプログラミング言語には,明確に逐次実行,分岐,反復が言語の構成要素として現れています.これらを組み合わせることでプログラムを作りますから,当然これらの構成要素を強く意識します.ビスケットとはいろいろと違うのですが,一番大きな違いは「いまどの命令を実行しているのか」という概念がそれらの言語にはあるということです.この「どの命令を実行しているのか」はCPUのレベルではプログラムカウンタという言い方をしてます.命令がメモリーに順番に並んでいて,その順番通り実行すればよいので,基本的には数が1つずつ繰り上がることから,「カウンタ」という呼び名になっています.もっと上の言語になると命令の列をメモリーとして意識しないのでカウンタと呼ぶのは変ですが.なんというんでしょうね.明確な呼び名がすぐに思いつかないのは,その概念が(ブロックのような)プログラムの構成要素としては出てこないからでしょうか.そのプログラムカウンタのようなものが,現在実行しているブロックを指し示していて,指し示すブロックが変わってゆくことが逐次実行,分岐,反復を表現しているわけです.

それに対して,ビスケットにはどの命令を実行しているのかという概念がそもそも存在しません.存在していないので,逐次実行,分岐,反復といった概念も明確に理解することには繋がらないですし.ではどんなことを学んでいるのでしょうか?

ビスケットの教え方を順を追って見てみましょう.この過程で,子供達のコンピュータの理解はどのように変化しているのかを推測してみます.

1)メガネの左右に同じ絵を入れて,その絵を動かす.メガネの中の絵の動き方で方向と速度を調整できる.この時点では自分で絵を動かすツールという理解になるでしょう.同じ絵は同じ動きをする.メガネの中を変えると,同じ絵は一斉に動きを変えます.メガネが壊れると一斉に動きがとまります.瞬時に変化が全員に伝わるすごさと,一斉に壊れるというコンピュータの脆さも伝わります.ときどき,システムのデザインをやっている大人からは,ここまでの理解だけではメガネに丸が左右にあることは無駄で,方向と速度を示すだけの一つの丸でよいのではないかという質問をもらいます.

2)同じ絵を使ったメガネを二つ用意する.たとえば上に進むメガネと下に進むメガネ.これは新しいビスケットに追加された機能で,2つのメガネがランダムに選ばれて実行します.その結果その絵はゆらゆらと動くことになります.普通のプログラム言語ではランダムな実行というのはかなり上位な概念で作られますが,ビスケットではそれが組み込みの機能として入っています.このとき,子供達には,メガネは命令というよりは,その絵が持っている性質を表しているという印象に変わると思います.我々は「おばけは上に行ったり,下に行ったりする」という言い方をしています.命令ではなく,あるべき性質の一つを定義すると感じです.だいぶ宣言型言語らしくなってきました.

これでもメガネのまるは,まだ一つで十分ですね.

3)2つの絵で,パクパクするアニメーションを作る.このとき初めて,メガネの左側の意味がでてきます.メガネはある絵をある絵に変える(位置関係も含めて)という説明をします.いままではたまたまメガネの左右に同じ絵が入っていたから動いて見えているだけでした.絵を変えるということができるとわかると,たとえば絵を10個書いて,10個のメガネで順に変化させるといった実験もできるようになります.2コマから10コマに変わるという理解で,逐次実行が理解できたと思ってもよいかもしれません.途中で同じ絵から始まるメガネを複数つくると,「赤いボールは,青くなったり,黄色くなったりする」といったことにもなります.これは状態遷移図につながります.ある絵で動きが止まってしまうことがありますが,それはその絵から始まるメガネを作っていないからです.これで反復が明確に見えてきます.それから最初にある絵を置いたとしても,そのあとその絵が出てくることがないということがある場合は,その絵が右側(結果)にはいっているようなメガネを作っていないということです.これらを通じて,プログラムが止まらずに動き続けるにはどうしたらよいか,という重要な概念を学ぶことができると思います.

つぎにやっと条件が分岐が入ってきます.

4)メガネの左側に2つの絵をいれます.この絵とこの絵がぶつかったら,という言い方をします.いままでは絵の単独の性質を記述していましたが,二つの絵の衝突を導入することで,その絵の位置関係を使ってある条件を表すことができるわけです.一番単純なのは「尺取り虫がボールにぶつかったらボールをける」というメガネですね.絵の配置だけを変化させています.もう少し複雑になると,「健康な人と風邪をひいた人がぶつかったら,風邪がうつる」というメガネで,2つの絵がぶつかると,片方の絵の種類が変化する,ということが表現できます.これを動かすと絵の数が変化する様子が見れるので,一つの箱庭のシステムとしてものをみることができるようになります.ここから,指数関数的な広がりの理解などに繋げられます.

こうしてみると,ビスケットでは逐次実行,分岐,反復にだけ特化しているというよりは,もっといろいろなシステム全体の動きを総合的に理解して,その中の一つに,逐次実行,分岐,反復が現れている,と考えることができるように思います.実際にはその3つだけが自然界で重要であるとは思えないですよね.たまたま,コンピュータのハードウェアが採用していたというだけであって.

それよりも,ビスケットが重視しているのは,「一つの命令は小さい変化しか起こせない」ということです.逐次実行,分岐,反復も小さい変化を組み合わせて作られてますし,それ以外にも小さい変化で作れるものはたくさんあります.つまり,プログラミングのもっとも基本的な考えは「小さい変化を組み合わせて複雑なことを実現している」ということであって,そこから上位の概念を教えるのがよいだろうと思います.
コメント (1)
この記事をはてなブックマークに追加

プログラミングを学ぶことによって獲得できる能力を言ってはいけない

2016-05-06 14:51:08 | 1
何度も繰り返して言ってますが,プログラミングを全員が学ぶ必要があるのはコンピュータとは何かを知るためです.何度も質問をされますが「プログラミングを学ぶとどんな能力がつくでしょうか」に対して僕は一切答えるつもりはありません.というか,我々(コンピュータの専門家)は答えるべきではないと思っています.

本心からいうと,たとえば佐藤さんのブログ

自己研鑽力,ルール適応力,根回し力,といったことが言われていて,僕も共感できますし.神谷さんの本「子どもにプログラミングを学ばせるべき6つの理由」の内容も同意です.うすうす感じています.きっと正しいと思います.

ただ,こういった力がつきそうということは,プログラミングを教えて普通に観察していると気がつくことなので,できれば外部からではなく,内部つまり学校の先生たちに気がついて欲しい.だって子供にいろんな力をつけさせるというのは先生たちの本業であって,重要な能力であればあるほど,先生たちはそういった子供たちの変化に敏感であるはずですから.

ある小学校に授業に行ったときなんですが,終わって校長先生の部屋でお茶をご馳走になっていたら,担任の先生がその次の授業の合間をぬって,僕たちに授業の感想を言いに来てくださいました.

「子供たちの普段とは違う側面を見ることができて本当に良かったです.あの子がこんなことができるなんてまったく知りませんでした」

それだけ言って,すぐに教室に戻られたのですが.いや本当先生はお忙しい.

僕らは毎回いろんなクラスで普段通りやっているだけで,その中にはバンバンやる子もいれば,友達に教えられながらやる子もいれば.まあいろいろです.普段がどうということはまったくわかりませんから,教え方としては,一番遅い子に合わせて,でもはやい子も退屈しないように気をつけてやっているだけです.何がどう変わったのか,たとえば普段,絵をまったく描かない子が描いた,とか,普段まったく発言しなかった子が自分から質問したとか.そういったことは,我々にはわかりません.

しかし,子供たちの変化に敏感な先生であればあるほど,たった1回の授業でも,いろんなことに気づくはずです.繰り返してやるうちに,これは何々力をつけるのにつかえるツールだ.ということがしっかりした証拠で言えるはずです.

逆に,事前の打ち合わせでいつも言われるのが,やんちゃだとか,理解が遅いとか,発達障害の子供がいるんですといった,ちょっと飛び出た子がいるので気をつけてくださいということですが.ところが,僕らも終わってから,どの子が心配な子だったのか気がつかないほどで,僕らも特別なケアはしていません.でも,いろんな先生からいつも言われるということは,先生方にとって,普通の授業をする上ではそういう子の存在を知っておくことが重要なんだとということなのでしょうが.僕らはそんなに重要ではないわけです.

外部講師の役割の一つに,担任の先生とは違う視点を教室に持ってくる,ということがあると思います.それは先生にとってももちろん,クラス全体にとっても重要なことでしょう.担任の先生ができることをわざわざやる必要はないですし,そこで担任の先生と奪いあっても仕方がない.

絵が描けない子が,絵が描けるようになりました.というのを担任の先生に言われるのは我々も嬉しいのですが,逆に,こちらから「絵が描けない子でも絵が描けるようになりますよ」と言ってしまったら,「いやいや,うちでは他の方法で絵を描けるような教え方をしてますから」になっちゃいますよね.それはすべての「何々力」に言えることです.

唯一,我々にしか言えないことというのが「プログラミングって楽しいよ」「コンピュータはこういうことなんだよ」ということであって.まあ,それだけを愚直に言っていくのがだれも敵に回さない方法だと思うのです.
コメント
この記事をはてなブックマークに追加

小学校でのプログラミング教育よくある質問

2016-05-01 10:00:25 | 1
先日書いたブログが拡散して,某新聞記者から取材を受けました.意見を持っている人にとって,それがちゃんと伝えられるいい時代になりましたね.そんなわけで,自分の中ではとっくに解決している問題ですがあらためてブログに書いておくことにします.

プログラミング教育が小学校でという話で,誰が教えるんだ.どの教科を削るんだなど,よく言われている課題がありますが,僕は実現はそんなに難しいとは思っていませんので,それを書きます.


1)誰が教えるの?
 前に書いたとおり,小学校の各学年で2時間程度ですから,専任講師が教えます.2時間の授業6学年分のやり方を覚えた人が講師になります.担任の先生は,同じ子供に毎回違うことを教えるのに対して,この講師は同じことを毎回違う子供たちに教えますので,その内容に関してすぐに上手に教えられるようになります.売れない芸人が毎回同じタイミングでお客さんを笑わせているのと同じ感じです.どの説明がわかりにくいか,どこはもっと短くてもよいか,2−3回授業をやるとすぐに改善されます.

 これらの講師はそれほど専門的な質問には答える必要はありません.まずは「今度ハカセに聞いておくね」で十分です.講師がわからない質問をしたということで,子供も鼻が高いでしょうし.中途半端な知識で知った風に答えてしまう方がやっかいです.中途半端な専門家よりも,子供の目線に立てる人の方が重要です.

2)機材はどうするの?
 専任講師がタブレットを人数分持っていきます.無線やサーバなどの機材も持ち込みます.いまだとタブレットは1台2.5万円くらいで,児童の人数にもよりますが30人として全部で150万円くらいで揃えられるでしょう.

3)全国に展開するには,講師は何人くらい必要で,お金はどれくらいかかるの?
 日本には小学生は各学年で120万人くらいいます.クラス数にすると,小さいクラス大きいクラスいろいろとあるでしょうが,平均20人として(人数の少ないクラスだったら,2学年同時にやってもいいですし),6万クラスです.6学年で36万クラスですか.各クラス2時間ずつできっちりとつめると,1日3クラスの授業ができます.12万人日必要です.1年に200日くらい授業ができるとすると,600人の講師がいればすべての学校に行き渡ることになります.各県で10人くらいと考えると,一人でどれくらいのエリアを担当するか想像できると思います.つまり,600人の年間の人件費と,各人150万円くらいの機材費ですね.人件費はどういう人材を講師にするかという考え方にもよりますが,わかりやすく,350万くらいとすると,合わせて500万円です.最初の年は30億円,翌年からは機材日がかかりませんから20億くらいずつです.そんなにバカみたいな金額ではないとおもいます.

実際には,人件費は各自治体がどういう人を雇うのかで,決まって行くとおもいます.たとえば,ICT支援員さんを雇っている自治体もあるので,その人数を増やして講師として派遣するというのもいいですね.

4)何を教えるの?
 前のブログの記事では全部ビスケットを教える風に書きましたが,高学年は違うことをやってもよいとおもいます.ただし,これが成立するのは,各クラスで2時間に収めるというのが前提です.ITに力を入れている自治体はもっと予算をかけてやればよいと思います.前のブログではあえて「ものづくり」の視点は外してあります.その視点は大事ですが,そこまで広げると話が散漫になってしまいます.図工などを中心としたカリキュラムの再編成で解決すべきで,もちろんプログラミングは最重要にですけど,設計とかコンピュータとは無関係に重要な話もいろいろとあるので.

5)なんの時間で教えるの?
 2時間だけの時間をもらえればよいので,学校がどの授業の枠でやるかを決めればよいと思います.僕は総合の時間でよいと思います.総合の時間はそもそもそういう使われ方をするために生まれたと思っています.

6)対象は子供だけ?
 本当は大人も受けるべきです.PTAや,もちろん学校の先生にも.大人を相手ですから,子供よりは短い時間で6学年分をやってしまうことができるように思います.そもそも,いまの大人は成長の過程で習ってこなかったことですから,どこかのタイミングで習う必要があると思います.

7)何年間続けるの?
 これを3年くらい続けたときに,学校でも自前のタブレットを揃えるというところが増えてくるのと,自分でも教えられるという先生が増えてくることが予想されます.自分のクラスで自由に使えるタブレットがあったときに,先生は他の教科の中でもプログラミングを導入してみたくなるでしょう.それらは,いま盛んに実証実験されている,国語,図工,音楽などの教科の中で実施していることとも繋げられます.

まずは,子供の教育に携わっている大人全員が,この授業の重要性を知ってもらうことが大事です.理解された後は,自動的に話が進むはずです.いま進まない理由は,単なる無知や誤解からですから,それを解くということが最も重要な課題です.

 
8)これをやるとどんな人に育つのか
 教育の評価は非常に難しいと思います.それを教えるか教えないかで,その人の将来がどう違ってくるのか,というのを何年も待たなければないわけですから.しかもあることを教えなかったといっても,その人は授業とは別に本で読んで知っちゃったかもしれないと考えると,正確な実験なんてできっこありません.

教育の別の見方として,子供に新しい視点を与えるというのがあります.コンピュータの中身を少し知るということです.これはほぼ無条件でプラスです.知らない方が幸せな人生を送れたということは考えにくい.年間30億の予算と,各自2時間の時間と引き換えに,新しい視点を与えるという選択になります.

それも早ければ早いほど良いでしょう.たとえば,子供はタブレットでゲームをやったとき,自分でゲームを作れて,それは意外と簡単だけど意外と難しいというのがわかるかわからないか.ゲームをやり始める頃には,中身についてもやりたいですね.

9)この先どうするのか
 本当のプログラミング言語はもっと色々とあるし,それを学ぶ方法も沢山あります.僕自身,プログラミングを覚えたのは30年以上前で独学でしたから,インターネットの時代に,環境さえ用意してあげれば大人がとやかくいうことはないと思います.それを支える見守る大人が増えればよいだけです.

そして,上に述べたことは,知らない大人にどう知ってもらうのか,ということを遠回しに言っているのことなのでした.
コメント (4)
この記事をはてなブックマークに追加

コンピュータはバカだけどすごい

2016-04-30 12:25:39 | 1
コンピュータとは何かということを言い続けてますが,それ自身ぼんやりした話ですよね.知っている人はなんとなく知っていて,知らない人はまったく知らない.一体何と言われてもぼんやりしたことしか言えない.

ということなので,僕が考えていることを,少しずつ説明してみます.

まず,みんなに知ってもらいたいのは,「コンピュータはバカだけどすごい」という話です.コンピュータの動きってときどき,信じられないくらいバカな動きをしますよね.一方でむちゃくちゃ賢い動きもする.どうしてそうなっちゃうのかということです.

コンピュータはプログラムで動いています.そのプログラムの中身はというと,小さな命令があってそれを組み合わせて一つのプログラムになっています.どれくらい小さな命令かというと,これが人間が考えるよりもずっとずっと簡単な・単純なことしかできません.数を読む,数を書く,数を引く,数を足す,数を比べる.本当にこんなことしかできません(本当にそうです).コンピュータがいろんなことができるのは,いろんなことを数に置き換えているからですけれど,もう一つ重要なことは,単純な命令しか使っていないけれど,それはそれはものすごい数の命令の組み合わせでプログラムにしているからです.10個や100個ではないです.1万個や100万個くらいの命令の組み合わせで動かしています.それがものすごい速さで動いて命令の多さが見えてこないので誤解されるわけです.

コンピュータがバカというのは,単純な命令しか実行できない,ということです.コンピュータがすごいのは,むちゃくちゃ多い命令を高速に実行するからです.コンピュータがバカだというのはプログラムを書く人だけの秘密ですね.

僕が,大人向けの講座でやっているトランプの遊びをご紹介しましょう.これはコンピュータの命令を組み合わせることがどれくらい難しいことなのかということを体験するものです.

2人ペアになって,トランプを5枚配ります.わかりやすいように,5枚のマークは同じものにするとよいです.

トランプを伏せておいて,それを数の小さい順に並べるという課題を,二人で解決します.

一人は命令を出す役,もう一人はコンピュータ役です.

命令出す役の人はカードの数を見てはいけません.コンピュータ役の人にやって欲しいことを言うだけです.

コンピュータ役の人にお願いできることは次のことです.
 カードを動かしてもらう.
 2枚のカードのどちらが大きいかを聞く.


こんな感じですすみます.

a「このカードとこのカード,どっちが大きですか」
b「こっちです」
a「では小さい方のカードをこっちへ,大きい方のカードをこっちへ動かしてください」
b「はい」

a「このカードとこのカード,どっちが大きいですか」

これを繰り返します.

まずは,最短で並び替えるということは考えなくて良いです.というのは,最初にカードがどのように並んでいるかで手数が変わるからです.それよりも,間違わないように慎重にやるようにしましょう.終わったと思ったら,ひっくり返して確認します.コンピュータ役の人はどこで間違ったかを知っているので(でもゲームの途中では言えない)教えてもらいましょう.たった一回のミスが最後まで尾をひきます.コンピュータ側の人からみると「その操作はさっきもやったのに」と思うような無駄なことも,命令する人にはわからないですよね.

何度か役を交代して,間違わないように命令をだすということがどれくらい難しいのかを身を以て体験しましょう.人間とコンピュータの違いがすごくよくわかるとおもいます.

(ぜひ身近な人ととやってみてください.プログラムを知っているからと言って,簡単にできるわけでは無いようですよ)

よく,コンピュータのアルゴリズム的な考え方が重要だ,といった言い方を聞きますけど,そもそもアルゴリズムというのはどういうものでしょう.

実は,この遊びではまだアルゴリズムにまでは到達できていません.命令を出す役の人は,カードがどのように動いたかを観察して,その都度次の手を考えているからです.でも,何度か交代してやっているうちに,必勝法というのがわかってきます.こういう考え方で,こういうときにはこうすればよい,といったことですけど.必勝法が思いつくと,その方法を文章に書くことができます.その文章を読んだ人もまったく同じやりかたで一発で成功できるようになります.この必勝法のことがアルゴリズムなのです.

必勝法ができると,ゲームの間はそのやり方に従って命令を出せばよいだけなので,ほとんど頭を使いません.必勝法を知らない頃はすごく考えていたのに,考えなくても,できるようになります.道具をつかったり(カードを並べた位置に印をつけるとか),カードの並べ方,重ね方などを工夫して,より手順が少なく,頭を使わない必勝法がよい必勝法です.

一方で人間がトランプの数を小さい順に並べる作業を考えてみましょう.人間の場合は,カードが全部表を向いています.なのでパッと見たら一番小さいカード,大きいカードがすぐにわかります.あとは両手を使ってささっと並べ変えれば終わりです.カードの枚数が100枚くらいになったらさすがにそんな簡単にはできませんが,5枚くらいだと本当に簡単です.人間がどれくらい高度で複雑な命令を実行できるかよくわかるとおもいます.

トランプを相手にしてますから一番小さい数が1で,一番大きい数が13ということを知ってますけれど,本当の問題は,数の範囲もわかりませんし,どっちに偏っているかもわかりません.

本当のコンピュータも,ここでやったように2つの数の大小を比べる,数を書く,数を読む,という命令しかできません.それらを組み合わせて,膨大な数を小さい順に並び替えているのです.並び替えるというだけで命令数は1000くらいは必要でしょう.

コンピュータでいろんなことをさせてますね.最近は写真に写っている顔を交換するという面白いアプリが流行っていますが,写真は1点1点の色を数で表してその計算だけで,こういうすごいことをやらせているんですから.

「コンピュータとは何か」の一つとして,コンピュータはどこがバカで,どうしてすごいのか.なんとなくわかりました?


では,次の疑問,何万,何百万という命令を間違わないように組み合わせなきゃないわけですが,それはどうやってやるのでしょう.そういう感じで,コンピュータ入門講座は進んで行きます.
コメント
この記事をはてなブックマークに追加

小学校でのプログラミングの授業案

2016-04-21 13:14:27 | 1
プログラミングを小学校からやるという方針がやっとでましたね.僕も以前から主張していましたが,政府の後押しが出たのは喜ばしいことです.ところが,やはりというか「そんなことは小学生のうちからやる必要はない」という意見もチラホラでています.コンピュータが嫌いな人から出ているのならまだしも,コンピュータの専門家の中からも聞こえてきます.こんなのいつひっくり返るかわからない危うい決定なんですから,せめて専門家の間では足並みを揃えたいところですが.

こうなる理由は「プログラミングを教える」ということがちゃんと定義されないで,それぞれが思ったことを言っているからですね.ということなので,僕が考えている小学生向けの授業をざっとご紹介しようと思います.

僕は,各学年で45分の授業を2回ずつで,6年間で12回(毎週2コマではなくて年間で2コマです)というのを考えています.プログラミングを教えると色々な効果があると言われていますが,それらは全部後回しで,この12回では子供達に「コンピュータとは何か」ということを少しずつ教えてゆきます.

1,2年生
 自分の書いた絵が動く.メガネを二つ以上つかってゆらゆらさせたり,2コマのアニメーションをさせたりする.

 伝えたいこと:コンピュータは自分たちのものだという感覚.作った通りに動く.間違うと間違った通りに動く.作品はネットで公開されるので,見られても恥ずかしくない作品を作ろう.


3年生
 身の回りにあるコンピュータが入っているものを探してみる
 尺取虫が動く.尺取虫がボールをける.

 伝えたいこと:ひとつひとつのメガネは単純な動きしかしない.メガネを組み合わせると複雑な動きになってゆく.身の回りのコンピュータとビスケットとは何が同じで何が違うか.同じなのは単純な命令(メガネ)しかないということ,違うのは命令(メガネ)の数が何万,何百万という途方もなく多い.多いから複雑.コンピュータには最初から複雑な動きが入っているわけではない.命令を組み合わせるから複雑になる.


4年生
 風邪が感染して広がってゆくシミュレーション.

 伝えたいこと:ものと情報の違い.ものは複製できない.情報は簡単に複製できるので,簡単に拡散する.一度広がってしまったものを消すのは難しい

5年生
 2進数のカウンタを作る

 伝えたいこと:計算するとはどういうことか.人間がする計算とコンピュータがする計算の違い.2進法は簡単な計算方法だからコンピュータに採用されている.

6年生
 矢印を並べて,それに従って動く絵.

 伝えたいこと:今までのビスケットの遊び方とはちょっと違う遊び.メガネを作るだけじゃなくて,絵をどのように並べるかで動き方が変わる.プログラムとデータの関係.データを解釈してうごくプログラムがあると,データの並びそのものがプログラムのように見えてきて,それがプログラミング言語になる.プログラミング言語の階層があって,ビスケットの上にもう一つ矢印言語を作ったということ.プログラミング言語という発明はコンピュータが発展した大きな理由である.1万個のメガネのプログラムを間違えないように作るのは大変だけど,プログラミング言語を間に入れると,メガネの数が人間が扱える範囲にまで減らせられる.
(この授業が一番伝えたいこと.コンピュータがどうしてすごいのか,ということを子供達に知ってほしい)


この他にも,ゲーム作りや絵本作りといった楽しい授業もいろいろとできるのですが,それらは図工とか国語の時間にやるべき内容ですよね.子供達のウケはすごく良いのでやりやすいとは思いますが,すべての子供たちがやるべきだとは思いません.そこで狙っている内容はプログラミングじゃなくても教えられるからです.

それに対して,コンピュータとは何かを教える授業は,プログラミングでしか教えられないので,それが必須にする理由なのです.

これらをやる理由は,小学校にある田んぼの話などこのブログにもいろいろと書いてますね.


コメント
この記事をはてなブックマークに追加

園児でもできるプログラミング

2016-02-19 17:26:16 | 1
桐蔭学園の幼稚部のアフタースクールでビスケットのワークショップが行われた内容をご紹介します.

【幼稚部】スペシャルプログラム「海のせかいを描いて動かそう!」

記事を読むと,みんな楽しそうに遊んでいます.これほど子供の表情がわかるくらい近くで見れるのも珍しいです.

この中の上から6枚目の写真でおばけのゆらゆらを作っている画面がはっきりと見えるので,そこの解説をしましょう.

いま,ひっそりとテスト的にリリースされているAndroid, AIR(windows/Mac)版には,メガネのランダムな選択という機能が入っています.これが初期のビスケットを非常に表現力の豊かなものにしています(古いビスケットでは動きません).



このように,おばけの動きで,メガネが2つ使われています.上のメガネはおばけが上に進む.下のメガネはおばけが下に進むです.今までのビスケットでは,メガネの左側(条件部分)がまったく同じ場合はどれか一つのメガネが選ばれたらそのままずっと選ばれっぱなしになってました.古いプログラミング言語の考え方ではこれが真っ当な仕様です.

ところが,新しいビスケットではこのメガネの選択をランダムにしました.毎回どちらが選ばれるか変わります.交互でもないです.

その結果,このおばけはゆらゆらと上下する動きになるのです.



どういう教え方をするかというと,「メガネをこうすると,おばけは上に動きます」「メガネをこうすると,おばけは下に動きます」「では,上に動くメガネと下に動くメガネを2つにしたら,どうなるかというと,このようにゆらゆら動くようになります」

そうやって,自分たちで試してもらいます.

それで,先ほどの子供の写真に戻りますと,写真をよく見るとおばけの動きに,メガネが3つ使われています.例えば,こういうことです.




ここでは3つ目に,おばけは後ろに下がるというのを追加しました.これによって「おばけは上に行ったり,下に行ったり,後ろに下がったり」するようになります.

メガネを3つ4つと増やせば,どんどん動きが複雑になってゆく,というのを発見する子供は,幼稚園児対象でも毎回何人かいます.


この応用で,カニが進んだり止まったり,というのもあります.横に動くというメガネと,動かない(左右で絵が同じ位置に入っている)というメガネをつくると,じっとしてて時々動くというカニができます.動かないというメガネをいれるといろんなものがすごく生き物っぽくなるんですよね.





ここまでは,基本的な動き(上下左右,早い遅い止まる)とメガネがランダムに選ばれるということだけを教えましたが,それらを組み合わせると実にいろんな動きを作ることができます.これらの動きはこちらからは教えません.自分で発見してもらいます.メガネを増やせば増やしただけ動きが複雑になります.

僕が子供たちに伝えたいことは,コンピュータの複雑さはどこからくるのか,ということです.ゆらゆら動くとか,ときどき止まるといったことは,もともとコンピュータの機能には入っていません.コンピュータは基本的な動きだけしかできません.最初はその基本的な動きだけで遊びます.それらを組み合わせることで複雑な動きができるようになります.新しい組み合わせを発見すると,できることが一気に広がります.その広がって行く感じ,これこそが僕たちがコンピュータに感じている可能性です.

これを幼稚園児に体験を通じて伝えられるということは,なかなかすごいことですよね.


さて,2月28日はビスケットの誕生日です.今年はちょっと特別なイベントビスケットバースディ〜パーティーを企画しました.様々な方にビスケットの魅力についてお話しいただきます.

http://party.viscuit.com/

阿部さんとの対談が個人的には楽しみです.
コメント
この記事をはてなブックマークに追加

小学校の田んぼとプログラミング教育

2016-01-31 12:21:15 | 1
僕はこのブログで「プログラミングを学ぶべき理由」をずっと説明してきました.要約すると,プログラミングはこれから重要なスキルであると言われているけれども,それ以前に,「コンピュータとはなにか」ということを知るためにプログラミングを学ぶべきなんですよ,ということです.

「コンピュータとはなにか」というのが説明が難しい.だいたいコンピュータの専門家でもここはうまく言語化できていないんじゃないでしょうか.僕もかなり手探りな状態です.

それで,最近つかっている例が田んぼです.多くの小学校に小さな田んぼや畑があって,担当の学年が決まっているのだと思いますが,お米や野菜を育てています.秋には収穫されて,それが給食に出されたりします.なんのために,これを小学生にやらせているのでしょうか.普通にスーパーに行けばお米や野菜は簡単に手に入ることができます.大人になっても趣味で農園をやっている人はいますけれど,大半の人は購入で済ませてます.まして,これからは農業の時代だからすべての子どもたちに農業体験は必須である,ということでもありませんよね.

逆に私たち大人が気持ち悪いと思うことは,子供達が,お米や野菜がどうやって育つのかを知らない,ということですよね.都会に育つ子供達だと,どうやって育つのかをまったく知らないまま大人になってしまう可能性があります.魚の切り身の話もありましたね.子どもは売られている切り身しか見たことがないから,切り身の状態で海に泳いでいると思っているとか.

教育を効率とか将来の効果とかそういう視点だけでみてしまうと,田んぼはたぶんやらないです.ところが,大半の大人たちは,それを知らない子どもを気持ち悪いと思う.なので,小学校で田んぼをやることは,なんとなくいいことだという合意は取れているわけです.

たんぼをやるというのは,分解すると,水とお日様が大事だとか,雑草をとらないと栄養が奪われるとか,小さい種から少しずつ大きくなるとか,毎日見てても成長の変化には気がつかないけど,長い期間で見ると確かに成長しているとか,そういう,わざわざ言葉にしなくてもいいくらい常識的なことをなんとなく知るということですね.

コンピュータとはなにかというのも,そんな難しい話をしているのではないのです.水やお日様や種や成長といったことに相当するコンピュータの中身のことを知るということなんです.

野菜の成長のことなんか何にも知らなくても,スーパーで買ってくるぶんには困らないように,コンピュータの中身を知らなくてもコンピュータは使えます.でも,野菜の成長のことを知らない子どもが気持ち悪いと同じような感じで,コンピュータの中身をしらない人が大勢いるのは気持ち悪いと思うわけです.
コメント
この記事をはてなブックマークに追加

ものと情報

2016-01-18 17:01:31 | 1
最近,ビスケットを使ったコンピュータサイエンス入門講座や,その内容についてコンピュータの専門家たちと話をしていて,なんとなく感じたことを書いてみたいと思います.


感染のシミュレーションを使って,情報とは何か,情報の原理について説明しています.そこでの説明は,「物は相手に渡すと自分のところからは無くなります.情報は相手に教えても自分は忘れません.ここでやっているのも,風邪を他人にうつしても自分は治りません.だからすごい勢いで拡散します.情報が拡散しやすいというのは,情報が原理的にもっている性質そのものなのです」というものです.

コンピュータは情報を処理する機械です.情報の処理を積み重ねて,そこにあたかもものがあるかのように動かしてます.たとえば,チケットの販売を考えると,昔はチケット売り場にそれぞれ100枚くらいずつ在庫を持っていて,お金と引き換えにチケットを売っていたわけです.どこかの売り場で売り切れたら,まだ売れ残っている売り場を探して買いに行った.いまは,チケットというものはなくて,あと何枚残っているか,という情報だけで,全国どこからでもチケットを買うことができるわけです.実に便利ですけど.もともと情報とものは全然違うのに,情報の処理を積み重ねてあたかもものがあるかのように動かしている.その辺りはきちんとしたお作法でプログラムを作らないとそれができないのですが,それを知らないでシステムを作ったりすると,昨年の夏にあった,嵐のコンサートでホテルの空室以上に予約をとってしまったというような珍事件が起きるわけです.

いま幾つかのグループで,いくつかのプロジェクトが同時進行していて,それぞれのグループで使っているグループウェアが違っていて,なかなか慣れるのが難しいのですが.でドキュメントを共有する方法もちがっていて,掲示板に共有したり,GoogleDocsつかってみたり.その中でどうしてDropboxでの共有が心地良いのかなと考えているのですが,その理由がファイルがモノっぽく見えるからなのかなぁとぼんやり思ってます.いろんな高度な機能が追加されて,それらの機能がアクセスしやすいところにある,という設計だけではダメな気がします.

ビスケットを作るときにインタフェースですごく意識したのが,情報の編集ではなくて,ものをつくっている,という感じをどう出すかだったんですよね.その一つが,いらなくなったメガネを捨てるときに,いっぺんには捨てられなくて,中の部品を一つずつお片づけして,空になったメガネをもとに戻す,という,情報の編集の観点からはなんとも面倒な手順をあえて残してあるところなんですが.
コメント
この記事をはてなブックマークに追加

プログラミングを学ぶべきたった一つの理由

2015-10-27 15:51:23 | 1
いよいよプログラミング教育ブームですが,自分の子供に教える・教えないという範囲ならば好き嫌いで済みますけれど,小学校義務教育への導入という極端な話になると,なかなか議論は尽きません.とはいえ,海外に遅れてはいけないということで,反対派を一気に押し切るというのは私は好きではありません.私の根底にあるのは,これほど面白くて大好きなコンピュータを万人に好きになってもらいたい,という気持ちがあるからです.義務教育への導入の理由は万人を説得できるものでなければならないと考えています.

たとえば,最近出版された神谷さんの「子どもにプログラミングを学ばせるべき6つの理由」という本を例にとりますが,この本は非常にうまく現在のプログラミング教育ブームをまとめている良い本です.今のブームの理由がわかると思います.しかし,ここであげているような6つの理由では,根っこから反対している人を説得できないのではないかと思うのです.それらの理由はすべて正しいけれども,すべて反論の余地があります.例えば「楽しい」という理由はぼくもその通りだと思うけれども,じゃあ楽しいのは他にないのかと言われると他にも楽しく学べるものはあります.その他「問題解決能力」「論理的思考力」「将来の可能性」「自分に自信」「創造力」というのもまったくその通りだし,一つのことでこれだけ6つも特徴が揃っているものはプログラミングの他にないとプログラミング側の人は思いますけれども,反論側の人からすると,それぞれ別にわざわざプログラミングでやらなくたって他で教えられるじゃないか,とも言えてしまいます.創造力なんて工学系の人は安易に口に出してはいけない言葉で,美大を出た人の教え方には到底叶わないですよ.なので,僕はこれらの特徴は副産物として,つまり他の理由としてプログラミングを学ぶけれど,学んだおかげで付録で付いてくるもうけものにしておいて.で,他の理由(それが僕は絶対的にプログラミングを学ぶ理由だと思っていますが)それ一点で主張してゆくことが,反対派に反論の余地を残さない方法なのではないかと思うのです.もうけものの理由の方は,それぞれ専門家がいらっしゃるので(「自分に自信」をつけさせる専門家とか)その方々に「プログラミング教育ってこういう分野にもつかえますね」と言ってもらうのを待ってからでも遅くはなくて,まあ第二フェーズで話題になることでしょう.

で,我々コンピュータの専門家が責任を持って口に出して良い「プログラミングを学ぶべき理由」というのは「コンピュータとは何かを知るため」の一点だと思います.この話をしたとき専門家ぽい人にびっくりされることがありました.「そんなものはやっていくうちに自然と身につくのではないか」だそうです.リコーダーをちょっと吹いただけで音楽とは何かを語れるようになるのかというと,なるともならないとも言えないですが.少なくともその議論の中に音大でバリバリ音楽を追求した人が関わっていなければ,非常に薄っぺらい議論になるくらいは想像できます.

昨今のプログラミング教育ブームは,コンピュータとは何かを追求している研究者ではなくて,コンピュータをどう活用するかという実務家の周辺で起こっているので「コンピュータとは何かを知るため」という深い議論にならないのではないでしょうか.コンピュータを使った研究者はたくさんいますが,コンピュータとは何かを追求している研究者は激減して,やはり世の中にすぐに役に立つ研究が人気ですし,研究費も豊富です.そういった違いも一般の人にはわからないですよね.すごいシステムを作ったプログラマーの方がプログラミングの専門家っぽくてわかりやすいですしね.

なぜ,「コンピュータとは何か」が重要なのでしょうか.それは,これから20年後のコンピュータがどのように進化しているかだれにもわからないからです.ヒントとしては,コンピュータがいかに進化したとしても変わらない普遍的な性質を見極めるということだと思いますが,それこそまさに「コンピュータとは何か」を議論するということです.

どんな教科でも,小学校で教えることは,まずはその分野の普遍的なこと(に優しく触れられるもの)を優先的に教えて,大学の専門になるに従って常にホットで実務的な内容にシフトしてゆきます.

たとえば,こんなことです.コンピュータの一つの命令というのは非常に小さい変化しかさせることができません.小さい変化を大量に組み合わせることで複雑なことができます.その動作が高速で正確なのであたかも最初からコンピュータはすごいことができるかのように見えますが本当は違います.ものすごい賢い部分もあるのに,肝心のところで馬鹿だったりします.すべては人間が作ったプログラムによって決まるのです.

コンピュータとは何かを考えると,同時に人間が考えるというのはどういうことかを考えたりもします.人間が苦労せずに簡単にできてしまうことが,コンピュータでは苦労したり,その逆だったり.

こういったことを,単なるお話として知るのではなくて,プログラミングという体験を通じて理解してゆく.そのためにプログラミングを学ぶべきなのです.

ということで,このブームの間に,いろんな種類のコンピュータ周辺の専門家たちと「コンピュータとは何か」の議論を深めて,そこからプログラミング教育の絶対的な理由を構築していかねばと思うのでした.
コメント
この記事をはてなブックマークに追加