動的言語にも欠点はある
ここまで，動的言語のメリットについて述べてきました。では，動的言語にはデメリットはないのでしょうか。
もちろんあります。どのようなことにも，トレードオフは伴うものです。動的言語の主要なデメリットは，簡潔性とエラー検出，そして実行効率です。
つい先ほど簡潔性を動的言語のメリットとして挙げたばかりですが，他人の書いた（あるいは半年前の自分が書いた）プログラムを読解するときにはデメリットになり得ます。簡潔なプログラムは，ヒントが少ないということでもあるからです。また最近ではIDE（統合開発環境）がプログラムの入力を補完しますが，この機能も十分には働きません。Javaなどの言語でプログラムの字面に与えられる型情報を利用しているからです。簡潔さはプログラムの読み書きを助けてくれることもあれば，そうでないこともあるのです。
ヒントが少ないことは，エラー検出にも影響します。プログラムに型情報がないので，プログラム上の間違いによって発生する型不整合エラーは実際に実行するまで分かりません。静的型言語なら実行前に確実に検出できますので，これができないというのは，静的型チェックに親しんだ人にとっては抵抗があるかもしれません。
もう一つのデメリットである実行効率は，深刻な問題です。動的言語の処理系の多くはインタプリタとして実現されることが多いので，静的言語と比較して実行効率に劣るものが多いのは事実です。例えば単純なループのような簡単な処理で比較すると，Cのようなコンパイラ処理系を用いた場合と，Rubyのようなインタプリタ処理系を用いた場合とでは性能に100倍から1000倍の違いが出ます。通常のプログラムの場合には，実行時間の多くはコンパイラ言語で記述されたライブラリ・ルーチンの中で消費されるので，それほど極端な差が付くことは滅多にないのですが，それでも10倍程度の差が付くことは珍しくありません。
また，型情報はプログラムの実行を効率化するためのヒントにもなります。動的言語ではこれが利用できませんから，処理系を実装する立場からは厳しいものがあります。実際にRubyの処理系を開発している立場から言うと，処理系を高速化したいのに，Rubyという言語があまりにも動的なので実現できない手法が数多く，嫌になることがあります。
デメリットが目立たなくなった
簡潔性，エラー検出，実行効率など，こんなにもデメリットがあるのに，最近，動的言語が注目されているのはなぜなのでしょうか。もちろんこれらのデメリットがなくなったわけではありません。それでも以前とは状況が変わり，これらのデメリットが与えるダメージが比較的小さくなったとは言えると思います。
状況の変化のうち，最大のものはコンピュータ性能の飛躍的な向上です。ハードウェア性能の向上は驚異的で，以前のスーパーコンピュータに等しい計算能力がカバンの中におさまってしまうほどです。単位価格当たりの計算能力で比べると，10年前の何分の1になったのか考えるのも恐ろしいほどです。10年前に私が使っていた（そしてそれなりに性能に満足していた）ノートパソコンと，今私がこの原稿を書いているノートパソコンを比べると，CPUクロックが266倍，メモリーが384倍，ハードディスクは200倍の性能（容量）を達成しています。うーむ。
一方，人間の能力は時間がたっても少しも向上しません。個人的にはむしろ歳をとって能力が下がったような気もしますが，それはそれとしてコンピュータの単価が下がることによって人間の価値（価格）は相対的に上昇しています。1分間コンピュータを使うたびにいくら，と課金されていたころは，人間のコストは無視できました。人間がどんなに苦労しても，貴重なコンピュータさまの時間が節約できれば結局はお得だったのです。ところが現代ほどコンピュータの価値が下がってしまうと，同じように人間のコストを浪費することは許されません。むしろ機械を働かせてでも人間は楽をすべきなのです。
そうなると，動的言語の実行効率の低さはそれほど重要な問題ではありません。少々実行効率が低くても，それを補うだけ人間のコストが削減できれば何の問題もないのです。
コンピュータ・ソフトウェアに対する要求の変化も見逃せません。以前には考えられなかったほど，あらゆる領域でソフトウェアが用いられるようになっています。ソフトウェア開発に対しても，以前よりも多くのものが求められています。開発量の増大，完成までに許容される期間の短縮，開発中あるいは開発完了後もたび重なる仕様変更に応えなければならないなど，開発者へのプレッシャーは強まる一方です。ですからどうしても開発効率を高め，人間のコストを下げることは必要です。先に述べたようにコンピュータ・コストは低下する一方ですから，プログラムが高速に動作することよりも開発生産性が重要になります。
エラー検出についても動きがありました。テスト駆動開発（TDD：Test Driven Develop-ment）の台頭です。個々のモジュールごとにユニットテスト（単体テスト）を用意し，頻繁にテストします。場合によってはテストを先に記述し，そのテストを満たすようにソフトウェアを開発するのです。正しくユニットテストが行われていれば，エラーが検出できるはずです。またユニットテストを実施するということは，個々のモジュールの「正しい動作」を検証できる仕様が存在することでもあります。そのぶん，信頼性が向上します。
実際に実行してみないと型不整合エラーが発覚しない動的言語ですが，ユニットテストが正しく行われていれば，本番前に網羅的なテストで検出できるので重大な問題になりません。また，型不整合によるエラーはすべてのエラーのうちもっとも検出が簡単で，直すことも容易なエラーです。TDDでは，もっと検出しにくいロジックそのものの間違いも見つけ出せます。TDDは動的言語だけに適用される方法論ではありませんが，動的言語の弱点をカバーできる働きがあります。
動的言語が注目されるにつれて，動的言語によるプログラミングを支援するツールも登場しつつあります。簡単にドキュメントを参照できるIDE，動的言語の性質を利用して従来よりもはるかに生産性を高めるアプリケーション・フレームワークなどがその一例です。また処理系自身も，JIT（Just In Time）コンパイラなどの技術によって，今までよりも高速なものが開発されてきています＊2。
アジャイル開発と親和性が高い
ソフトウェア開発者へのプレッシャーが強まっている状況を感じとったIT界のリーダーたちは，それに対抗する手段としてアジャイル（俊敏さ）という考え方を導入しました。彼らの宣言である「Agile Manifesto（アジャイル宣言）」に，その意義が述べられています（図[拡大表示]）。
この宣言に名を連ねた17人のうち，Rubyに注目している人が多いのは偶然ではないと思います。Andrew Hunt氏とDave Thomas氏は「ピッケル本」として知られるRubyの解説書の定番Programming Rubyの作者ですし，Martin Fowler氏も長年のRubyファンとして知られています。また，Ron Jeffries氏，Brian Marick氏は過去のRuby Conference（Rubyの開発者会議）に参加しています。そして，Kent Beck氏，Alistair Cockburn氏，Ward Cunningham氏は，いずれもRubyに強い興味を持っていると聞いています。
このことはRubyが，あるいはRubyを含めた動的言語が彼らが理想とするアジャイルな開発のために非常に有効であることを意味しているのではないでしょうか。「変化を受け入れる」俊敏な開発には，柔軟性と生産性が高い動的言語こそがふさわしいのでしょう。
速く柔軟な開発の助けとなる
動的言語は万能ではありません。数値計算やスーパーコンピューティングのような最大限の速度が要求されるような分野や，OSや組み込みなどシステム寄りの基盤に近い分野では，その利点よりも欠点が目立つでしょう。しかし技術の進歩は著しく，動的言語が適用できる領域は確実に広がり続けています。例えば，開発者である私自身が8年前にはRubyに絶対に向かないだろうと思っていた分野でも，Rubyは活躍しています。スーパーコンピュータを使った気象データ処理や，バイオ・インフォマティクスの分野です。将来，どこまで適用分野が広がるか楽しみです。
技術の進歩と一般社会へのコンピュータの浸透によって，ソフトウェア開発を取り巻く状況は確実に変化しています。世界はもっとたくさんのソフトウェアが，もっと速く，もっと柔軟に開発されることを求めています。開発者へのプレッシャーは増大するばかりです。人間がその限られた能力をコンピュータの力を借りて拡大し，もっと俊敏にソフトウェア開発をしようとするとき，動的言語はその大きな助けになるに違いありません。
まつもとゆきひろ Yukihiro Matsumoto／ネットワーク応用通信研究所 主任研究員1965年生まれ。鳥取県米子市出身。筑波大学第三学群情報学類卒業。高校時代からのプログラミング言語おたく，オブジェクト指向おたく。1993年からオブジェクト指向スクリプト言語Rubyを開発中。古今東西のプログラミング言語の「良いとこ取り」の性質から海外でも人気上昇中。1997年から株式会社ネットワーク応用通信研究所 主任研究員という立場でRubyの開発をメインの仕事としている。メールアドレスはmatz@ruby-lang.org。 |
