Scribble at 2022-09-06 09:24:41 Last modified: 2022-09-07 18:24:55

いま命題論理学やブール代数といった、quantification の理論を含まない論理のテキストを作っている。もちろん既存のテキストは、われらが戸田山元会長からエンダートンに至る色々な著作物を参考にしているのだが、やはり平易で俗っぽい言葉を使ったり、長々と文章を書き連ねるという表面的な特徴だけでは、その解説や説明や議論が〈適切である〉とは限らないし、実は〈分かりやすい〉とすら言えないと思う。特に、たいていの教科書では形式言語として導入する L のような系を、僕ら自身の推論や判断からボトム・アップ式に組み上げるような方法の説明は、表面的にどれほど「分かりやすい」文章でも、たぶん不適切だと思う。

それは、僕らがプログラミング言語を学んだ経験を思い返すと分かるかもしれない。そこでも人によって習得した経緯は異なるだろうが、たとえば自分たちの常識とか感覚を基礎にしていては、等号記号を LET として扱えるようにはならない。$id = $_POST[ "id" ] の等号記号が「等しい」という理解のままだと、では $id はどこで定義されたり値が入るのかという疑問が残ってしまう（なので、LET という操作を目的として等号記号を使わない言語もあるし、あらかじめ var $id のように定義しておかないとエラーになる言語もある）。

言語、とりわけ自分たちが何ほどか或る言語を習得して使っているうえで別の系なり規則を学ぶときには、自分のもつ知識や経験に照らして納得できるかどうかという基準だけで理解しようとしてはいけないものだ。それでは記号操作や言語処理としての素養が全く向上せず、手持ちの道具だけで全てを取り扱おうとする傲慢な思考や認識へと誘導されるだけである。どのような新しい言語、学問、情報、そして体験でも、人の見識や理解を広げたり改めるチャンスだ（場合によっては歪めたり間違った内容に変更してしまうこともある。カルト宗教や陰謀論にハマる人もいるわけだ）。そこでは、見知らぬ道場へ招かれて初めて目にする流派の型を眺める武闘家のような態度が求められる。そして、そういうことは何も北斗神拳伝承者でなくても誰だってできることなのだ。

そのために活用されているのが、いま IT 業界でも盛んに活用されている gamification である。いま使われている大半のプログラミング言語は、少なくともチューリング完全であるという要件を満たす限り、大抵の与件や仕様を満たす設計やコーディングにおいてパフォーマンスつまり非機能要件としての差はあっても、機能要件としての差はない（言語 A で実行できる処理が言語 B では原理的に実行不能であるような処理などない）という意味で「同等」である。すると、それらのどれをどう使うかは、簡単に言えば与件から考えてパフォーマンスの何を優先するかによって決めてよいし、そこでも大差がなければ学習効率やプログラマの経験、もっと言えばプログラマの好みで選んでもいいはずである（もちろん同等の成果が出せる力量をもっているなら、だ。プログラミング言語として同等であっても、それを使うプログラマが或る言語についてはよく知っていても他の言語については知らないということはいくらでもありうる）。

同等な言語について学ぼうとするプログラマは、習得して有効に使えるなら同等の成果を出せると期待できるわけだが、必ずしも自分が知っている言語のルールをもとにして新しい言語の文法や記号の意味を理解してはいけない筈である。よくあることだが、言語によっては同じ記号で異なる機能があったり、いわゆる副作用がある場合とない場合で仕様が違っていたりするからだ。そういうことを弁えていれば（つまり、それを知っているのが教科書の書き手ということになる）、新しい言語を習得するにあたって、まずはその言語でやれることを見せたり、記号の正確な役割を丁寧に説明するだろう。読む人が知っている言語ではなかった副作用があるかもしれない関数について、〇〇言語でいう●●関数のようなものだ、などと簡単に説明する通俗的な教科書も多いが、せめて注釈で正確な解説を補足するとか、「更に正確な効果は公式マニュアルを見よ」などと書くべきであろう。教科書だから〈ここまでのレベルでいい〉と言って正確な情報を無視するのは、実のところたいていの場合において、教科書の筆者自身がその程度しか理解していないからだったりするのだ。（もちろん自戒の趣旨も含めて）馬鹿や無能が教科書を書いてはいけない。