エンバグ効率 - 純粋関数型雑記帳

昨日の続き
M氏がエンバグ効率なる言葉を作ってしまったので、
ちょっとそれについてお話しましょう。
エンバグ効率というのはちょっと不自然な感じのする言葉ですが、
意味はそのまま、バグを仕込む効率のことです。
もちろん、エンバグ効率は低い方が良いのです。

- - - -

ICFPの結果が発表された。
今年もHaskellは一位。
これは取りも直さずHaskellが優秀な言語であることを示しているのだが
(Haskellがすごいのか、Haskellを使うような人がすごいのか？
無論前者である。だってそうじゃないと他言語ユーザがアレということになってしまう)、
ではなぜHaskellは優秀であるのか。
遅延評価、型推論、パターンマッチ、モナドなど、
Haskellを特徴付けるキーワードはいくつかあるが、
今回はそういうわかりやすい部分以外での優位性が
浮き彫りとなる結果になったような気がする。

というのも、まずはこちらを御覧頂きたい。
http://icfpc.plt-scheme.org/icfpc2005-talk.pdf
この資料の59ページからに今回のSubmissionに使われた
言語の統計が示されている。
最初は160あまりの提出があって、いろいろな言語が用いられていて
カラフルなのが分かるだろう。
次のページ(60ページ)、No failure in regular season とあるが、
これはジャッジのCop&Robberと戦わせたときに"バグが出なかった"プログラムである。
(ちなみに、今回のシステムを簡単に説明しておくと、
投稿されたプログラムはまずある程度の強さのジャッジのプログラムと対戦させられる。
そのジャッジプログラムに勝てなければそれで終了。
勝てばプレイオフに進出。数百回のマッチを経て勝者が決定される)
見て分かるとおり、いきなり三割近くのプログラムが死んでいる。
なんと、三割ものプログラムがたった6回の試合すらまともに実行できなかったのである。
おおよそいろいろな言語で5割から7割強の生存率である。
Cの生存率が著しく低いのを除くとどっこいどっこいという感じか。
そして、次のページ(61ページ)を見て頂きたい。
一気に生存数が減っている。これはジャッジプログラムに勝てなかった
プログラムが排除された結果である。
Perlが全滅。その他もかなり少ない。
そんな中でHaskellの生存率の高さが際立っている。
次のページ(62ページ)は最終的にpre-twistで生き残ったプログラムである。
プレイオフで6試合ほどさせられた結果だ。
C++がついに一チームに。さっきまで7チームあったので、
C++バグりすぎ、といったところか。
Ocaml、Java、Haskellがまだまともといえる数を残している。
もちろんトップはHaskellだ。

ここまでがpre-twistである。
以降、twistバージョンの結果。
63ページにはtwistバージョンを提出したチームが示されている。
twistにおいてはゲーム内容が著しく変化、
制限時間が24時間しかない、というのを考慮しなければならない。
つまり、twistを潤滑に提出できたということは、
今回のテーマであるre-hackを潤滑に行えたということになる。
ここではC++、Java、Perlがとても低い数字を示している。
Haskellはここでも一番である。
(ちなみにこれを受けてスライドの横のコメントに、
再利用可能なコードを書きやすい言語であるHaskellを開発していること、
および再利用可能性に重きをおいていることについて、
Haskellコミュニティを褒め称えよ！のようなことが書いてある。
つまり、Haskellが再利用性が高いコードの書ける言語であると公に認められている)
そして次(64ページ)がtwistのregular season でバグらなかったプログラム。
このあたりからHaskellが著しく高い値を示し始める。
次(65ページ)がtwistのジャッジに打ち勝ったプログラム。
Haskell以外のプログラムが悲惨な数字になる中、
Cがなぜか高い数字を示している。何でだろうか。
そして、次66ページが最終結果、
twistでジャッジにも勝って、プレイオフでバグも出なかったプログラムである。
twistのプレイオフは350試合あるので、pre-twistよりも条件は厳しい。
見て分かるとおり、なんと9チームしかない。
うち三チームがHaskell、あとは
C++,Ocaml,Python,Java,C,その他(というか、Dylan)がひとつずつである。
(9チーム中3チームもHaskellがあったというのは特筆に価する)
つまり、今回はまともなプログラムを提出できたチームが
たったの9チームしかなかったということだ。
うちのチームはその中で3位ということになる。

さて、ここで考えなくてはいけないのは、
正しいプログラムを書くというのがいかに難しいことか、ということだ。
今回はそれに加えジャッジに勝たねばならないので、
一概には言えないが、まさかここまでまともに動くプログラムが
少ないものだとは思っていなかった。
たとえば去年のような形式(仮想マシンに対するプログラムを提出)だと
多少バグっていても失格にはならないので、
今回のようにプログラムそのものを提出する形だと
世のプログラムにいかにバグが多いのかということが顕著に現れたのだろう。
ところが、うちのチームは幾度のマッチにも一度たりともバグっていない。
特に気をつけたわけではないので、何も意識せずに堅牢なコードが書けたということになる。
これが言語の力でなくてなんであろう？

ここでエンバグ効率という言葉を考える。
仕事量に対してバグを仕込む効率であるから、
もちろん低いに越したことは無い。
Haskellはこのエンバグ効率が低いのではないかというのである。
ちなみに、エンバグ効率とデバッグ効率は相反する言葉で無ければ
直接関係のある概念でもない。
デバッグ効率はすでに仕込んでしまったバグを如何に発見、修正しやすいか、
エンバグ効率は如何にバグをしこみやすいかなのだ。
(ちなみに先のスライドではC言語はバグを見つけにくく、
後になってからそれが発現するのではないかと指摘されている)
Haskellのエンバグ効率が低いのは先の統計からも明らかである。
(スライドによると再利用効率も高い)
ではなぜ低いのか？
純粋関数型言語ゆえに値の書き換えが無い、
強力な型システムがコンパイル時にバグを見つけてくれる、
などがそのあたりの解答ではなかろうかと思っている。
これらはコーディングスタイルによらずHaskellを使っているだけで
受けられる恩恵なので、それだけで他の言語よりもバグが出にくいはずだ。
実際のところ感覚としてはそのように思う。

そういうわけで、今回の結果として、
やはりHaskellで書いたプログラムはバグが出にくい、といえるだろう。
いとも簡単に堅牢なコードを書ける。これは大変な長所なはずなので、
これからアピールしていっても良いのではないかと思う。