  |
http://d.hatena.ne.jp/perlcodesample/20130227/1361928810
たとえ動的型付けでも整数と文字列は足せないわけで、結局型がないわけではない。そう言った意味で、動的型付けの恩恵を得るには暗黙の型変換が必要不可欠だ。またダックタイピングによって関数へ適用できる型が静的な言語より広いことが多い。そう考えると動的型付けのパワーは、関数に渡せる値が幅広いおかげで以下の2つのご利益があることだと思う。
動的型付けをする言語では、ほとんどのものを文字列や、汎用のリスト型や辞書型のまま表現することが多い。これに対し、静的な型付けをする言語では専用の型をどんどん用意し、それらの型を変換する関数を用意しておく。型が多ければ多いほど、関数は部分関数から全域関数へと近づく。つまり不具合は減る。よって、静的な型付けをする言語で正しく型を設計することで不具合を減らすことができる。
しかし、その分型を明示的に正しく変換する必要がある。IPアドレス型、HTTPヘッダ型、Cookie型、ファイル型・・・様々な型をそれぞれ正しい記述で書く必要がある。対して動的な型付けの言語ではこれらを文字列や辞書型のまま扱う傾向が強いので、それっぽい文字列やそれっぽい辞書をマニュアルなしで組み立てて関数に渡すことができるので、開発工数が低い可能性がある。
もっとも、IDEが優秀であれば型変換する関数を正しく予測してくれるのかもしれない。ので、型変換するコードを瞬時に書ける程度優秀なIDEがあれば不具合が少なくて済む分静的型付けの方がいいし、そういうIDEがないのであれば文字列や基本型だけの知識でどんどん書ける動的型付けに軍配があると言えるんじゃなかろうか。
不具合のないプログラムを書くのであれば、動的型付けでも静的型付けでも生産性は一緒な気がする。むしろ静的型付けの方が不具合が入り込む余地がもともと少ない分生産性は高くなるだろう。多くの人が認める通り、不具合のあるプログラムを書くことはプロとしてあるまじき行為で、恥じるべきだ。
しかし、不具合のあるプログラムは世の中に存在しえないもので速攻削除すべき、と考えるのは行き過ぎだ。残念ながら現実は学問や理論の世界とは違う。プログラムが以下の条件を満たす場合、不具合があってもなくてもいいので、とにかく素早く作ることが求められる。不具合があってもいいのであれば、前述したように少ない知識でも適当に組める動的型付け言語の方が、とりあえず動くまでの期間や人的リソースの調達のしやすさなど、軍配が上がる可能性は高い。不具合のあるプログラムでも許容されるのは以下の場合だ。
3つ目の理由がとにかく大きい。「1日でバグだらけのものを作って動かし始め1ヶ月後にバグをほぼなくす」のと「2週間でほぼバグがないものを作って動かし始める」のとでは、前者の方が金額で言えば後者より倍優れていることになる。バグのある物をお客さんへ提供しているにも関わらず、だ。
もう言わなくても分かると思うが、この条件に当てはまるのがWEBサービスの開発だ。ユーザに多少エラー画面が出ても、ほとんどのユーザはそんなの慣れっこだ。プログラムはサーバにアップロードすれば簡単に修正できる。そんなWEBサービスださい？恥ずかしい？ああ、そうだ。しかし、そんなこと関係なしに、リリースすれば財布にはお金が入ってくるし、しなければお金は入ってこない。
逆にこれらの条件にあてはまらない開発はたくさんある。医療系や金融系は不具合の損失が重大過ぎる。組み込み系やパッケージ系は、製品を売り初めてしまえば修正は困難だ。
動的型付けは、コードの見える化には逆行する。企業は、ビジネスロジックや現状の見える化に躍起。コードについても、Going Concernを標榜しPDCAサイクルを回したいならば、見える化して...
動的型付け変数、JavaScriptやPHPに取り組みだしたときは、意味不明な挙動にすごく嵌まってしまった。が、慣れてきて、変数の内容を数値で解釈したがるタイプの言語か、文字列にしたが...
39
