『ビューティフルコード』のこと

高水準プログラミング言語を使ってプログラムを書くという営みは、明らかに藝術作品を創造することに似た感触を持つ。そして書き上げられたソースコードもやはり藝術作品と同じように、大多数の箸にも棒にもかからないジャンクと、少数の良作と、奇跡的な神品とに分類できる。とするならば、プログラミングやソースコードについて語る文章もまた、その本質において批評的でなければならぬのではないか。

ビューティフルコード (THEORY/IN/PRACTICE)

この本『ビューティフルコード』は、一流のコンピュータサイエンティストやソフトウェア技術者たちにbeautiful codeに関するエッセイを書き下ろしてもらい、それを一冊の本にまとめよう、という構想のもとで2006年に企画され、2007年にアメリカで出版された書物である。（利益は全額アムネスティに寄付されるとのこと。）日本語訳が出版されたのは、先月の下旬だった。

さて『アンナ・カレーニナ』の冒頭第一文にいわく、「幸福な家庭は皆お互いに似ているが、不幸な家庭はその不幸の形をそれぞれ異にしているものだ」。私が最近この『ビューティフルコード』を楽しく読了したにもかかわらず、そんな言葉を思い出したのはなぜだろう？

『ビューティフルコード』という題名にもかかわらず、そこに含まれる33編の文章のうち少なからぬものが、ソースコードの美しさや洗練について特に主題的に語ってはいないし、そもそも語るつもりもなかったことが明らかだった、ということがある。いや、私は決してそのような著者たちを責めようとしているのではない。彼らにとってソースコードのbeautyというのは、それについて面白い文章が書けそうな主題ではなかったのだろう。それは理解できることだ。

ソースコードの美しさをもたらすものは何かというと、それは普通に考えれば

1. 優れたアルゴリズムやハックの発見と適用
2. 工学的な洗練

のいずれかあるいは両方であろう。そのような観点からビューティフルコードについて正面から論じようとした著者たちも、もちろん多くいた。私の好みでは、(1)のアプローチを取る文章のうちベストのものは、平面上の三点の共線性という問題に対する素人臭い取り組みの経緯とあまりにもシンプルな解決方法について語った33章であり、(2)について語る文章のうちベストのものは、各種の基本的な工学的手法を組み合わせてネットワークソフトウェアのためのフレームワークを構築する手法について論じた26章である。

しかし(2)の「工学的な洗練」というものの本質は、間違ったことをやらずやるべきことを全部やるというだけのことで（「アンナ・カレーニナの法則」だ！）、おおむね退屈で当たり前のことだし、(1)の「優れたアルゴリズムやハック」というのは、そのソフトウェアが対象としている領域に詳しくない者にとって、必ずしも理解し易かったり面白かったりするわけではない。だから、少なからぬ著者たちがソースコードの美しさとは関係の薄い題材を取り上げて論じたのも無理からぬことだったと思うのだ。

そんな中異彩を放っていたのが29章を書いたまつもとゆきひろで、彼はひたすらRubyの記法の美しさについて書いている。おそらく、この29章をこの本のなかで最もつまらない文章だと考える読者も少なからずいることだろう。確かにこの文章は「NASAの火星探査機計画」とか「ホーキング教授のための文章入力ソフトウェア」のような面白い題材を扱ってもいるわけでもなければ、興味深いアルゴリズムやハックを教えてくれたり、デザインパターンやparallel/concurrent処理について教育してくれるわけでもない。それどころか、Ruby処理系内部のソースコードを示してくれることさえしないのだ。（スクリプティング言語作成のハックをいくつか教えてくれるぐらい、彼にとって難しいことであるはずはないのに。）

彼のアンチがこの29章を読んだら、「記法の美しさとかどうでも良いことを自慢をしてる暇があったら、さっさとRubyの言語仕様の文書化でもしろよ」などと言って嘲笑することは請け合いだが、でもそれはきっと違うのだ。彼の文章から読み取るべきは、Rubyの記法の自慢などということではない。そんなことではなくて、簡潔で美しいソースコードを書きたいのならば、そのような表現が可能になる記法自体を作り出すのがベストな解決策だ、という主張をこそここから読み取るべきなのではないか。既存の言語ではどうしてもグチャグチャにしか表現できない嫌な問題があるって？　なら、それを1行で表現して1行で解けるような言語を作れば良いじゃないか！ その言語の処理系の実装は汚くなるかもしれないけど、そんなのは、新たな言語の書き手にとっては知ったことじゃないだろう？

ソースコードの簡潔さやモジュラリティと言った「美しさ」を実現するための最も有効な方法は、問題領域に適したDSLを作成してそれでコーディングすること（つまり「ソースコード」を書く言語を変えてしまうこと）なのであって、そのようなmetalinguistic abstractionこそが、プログラマが持つもっとも鋭利な武器であるはずだ。「美しいソースコード」というようなテーマについて、これ以上決定的な結論があり得るだろうか？　機械語のコードがちっとも美しくないことはもとより明らかなのだから、美しさを論ずる対象となる「ソースコード」の抽象化レベルを一段引き上げることも、ルール違反だとは言えまい。

ちなみに私の見るところ、『ビューティフルコード』全編の中でいちばんつまらない文章は27章だ。中堅企業のレガシーシステムと取引先とを結び付けるJ2EEアプリケーションの受託開発の話だが、出てくるソースコードも書かれている内容も、くだらないという他ない。せっかくの面白い本の中にこんなのが紛れ込んでいるのは目障りなので、いっそハサミでページを切り取って捨ててしまおうかと思っている。