+ イールドはイケてる、クロージャはイケてない

先日の話の続き…かな。

俺の最近のお気に入り、「イールド」の話です。

イールドはですね。return みたいなものなんですけど、集合オブジェクトの要素を、1個ずつ逐次returnするようなものです。

昔ながらのプログラムだと、集合オブジェクト（リンクリストとか）を全部作ってからリターンだったでしょ。
でもそれって、メモリの利用効率や、ひいてはプログラムの実行効率が悪い。

かな漢字変換処理の開発初期の話で、ひらがなを全部入力してから漢字に変換してたら遅かったけど、かなの入力ごとに少しずつ変換を始めるようにしたら、ユーザの体感速度が劇的に短縮された、ってのは有名な話。


イールドを使うと、呼ぶ側のプログラムは集合が返ってくる体で書いて、呼ばれる側のプログラムは1件ずつreturnするような書き方でかけばよい、となるのです。

で、言語内部実装の効率化策によって複数件まとめられるかもだけど、プログラマ的には1件ずつreturnしてると思っとけばOK。

人間も理解しやすいし、システムとしても動きやすい。すばらしい。


この概念はですね、

・Forループ
    ↓
・イテレータ (=ForループをOOP風に書くやり方)
    ↓
・集合オブジェクトのプロバイダとコンシューマ

という、集合に対するプログラミング概念発展の歴史の、エッジ＝新しいほうの端っこにあるわけです。


イールドだと、

• プロバイダモジュールはマルチコアCPUの複数コアで走れる可能性が残されていたり
• プログラム再利用に関する人類大敗北の黒歴史の中で、唯一輝く成功例「Unixシェルのパイプ」風に、モジュールをつなぐこと につながったり

ソフトウェア構築の概念として、広まるといいことが、いろいろあるのです。


発展的な話だけど、マルチコアでプロバイダを実装して、コンシューマ側では「ソート済みの集合に対して処理したい」という場合に関しては、さらにちょい工夫が要るのだけどね。

---

逆に、

今ダメだと思ってる技術は「クロージャ」です。

これ、言語システム側がどうがんばっても、「削除するタイミングを決定できない」状況が生じ得る。ダメ。ぜんぜんダメ。

よく、ガベージコレクションの信奉者が「人間はそんなこと意識するよりも…」論を展開するけどさ。
人間のプログラマが意識するか、言語処理システム側が自動的に考えるか以前に、概念として理論的に「破壊を制御できないシステム」になる。
それは、ダメ。

JavaのStop The World問題だって、それでしょ。

これについては、引き続き、毒を吐いていきます。


【* 日々のメモ】