クラッシュ・バンディクー1 TA 全一宣言

昨日の配信で達成。
Peercast Record/クラッシュバンディクー

 
ラップタイム
パプパプ    0:07:17
リパールー    0:15:51
コアラコング    0:28:52
ピンストライプ    0:37:21
ブリオ    0:48:22
コルテックス    0:51:39

私より速く走れる方がいらっしゃいましたらご連絡ください^^

追記
抜かれたので再挑戦中

追記

夏のプログラミングシンポジウムを見てきました

夏のプログラミングシンポジウムに午前中だけ行ってきたの感想を書きました。

プログラミング美学

• プログラミング美学
• プログラム美学
• プログラミング言語美学

ギリシャ時代の美への探求を例に出してプログラミングの美に関する考察など。

鑑賞に知的活動が必要→「つまり素人には理解できないということであります」

(´；ω；`)

「コンピューターを非機械的に扱える人はプログラミングのセンスがある」

クラス一つ一つが人か何かに見えてくればセーフかな？

「受注というスタイルでは美を追求することは難しいだろう」

等。後半はさっぱり話についていけなくなった。

最後にデモがあったけど今までの話と何がつながってたのかよくわからなかった。「美しい」って、やっぱり鑑賞用とかじゃなくて、整理整頓するってことじゃないのかなあ。プロ勢怖い…

Beautiful Error Handling

エラー処理は汚くなる

一般的できれいな方法がない

美しいプログラムは理解しやすい。変更しやすい。バグりにくい

これ。これを目指したいですよね。

エラー処理：堅牢なプログラムに必要な処理

• タイムアウト
• 無線が切れた
• 自分のバグ

「（自分要因だろうが他人要因だろうが）通知しなきゃならない。最近のトレンドは例外を飛ばす」

エラーの抽象化 / エラーを受け取る側の抽象化

の２つの話で成り立ってるわけね

まとめ

プログラマは職人であるべきだけど、現実に職人である人は少なくて、多数の凡人も職人のようにプログラムを書ける必要がある。（だからHaskellを使いましょう）

Beautiful Programming Language and Beautiful Testing

このプレゼン資料emacsなんですけどぉ（どやぁ

Haskellの規律

Haskellのお勉強。pure関数とそうじゃない関数に分かれてるという話。副作用がある場合は「IO」という構文が入る。やばいちょっと楽しそう。

型チェックが固いからバグが入りにくい。型が台無しにならない。→値に関する誤りは残る（0除算など）→Haskellでもテストを書くべき

Haddock

利用例ドキュメントとテストコードを兼ねる記述。C#とかJavaとかにも欲しいなあ

バグのない二分探索が実装できたのは発明から12年後

Haskellerはもっとテストを書きましょう

一言に「美しいコード」と言っても、整理整頓されたコードだったり見た目が美しいコードだったり、いろいろ考えさせられるものがありました。