Haskell言語の高階関数
Haskell言語では、
- 「関数を引数として受け取る関数」または「関数を戻り値として返す関数」
を高階関数と呼ぶそうです。
その用法は著名なので、なんとかその用語を避けて議論する必要が有ります。
そうしないと、プログラミング分野で「高階」に関する話は、その第一級オブジェクトにすべて収斂されてしまうからです。
そもそも、「原因→結果」で、原因が自然言語で書かれた仕様で、結果がプログラムの一部分だとすると、
- 結果から見て原因は高階に決まっている
- 高階か一階かよりむしろ、階位の差がどれだけか
の議論になると思います。今後は、このブログでは、あえて「高階」と言わず、
- 「階位差」に関する議論（全て一階で高階がが無い場合、「階位差」に関する議論は不要だから）
をして行こうと思います。
プログラムを1階として、
- 「階位差」0.5程度は形式仕様言語で、
- 「階位差」1程度は自然言語になると
（バッサリとした考えで）思っています。
形式仕様言語も、自然言語も、「階位差」の違いに過ぎない可能性が有ります。
ウォーターフォールとアジャイルの通観
「階位差」の有る、原因と結果に関し、
- 原因から結果に至るのを下向因果
- 結果から原因に至るのを上向因果
というそうですが、双方取り混ぜる立場を取りさえすれば、
- ウォーターフォールとアジャイルの通観
を容易に達成出来るのでは無いか、何て事も思ったりします。
何で片方だけなのか、何で片方だけでは無ければならないのか？
良く考えたら、何の根拠も無いですよね‼️
BFFについて
「型駆動開発の問題点 １」で、
- 費用が、人件費か経費かで
- 全く違う形式のCSVの入力を必要としている
システムの事について、恨み言を言いましたが、
- BFF （Backend For Frontend）というサーバーを、
- 業務サーバーとクライアントの中間に建てる事で、
- フロントエンドとバックエンドが持つ責務の分離できる
そうで、
- CSVの形式変換をBFFでやればOK
なのかも知れません。
結論
これからも「型駆動開発の問題点」でプログラミングが嫌いになる人は存在し続けることでしょう。
