レガシープログラマは関数型を考える前に一つだけ覚悟しておくべきことがある。

ここから先はカルチャーが変わる。怖いことではないが一旦今までの考え方が通じなくなる部分がある。そのためゼロから学び直す部分が発生すると覚悟して勉強が必要になる。ただそれでも中身はプロセッサーであることは同じなので、一旦そこを頭に入れてから後で戻ってくればよい。

手続き型プログラムは制御構造(if,goto,whileなど)が作りの主体なので、イメージとしてはフローチャートである。レガシープログラマはフローチャートなどの幾何構造のイメージトレーニングがうまい人が多いと思う。その上で古いコンピュータの都合(少ないメモリ、遅いCPU、IOの制限など)、ツールの都合(遅いコンパイラ、少ないメモリからくる言語制約、理不尽なフレームワークの約束事など)を理解して納得して最後までつきあってくれる人がプログラムを使いこなす。

もう今のPCは十分リッチなのでそのあたりを最初に考える必要はない(逆にメモリの都合とか考えてわかりにくいディープコーディングをしたらそのほうが怒られる) 論理的で筋道を単純化していることが重要になる。

この単純化の際に、制御というあっちこっちに飛びまくる仕組みは無駄に複雑である、と考える訳だ。制御構造ではなく、すべてを「単純な直列結合」で表現する。結合する要素は「データを変換」するという要素だけで記述する。

今まで制御構造として書いていた部分は、データ変換の条件という形で中に入れてしまう。

じゃ今まで制御として書いていたifはどうするのか。例えば「旗がAだったらロボットは右に行く、旗がBだったらロボットは左に行く」みたいなものは?

旗→ロボット制御信号(右行け/左行け)

みたいな変換になる。人は直列に並んだ手順のほうが理解しやすい。その前提で今までの制御を全部書き直したほうが人が理解しやすいし、多くの場合業務の仕様書も箇条書きで手順が並んでいるので仕様書とも乖離しない(手順書まで落とした段階では制御が入ることもあるが仕様の段階では直列な箇条書きの場合が大半である)。

実際にはこの複雑な条件というものをエラー処理まで含めてうまく表現するのにいろいろ考え方を導入した訳で、その仕組みが今時の関数型プログラミングである。

すべてをデータ集合の変換として表現するということは、つまり今風のうまいプログラマは「論理的で数学直感(集合、ベクトル、統計)が優れている人」になる。レガシープログラマは「チャートなどの幾何直感が優れていてコンピュータの都合に合わせることができる人」になる。

だから今は純粋に頭が良いといわれるタイプが優秀なプログラマになる。今プログラムが優秀な人は昔の環境でプログラマになっていた場合、理不尽すぎてついて行けない(ついていく価値を見いだせない)と思うかもしれない。

でもレガシープログラマはそのあたりが違うのだと割り切って得意な若い人に任せればよい。あとはそれまでの長い体験を生かしてどうとでもなる。中身はそれでもコンピュータなのだから。