https://twitter.com/kinaba のログ (twilog の方が便利です。)
| #SRM うわああああああああああああリテラルにLLつけるの忘れたああああああああああああああああああああ | |
| #SRM よっしゃ0点ゲット | |
| 二点の中点だけだとだめなのかー。ぬぬぬ | |
| s/1<</1LL<</ したら通った…orz | |
| @naoya_t 寝る前に100LL回書きます！ | |
| ビットで集合を表すケースは完全にライブラリ化しとくべきだよなあ、と思いつつ、でも今回のは集合ではなくて純粋にビットの演算だしなあ。どうしたものか | |
| 書き取り練習終わったので陽だまりのピニュの5LL巻を8LL回くらい読み返しながら寝よう。 | |
| http://d.hatena.ne.jp/nodchip/20090724/1248408482 極論だけどもし仮に"エレガントなコードを書けば回答を早く取得する確率が高ま"らないなら、そこからは「そもそもエレガントなコードなんて目指すべきではない」って結論しか出てこないと思うんだよな | |
| ２つ前提があって (1) クリーンなコードを書くべきなのは「その方が開発が楽だから」であってクリーン性そのものが最終目標じゃない / もし仮にクリーンなコードを書いても開発が楽にならないことがわかってしまったなら、それは目指すべきものではないということだ | |
| 極端な方の前提としては(2)ICPC等での回答を早く取得する確率と、コンテストに限らない一般のコーディングの際の開発力はそれなりに関連する / 立証する調査が欲しければ http://japan.internet.com/busnews/20090423/8.html とか。ICPCでもSRMですらないから、まあちょっと無理がありますが | |
| とはいえ元記事にはそれなりに同意していて、つまり、「コードの綺麗さ」を明確に評価基準にした教育やコンテストはあっていいと思う。間接的に役に立つ、と述べるだけではなくて、明示的に光を当てる価値はあるはず。 | |
| @fkm 速度を考慮して書くことってないなあ…。可読性や拡張性を損なうような速度最適化をしないと解けないような問題は、ICPCとかでも「問題が悪い」という評価が下されると思う | |
| @fkm 可読性＆可書性(?)を理由にならやりますね＞配列の最大サイズを固定値。C++の多次元vectorとか面倒くさくて死にそうになるので…。速度のために配列を使うのは一度vectorで書いてTLE食らってこのクソ問題め…と言いながら渋々かなあ | |
| @fkm やー、書き方は人それぞれなので、それじゃダメだということも特にないかなあと。上位陣のコードでも読めない人のは読めないですし… | |
| 競技プログラミングに強くなれば良いコードが書けるようになる、という方向の主張はする気がなくて。どっちかというと逆向き。「プログラミングコンテストだから普通とは違う書き方をしなければならない」なんてことは決してない。良いコードが書けるというのはコンテストにおいても常に強力な武器だ。 | |
| 「可読性の高いコード」でも「ペアプロ」でも「テストファースト」でもBDDでもデザパタでもなんでも、みなさまの好きな技法は全てプログラミングコンテストに活かせるし、"普通の"プログラムは得意だというひとはもっと自分の持てる業の適用範囲を信じていいと思うよ、という | |
| @andochin あ、はい、どうぞ、とゆーかグロいアイコンですみません。 | |
| アクオス前ってそんな人数集まれるスペースあったっけか | |
| @camlspotter 実は密かにわらいぶくろより使える魔法の数が少ないおどるほうせきです。よろしくお願いします。 |