最近、dynamic typingな言語の元気がいい。Webサイトなどはスクリプト言語で開発すると開発サイクルを短くすることができ、リリースサイクルの短さが物を言う昨今、時代にフィットした言語のように思われている。数年前に働いていた会社ではシステムをほぼPythonで開発していた。確かに開発はしやすいのだが、今はPythonで全部作ってくれって言われたら、あんまりやりたくない。ネックになる問題はリリース後のシステムの運用だ。

dynamic typingな言語はその字の通り型チェックを行わない。そのため型エラーは実際にそのコードが走ったときにならないと発生しない。システムをリリースし、運用を開始した後にバラバラとエラーが出ることになる。ユーザーに見える問題になる訳だし、エラーが発生すれば緊急に対応しなければいけない。滅多に走らないコードだったりすると、しばらくしてたまに落ちるなんていう現象も起こってしまう。このため、システムのメンテナンスが非常に頭の痛い問題になる。

dynamic typingな人たちの言い分は、テストコードをしっかり書いてユニットテスト、レグレッションテストをしっかりやっていれば、ほとんど問題にならないという。しかし、システムが大きくなればなるほど、外部依存関係が増えれば増えるほど、テスト環境を作り出すことが難しくなってテストしきれなくなってくる。バックエンドにリクエストを投げたら、タイムアウトした場合とか、複数のバックエンドから集めてきたデータが内部でこう表現されたときに走るコードなんていうのは、再現が難しい。こうなってくると、テストドリブンで開発すればいいとは言っても、現実的には難しい。

そうはいいつつ、言い分は判るのだ。Strongly typedな言語は開発スピードが遅くてたまらん。字面だけ見ても判るがJavaのコードの煩雑さはIDE無くしては開発できないのではないかと思うほどだし、C++にしても、リストをスキャンするだけでもやたら滅多らゴチャゴチャ書かなければならない。

Pythonだったら
なのが、C++だったら
になる。その上、コンパイルを待つ時間も馬鹿にならない。このコンパイルを待つ時間は開発効率に一番影響を与えている気がする。

データの型をちょこっといじるとリファクタリング作業になり、これまたIDEを使わないと手間ばかりかかることになる。

その代わり、一度うまくコンパイルされれば、型エラーは発生しない訳で、リリース直後からトラブルに見舞われることは、スクリプト言語に比べると格段に少ない。精々segmentation faultぐらいのものだ（とこれも困るんだけどねぇ）。

まとめてみると、解決しなければならない問題は2点ある。

1)リリース後のエラー発生が少なくなること
2)開発効率が上がること

今の時点では1)の問題の方が大規模・高負荷のサービスでは問題。そのために2)にはしかたなく眼をつぶっている。

最近の傾向としてみれば、C++に比べてJavaの方がメモリ管理に関連するバグが出にくいため、1)について有利であり、パフォーマンスがそれほど重要でなくなってきている今、Javaを選択する開発プロジェクトが増えているように思う。

しかしながら、エンジニアの中でのJavaの評判は下がる一方で、冗長なソースコードが嫌われる傾向が一段と濃くなってきた。つまり、2)への批判だ。面白いことを言っている人が居た。曰く、「strongly typedな言語って、bureaucracyだよね」と。　型チェックを通すためにそこらじゅうのコードを直したり、型宣言をしつこく書くのは、やたらに書類を書いて出さなければいけなかったり、お役所仕事でちょっとしたこともなかなか実現しないのと非常に似ている。

お役所仕事を嫌うとすれば、型チェックだって嫌っていいんじゃないの？と自問自答したくなる。かといって、実行時エラーの尻拭いは嫌だ、とジレンマに苦しむばかりだ。

型をいちいち書かなくても型を推論してくれるOCamlは、なんとなくこの問題を解決してくれるような気がするんだけどなぁ。。。。しかし、如何せん関数型プログラミングは、しょうもないことをするのにとても複雑な手法を採らなければならなかったりすることもあって、みんなが使う言語にはなれそうもない。

2005/12/30

用語
dynamically-typed languages
statically-typed languages

dynamic typing
static typing

strong typing
weak typing