昨日メモした記事に関して

気になったところがいくつかあった。

経験の浅いプログラマにとって,適切なアルゴリズムで繰り返したり,適切なリソース管理を実装したりすることは容易ではありません

後半部分はともかく、前半部分は重要だろうか?確かに例で挙げていた木構造のデータを再帰的にたどる処理をイテレータやジェネレータなしに書くのは難しいと思うが、このような基本的な処理は大抵ライブラリとして用意されているか、使う必要性がほとんどないかのどちらかだと思う。特にJavaは何でも用意されている言語なので、今回の例のような実装がそもそも必要になると思えない。

ところがRubyを使えば,難しい部分はすべてブロック構文を使って隠ぺいできます。Rubyのライブラリにはブロックを用いた豊富な語彙(ごい)があります。それでも足りない場合は,スキルの高いプログラマが繰り返しやリソース管理を行うブロック付きメソッドを作ってしまえばよいのです。他の人はただブロックの中身を書くだけで簡単にその恩恵にあずかることができます

Javaでもクラス内に隠ぺいできる。また、難しい部分を隠ぺいできるのが良いのではなく、隠ぺいすべき部分とブロックとして切り出す部分をうまく分離するという設計ができることが重要かつ難しい作業なのだと思う。確かに、高階関数ができない言語では同じことの実現をやりづらい部分もあるが、単なる関数としてまとめておくだけでも分離という意味においてはできる。


また通常ボトムアップで、仕様変更の影響を受けにくい汎用的でプリミティブな部分を先に開発すべきであるが、ループはえてしてそういった部分に該当しない。ループを先に作っておくのはフレームワーク的な部分ならあり得るが、仕様変更に影響されやすいので上級者でも容易ではないと思う。また、繰り返しになるが、プリミティブなロジックのループのことを言っているのであれば、Javaならあらかじめ容易されていると思う。


例えば、ユーザ定義型のオブジェクトを扱う周辺のライブラリ(例えば、上記の木構造をたどるなど)を作る場合でも同様で、逆にこの部分を自作するのはスキルの高いプログラマであっても保守が大変。そういったプリミティブな部分はなるべく既存のライブラリを使うべき。


また、ループの嫌なところは、仕様変更でループ呼び出しの順序が異なったり、ループのネストが深くなると読みづらくなったりするところだと思うが、そういうのをブロック構文で隠ぺいできるのはすばらしいと思う。また、Pythonでもリスト内包表記ができたり、ループが表面に見えててもRubyイテレータと本質的には同じなので問題ない。

そうした苦労の中で導き出された解決策が「スコープによるリソース管理」です。

リソース管理に関しては、私はJavaPythonの解決策がfinallyしか分からないので何とも言えないが、難しい部分のロジックを隠ぺいしたというだけならJavaPythonでもできそうであるが具体的な方法は保留。


最後にまとめておくと、Rubyを否定している訳ではなく、ロジックの構造や基本的な処理をライブラリなどで簡潔に表現できるのはすばらしいと思う。ただ、ブロック構文によりコーティングの難しさの本質がなくなる訳ではない。難しさの本質は汎用的な部分とそうでない部分の切り分けや、データをいかに依存関係を単純にして、またそれに付随する処理を簡潔に表現できるように設計していけるかだと思う。


そういうところをブロック構文を使えばできる訳ではなく、あくまで汎用度を高めるとか、コードを見やすくできることを実現できるにすぎないと思う。難しい(重要)な部分とそうでない部分の切り分けを中身ではなく、構文上実現しやすいというだけだと思う。