学校でのプログラミング教育について

1 まえがき

他記事のなかでもプログラミング教育について触れてきましたが、
ここで一度まとめておこうと思いました(注釈で述べているパターンが多かったです)。

昨今のプログラミングの義務教育化に伴い、色々なご意見が飛び交っていますが、
自分もそれについてはいくつか思うところがあります。

対象は大きくは二点あって、(1)教育でネタとする題材と、(2)使う言語です。
(1)については、仮に教育でそれをネタにした場合に、
うまくいけばA.I.資産が手に入るというプランを思いついたので、シェアしたいと思います。

2 題材

題材としては、このブログで何度も出てきているPDFリーダーです。
かなりいい線いっていると思っています。
理由は幾つかあります(これまでに書いてきたことと重複する点もあります)。
大きくは学習者のモチベーション、とそれ以外の副作用、特にA.I.的な観点での重要性について説明します。

2.1 学習者のモチベーション

2.1.1 まだ他にない類のネタであること

プログラミングを覚える際の題材としては、既に存在しない、なので自分で作る必要がある類のネタがいいと思います。
ゲームみたいなものをネタにすることも考えられますが、昨今、スマートフォンやコンシューマのゲーム機、PCでいい感じものがすでにあるわけで、
それを自分でもつくってみるというのは、モチベーションとして少し効果が薄いと思います。
その点、このブログで紹介しているPDFリーダーは自分が知る限りでは存在しないので、
有用性を学生さんが感じれば、モチベーションの観点で効果は高いと思います。
以下、このPDFリーダーについて学生さんが有用性を感じ、自分で作りたくなる要素を挙げてみます。

2.1.2 有用性1 ー他の教科の教科書に適用可能

他の科目の教科書が電子化(PDF化)されていれば、そちらにプログラミングの授業でつくったものをすぐに適用できます。
よく教科書にマーカーを引いて勉強する人がいますが、マーカーを自分で引くのは大変ですし、
学習が進むと、マーカーで強調したい箇所は変わると思いますが、そういうのは現実のマーカーではできません。
このPDFリーダー技術であれば、部分一致等で少ない条件で網羅的にマーカーを引けますし、
一度書いたマーカーを消したりできます。効率よく勉強できる、それも各生徒ごとに自分にとって一番いい読み方ができるように
自分でPDFリーダーをチューニングする=勉強がやりやすくなる、そのためにプログラムの勉強ももっとやってみようと思う、うまいサイクルができると思います。

2.1.3 有用性2 ー英語教育にも有効である

着色することで、英語が読める人間が見ている単位(名詞句単位)で英文を眺めることができるようになります。
英語はスペースで区切られていますが、本当はそのスペースの位置ではなく名詞句などの単位で見ている気がします。
一応、私も英語は読める方だと思っていますが、名詞句単位でみていると感じています。

previous arrow
next arrow
Full screenExit full screen
Slider

 

2.2 教育外での副作用

以下は、このPDFリーダーを学校教育のネタにした際に発生する副次的な効果、A.I.という観点で重要な副作用自体と、そこに向けて自分が考えているシナリオです。

2.2.1 構文解析については出版社が手で行う

名詞句という単位で完璧に着色されていないと効果が半減する一方で、
名詞句を認識する構文解析技術はまだまだ不十分ということです。
ただし、教科書に限って言えば対象となる文書は絞られるため、出版社側が予め完璧に構文解析されたものを、
手で用意することが可能と思います。当然、何もないところからやるのはきついので、
機械的に構文解析したものを手で修正するという形を採れば現実的だと思います。
そうすることで、学生さんは完璧に構文解析がなされている教科書を相手に、自分でプログラミングしていき、
名詞句単位で着色した際の100%の効果を得ることができます。

2.2.2 将来的なA.I.資産への布石

さらに、上のやり方(出版社、文章の書き手が正確な構文解析結果を与える)は重要で、
それも今流行りの画像認識とかの機械学習とは別路線の、
人間の言葉が理解できるA.I.みたいのをやろうとした時には、構文解析による句構造の特定が必要条件になってきます。
そしてそれは今の技術では不十分だと見ています。名詞句すら完璧には特定できていません。
もし、このPDFリーダー的なものが普及して、全部とは言わないですが硬い文書、
例えば論文や教科書などについては、出版する前に著者が機械的に構文解析されたものを手で直しておく、
というフローが慣例として成立すれば、上の意味でのA.I.研究におけるいいサンプルを提供することにもつながってきます。
その辺り、プログラミングの教育という目的以外にも大きな大きな戦略的布石になってきます。

