15:39:31 [g000029'in]
15:39:48 <g000029> 今日も Successful Lisp / David B. Lamkins ぼっち読書会やります
15:39:52 <g000029> (((Chapter 28 - Practical Techniques for Programming)))
15:41:32 <g000029> コーディングのスタイルについての話みたいですね
15:41:37 <g000029> http://psg.com/~dlamkins/sl/chapter28.html
15:41:44 <g000029> ((((Elements of Lisp style))))
15:45:52 <g000029> lispは構文が単純なので、より複雑な文法を持つ言語より、見た目についてスタイルがどうこうというのは少ないという話のようです
15:46:12 <g000029> コードのサイズもコンパクトにまとまると
15:47:36 <g000029> また、emacsのようにインデントなどの面倒を見てくれるエディタを使っていれば、細かいところは任せておけば良いというのもあると
15:48:03 <g000029> 逆にlispの支援機能がないエディタは使うべきでないともあります
15:48:50 <g000029> これは確かにそうかなと思います。全部分かった上でがんばるなら良いと思いますが、大抵変な見た目のコード書いてる人は、知らないけど突っ張ってる人が多いですね
15:50:08 <g000029> ということで見た目についてはそんなに語られないとすれば、何を語るんだというところになりますが、適切なデータ構造の選択や読み易いコードの話をするようです
15:50:15 <g000029> ((((Property lists are handy for small (very small) ad-hoc databases))))
15:54:39 <g000029> 大昔(Common Lisp登場より前)の処理系ではデータ構造といえば、リスト位しかなく、またシンボルのプロパティを活用していたという説明です
15:55:10 <g000029> 確かに80年代位の古いAIの本にはプロパティリスト説明があったりします
15:56:08 <g000029> プロパティリストも色々できたりするのですが、定義が大域的であることにより排他制御が難しかったり、アクセスがハッシュより遅かったりするのが問題であることが説明されています
15:58:20 <g000029> 簡単に言えばプロパティリストよりもっと良いデータ構造があるよという話ですね
15:58:38 <g000029> ((((Declarations help the compiler, sometimes))))
16:07:12 <g000029> 話は変わって、宣言の話です
16:07:33 <g000029> 各種宣言の話がありますが、特に最適化についての説明があります
16:08:51 <g000029> 基本的に、Common Lispでは、デフォルトでは、実行時の型チェックがされるため
16:09:17 <g000029> 安全な方に舵が切られるという感じですが、
16:09:35 <g000029> 最適化の宣言は、型を宣言することにより、この実行時の型チェックを省く
16:09:38 <g000029> という感じになっています
16:10:29 <g000029> 間違った型のオブジェクトが渡されたりすれば、より危険なコードになるわけですが、
16:11:16 <g000029> 実行時の型チェックが省かれる分だけ高速になる、というところです
16:11:54 <g000029> この辺りが詳しく書いてあるという感じです
16:12:01 <g000029> ((((DEFVAR versus DEFPARAMETER))))
16:16:53 <g000029> 何故か前置きが非常に長いのですが、DEFVARとDEFPARAMETERの違いの説明です
16:17:30 <g000029> DEFVARは既に値が束縛されていれば、再度フォームを評価されても新しい値にはならないのですが、
16:17:53 <g000029> これがファイルを何度も読み直したりする開発中に役に立つ、という説明です
16:19:25 <g000029> ファイルを読み直す度に再度初期化されたり、予想しない値に変化したりすると厄介なバグになりますが、そういうものを防ぐために導入された、というようなところです
16:20:03 <g000029> Venue Medleyのようなイメージベースの処理系の説明があったりして、マニアックなセクションだなと思いました
16:20:55 <g000029> それとスペシャル変数には耳当て(**)を付けるという規約の説明があります
16:20:58 <g000029> *foo*のような
16:21:07 <g000029> ((((Define constants with DEFCONSTANT))))
16:22:58 <g000029> defconstantの説明です。大域的な定数の設定に使いますが、コンパイラは、コンパイル時にこれらを即値に置き換えるという最適化を行なうことがあるという説明です
16:23:19 <g000029> 名前の規約として、+foo+という風に書くプログラマもいる、という説明があります
16:24:49 <g000029> Common Lispの策定の投票項目にもあったみたいですが、スペシャル変数のように何か印を付けるかどうかについては、付けないで決定されて、今に至ります
16:25:38 <g000029> +foo+のように印を付けるとみやすい気はしますが、束縛や代入で使われるとコンパイラが警告/エラーを出すことがほとんどなので、見逃すということはないですねー
16:25:58 <g000029> ((((Know when (not) to use the compiler))))
16:33:55 <g000029> 処理系には大抵インタプリタとコンパイラが付いてくるということで、
16:34:33 <g000029> 使い分けの説明ですが、SBCLや、CCLはコンパイラ指向の処理系なのでインタプリタがなかったり、あっても実験的な位置付けだったりしますね
16:35:25 <g000029> インタプリタの方がデバッグしやすいので、開発時はインタプリタを使うのがお勧め、とのことですが、ここでいうデバッグは、動作についてのデバッグかなと思います(多分)
16:36:01 <g000029> コンパイルすると静的なチェックはしやすいので、これでもある程度デバッグできたりはします
16:36:40 <g000029> でも、コンパイルすると変数の情報が消えてしまったりするので、対話的なデバッグはやりにくいので、このことを指しているのではないかなーと思いました
16:38:12 <g000029> また、マルチプラットフォームでの開発でのファイルの読み込み方法について解説されています
16:38:55 <g000029> まず、インタプリタでファイルをコンパイルすることなしに全部読み込み、それからファイルをコンパイルし、コンパイルしたファイルを読み込むのが一番安全ということです
16:39:48 <g000029> これについて理由が説明されていますが、マクロの定義の依存問題等は確かにこれで解消される気はします
16:40:14 <g000029> とにかく、安全に読み込むということなら、これが良いのかもしれないですね
16:41:36 <g000029> しかし、最近のASDFや、その上に構築されているquicklispだと普通にコンパイルするので、コンパイルされても問題ないように書くという方が推奨される気がしますねー
16:42:18 <g000029> ((((Speed vs. ability to debug))))
16:45:16 <g000029> 速度とデバッグについての話ですが、開発時には最適化設定で、safetyを最大にしておき、可能ならインタプリタで実行、コンパイラのみの環境ならspeed最小、debug最大にして
16:45:56 <g000029> コードに問題がなくなったら、必要に応じて最適化オプションを調整、最適化の必要がなければ、そのまま、という指針が述べられています
16:46:11 <g000029> これはその通りというところですね
16:46:17 <g000029> ((((Efficiency: spotting it, testing it))))
16:53:49 <g000029> lispで陥りがちなパフォーマンス上の問題点と解決策の説明です
16:55:33 <g000029> リストの構造的特徴を把握してないというのは割とありがちですね
16:55:56 <g000029> 末尾再帰云々も良く議論されるところではあります
16:56:03 <g000029> ((((Recognizing inefficiency, profiling; performance vs. readability))))
17:01:10 <g000029> パフォーマンスチューニングについての話です。割と言語に関係ない一般的な説明があります
17:02:44 <g000029> チューニングをするとしたら、ボトルネックをまず確認することが大事で、大抵の処理系はプロファイラをもっているので活用し、ボトルネックみつけて解消という感じです
17:06:04 <g000029> lispでは、可読性かパフォーマンスの二択を迫られることもなくチューニングできることがほとんどなので、適切な抽象化と最適化の手順を踏みましょう、ということみたいです
17:06:43 <g000029> ということで、28章は終わりです。次回は29章から再開です
17:06:57 [g000029'out] ; Quit: (quit)