今日はビューティフルコード (THEORY/IN/PRACTICE)の読書日にした。
＃読み進めながら付け足していきます
小さな文字なのに６００ページもある。
それでも１章あたり１０ページ前後なので、とても読みやすい。
ただ、内容がとても高度で中々理解にまで結びつかない＾＾；
１章：正規表現マッチャ
いきなりカーニハンですか(笑)
正規表現のコードがとても短い。
こういうのを見ると自分がまだまだだなぁ、と思ってしまう。
シンプルでキレイでそれでいて難しい問題を簡単にしている。
そんな印象。
ただ、イマイチ使い方が分からないので、入門 正規表現 ~検索・置換・テキスト処理に強くなる!でも買って正規表現自体を勉強するかな。。。
２章：Subversion の差分エディタ
抽象化の度合いについて。
いきなり難しくなったので、美しさが理解できましぇん＾＾；
プログラムって具体的に書かないと動かないけど、
プログラムって抽象的に考えないとキレイに書けないよね。
３章：私が決して書かなかった、一番美しいコード
クイックソートの性能分析。
相変わらず書いてることはほとんど理解できないけどこれは納得できる。
- コードを削ることで機能を追加しなさい
- デザイナーが自分は完璧に達成したと分かるのは、付け加えるものが何もないのではなく、取り去るものが何もない時である（サン＝テグジュペリ）
章中に何度も出てくる珠玉のプログラミング―本質を見抜いたアルゴリズムとデータ構造が欲しくなった＾＾；
４章：ものの見つけ方
やっと理解できる内容に。
｢正規表現を習得していない本物の熟練プログラマなどというものには、私は出会ったことがありません｣が衝撃的＾＾；
ものを見つけるときは
- 言語に組み込まれたハッシュ表を使って解決しようとする
- それで駄目なら、２分探索木を使ってみる
- それでも駄目なら、しかたなく、もっと込み入った他の方法を考慮する
よく覚えときます。
５章：正しく、美しく、早く（この順番で）
最終的な最適化はテーブル化。
配列のインデックスで検索できるようにするのが一番単純で速い。
一つ勉強になったのが、P67 例5-5 にある検証最適化版。
こういう考え方は頭になかった。
速いけど醜いコードを美しくするよりも、
美しいけど遅いコードを速くする方が
ずっと容易である。
醜いコードは見にくいコードなので、美しくすることは難しいし、仮に美しくできたとしても、それが正しいか、速いかの検証が大変そうね。