3 対象言語

以上のとおりに、このブログで紹介しているPDFリーダーが教育のネタとしていい線いっていると思っているわけですが、
それでは、どの言語でやるか、という選択も大事になってきます。
自分は関数型プログラミング言語を教えて欲しいと思います。対象言語はHaskellかScheme(LISP)です。
Schemeは自分も学習段階で、使いこなした、というレベルではないので、以下はHaskellを対象にした話です。

3.1 題材であるPDFリーダーをつくる観点での利点 -構文解析器(parser)を書きやすい

名詞句という最小の単位については書き手がなんとかするとして、その上のレベルでの構造については、
依然としてプログラマ(学生さん)が自分で抜き出す必要があります。
具体的には、例えば教科書の文中で第一の〇〇とか第二の〇〇とか第三の〇〇、みたいな並列要素が出てきた際に、
「第(数字)の(名詞句)」みたいな一連の塊を機械の側に認識させたくなる局面があると思います。
その際には上のような規則的に現れる構造を解析する解析器、これをパーザー(parser)と呼ぶのですが、
それを書けるようになる必要があります。正規表現だと難しくなってきます。更に今のは文字列自体ですが、名詞句区切りにページの座標情報や、それよりも上位の情報、例えばこれは武将の名前だとかそういうのが付与されていると正規表現では手も脚も出ません。
その点、Haskellはparser combinatorという概念を駆使して、小さいparserを組み合わせて大きいparserを作っていく、
ということが簡単にやれます。興味のある方はhackageのparsecライブラリを見てみてください。

3.2 他教科(数学)との連携

Haskellは型理論という論理学だけでなく、圏論という数学にも立脚しています。
この圏論がどうこうというのは難しすぎるので義務教育の範囲では触れるべきではないと思いますが、
重要なのは、数学と親和的である素地があるということです。
一例としては、高校で習うフィボナッチ数列をHaskellで書いた場合は以下のような感じになります。

fibonatti 0 = 0
fibonatti 1 = 1
fibonatti n = fibonatti (n - 1) + fibonatti (n - 2)

高校の数学の教科書に書いてある表記と一致しているのが分かります。
更にリスト内包表記という概念がありますが、例えば3の倍数(nsとします)をHaskellで表現した場合は、以下のようになります。

ns = [n | n <- [0 ..], mod n 3 == 0]

mod n 3というのは3でnを割った時の余り、
n <- [0 ..]というのは、n ∈ Nというのを表しています。Nは自然数です。
数学に慣れている人なら、数学表記そのものだとわかるはずです。他言語でもリスト内包表記の構文を持っているものがありますが、
自分はそちらを先に見た際にはチンプンカンプンでしたが、Haskellの表記を見て初めて理解できました。
Haskellが最初にリスト内包表記という概念をプログラミングの世界に持ってきた?みたいです。やはり数学を意識している言語なのだと思います。
他にも、where節なる構文(非常に重要な構文)がHaskellには存在しますが、英語の数学の教科書を読んでいるとwhereはあちらこちらに見られます。
このように、Haskellと数学は非常に親しい関係にあります。
さらに実は物理学とも関係してくる面白い領域がHaskellにはあります。
微分方程式を解くとかそういうのではなく、
時間的に相互に影響しあう変数(Behavior)と瞬間的に値を変える(Event)という2つの概念をつかって、
物理系を表現しようとする試みです。これはFRP(Functional Reactive Programming)という領域になります。
実はこのPDFリーダーのようなGUIを表現することを主要な目的とした領域です。
まだまだ速度的な問題点があり、自分はPDFリーダーで使いませんでした(途中まで使っていて最後は止めました)が、
今後は改善されてくると期待されます。
更にロボット工学にも、応用されていたりします。Yampaというライブラリが一例です。

3.3 新しい感があること、実際に新しいこと

ここ数年(2011年あたりから?)Haskellを含む関数型プログラミングスタイルが再注目され、
他言語にも、関数型プログラミング言語が用意しているギミックが少しずつ輸入されています。
このように、時代の最先端を走っている感があります。未来を担う世代には、最先端に触れていて欲しいです。
学校教育ですぐにやらないにしても、こういう最先端を最後にはやってもらう感を出し、
そっちを逆算しながらカリキュラムを組むというのが大事と思います。

