『Coders at Work』まとめ Part 3の続き。
おまけと言いつつ、今度こそ本当にまとめる。と言いつつ感想を書く。
・C++は明らかにダメ
・デザインパターンには問題がある
・メモリ共有型のマルチスレッドは明らかにダメ
・トランザクショナルメモリは今ホットだが疑問。ちなみにMicrosoft Researchの研究者はダメと結論づけた
・何層ものレイヤを重ねることには不安がある。その上さらにレイヤがブラックボックスなのは明らかにダメ
・プログラミング言語が格納域を扱うことには問題がある
・Prologはもっと注目されるべき
・純粋関数型言語は注目はされているが、うまくいってはいない
・ソフトウェアの再利用はうまくいっていない
・コンピュータにはこの数十年間、見るべき進歩がない
私見：
先日、fingertreeというデータ構造を知った。私の感想――「これは早すぎる最適化だ」。
Fran Allenいわく、「ある計算には良いことが別の計算にはよくないということも出てくるでしょう。ある整理方法が、マトリックスのようなシンプルなものでさえ、違ったやり方でアクセスした場合にはまずいものになり得ます。だからアクセスの順序と場所の組み合わせによるのです」。
どんなデータ構造が最適かは、実行してみるまでわからない。もちろん理論上は、実行前に予測することも不可能ではない。が、そういう予測はほぼ常に、惨憺たる結果に終わる。たとえコードを書いた瞬間には予測が当たっていても、そのうち外れる。プログラムは変化してゆくものであり、「アクセスの順序と場所の組み合わせ」も変化してゆくからだ。
何種類かのデータ構造をあらかじめ用意しておき、実行時にVMがプロファイリングにもとづいて最適なデータ構造を選択する？ それが未来だとは思えないし、現状から移行するほどの価値があるとも思えない。
ではどうすればいいのか。
最適なデータ構造を選択するプログラムではなく、作り出すプログラムを作り出すべきだ。
それも、たとえばJavaのjava.util.Mapがインターフェイスでjava.util.HashMapが実装、といったレベルの抽象化では足りない。そもそもmutableなデータ構造は格納域を扱っている。immutableなら格納域の問題はないが、それが実際に機能しうる解決策なのかどうかわからない。少なくとも私は、「クリス・オカサキの本、"Purely Functional Data Structures"」を見て首をかしげた。
もしかすると、「データ構造」という概念そのものに問題があるのではないか。配列――たぶん最初のデータ構造――が現れたときから、私たちはずっと道を誤っているのではないか。
おそらく、まだ誰の夢想にも現れていないアイディア、「一夜にして様相を変えるようなもの」が必要とされている。私の生きているうちにそのアイディアが現れるかどうかわからないが、それは必ずある、と私の勘が告げている。