――それでは最後のテーマに入ります。関数型デザインとオブジェクト指向について、です。

カテゴリ

増田：
認知科学でカテゴリとプロトタイプというのは（羽生田：そうそう）、ものすごく大きな画期というか転換点だったんで、だから僕なんかやっぱり、カテゴリの考え方っていうのはそっちから学んでいるんですけど…で、面白いなと思うのは、これは誰かが言っているわけじゃないんですけど。

増田：
あれば認知科学で言っているカテゴリ論とまさに一緒なんで。
私なんかはそうやって見ているんですよね。

羽生田：
だから英語でカテゴリという名前で、あの数学理論というかメタ数学理論を呼ぶことにしたのは当時は大胆なように見えたのかもしれないけど、今から振り返ると自然科学への応用だけでなく哲学や社会科学への適用なんかも含めて大きな射程を捉えている。
そういう意味でカテゴリ論＝圏論の創始者のマクレーンは偉かった。

増田：
うん、そう。だからね、数学そのものは数式は得意じゃないんだけど、説明とか、概念の、論文のアブストラクトみたいなところはね。言語学的には面白いことがいっぱい書いてあるんで。

羽生田：
要素としての元を集めて包み込んだら集合になるっていうのはその人間が空間にいて箱で区切ったものを考えるというか、（増田：
そうそうそうそうそう）その中に自分が包まれているようなイメージで考えるとか、そういうことと同じだということで。

増田：
そうそう、そういうこと、そういうこと。そういうことですね。
だからまさにね、イメージスキーマ。それが身体性を伴ったイメージスキーマなんですよね。
内側と外側とか、入れるとか出すとかっていう。

羽生田：
なんか結局、コレクションにオブジェクトを入れるとかっていうこととまさに同じこと（増田：そうそう）。それが集合論みたいな形式化されることもあるし。

イミュータブルと関数型

増田：
逆のというか、別の言い方をすると、認知科学論的には、そういうところに刺さった表現じゃないと、あんまり普及しないというか、すごいアイデアとしてはいいのかもしれないけど、人間のもともと持っている素の感覚にどっかで共鳴しないと、なんていうのかな、理論として広まらないみたいな
それで、さっきの最初の方に出た話で、すごく興味があったのでくいついちゃうけど、関数型と、イミュータブルなクラスっていうのは本質的に違うっていうみたいな、とらえ方なんですか。

羽生田：
いや、そうじゃなくて関数型プログラミングとか関数型何々って言ってるのは緩くとらえればイミュータブルなデータ構造を使ってそれに関数をどんどん適用していって計算を進めていくっていうことで。
ただ、オブジェクト指向プログラミングだと、関数型プログラミングをJavaでやることもできますけど、やっぱり状態は使わないにしても、何でもデータに関数を適用してそれをこう積み上げてすべてのシステムを組むっていうふうにはしないじゃないですか。

増田：
ああ、関数の組合せっていう、あ、なるほどなるほど。もっとほんとに根本的にというか素朴なモデルとして関数をつないでいく。（羽生田：そうそうそうそう）
f、gっていうようなものをつなげていくという感覚ではなくて。

羽生田：
やっぱり、状態は持たせないけど、まあざくっ、ざくっとオブジェクトを置いて、で、それをくみ上げていくっていうイメージで、やっぱりシステムを組むじゃないですか。
関数屋さんたちはそうじゃなくて、全部関数をどんどんアプライしていって終わるんですよ。（増田：あーはいはい）
やっぱりそこでシステムの組み方に関する感覚が違うと思うんですね。

増田：
どこだったかな？TAPLだったかな、松下本だったかな。それって、tとfですっていう話があって。
（tとfを両手の人差し指で示しながら）tを軸にしてfを整理しに行くのか、fを軸にしてtを整理しに行くのかっていうアプローチの違いがありますっていうことはどっかの本に書いてあったんですよね。

羽生田：
あ、そうなんですか。tとfってtrue？

増田：
タイプと、ファンクション。

羽生田：
ああ、わかりました。なるほど、そうそう。trueとfalseかと思って

増田：
タイプとファンクションていうのが要するに

