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

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

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

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

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


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

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

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

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

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

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


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

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

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


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

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

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

Prologは関係を表現できます．というか関係しか表現できません．たとえば，Ａ＋Ｂ＝Ｃという式があったとします．普通の言語ではＡ＋Ｂの計算をして，Ｃのメモリーにその値を書き込むという解釈をします．ＡとＢの値が決まっていてＣは未定義だったり，Ｃの新しい値としてこういう計算をしました．それに対して，ここで表現した式は計算の方法ではなくあくまでも式というか変数同士の数学的な関係を表していると解釈できます，たとえばこの式があったとき，Prologでは「Ｂが２０，Ｃが５０のときＡは何でしょう」という聞き方にもこたえることができるのです．

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


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

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

Twitterで住井さんと山口さんがプログラミングの興味深い議論をしてまして．その議論をきちんと追えてはいないんですが，ビスケットについても語られていた部分があったので，ちょっと考えてみました．

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

「右に動き続ける」と「「右に少し動く」を繰り返す」の間には認知的にはギャップがあるはずで、Scratchを使うと「「「右に少し動く」を繰り返す」→「右に動き続ける」」が学べるように思えるけれど、Viscuitで学べるかはよく分からない。

— Ryusei Yamaguchi (@mandel59) 2016年5月7日

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

唯一，我々にしか言えないことというのが「プログラミングって楽しいよ」「コンピュータはこういうことなんだよ」ということであって．まあ，それだけを愚直に言っていくのがだれも敵に回さない方法だと思うのです．

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

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

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


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

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

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

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

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

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

５）なんの時間で教えるの？
　２時間だけの時間をもらえればよいので，学校がどの授業の枠でやるかを決めればよいと思います．僕は総合の時間でよいと思います．総合の時間はそもそもそういう使われ方をするために生まれたと思っています．

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

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

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

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

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

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

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

そして，上に述べたことは，知らない大人にどう知ってもらうのか，ということを遠回しに言っているのことなのでした．