2013/03/02

型論争

ふたたびの盛り上がりを見せてる静的vs動的型論争だけど、これを「適材適所でしょ」 というtrivialな話で片付けたくないのは、双方の主張に(あまり意識されない)前提があって、 その前提をはっきりさせることには意味があるんじゃないかなと思うから。

それぞれの文化には慣習みたいなものがあって、そういうのは その文化における弱点を自然に回避するように形成されてるんじゃないかと思う。 だから一方の陣営がいくつかの具体的体験を頭におきつつ一般化して「この手の問題で困るでしょ」 と話を振っても、もう一方の陣営にとってそういうスポットは「わざわざやろうとは 思わないし、やる必然性も無いし、慣習にしたがっていたらそもそも思いつきもしない」こと だったりするんで、ピンとこない。

静的型チェックがあれば型エラーを機械的にはじけるよ、と聞いた動的型プログラマが 「でも型エラーなんてtrivialなものでテストやコンベンションで簡単に防げるし、 それより型で捕まえられない類のエラーの方がずっと大きいでしょ」と言う時、 彼の頭の中には「『<X型のリスト>を取り<整数>を返す』関数と『<整数>と<文字列>を取り<整数>を返す関数』を引数に取って『<文字列のリスト>を取って【{<整数>を取り<X型>を返す関数}を取って{<整数>を取って<整数>を返す関数}を返す関数】のリストを返す関数』を返す関数」みたいなものを書く、なんて事態は想定されてないのだと思う。だってそんなの書こうと思わないし、書いたらハマることはわかってるから もっと分解してわかりやすいように書くでしょ。

でもそういう妙な型を考えるとすんごくすっきり書けるケースってのがあって、そういうのをSchemeで書いてると「整数を返す関数を返す関数」が要るところに「整数を返す関数を返す関数を返す関数」を使っちゃった、なんてことでハマって型のサポートが欲しくなる。(printfデバッグしてもあんまり役に立たない。どっちも関数としてしか表示されないから。関数をレイヤごとに別クラスのオブジェクトにくるんでやれば区別が付くけど、それっていちいち型宣言してるのと手間は同じになるし)。

動的型の強みである時定数の大きなケースというのも、静的型開発では「そもそも非平衡状態は速やかに収束させるべきものである」という運用でやってるから(参考: これとかこれ)、なんでわざわざ不安定な状態を長引かせたいのかわからん、てことになるんだと思う。

私は『Land of Lisp』の性格テストではCと答えるどっちも欲しがりなんだけど、 こういう出発点の違いがあるから、 そう都合良く双方の良いところ取りはできないだろう、とは思っている。

「動的言語にアノテーションを入れて少しずつ静的検証…」ってことを書いたら 「それってgradual typing」って反応があって、 確かにそれも一つの解として視野に入れてるんだけど、 それがあるからって高階な型をばりばり使えるようになるかというと多分そうはならなくて、 動的な文化の出発点というのはあまり変わらないだろうな、と思う。

Tag: Programming