「静的」と「動的」という議論は数十年にわたって続いている。「どちらが優れているか」と問うのではなく、どの段階でエラーが検出されるのか、そして各段階でどのようなコストがかかるのかを問うべきである。
不具合は早期に発見すればするほど、修正コストが安くなる
- コードを入力している間――ほぼ無料で、エディタが即座に赤線で指摘してくれる
- コンパイル時 — 数秒待つ
- テスト実行時 — 数分
- ユーザーのマシン上では — 費用と信用を損なう
静的型付けは、エラーを最初の2段階に押し上げる。それこそが静的型付けの価値のすべてであり、それ以上でもそれ以下でもない。
静的スタイルの代償
データを使用する前に、その構造を記述しておく必要があります。一度きりのコードであれば、これは無駄な作業です。しかし、長年にわたり多くの人が共同で修正を行うシステムにおいては、その記述こそが、決して時代遅れにならない唯一のドキュメントなのです。
境界線が曖昧になりつつある
主要な動的型付け言語にはすでにオプションの型クラスがあり、静的型付け言語では型推論がますます高度化しているため、明示的に型を記述する必要はほとんどなくなりました。その結果、両者は中間点で折り合いがつきました。
状況に応じて選択する
- スクリプト、データ分析、迅速なテスト — 動的スタイルは記述速度で勝る
- 共有ライブラリ、長期稼働システム、大規模チーム — 静的型付けは数倍の成果をもたらす
- 外部との境界となるコード — どの言語であっても実行時にチェックが必要。型だけでは不正なデータから身を守れないため
このデータ型は論理的なエラーを検出しません。日付に文字列を加算しないようにするだけです――便利ですが、正しい処理だと誤解しないでください。
Thảo luận