こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
今日は、関数型デザインの第一章を読んでいきました。
本書の意義
1章に入る前に、本書のまえがきなどを通して、立ち位置を確認していきました。
まえがきにあるように、Clean ArchitectureやUML,デザインパターンなどを参照しながら、アーキテクチャの原則を見ていくということで、Clean Architectureやデザインパターンをリファレンスアーキテクチャとして参照するような誤解や関数型とオブジェクト指向型といった変な二項対立を取り除き、あくまでもアーキテクチャの原則を説明してく本だと思うという話をしました。
不変性ってわざわざ関数型言語を使わなくてもfinalをつければいいのでは？
finalをつけるでも、本書の1章の例でも、やりたいこと(オブジェクトの不変性を保ちたいということ)は一緒なんだろうという話をしていきました。
ただ、finalだとつけ忘れがあったり、すべての定数に必ずfinalを使うことで可読性が悪化したり*1する必要があるので、それだったら関数型言語の方が優れているよね、という話なんじゃないかということをしていきました。
また、ここで伝えたいのは関数型言語が絶対に良いというわけではなくて、関数型言語の不変性という考え方がオブジェクト指向でも例えばイミュータブルオブジェクトみたいな形で使える点を示唆しているんじゃないか？という話がありました。
不変性と状態
不変性を重視するのは、すなわち状態を持たないことを大切にするのと同じ発想なんじゃないか？という話になり、だからこそ状態はフロントには持たないみたいなステートレスオブジェクトのトレンドがあるのではないか、という話をしました。
状態を持つことが悪ということなのか？という意見も出たのですが、それは違うんじゃないかということで、状態を色々なところで管理するようにするのが悪なのではないか？という話が出ました。
インフラで言う可搬性の話ともすごく近い気がするという意見も出ていたのですが、具体的にどのようなところがどういう風に関数型の不変性と繋がるかというのは、なかなか言語化するのが難しいという話になりました。
関数型言語の弱点は？
関数型言語にも弱点があるから使われていないような気がするのだけれど、それは一体どういうものなんだろうか？という話をしていきました。
まず、関数型言語の方が読みにくいという話が挙がったのですが、これに関しては今日の参加者が全員手続き型の言語からプログラミングに入っているからではないか？という話になりました。
例えば、x = x + 1という式は手続き型言語を学んでいる人からすればめちゃくちゃわかりやすいですが、プログラミングを何も知らない人からするとどういうことなのかさっぱり分からない式になるので、手続き型言語が読みやすいという話にはならないのではないか？という意見がありました。
次に、手続き型言語の方が設計がしやすいんじゃないか？という意見も出たのですが、基本的に設計は言語によらないのでは？という話になり、例えばモデリングなどはどの言語を使うにしてもやっていくものだということで、これも違いそうだという話になりました。
次に、メモリの使用領域が増えるという話になりました。これはたしかにそうで、実際本章でもTCOの話が書かれているので、弱点として有り得そうだという話になりました。
限られた時間で調べてみると、たしかにメモリの問題が昔はあったそうで、それが原因で関数型言語は廃れたそうですが、現代ではその心配もなくなっているということで、弱点とは言えなさそうだという話になりました。
ただし、そのような背景があったからこそ関数型言語に馴染みがある人は少なくなっているので、手続き型言語が現場で採用されることが多いというのは納得だという意見が出ました。
最後に、関数型言語だと一連の処理が多くなって似たような変数がでてきてしまったりして、間違った変数を使ってしまうとかはありそうだという話がありました。
ただ、関数型言語で現場で大きな処理を書いた経験がある人があまりいないので、本当にそうなのかな？というのは今ひとつ腑に落ちずに終わってしまいました。
全体を通した感想
数ページしかなかったので量が少なくて議論がはかどらないかな？というのは心配になったのですが、まったくそんなことはなく、30分くらいオーバーして、色々議論をしていましたw
今日出た疑問に対しては本を読み進めていくと回答が書かれている感じがあり、すでに先回りして読み進めている方もいらっしゃったので、この先も読書会が盛り上がることを確信しました。
*1:そもそもすべての定数に必ずfinalをつけるルールがあるならfinalをつけなくてもfinalになるような仕組みのほうが優秀