羽生田：
わかりました。うん、なるほど。そうそうそう。
だから、オブジェクト指向っていうのは、そういう意味ではｔつまりタイプなんですよ。モジュール化の単位がｆというよりはｔにフォーカスが当たっている。（増田：そうそう）。tがあってfを整理っていう（増田：そうそう）。
やっぱりね。状態は使わないけど、やっぱり型が。

増田：
あくまでもtなんですよ。

業務と型

羽生田：
そうでないと業務を整理できないと思うんだよね。

増田：
それはね、僕は個人的には業務の場合はやっぱりtから入るのが合理性があると思っていて、一つはやっぱり種類がめちゃくちゃ多いっていうのがあるじゃないですか。だからtから抑えにいかないと、fを軸にしてもやっぱtがっていう話が１つと、数学的には、整数って範囲って変わらないじゃないですか（羽生田：はい）でも業務って、数量って言ったときに

羽生田：
基本的には有限の世界で、しかもね（増田：かつ、変わるんですよね）。何個っていうところが商売上重要ですからね

増田：
そうそう。それこそ、個数の限度もあるんだけど、６個単位じゃないと扱えないとかね。あるいは６個単位じゃないと扱えないんだけど１個バラにした場合は特別なルールでなんとかするって出てきちゃう世界なんで。そうするとやっぱりそのタイプのなかにそこら辺のいやらしさをファンクションとして閉じ込めておいてあげないと、そうしてあげれば、なんというか安定した部品として使えるっていうね。

羽生田：
やっぱり言語学の話ですよね。だから名詞に着目するのか、動詞形を考えるのかといったときに、まずは名詞で安定した体系をつくった上で動詞を考える。表現可能性という意味では最終的にはどちらでも基本的には同じなんだけど、実践的に敢えて、名詞的な語彙つまり型の分類整理を意識する。

増田：
実践的に（羽生田：実践的な話ですよね）、限られた時間の中で、どんなアプローチでどんな整理をかけるかっていうかは、tでまずは押さえて、tをつかってfをセットにしていくっていう方が、安定感が出てくるかなっていう。
ただ、例えばなんだけど、IoTでストリーミングしているやつを処理するっていうようなモデルであったら多分、関数をずらーっと並べてどんどんどんどん食わせながら整理したほうが、わかりやすいし、たぶん変更にも強い。そういうことなんだろうと思うんですよね。

羽生田：
だから構造が複雑なものというよりは、大量にあって結構フラットなものだったら関数のほうを（増田：関数でやっていくっていう）ことになるのでしょう。あくまで対象世界の特性によって使い分けるものでしかない。
今後、オブジェクト指向っていうものと関数型っていうものがどっちも視点の違いってことで、組み合わせていくっていうことしかないと思うんですけど。

増田：
あの、そうですよね。アプリケーションの中で関数的に片づけちゃった方が分かりやすくて簡単なんじゃないのっていうことは実際あると思うんで、どっちかでやると。
何がなんでも関数だとか、何が何でもオブジェクトでやるってことではないと思うんですよ。

羽生田：
そうなんですよね。

増田：
まあたとえばなんていうかな、今時ETLっていうかどっかとサービスつないでデータ取り込んで、こっちにぶちこむみたいなところをオブジェクト指向設計と実装が必要か、といわれたら、やっぱり答えはノーだと思うんですよね。やってもいいけど。少なくともあんまり経済的な合理性はないっていう。

羽生田：
そうですね。役に立つ型もどんどんかわっていっちゃうだろうし。

増田：
さっきのストリームなんかで、ファンクションで済ませられないものは、ちょっとしたところの、このユーザーだけ特別ですとか、このユーザーだけ利用頻度が変わりましたっていうことに対して、個別のそういうちょっとしたデータの違いに対してルールを書きに行かなきゃいけないんで、たぶんその、フラットにデータが、何ていうかな、等質性のあるデータをどんどん大量にさばけばいいっていう世界ではないんで、そこらへんが多分適用領域の判断基準なのかなって気はしますけど。

羽生田：
あとやっぱり型って、型理論とかむずかしいからそこまでいかなくてもいいけど、自分がどういう意図で対象を捉えようとしているかという宣言なわけだから、型なしよりはやっぱり型を明示したほうが他人にとっても良いと思う

業務と型のとらえ方の変化

