あきばこ工房

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

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

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

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

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

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

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

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

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

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

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

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

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

かなり前に「コンピュータ言語にnullがあることがすべての元凶」との論説がよくありました。

最初に読んだときは「うーん、そうなのかなー、便利だけど」と思いつつも、OptionやEitherなどを使い慣れてくると「うーん、なるほどなぁ」と思うことになった。

全否定する気は今でもない。0(全ビット0)や-1(全ビット1)はハードの論理ゲートにとって特別な状態として取り扱いやすいのは確か。1ビットが粗末にできない時代は仕方ないだろう。その延長上で高級言語が進化しているのだからその過程でnullがあったのも仕方が無いこと。

論理的にはないほうが素直になるというのなら、これからそうする ということでよいだろう。どんな文化/歴史にも無かったほうがよい黒歴史は存在するものだし。

最近のアプリやシステムサービスはおおよそMVCモデルで作られることが多い。モデル-ビュー-コントローラ

データ(DB含む)はモデルとして定義して、概ねクラスで作る。

コントローラは呼び出し元(httpサーバー経由で来るユーザ操作とか、デバイスからの呼び出しとか、外部サーバーからのAPI呼び出しとか)からの要求を受け付けて、モデルに突っ込んで、サービスを呼んで加工し、ビューで返すべき結果にまとめ直して、呼び出し元に返す。

こういう形式にまとめられた理由について、論理的な解説書はいろいろ理由を書いているがその個々は私は別に頭に入ってはいない。読めばもっともだと思う。

でもプログラムはそれにはまらない書き方は出来るし、クラス分けも別の見方の分け方もできる。初期のオブジェクト指向系の人(教育系のSmalltalkの人とか)にすれば現実モデルと全然合致しないと言うかもしれない。

なんでDBのレコードって現実世界に実物が存在する物ではないのにクラスになるのかとか、レコードの分割単位は実際のオブジェクトの単位ではなかろうとか。オブジェクトのほうにモデルとスキーマをがっちり合わせたらRDBの形には入らなくなる(もちろんそっちの考え方のシステム/言語も今はいろいろあるだろう)。

でも、なぜこの分け方が多いかは単純に「たくさんこの手のシステムを作った人から見て、こう分けたほうが後々を含めて一番手間がかからなかった」という経験知見ということだろう。

建物を建てるときに、1階より2階を大きくした建物を作ることは出来る。芸術家がデザイン的に建てる場合もあるし、立地上そうする必要があったということもあるだろう。でも特に条件が無ければ2階は1階と同じか小さくしたほうが建てやすい。

プログラムの規模が小さいうちはどうとでもなるのだ。段ボールの家なら1階と2階がどういう関係でも問題ない。実用的な規模、または大規模なシステム、多人数、多数の企業が関わるシステムだと、大枠が合理的にわかりやすくないと破綻する。経験・知見でこれいいよね というアプリ/サービスの作りの一つがMVCである。

経験知見により取捨されていく方法論は大事にすべきなのだろう。ただ将来ともその知見通りとは限らない(とにかくソフト分野はカルチャーが常に変わり続ける)。自分の若い頃の知見(コンピュータの都合に合わせたシステムが後々手間がかからない)は、技術と方法論の進歩でいくらでも変わっていくのだ。