Chandlerの個人情報管理プロジェクトの廃止をきっかけに、動的言語の拡張容易性の可能性についてTSSで議論があった。Ted Neward氏は言語にまつわる言い争いという枠を超えて、この問題に関する構造化された洞察を示そうとした(ブログ・英語)。
まず最初に、Neward氏は「コードのラインであるので、ラインプロジェクトの規模」、または「1秒あたり100000の要求にスケールする必要がある ように、容量の取り扱い」という観点で言語のスケーリングは理解することができる、と強調している。その2つの項目は、線引きされなくてはならない。とい うのは両者は重要であるけれども、常に密接な関係があるというわけではないからだ。つまり、アセンブリー言語やCは容量の拡張容易性を助長するが、規模の 拡張容易性は助長しない。
Neward氏は、規模の拡張容易性を「プロジェクトの複雑さの度合いを拡張、または高める言語の機能」と定義している。彼は、Mike Clark氏の概念に言及している。その概念は、「すべてのプロジェクトは一定の複雑さの度合いがあり、インフラストラクチャーやツールに費やせば費やすほど、実際のビジネスロジックに費やすことが少なくなる」と示唆している。またNeward氏によると、この点こそが静的および動的言語の拡張容易性につ いての討論の場で要となる点のようである。
静的言語の支持者は、タイプの安全性の確認は「プログラマーが記述する必要がない一連のテストを実行するオートメーション化されたツールとして、プログラ マーの作業負担を軽減する」と論じている。さらに、これらの言語向けのIDEサポートは「動的言語プラットフォーム上では不可能だと広く信じられている」 リファクタリング用の強力なツールを提供している。しかしながら、動的言語の支持者は「これらの言語の動的な性質は、コードベースの作成や保守時に作業量 が少なくなり、その結果コードのラインが大幅に少なくなり、それゆえに動的言語のスケールが暗に改善される」という事実を提唱している。
Ted Neward氏によると、「概して動的言語のプログラマーは、 静的にタイプされたコードのラインごとの作業よりもコードのラインごとの作業を厳しく非難する」ということは事実ということだ。しかし、動的言語はある意味では、一定数の系統的テストを保証するコンパイラーを使用しないことを考慮すれば、ほぼ確実にさらに多くの単体テストを生産する必要がある。
IDEのリファクタリングに関して、Neward氏はタイプ情報はランタイムまで失われていると仮定すれば、Eclipseのリファクタリングのサポートは動的言語のプラットフォームに限定される、と認めているDave Thomas氏に言及している。しかしながらThomas氏は、「ファイル同士の単純な検索と置換は、重要なエディタサポートであるが、Eclipseま たはIntelliJが提供するリファクタリングと同様の多数のことをおこなう。 その理由は、もはやタイプは問題ではないからである」と強調する。そしてNeward氏は、動的言語専用のツールをIDEベンダーが開発してくれるのを期待すると強く主張した。
[… ]比較的簡単に想像できることは、タイプされているコードをIDEがアクティブに「実行」させることである。それは編集過程の間中、情報を追跡しながら、Eclipseがコンスタントにコンパイルしているのとほとんど同様の方法である。
さらに忘れてはいけないことは、TSSデータベースで強調されているように「最初のリファクタリングブラウザは、世界初の動的言語の1つであるSmalltalk用(そしてSmalltalkに)ビルドされた実装であった」ということだ。
容量の取り扱いの拡張容易性に関しては、Ted Neward氏はその重要性を強調している。というのは、「使用率のピーク時に、期待されているユーザ負荷を処理することができないプロジェクトは結果的 に失敗する。まず第一にそのプロジェクトは決してシップされないかの如く確実に。
動的言語の反対者は、これらの言語は容量の取り扱いという点においてスケールすることができないと議論している。その理由は、「ランタイムの上にビルド」 されているからで、JVM HotspotやCLR実装に見られるガーベジコレクションへ投入されるエンジニアリングの努力よりほぼ間違いなくだいぶ劣っている。動的言語の支持者は 「Rubyを買ったその日から使えるMRV(Matz's Ruby VM?)解釈プログラム上で十分うまくスケールするWebアプリケーションやWebサイトが多数ある」と応えている。
Ted Neward氏は、「JRubyのリリースおよびIronRubyやRuby.NETのようなプロジェクトに関わる作業のおかげで、これらの動的言語がJVMやCLRのような最新のバーチャルマシン上で実行することができる、と想定するのは極めて妥当である」と指摘する。
静的にタイプされた言語向けに設計されたVM上で実行中、動的言語がたいていある種のパフォーマンスやメモリをヒットするが、 DLRやMLVMに関する作業と同様にこれらの動的言語のシナリオにさらに有益である、基礎をなすプラットフォームの強化もこれを減少する。
Ted Neward氏は、 ツールを採用し、それぞれの特異性にランタイム環境を最適化することによって、プロジェクトの規模および容量の取り扱いという観点から、動的言語の拡張容易性を改善するためのタイミングのいい機会があると信じているようだ。もっと一般的に言えば、むしろ静的言語と動的言語の意見の相違に異を唱えている。たとえばExcelのようなアプリケーションが、プログラマでない人が意義ある方法でエンジンを実行するコアエンジンと、それを囲むスクリプトエンジンを 作成することによって、首尾よく2つを結合するという事実を強調している。Neward氏は、Karl Marx氏の言葉を次のように言い換えて総括した。「その機能に基づいてそれぞれの言語から、そのニーズに基づいてそれぞれのプロジェクトへ」。
原文はこちらです：http://www.infoq.com/news/2008/02/scalability-dynamic-vs-static