Re: 関数プログラミング

このあいだの記事の続きというか。ちょっと古い記事ですが[id:nobsun:20070417:FunctionalBrain]をみて考えたというか。
昔、[id:lethevert:20060329:p1]とか[id:succeed:20060331:1143826028]とかで議論にしたことですが、関数型で難しいのは、オブジェクトの共有という構造なんですよね。オブジェクトの破壊的な更新は一意型のようなトリックで関数的に扱えるので特別問題ないと思うのです。for-notationのようなシンタックスシュガーを作るのも簡単なわけですし。
それどころか、関数プログラミングは状態を表現できないというのは、悪質なデマ(笑)というか嘘もいいとこじゃないですかね。State Monadとかどう説明するのかと。間接的にしか表現できないと言われても、代入しようがレコードごと作りなおそうが、間接的に表現していることに変わりはないわけで。本物は作りなおされないけれども代入もされなくて、ただ自分自身の状態が変化しているだけなんですから。
しかし、オブジェクトの共有だけは関数型では扱えない。そもそも、Identityという概念そのものがないので、共有という概念も同様に存在しないわけですから。
前回、内在化・外在化という言葉で表現していたものは、このオブジェクトの共有と深く関わっているところで、プログラムの対象をオブジェクトの共有構造を使ってプログラム内部にモデル化して取り込むアプローチを対象の内在化と表現していたのでした。このようなアプローチは、オブジェクト指向分析やオブジェクト指向設計では一般的に見られるものだと思うのですが、大半のオブジェクト指向に親しんだプログラマは、ある程度の規模のプログラミングを行うにはこのアプローチを採用するのではないでしょうか?*1
オブジェクトの共有が使えないということは、この慣れ親しんだアプローチを捨てなければいけないわけです。なにも全部捨てる必要はなく、使えるところを残して再構成することはできるかもしれません。でも、具体的にどうやればいいのかは、まだハッカーの頭の中にしかないという状況ではないでしょうか?
今後、気が向いたら、関数プログラミングに向いたプログラミングのアプローチについて、思っていることを書いていこうかと思っています。とりあえず、実験的な試みなので、思ったことがあれば、コメントなりTBなりいただけると参考になります。

*1:もちろん、オブジェクト指向「言語」は必ずしもこのようなアプローチを取らなければいけないわけではなく、そういう意味ではオブジェクト指向と副作用は「無関係」ではありますが、オブジェクト指向「分析」や「設計」のことを考えると無関係とは言い切れないのではないかと思います