プログラムとはなんなのかということについては、ヴィルトの「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」であるとしたら、それに応じた、プログラムの設計と検証を込みでのプログラミング教育が必要ではないかと思います。