アカウント名:
パスワード:
つまり
もし、制御を分散させる(モジュール化してテストしやすくしたり、プラガブルにしたりする)のが本質的に不可能
になったら、それは妥協した関数型プログラミングなだけです。例えて言えば、オブジェクト指向プログラミングなのに静的・グローバル型の値を使いまくるとか。
関数型プログラミングでは入力と出力のみが可変なので、制御を行う部分はユーザーが担ったりフレームワークで吸収したりするべきなのではないでしょうか。
>制御を行う部分はユーザーが担ったりフレームワークで吸収したりするべきなのではないでしょうか。
そういうフレームワークを作れなかった、その位置こそチューリング完全が何の制限も無く完全に必要だったから、関数型プログラミングは伸びなかったのでしょうね。まだTDDなら「死ぬほど大変だ」という事が分かる位、実例は有りますが、フレームワークはそこまで至っていない(永久に至らない?)と思います。
そもそも歴史的にも、関数が元祖で、それに環境を加えたラムダ計算とかに進み、さらに、名前を(姓と名の様に)2つにしたオブジェクト指向に進んだという経緯なので、関数型とは新しくないし、(その後の歴史で付け加えられたものが)足りない、空想に過ぎない様に思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
関数型プログラミングには副作用がない (スコア:0)
つまり
もし、制御を分散させる(モジュール化してテストしやすく
したり、プラガブルにしたりする)のが本質的に不可能
になったら、それは妥協した関数型プログラミングなだけです。
例えて言えば、オブジェクト指向プログラミングなのに静的・グローバル型の値を使いまくるとか。
関数型プログラミングでは入力と出力のみが可変なので、
制御を行う部分はユーザーが担ったりフレームワークで吸収したりするべきなのではないでしょうか。
Re:関数型プログラミングには副作用がない (スコア:1)
>制御を行う部分はユーザーが担ったりフレームワークで吸収したりするべきなのではないでしょうか。
そういうフレームワークを作れなかった、その位置こそチューリング完全が何の制限も無く
完全に必要だったから、関数型プログラミングは伸びなかったのでしょうね。
まだTDDなら「死ぬほど大変だ」という事が分かる位、実例は有りますが、フレームワークは
そこまで至っていない(永久に至らない?)と思います。
そもそも歴史的にも、関数が元祖で、それに環境を加えたラムダ計算とかに進み、さらに、
名前を(姓と名の様に)2つにしたオブジェクト指向に進んだという経緯なので、
関数型とは新しくないし、(その後の歴史で付け加えられたものが)足りない、空想に
過ぎない様に思います。