テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

プロコンRubyアカン・・・

この前のARC037で惨敗したので, プロコンしばらくやってみようかという気になっている.

Rubyでちょっとやってみた結果, Rubyアカンという結論になった. アカン理由を列挙する.

  1. だるいはずのC++の方がstdinの取得がなぜか楽. Rubygets.split.map(&:to_i)とか書く必要があり, 結構うんざりする.
  2. Rubyで美しく書けるぜ!と思って書くと, 大抵TLEする. 組み合わせとかを全部生成してから処理という関数的な考え方はダメ(現実社会ではふつうこちらが好ましい). そういう場合は大抵はdpしないと死ぬ.
  3. そもそも想定解法でもTLEすることがあって, これは萎える. 主催者側も, 全言語で試験してるわけではないんだろう.
  4. 配列の確保が遅い. 例えば3003の3次元配列を確保しようとすると数秒かかる. この時点でTLE. int dp[300][300][300]と静的に確保すべき.
  5. 関数が外のスコープの変数にアクセス出来ない. アクセスしたいならば@をつけるか, 大文字変数にする必要があり, だるい. dpするためにlambdaで書くとかいう作戦に出るが, ラムダは引数が[]再帰呼び出し箇所の可読性が致命的に死ぬケースがある.
  6. 標準にpriority queueすらない. プロコンでは結構使う(グラフ系で). おそらくMatzがプロコン嫌い.
  7. 利用人口が少ない. ライブラリをパクろうとしても, コードが見つからない.

一般的なプログラムをするのであればRubyは大変良いのだが, その魅力のほとんどはプロコンでは関係ない. Pythonはどうかというと, 結局あんまり変わらない. 上のリストでは, priority queueがあるくらい. スクリプト言語のデバグのしやすさなるものも, プロコンにはあんまり関係ない. なぜならば, プリントデバグしたくなるケースがほとんどないから. そういう状況になったらすでに負けてる気がする. 特にdpとかはプリントしたところでデバグするのほぼ無理. 一発で正しい論理を書くしかない.

プロコンというものはC++でやるように作られているのだという結論に至った. 問題AだけはRubyで書いてfastestとるとかいうのは面白いかも知れない. ワンライナーで書けることも多いので.

ところで, プロコンというのはプログラミングという名前を使うべきではない. アルゴリズムコンテスト, 略してアルコンとでもした方がいい. これをプログラミングと言われると萎える. アルコンではライブラリを利用する場合はソースコードに直接貼り付けろなんだけど, あまりにも現実のプログラミングとかけ離れた考え方で本当に害悪なので, 実行前にライブラリのインストールを許す形式にした方がいいと思う. もしそれを許さないのであれば, ライブラリなどのデータ構造も全部禁止しないと矛盾してる.

大変萎えたが, 本人は嵌ってしまって夜も眠れない感じなので, しょうがない.