課題の一つして考えている「数当てゲーム」についての解説を公開しました。

なぜアンプラグドなのか 正直に言えば、アンプラグドであることにこだわりがあるわけではありません。講座としては、OSのバージョンなどなど細かいことを気にするのが手間だからという程度の理由です。 「それではあんまりな理由だ」と思われるかもしれません。 そこで、すこしましな理由を挙げると、アンプラグドでかまわないからと言えるでしょう。アンプラグドな環境で試したことを、PCやタブレットでも試してみたければ、講座のあとでもできることですから。 ですので、環境が整えば、アンプラグドでない講座も検討の範囲には入っています。 なぜパズルやゲームなのか プログラミングや情報工学の教科書や課題には、たくさんのパズルやゲームが載っています。 それは、パズルやゲームが、プログラミングや情報工学の多くの問題を的確に現しているからです。問題そのものもですし、問題の解き方についてもです。 この点においては、講座がアンプラグドであることはむしろ利点でもあります。というのも、ちょっとしたバグによって混乱するような事態を避けられるからでもあります。 パズルやゲームという問題の解き方を形式的に考えたり書いたりする際には、疑似コードという方法もあります。その言語を実行する環境が存在しないプログラミング言語を使う方法です。 こちらについては、ちょっとした疑似コードの用意がありますし、必要なら疑似コードの規格も公開できるかと思います。   　　　* * * * と言うわけで、「なぜアンプラグドなのか」については、それで困らないからです。 「なぜパズルやゲームを使うのか」については、そこにプログラミングや情報工学の重要な問題がシンプルな形で存在するからです。

プログラムとはなんなのかということについては、ヴィルトの「Algorithm + Data Structure = Program」という著書があります。ここで、「Algorithm + Data Structure」とありますが、AlgorithmとData Structureはかならずしも分離できるものではありません。また、逆に、必ずしも一体のものでもありません。ですが、片方を選ぶともう片方も決まってくるという傾向はあります。場合によっては、あるデータ構造を選ぶと計算が速くなったり、プログラムを書くのがとても楽になったりします。 このAlgorithmについては、「Algorithm = Logic + Control」とも言われます。 「Algorithm + Data Structure = Program」のほうはまだわかりやすいかと思いますが、「Algorithm = Logic + Control」のほうはわかりにくいかもしれません。 AlgorithmとData Structureの場合のように、LogicとControlもかならずしも分離できないと考えていいのではないかと思います。そうした場合、処理 (おおむね “文” とします) の並びや、入れ子が、データをどう処理するのかというLogicに相当すると考えてみます。 では、Controlはどうなのかというと、 “文” に含まれると言えば含まれますが、 “if” だとか、 “while” だとか、手続き型の言語の場合であれば順次実行あたりがおよそ相当するのではないかと思います。これらは、 “文” として書かれるので、Logicの一部とも言えるかもしれません。あるいは、 “if” などは、それ単体ではあまりどうこうということはできず、言うとすれば複合文として記述され、また実行されます。この複合文であるというところがControlの特徴かもしれません。 複合文がControlだと考えると都合がいいのが、関数呼び出しや再帰もControlであると考えやすいという点が挙げられるかもしれません。 問題は (?)、Prologですが。 P(なんとか). という事実の場合、それは単純なLogicだと考えましょう。この事実がベースにあって、 P(x) :- Q(x), R(x). というようなルールが書かれます。この場合、まず Q(x),R(x) という部分は、 Q(x) であり、かつ R(x) であるということになりますが、この Q(x),R(x) の部分は、そのままLogicだと考えていいと思います。と同時に、 Q(x) と R(x) が同時に成立しないと P(x) は成立しないというControlでもあるとも考えられるかと思います。あるいは、 Q(x);R(x) と書くと、 Q(x) か R(x) のどちらかが成立すればいというControlであるとも考えられるかと思います。ただ、ユニフィケーション自体にLogicとControlが含まれるとも考えられるので、他の言語ほどにはLogicとControlが目には見えないかもしれません。 さて、「Algorithm = Logic + Control」であるなら、「Algorithm + Data Structure = Program」は、「Logic + Control + Data Structure = Program」と言えることになります。Scratch、ScratchJrなどでは、Data Structureの部分が見えにくいように思います。 また、ScratchやScratchJrだと — あるいは他の場合も — 、プログラムが動いたからいいという立場をとるとか、そういう立場を取らざるをえないように思います (これは、もちろん指導者にもよりますが)。プログラムを書いた経験がある人ならわかると思いますが、この立場はプログラムの検証という面から見るとかなり甘いものです。というか、プログラムを開発中の仮のテストではそれでもいいとしても、そのテストで済ませるというのは、甘いというよりも危険とも言えます。 「Logic + Control + Data Structure = Program」であるとしたら、それに応じた、プログラムの設計と検証を込みでのプログラミング教育が必要ではないかと思います。

