プログラミングを学びはじめたころ、わたしにとっての最初のハードルは分岐でも繰り返しでも関数でもなく、型でした。コードを書いたらすぐに動かしてみたいのに、暗黙の型変換はよくないとか、文字列のつもりなのに数値が入ってきてるとか、細かいことをチクチク指摘してきて、あまり面白くありませんでした。まるでプログラムが敵対的な意思をもっていて、動こうともせずにここがダメだからやりませんと言っているように感じられたのです。一家に一台の時代、Pentium III のノートパソコンを独り占めしていた中学生のころのことで、思い通りにならないと面白くない年頃だったのでしょう。
プログラミング教育に携わっていた経験から言っても、型を説明するのはむずかしくて、一斉講義であれば極力避けますし、個別の対面指導であれば、型は難しいよねと寄り添ってから、いまやりたいことと、次にやることのイメージを具体的にしてあげて、学習意欲を損なわないように助けるという方法をとると思います。型を教える特効薬はなくて、アクティヴラーニングで乗り越えよう、ということです。
コンピューター、正確にはチューリングマシンは、長いテープとその上を移動するヘッドのようなものでできていて、テープのひと区画を読み取ったり書き換えたりしながら動くわけで、別に型は必要ありません。ただし、チューリングマシンは頭がよすぎる故の弱点があって、計算を終えることができるかどうかを自分自身で検証できません。そこで、チューリングマシンより単純で、そのかわりにチューリングマシン以上の検証ができる計算モデルを導入することで解決しようとしました。型はその流れのなかのひとつなのだと思います。この考え方は計算機科学的すぎますが、結果的にソフトウェアの保守性を維持したり、エディタですばやく補完が効いたり、エンジニアリングにおいて都合がいい機能を支えているのです。
計算機科学に限らず、科学的・理論的な議論では「実数Rの要素a, bが以下の性質をもつとき」のような表現があります。これはふつうは集合論だと読み取るのですが、型と考えてみるのもおもしろいと思います。たとえば2次方程式は中学数学では解なしだったとしても高校数学では複素数解だったりするわけで、これは型によって振る舞いが変わる例として親しみやすいと思います。英語でも、種としての犬は Dog で、道端で散歩している犬は a dog なので、集合と要素、型とインスタンスという構造があります。こうやってほんの少しだけでも計算機科学のことを考えながらプログラミングしていると、一片の花びらを見て桜という集合・型を意識するような計算機科学的な世界観が広がっていって、プログラミングがますます楽しくなっていく気がします。