3.4 将来性

 

3.4.1 陳腐化するか

マイナー言語だと廃れる危険性がありますが、Haskellはその筋(関数型プログラミング)の学者さんたちが後押ししていますので、おそらく廃れないと見ています。
Haskellは最近注目されてきて、本(日本語も英語も)も少しずつ増えて来て、次世代の言語だ、
みたいな扱いを受けています(上でもそう書きました)が、実は言語自体は1990年代に生まれています。
その間、廃れることなく続いているのでおそらくこれからも廃れることはないと見ています。
さらに、仮にHaskellが言語として陳腐化したとしても、そこから学んだことは無駄にはならないです。
これは他言語にも言えることですが。ただし、実際にHaskellを業務で使わないにしても、
考え方を普段使いの言語に応用している、という意見はよくあります。そしてそれは普段使いの言語とは考え方が全然違うために、逆に大きく参考になったという場合が多いようです。

3.4.2 数学的な最適化

map, fold, filter, zipなどの数学的に素性のあきらかな関数でプログラムを構成しておけば、
数学的に同じ結果になるという証明がなされている定理については、コンパイラが最適化をかけてくれます。
有名なのはFusionの技術とか、Recyclingなどです。このあたりの証明については、
このブログでも何度かネタにしているAgdaのような定理証明の自動化の技術がこなれれば、
数が次々と増えてくることが期待されます。それにより、前に書いたコードがいきなり早く動くという可能性が出てきます。
実際、ここ数年のHaskellコンパイラ(GHC)の進化により、以前書いたコードが早くなったケースがいくつかあります。
spacemacsで型エラーチェックをかけて進めた際に、コンパイラ側が「この部分をどうしてこう書かないの?」という提案をしてくれるくらいです。

3.5 生産性

抽象度が高い=少ない労力で幅広い範囲を網羅できるということになると思います。〇〇算と方程式の関係に近いと思います。
高階関数+ラムダ式+where節の組み合わせだけでも、相当色々なことが簡単に表現できます。
その分だけ速度を犠牲にしている側面がありますが、数値計算や画像処理といったシビアな領域でなければ、
昨今のハードウェアの性能向上により、実効速度の観点で人間が違いを感じられる領域は徐々に減ってきています。
上に述べましたとおり、数学的な最適化が自動でかかるので、むしろ複雑な領域では有利といえます。
こういう最適化は、最初からそういう関数で構成してくことを前提としていて、
そういう最適化が必須と考えている言語だからできることで、後からその機能を追加した言語では難しいと思います。
更に、型安全とかありますので、ミスが少ないです。さらに少ないタイピング量で表現できる範囲が広いため、
タイピングミスも少なくなってきます。

3.6 足りていないライブラリ(逆にそれが良い)

上のPDFリーダーでも述べたことですが、既にこなれたライブラリが存在する状況では、
学生さんがわざわざ自分で実装するという気力がわかないという気がします。
宿題とかにしても、ググれば出てくるコードをコピペするというのでは、
それはそれで何かをつくるために最善?の行動を学ぶ、という意味では力がつくわけですが、
何かを失っていると思います。特に他人がやっていないことを自分でやる、という観点での力がつかない気がします。
そういう意味だと、Haskellはまだまだ普及していないので、ライブラリが足りていないですが、逆に教育的にはメリットになります。
正確には、筋のいいライブラリがHackageに用意されているのですが、それを使って応用した類のものが余りないです。

3.7 教育(時間がかけられる)だからこそできる

Haskellを学んでみたいという潜在的需要はプログラミングを既にやっている人の中でも存在すると見ています。
ただし、Haskellで何をつくるのか見当がつかないという理由とともに、
プライベートでHaskellを勉強する時間がとれない、というのもありそうです。
その点、教育では時間をかけられるわけで、そういう時間だからこそ、
仕事を持った後ではやれないようなことに時間をかけて欲しいです。
他のメジャー言語はそもそも企業から有用性があるとされており、仕事を持ち始めてからでも、
仕事内で覚える時間が十分にとれると思います。

他にもあった気がしますが。とりあえず思いついたものだけ書きました。
あとで、追記していく予定です。

Author: polymony

Created: 2019-06-27 木 07:13

Validate