　また、『図解 プログラミング教育がよくわかる本』〔石戸 奈々子, 講談社, 2017.〕のp. 14にはこのような箇所がある:|　なぜ? どうして?|　ロボットをつくり、「まっすぐ歩く」という動きをプログラミングしたの|　に、その通りに動かない。理由を考える 　また、p. 15には明確にこうある:|　自然に試行錯誤ができるという特徴もあります。 　ここは本文にあるこの部分に対応すると見ていいだろう:|　自分が意図する一連の活動を実現するために、どのような動きの組合せ|　が必要であり、一つ一つの動きに対応した記号を、どのように組み合わ|　せたらいいのか、記号の組合せをどのように改善していけば、より意図し|　た活動に近づくのか、といったことを論理的に考えていく力 　これは一面において試行錯誤とも言えるだろう。だが、すくなくともプログラミングにおいては必要な試行錯誤と、不要な試行錯誤が存在する。 　さて、プログラミングにおいては試行錯誤は悪だ。単純なミスはなくならないだろうから、その分の試行錯誤は除いてだ。また、モデルが明確でない場合というのもある。モデルそのものを検討する際の試行錯誤は必要だが、まともにモデルが作れていないための試行錯誤は悪だ。 　では、「自然に試行錯誤ができるという特徴」というのは、いったいどれを指しているのだろう。すくなくとも『図解 プログラミング教育がよくわかる本』の例であれば、それはデバグの範疇であり、不要な試行錯誤の一例であると思える。 　プログラミングにおいて試行錯誤ができることを勧めるのは、プログラミングについての根本の理解ができていないからとも言える。プログラミングにおいては、試行錯誤がないことが最善だ。そのためには、試行錯誤によって、かつ「プログラムが動いたことでよしとする」という立場ではなく、「プログラムが意図のとおりに動くことを論理的に証明」する/できるという立場に立つ必要がある。 　もう一度繰り返しておこう。プログラミングにおいては試行錯誤は悪だ。 　　　* * * * 公開して急なおしらせになりますが、2017年 10月 9日、13:30〜16:30に、「コンピュータを使わない、コンピュータとプログラミング入門」という講習を試験的に行ないます。 主な対象は小中学生ですが、高校生以上、大人も受講していただけます。 場所は、山梨県 大月市 市立図書館 会議室です。 参加の予約は不要です。ただし、申し込みをしていただくと、準備に際して助かります。 また、見学も歓迎いたします。 詳細というほどのものではありませんが、こちらのページを参照していただければと思います。

