SICP3章後半に書いてあるストリーム(遅延リスト)について

SICP3章ってそんなに「オブジェクトはオワコン！ 関数プログラミング的なストリームこそ最強！」な内容だったかなぁ、と思って3章の最後を読みなおしてみたが、こんな内容だった：

• オブジェクト（状態をオブジェクトのローカル変数とし、状態の変更をローカル変数への再代入とするような）モデルは直感的で強力だけど「実行順序」や「同期」といった面倒な問題をプログラミングにもたらす。
• 関数プログラミング的モデル化であるストリームは状態を「時間」をパラメータとしたリストとしてモデル化することで「実行順序」の問題を解消する。 銀行口座のモデルも口座へのトランザクションの列を入力ストリームとして残高の列を出力ストリームにすれば対話システムとして「状態」を持っているかのように振る舞える。
• しかしストリームであっても複数の対話者が口座を共有している状況を考えると、入力ストリームをマージさせなければならなくなり、 これを考えると「順序」や「同期」をどうすべきか、という問題がプログラミングに再導入されてしまう。(それを排除するための関数プログラミングだったのに)
• オブジェクト指向もストリームも強力なモデル化ではあるが、それぞれ単体では満足いくようなモデル化にはならない。

自分的にまとめるとすれば「ストリームによって、オブジェクトとは異なる強力なモデル化が可能になる。だが万能ではない」となるな。
どうやったらこれを「オブジェクトはオワコン、ストリーム最強」と読み取れるのかは不明。
まぁいいか。

**

ちなみにストリームが出てくるのは3章の後半にすぎない。3章全体としては前章までの手続き的抽象、データ抽象では対処できない問題、すなわち大きなプログラムを構成するための戦略（いかに全体としては不整合を起こさないよう、独立した小さなプログラムに分割して独立に開発するか＝モジュラリティを高めるか）について書かれており、いち戦略としてのオブジェクトモデルとそれにまつわる諸々がその前半を占めている。(で、後半がストリーム)

プログラムの構成技法といえば一般的にオブジェクト指向マンセーなので、ストリームっていう抽象化が出てくるって時点で他のプログラミング本とは一線を画すものだよなぁ。

3章では遅延評価は代入があるプログラミングモデルとはなじまないんだよねーと書いてあるけど、Haskellはモナドによってそれをうまくプログラマが書くプログラムの外に押し出すことに成功してる(?)ので、もしSICPが改訂されるとしたらそのへんが補われることになるのかなぁとか妄想してる。

いやー、やっぱSICPっていい本だなぁ。(4章以降未読だけど)