増田：
実はわたしが型について今日話題にしたいと思った経緯として、旧TwitterのX上での議論に触発されたというのがあります。Rubyの開発者の松本さんに対して、型理論もわかっていないでプログラミング言語の良い悪いの議論はできないと絡んだ人がいたんですね。その議論の経緯はいろいろあって今は一応落ち着いているんですけど。

羽生田：
そんなことがあったんですね。

増田：
そして、その議論の後、そのもともとの論戦とはまったく別に、まともな議論として、型のあるなしの是非とか、自分は型というものをこうとらえているよ、とかっていう割と健全な情報が流れるようになったんです。

羽生田：
あ、そういう背景があるんだ。なるほどね。
だから、型って、業務の中でとらえ方がだんだん進化していって、対象に対する解像度が上がっていくわけだから、型を一回定義して終わりっていうわけじゃないと思うけど、その時点での理解はちゃんと型にピン止めしといたほうがいいと思う。（増田：というかね、もう）柔軟にどんどん変わっていくんだから、めんどくさいって言われてもね。

形式手法としての型

増田：
型は、そもそも何であるの？っていう話になったときに、これもTAPLの導入部分に書いてあるんだけど、要するに、ある制約を与えることで、プログラムが健全になるっていうか、安定するんです。そういう道具ですっていう話。
型があることによって、意味を伝えるという。
ある意味、TAPLはそれを副作用というか副次的な効果でそれを言っているんだけど、なんていうのかな、非常に現世ご利益的なね、

羽生田：
それ、だれが言われている？

増田：
TAPL:型システム入門（Types And Programming Languages：訳　https://www.ohmsha.co.jp/book/9784274069116/）の、一番最初の導入部です。

羽生田：
一番最初に書いてあるんだ。

増田：
あともう１つ、そこに書いてあったとおもうんだよな。最も軽量な形式手法は型なんですって書いてあるんですね。（羽生田：たしかに）
だから私はその立ち位置なんですよ。

羽生田：
ほんとにね、型チェックがあるなしで全然違うから

増田：
そうそう

羽生田：
あとやっぱり記述、何が書いてあるかを理解するっていう（増田：そうそう）のに、型があったほうが絶対に直感的にわかりやすいよね。

増田：
ドキュメントとしての型の記述、型の意味っていうのはすごく大きい。
だから形式手法、なんですよね。

羽生田：
あとやっぱりどんな型を使っているかっていうのをリスト化しておくだけで、その、「同じ言葉」の共通語彙の一番、共通語彙がこれだって。だから、これを組み合わせて、なんでもできますって言える（増田：
そうそう）わけだから。

増田：
語彙なんですよね。本当に、表現すると語彙なんですよ。

羽生田：
そう考えれば自然言語でやっていることを（増田：そうそう）、素直にプログラミングにも使っているってことになるとおもうんですけど。

増田：
プログラミング言語の型がある言語とないっていう言語があるとかいう議論から行っちゃうとなかなかそっちに行かないんだけど、実用面から考えたときに、アプリケーション特化の型を用意しておいた方がプログラミングが楽になるよねっていうすごく単純なことで、これ実は私も記述を初めて見たのは、Simula67のマニュアルなんですよね（羽生田：あー）。
汎用的な機能を持った言語をどうやって特定のアプリケーションで使いやすくするかといったときに、クラスというか、独自のアプリケーション固有のクラスの型を宣言してやるとそこのギャップがブリッジできるよ、というようなことが書いてあって、あ、これもう本当そうだよなって。
だから、今まさに私がやっているのはJavaという汎用言語を使ってアプリケーション特化の型を値オブジェクトとか作って安定したものをわかりやすく作るっていう。変更にも強い、みたいなね。
型…私自身はプログラミング言語何でも手を出す方なんで。JavaScript、Ruby、むかしのPHP、Perl、Python全部手を出したんだけど軒並みだめなんだよね。もう、体質的に、実行時エラーにめちゃくちゃ弱い。（一同：笑）

羽生田：
面白い

――まだまだ話が尽きないと思いますが、この対談を読んでオブジェクト指向について議論したい人もいると思いますので、
　　オブジェクト指向カンファレンスのような皆でワイワイ議論できるところで続きを議論しましょう。
　　本日は貴重な話をしていただき、ありがとうございました。