　2020年からのプログラミング教育の必修化に向けて、文科省が掲げている標語が「プログラミングを通して教科を学ぶ」というものだ。 　言うのは簡単。だが、実際にどうするのかと考えると、この標語は難題だ。 　教科として、国語(日本語)、算数・数学、理科(物理、化学、生物、地球科学)、社会(歴史、地理、公民)、図工、音楽、体育というあたりを考えてみよう。 　算数・数学は数式に対応するプログラムを書くことによって、簡単に実現できるように思える。よく見るのは、タートルあたりで多角形を描かせるというものかもしれない。もっとも、これは二次関数とか連立方程式とかそのあたりまでであって、高校における微積分になるとすこし面倒になる。あるいはやはり高校だと確率・統計も入ってくるかもしれない。確率・統計になると、もう表計算を使ったほうが手っ取り早いし、わかりやすいだろう。それも、スクリプトもいらない。セルに埋める関数で充分だ。 　理科(物理)も、ニュートン力学の初歩のあたりは、どうにかなるだろう。だが、直線での等加速度運動あたりから、数学で書いた微積が関係してきて、面倒になる。 　だが、この2つはまだわかりやすいほうだ。 　理科(地球科学)はどうだろう。地球の深さによる圧力、重力、熱になると、一筋縄ではいかない。地球の熱収支であればなんとかなるだろうが、これは表計算を使ったほうがわかりやすいし手っ取り早い。大気圏の状態についてはどうだろう。天気予報でもやらせたいのだろうか。そうでなければ、対流圏などの知識を扱かうという問題になる。 　理科(化学、生物)はどうだろう。これらを「プログラミングを通して」という原則で学ぶなら、偏微分方程式を扱かえる必要がある。中学生にはたぶん無理だろう。とすると、これも知識を扱うという問題になる。 　社会(歴史、地理、公民)はどうだろう。まぁ、公民については、社会秩序うんぬんをシミュレートさせるということもあるかもしれない。でも、それも表計算で充分だし、むしろわかりやすいだろう。歴史と地理はどうだろう。どうにもわからない。表計算を知識ベースとして使うくらいだろうか。 　なお、「理科 (生物)」や、「社会 (いろいろ)」は「捕食-被食関係」だとか、その「[ロトカ・ヴォルテラの方程式」なんかをやってみるということもあるかもしれなり。ですが、考えてみればこれも表計算でできます。 　図工はどうだろう。タブレットの中の謎物質でなにかを作るということはあるかもしれない。だが、それは粘土でやるのとどう違うのか。あるいは描画ソフトで絵を描くということもあるかもしれない。実際に描画するほうが得意な人もいるだろうし、描画ソフトを使うほうが得意な人もいるかもしれない。あるいはARを通した表現ということもあるかもしれない。だが、そうなるとプログラミングが主ななのか、図工が主なのかわからなくなる。小学校であれば、描いた絵のパーツを動かすというようなところでお茶を濁すかもしれない。あぁ、昔(今も)のスライドのように、なんか目に優しくないのが大量生産されるのかと思うと気が重いですが。 　音楽はどうだろう。タブレットに鍵盤を表示し、というのは「プログラミングを通して」という題目にはあわないだろう。とすると、データを打ち込んでの演奏くらいだろうか。まさかフーリエ変換を使って、楽器の音を再現するなどということはできないだろう。 　体育はどうだろう。ダンスの機会もあるそうだから、音楽の再生と、ライトの制御なんてことはできるかもしれない。 　ここまでは、まだ、なにか方法があるかもしれないものだ。 　問題は国語(日本語)と英語(あるいは他の外国語)だ。いったいどうやって「プログラミングを通して教科を学ぶ」のだろう。まさか形態素解析や統語解析のプログラムを書かせるわけでもないだろう。用意された用例コーパスから、語句の用例を求めるとかだろうか。それもかなり難易度が高い。あるいは電子辞書を引くだけだろうか。現実的なのは、用例も含まないわけではないが、単語帳として使う方法だ。これなら表計算で充分ではある。ただしプログラミングを通して教科を学ぶという題目からは離れるが。 　まさかとは思うが翻訳ソフトを作るとか、使うということはないだろう。既存の翻訳ソフトはまだまだ信用できないし。 　あるいはスライドを使ってなにかをするというのはあるかもしれない。でも、それはプログラミングを通して教科を学ぶと言えるのだろうか。 　といったところで考えると、「プログラミングを通して教科を学ぶ」というのは、かなりの無理難題であるように思える。実際にやるなら、表計算で計算をするか、表計算を知識ベースとして使うかで、かなりのことが済んでしまうようにも思える。もっとも、表計算だとプログラミングにおいてあちこちに出てくる、探索を扱うのはすこし難しいかもしれませんが。知識ベースとして表計算を使うなら、「もういっそのことProlog使う？」とも思えます。 　　　* * * * 公開して急なおしらせになりますが、2017年 10月 9日、13:30〜16:30に、「コンピュータを使わない、コンピュータとプログラミング入門」という講習を試験的に行ないます。 主な対象は小中学生ですが、高校生以上、大人も受講していただけます。 場所は、山梨県 大月市 市立図書館 会議室です。 参加の予約は不要です。ただし、申し込みをしていただくと、準備に際して助かります。 また、見学も歓迎いたします。 詳細というほどのものではありませんが、こちらのページを参照していただければと思います。