僕とKuwataさんの連絡は、口頭を除けば公開チャンネルを流れる状況になってしまいました*1（最近は内部ドキュメント書いてないっす）。それで、そろそろ型推論のやり方を（公開で）書かないとなー、と思うのです。が、気になることがあるので、ちょっと愚痴っぽい話をここに書いておきます。
「Catyについて僕が語ると、プロモーション上よろしくない」と忠告してくれる人がいます。これは例えば、Catyのターゲットユーザーであるデザイナ／Web制作者に対して僕が、「型システムがドータラ、モナドがコウタラ」みたいなこと話したら、ドン退きされて悪影響があるだろう、と。そりゃそうでしょうね。よくわかります。やりませんよ、それは。
しかし、技術者に対しては、Catyの内部構造や背景理論について僕が語ることになにがしかの意味がありそうだし、できるだけ語りたいと思っています。それによって直接間接に、「Catyは小難しくて使いにくそうだ」という印象が拡がるとしたら、それはとても哀しい。望ましくない誤解が生じているってことですから。
Catyは小さな学習負担*2で使い始められて、間違いをしにくく、間違ってもソフトウェアがそれを検出するようなシステムを目指しています。標語的に言えば「優しくて易しい」システムね。
一方で、Catyの内部構造が容易に理解可能かというと、そういうわけではないです。ですが皆さん、ちょっと冷静に考えてください。ユーザーにとっての難易度と内部構造の難易度が比例関係にあると思いますか？ 同じ機能を提供するソフトウェアなら、ユーザーに十分な知識と技量を要求して、「ユーザーは非常に注意深くて間違いは犯さない」と仮定したほうが作るのが簡単ですよ。
Catyは、「ユーザーは知識と技量をあまり持たず、勘違い／不注意／悪意などから間違いを犯すだろう」と仮定しているのです。ユーザーが出会うかもしれない困難を、できるだけソフトウェア側で吸収しようとしています。ソフトウェア側で困難を引き受けるのだから、作り側が問題解決を事前にしなきゃならないでしょう。これ、あんまり簡単じゃない。たいした考えもなしに使えるソフトウェアを作ることが、たいした考えもなしにできますか？
もし、ユーザーにとっての難易度と内部構造の難易度が比例するなら、不勉強で頭が悪いヤツが作ったソフトウェアほど「優しくて易しい」ってことになりますよね。そんなことあり得ないでしょ。使う側の負担を減らしたいなら、作る側がチャント、チャントチャントチャント考えなきゃダメでしょ。考えるってのは問題を解くことであり、問題を解くには基礎知識と思考のノウハウとエネルギーが必要です*3。
もちろん、僕らの能力不足から解けない問題が残ってしまうこともあるでしょう。でもね、そこに問題があるのに問題を解かなくてもいいことを正統化する理屈なんてないと思うぞ。ときには、最終的に解けないこと（敗北）を認めることになるにしても、解こうとしないとね*4。
Catyの内部構造がcomplicatedってことは全くないけど（complicatedなら破綻します）、設計判断と実装のあいだの関係を理解するには、それなりに「モノを考えるための枠組みと力」は必要です。「優しくて易しい」って課題は、ホントに難しいのですから。
