Pythonと型
- http://www.rubyist.net/~matz/20050107.html#p01
- http://www.artima.com/weblogs/viewpost.jsp?thread=87182
これ*1って嬉しいの？
まず，静的型言語*2で嬉しいことを整理してみよう．
- 型エラーをコンパイル時に検出できる
- 型が明示されることにより，プログラミングが容易になる
こんなものだろう．言語によっては型推論などにより，型の宣言を省略できるので，2が成り立たないこともある．2はデメリットという考え方もできる．まあ，僕としてはオブジェクト指向言語くらい複雑になっちゃうと，メリットの方が大きいとは思うが．
- 型宣言しなくていいのでプログラミングが楽
- プログラムが柔軟になる
といったところか．2はちょっとわかりにくいかもしれないが，例えば「Rubyではwriteメソッドを持っている言語はなんでも関数fooのパラメータとできる」みたいな感じだ．Javaだと「IBarというインタフェースを完全に実装した言語しか，(IBarのwriteメソッドしか利用していないにもかかわらず)fooのパラメータとできない」となり，柔軟性が下がる．*4
それを踏まえてPythonを考えてみる．
x = adapt(x, t1)
という式は（多分）実行時に実行される式である．C++のdynamic_castと同じ．ということは，関数適用の型エラーを実行時まで検出できないことになる．これって嬉しい？僕はべつに嬉しくない．
一方で，この型チェック機構の導入によって，t1はxの型のサブタイプに厳密に一致していなくてはならないことになる（のだろう）．t1を，各関数ごとに必要十分なものを定義すれば，これまでと変わらないことになるが*5，そんなわけにはいかないだろうから，やっぱり使い回すことになり，結果動的言語の柔軟性(2)が失われることになる．
総括すれば，得られることは「型宣言を明記することにより得られる，プログラムの読みやすさの向上」であり，失うものは「プログラムの柔軟性」である．これって，良い取引かな？僕ならこんなPythonは使わない．C#かJavaでいいじゃん．議論も燃え上がるわけだ．
Optionalなんだから使わなければ良いという考えかたはあるが，使わない機能を実装するのは単純に時間と手間の無駄である．別に僕が実装するわけじゃないんで，Guideが良いんなら良いんだけど．
RubyとPythonは，共にOOPLなLLということで，並べて語られることが多いが，この拡張で言語の性質に決定的な違いが出てくる気がする．僕が支持するのは，Rubyだな．
DBCは便利かも．これって，Rubyなら特に言語に拡張を加えなくてもできそうだけど．これをコンパイル時にできるようになれば，もっと嬉しくなると思うけど・・・できるかな？
ある程度ならできると思うけど．コンパイル時に検証できるAssertionと実行時まで検証できないAssertionが混在している状況は，多分あんまり嬉しくないよね．でも，それを言うとTyping Rubyもいっしょか．
