『BEST SOFTWARE WRITING』を読みました。
理屈ばっかりの眠たくなるような本ではなくて、良いストーリーで楽しく読むことができました。
示唆に富む話が多く、勉強になりました。

一つは、今更ながらJavaのチェック例外について。

『Thinking in Java 第3版』では、RuntimeExceptionをチェック例外を「オフ」にするためのラッパーとして使う方法を示した。
今ではそうするたびに、それが正しいことに思える。

IBMのdeveloperWorks Japanにチェック例外についての記事(Javaの理論と実践: 例外をめぐる議論)がありました。
チェック例外の利点は「例外がソースコードに文書化される」こと、
短所は「実装の詳細を不用意にさらけ出している」「不安定なメソッド・シグニチャー」等。
結局は適材適所かもしれませんが、文書化できればすべてチェックなし例外でも良さそう。
Javaに大きく影響を受けて作られたC#がチェック例外の機構を受け継いでいませんですし。

次に静的型チェックについて。

「テストされていないものは、壊れていると思え。」

コンパイラはテストの一形態にすぎないい、という考え方が面白く感じました。
大切なのは強いテスト。
コンパイルが通っただけではプログラムの品質は保証されません。

確かにその通りだと思います。
みんながちゃんとテストを書いてくれると動的型言語でも良いのですが。
開発環境のサポートなどを考えると、静的型言語の方がソースコードに情報が多い分、コード補完の機能など利点も少なくないように思います。
将来的には開発環境が賢くなると、静的型言語の利点が失われていくのかもしれません。

ちょっと脱線しますが、

もし静的型チェックがそれほど重要であるなら、なぜPythonで大きく複雑なプログラムを（静的型付け言語に比べてずっと少ない時間と労力で）構築することができるのか？

Pythonがしばしば「実行可能な擬似コード」と呼ばれる理由がわかるだろう。
これは擬似コードとして使えるくらいシンプルであるだけでなく、実際に実行できてしまうというすばらしい性質を備えているのだ。

Pythonに非常に好意的な意見だったので嬉しい文章でした。

XP(エクストリームプログラミング)について。

今日では、エクストリームプログラミングを実践していると主張しているプログラマたちの多くは、それをお気に入りのものを提供してくれるメニューみたいに扱っていて、彼らはその中から好きなものを選び（ドキュメントなし！イェイ！）、嫌いはものは無視し（テスト駆動開発、ペアプログラミング）、結果として、私たちが伝統的に「早撃ちプログラミング」と呼んでいるものに落ち着いている。

この文章には笑ってしまいました。
たしかに教典の中から自分に都合の良いものだけを選んでいて、都合の悪いものは無視しているケースが多いと思います。
テスト駆動開発とペアプログラミングの他に、ソースコードの共同所有やYAGNIもあまり実践されていないように思うのですが、どうでしょう。

『BEST SOFTWARE WRITING』のような面白いプログラミングの本がもっと出版されるといいですね。