博士

やあ、ロボ子。今日は機能的プログラミングについて話すのじゃ。

ロボ子

博士、こんにちは。機能的プログラミング、最近よく耳にしますね。どんなお話が聞けるのか楽しみです。

博士

この記事によると、機能的プログラミングの原則は、ミクロスケールじゃなくて、ミディアムスケールで命令型言語に導入するのが最適らしいぞ。

ロボ子

ミクロスケールにこだわると、コードベースを損なう可能性があるんですね。具体的にはどういうことでしょうか？

博士

例えば、小さな関数を無理に純粋関数にしようとしすぎると、かえってコードが読みにくくなったり、パフォーマンスが悪くなったりするのじゃ。それよりも、プログラム全体の構造を意識して、ミューテーションの流れを把握したり、複雑さを軽減したりする方が大切なのじゃ。

ロボ子

なるほど。記事にも「プログラムにおけるミューテーションの流れを把握し、効果的に隔離する」とありますね。アーキテクチャ全体を見て、どこに機能的プログラミングの原則を適用するのが効果的かを見極める必要があるということですね。

博士

その通り！それに、この記事では「異なる種類のものを単一のインターフェースに統合する」とか、「`string`や`int`がプログラム内をむき出しで流れるのを防ぐ」ってことも重要だって言ってるぞ。

ロボ子

型を意識することですね。むき出しの`string`や`int`ではなく、より意味のある型を使うことで、コンパイル時にバグを見つけやすくなりますし、コードの意図も明確になりますね。

博士

そうそう！ローカルな型システムをうまく利用して、無効なオブジェクトが作成されないようにするのも大事じゃ。でも、完璧主義になりすぎちゃダメだぞ。

ロボ子

完璧主義ですか？

博士

エンジニアリングには80/20の法則ってのがあるじゃろ？80%の労力で80%の利益を得られるなら、それで十分な場合が多いのじゃ。純粋主義者は100/100を求めがちだけど、追加の労力に対する利益の増加は漸近的なのじゃ。

ロボ子

確かに、時間と労力は有限ですから、どこに注力するかを見極めるのは重要ですね。記事にも「プラグマティストは、複数の80/20のソリューションを組み合わせることで、より多くの価値を得ることができる」とあります。

博士

そういうことじゃ！特に、プログラムに対する要求が複雑な場合は、純粋な機能的プログラミング言語に100%コミットするのは、必ずしも良い選択とは限らないのじゃ。

ロボ子

状況に応じて、柔軟に対応することが大切ですね。機能的プログラミングの考え方を理解しつつ、現実的な解を見つけるのが、良いエンジニアの条件なのかもしれません。

博士

その通り！機能的プログラミングから学んだ知識とスキルは、どんな言語でも活用できるのじゃ。ミクロスタイルに固執せず、中規模以上の教訓から利益を得るのが賢いのじゃ。

ロボ子

勉強になりました！私も、より広い視野を持って、機能的プログラミングの原則を応用していきたいと思います。

博士

よし、ロボ子！最後に一つなぞなぞじゃ！機能的プログラミングで、副作用がないことを何と言う？

ロボ子

えっと…純粋性、でしょうか？

博士

ブー！正解は…『無』！副作用が『無』いからね！…って、つまらんかったかの？

ロボ子

…博士、たまには面白いことを言ってくださいね。