今月の情報処理学会の会誌「情報処理」で，プログラミングコンテストが取り上げられていました．
Short Coding ~職人達の技法~は，私が知る限り，オンラインジャッジについて触れた数少ない(もしかして初めて?)本です．処理系の特性を深く理解して，字数を減らそうという試みは，ちょっと大学では教えにくいですが，本道ではないことを承知した上で勉強するのはいいことだと思います．p.371の表の「明解に書こう!」は，ひそかなお気に入りです．
また，EPOCH@まつやまの競技ルールというのも知りました．予選で，プログラムの見易さが評価に含まれているのが，興味深いです．
研究室内で，プログラミングコンテストの問題を解くゼミをやってきましたが，コンテストそのものにプレイヤーとして，あるいは主催者an organizerとして参加するのは，自分の能力では難しいです．
そんなときにふと，「デバッグコンテスト」というのを構想しました．‹^–â‰ðŒˆ‚Ì•”‰®によると，β版(評価版）に関して『バグを見つけると賞金がもらえる"デバッグコンテスト"などが開かれる場合もある』そうですが，もちろん別物*1です．
妄想するデバッグコンテストの基本ルールは:
- 参加者は，非テキストの形態*2で与えられたソースファイルをタイプします．
- もとのソースファイルには，1個以上のバグが含まれています．修正して，公開または非公開のテストケースすべてに通れば，デバッグ完了です．
勝敗をつけることができます．修正箇所が少なければ少ないほど，良いデバッグ*3とみなします．もとのソースファイルをXとして，2人の学生が修正して作ったソースファイルをA，Bとしたとき，
- 「XとAの異なる行数」と「XとBの異なる行数」を比較し，小さい方の勝ち．
- 異なる行数が同じなら，「XとAの異なる字数」と「XとBの異なる字数」を比較し，小さい方の勝ち．
- 異なる字数も同じなら，先に作成したほうが勝ち*4．
こんなデバッグコンテストの効果ですが:
