2011-06-10

心はさらわれるもの

購読しているブックマークからリンクされていた "一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選" という記事が面白かった. この人はだいぶ色々読んでいてすごい. Java には読むのに良いコードが色々あるものだと見直した.

私は推薦リストを作るには至れない. 本もコードも, 読んだ直後に気分が盛り上がって紹介することは時々あれど, お勧めするほどには自分の趣味や記憶を信じられていない.

私の読書/コード体験にはストックホルム症候群みたいなところがある; 苦労して何かを読んだあとはつい, こいつは必読/珠玉の一冊/ツリーだ! と思ってしまう. これを読んでないヤツは素人, なんて気分にすらなる. 友人も似たようなことを言っていたから, もしかしたらよくある気分なのかもしれない.

そんな気分になったら, 私は架空の積読タワーに思いをめぐらせ, この山と積まれた本やツリーはどれも読んだあとはきっと珠玉必読よまねばもぐりなマスターピースと映るに違いないと考え, もぐりで素人な自分と心の平静を取り戻している.

けれどこんな態度はうかつさが足らず退屈とも思う.

心をさらわないコード

珠玉必読が軒を連ねる一方, 読んだあとにこりゃダメだとがっくりくるコードも世の中には結構ある. 銃口の媚薬をかき消すダメなコードの話をするのは, 良いコードの話と同じくらい面白い. 認知の重力を抜け出せたのには何かわけがあるだろうから. 少くとも私にとっては.

さっそく思いつくままに並べてみたい.

私の中でのこりゃダメだの代表は MySQL. これを見て C++ を罵倒されたり, 逆にここからプログラミングを学ばれだりするとたまらない. あのカオスの中でクエリーを最適化できるハッカーたちの腕力には頭がさがるけれど, 歴史が許せばなかったことにしてほしいと思う. いやなくならなくていいから書き直してほしい. Drizzle では荒廃した pluggable storage インターフェイスが書き直されており希望を感じた. InnoDB は比較的よいとおもう. ただ古いよね.

Tamarin. 普通に質が高くない. スマートポインタを使って write barrier するトリックはクールだと思ったけれど, C++ ベースの言語処理系で参照を特別なスマートポインタに入れるのは特段珍しくもないことを後から知った. ES4 も亡くなったことだし SpiderMonkey でいいんじゃないかな読むのは.

JavaScriptCore. 速さの秘密は気になるものの, 歴史的経緯と市場の圧力で素敵なコードに育つ時期を逸してしまった気配がある. "わたしが一番きれいだったとき / 街々はがらがら崩れていって / とんでもないところから / 青空なんかが見えたりした" と 茨城のり子はうたったけれど, そんなかんじ. まあ慣れればいじれるのかもしれない.

Python(2.x). 特段酷くもないけど, なんというかフツーだった. 言語処理系はだいたい一つ読むと飽きるので, 貴重な好奇心はもっとクールなコードに費すのが良いと思う. (Python が好きな人はこの限りでない.)

GCC. もう Clang でいいよ. C で lisp の真似事しちゃダメだよ...

LLDB. あまりに 1990-ish. これが 2010 年に書かれた事実に胸が痛む. でも gdb は輪をかけて悲惨だからデバッガのコードが読みたいなら我慢するしかない. LLDB に限らず LL ファミリーはもどかしい子が多いです.

Maruku. Jekyll が使っている Ruby 製の markdown parser. Jekyll の markdown 整形がどうにも上手く動かず, 自分が何かを勘違いをしているかもとコードを覗いて絶望した. markdown パーサみたいに単純(そう)なものをここまで複雑にできるのか... ruby だからといってコードがまともとは限らない良い例.

Mozilla. 実際悪くないしクールだけれどなにしろでかすぎる. あと XPCOM コンベンションは辛い. Mozilla はドキュメントが充実しているから, まずそれを読む方が学ぶことは多い気がする. そしてドキュメントを読むとだいたい満足する, と思う. なおこれは C++ レイヤの話. JS レイヤは知らない. あとブラウザはどれも概ねでかいじゃんと問い詰められると反論できないので見逃してください.

JUnit. よく勧める人がいるけど, API でだいたい想像がつくものの中身はいまいち楽しくない. ダメというより優等生すぎてつまらない. もしかすると私は API デザインがドキュメントも含めきちんとしているものには食指が動かないのかもしれない. フレークワークの類も同じ理由で興味が湧かない. このへんの匙加減は悩ましい. お勉強という意味では読んだ方がいいんだろうけど, お勉強という理由だけでコードを読むのはしんどい.

つづき. 最近だと Twitter 周辺で作られている Scala 製サーバのうちいくつか. (たとえば KestrelGizzard.) ちょっと読んだ範囲では教科書や論文や Blog をみながら作ってみましたというカジュアルなコードだった. カジュアルな物を読むよりは由緒正しいものを読んだ方が色々面白い気がする. あるいはコード以前に教科書や論文をあたるのもよいとおもう. ただ読んでないコードものも結構あるので, この印象は濡れ衣かもしれない. あと Twitter ファンの場合この限りでない.

そういえば先の記事にでてきた h2dabatabse の前身(?)である hsqldb はひどいコードだった. その頃は Java 製のデータベースを探していて, hsqldb の次には Derby を眺めた. hsql のバンカラなコードとは逆に, Derby は abstraction と indirection が深過ぎ挫けた記憶がある. ちょうどいい感じに書かれた RDB はどこかにないものか. SQLite は謎の VM が入っているなど面白いところは多いけれど, 並列性とかクエリーの評価みたいな RDB に肝心の所はさぼっているからなあ...

愛すべきリストたち

一通り罵倒して憂さを晴らし気が済んだ. やれやれ...

自分のものはさておき, 誰か他の人のリストを眺めるのは好きだ. 中でも印象にのこっているのは我らが父 Michael Feathers のリスト "10 Papers Every Programmer Should Read (At Least Twice)". たぶん半分くらいは読んだ気がする. 今更 Parnas の書いたものを読んだところで観光以上の意味があるとも思えなかったけれど, ソフトウェア工学も 40 年前よりは進化していることがわかったのはよかった.

このリストは多くの Feathers ファンを刺激したらしく, 派生して書かれた "10 Papers Every Software Architect Should Read (At Least Twice)" というリストもある.

他人のリストを眺めるのが楽しいのは, そこに書き手の人となりが滲むからでもある. レガシーコード改善ガイド だけを読むと Feathers を強面のデスマ帰還兵と思い違っても不思議はない. でもこのリストからは literature を愛するもう一つの顔を覗けて親しみがわく. Parnas についても "この paper は古いが人類の進歩を感じたよ" という旨の感想を書いておりシンパシーした. フェイスブックのプロフィール欄を読み漁ったスタンフォード生のきもちが少しはわかったかもしれない.