Steve Yegge氏は、スタンフォード大学で行った動的言語に関するプレゼンテーションのトランスクリプト（書き起こし）を自身のブログに投稿し、ブログ圏で多くの反応を引き起こした。そのトランスクリプトは、Steve氏が支持する動的言語について多大な洞察を与えている。彼によると、静的言語は限界に達しており、動的言語は現在比較的多くの機会を提供しているとのことだ。Steve氏は、パフォーマンス、保守性、およびツール不足に関する既存の問題を認めているが、それらを解決できると信じており、動的言語の普及を妨げているものは、新しい言語を使用したがらない業界の態度であると考えている。
Cedric Beust氏は、Steve Yegge氏の投稿に反応し、Steve氏の主張の多く、特に「動的ツールの構築は静的言語の場合よりも困難なわけではない、単に異なるだけだ」という主張に対して、異を唱えた。
それは異なる*だけではなく*困難です（時には、不可能な場合もあります）。静的リファクタリングが状況を100%完全にはカバーしていないという事実は確かな点ですが、1) 100%近くをカバーしており、2) 動的ツールよりもはるかに速いスピードで100%に近づいています。
[…]
大型ソフトウェアにおいて、動的に型付けされた言語が静的に型付けされた言語に取って代わるのを妨げ続けているものは、型のないソースファイルの大きな塊を理解することが不可能であり、自動リファクタリングを信頼できないものにするため、ほとんど適用できず、開発者にリファクタリングへの恐怖感を抱かせるという単純な事実です。
しかし、Cedric氏とSteve氏は、異なる言葉を使って説明していても同意しているように思える点が1つある。両者とも、今日の業界では大規模な開発プロジェクトで新しい言語を導入することは極めて困難であると考えている。Ted Neward氏は、Cedric氏とSteve氏の投稿記事に同調しているが、この見解には賛同していない。彼は、「独自の言語を作成することへの参入障壁が今日ほど低かったことはない。」と主張している。彼は「新しいプラットフォームをITに配備するコスト」を認識している。それでも、「取り掛かるプロジェクト作業は多数あり、次の大規模プロジェクトで何らかを利用する前に実験や経験集めの余地がある」と考えている。そして、そのような実験は、利用可能な実行エンジンの1つで言語を実行できるようにすることで、容易にできる。
この点こそ、既存の実行環境（特にJVMやCLR）の1つで実行することが非常に強力になるところです。実際の配備プラットフォームは変化せず、IT担当者はシナリオ全体から多かれ少なかれ切り離された状態になります。これが、JRuby、IronPython、Jython、およびIronRubyがネイティブに解釈される対応物よりも優れている点です。
結論として、Ted Newardは、「結局は、静的vs動的に関することすべてが […] 大した問題ではない」と言い、次のことができる言語を選ぶべきだと述べている。
- 頭の中の概念を表現する能力を提供できる
- 頭の中の概念の発展に合わせて、発展する能力を提供できる
Ola Bini氏の反応は、多言語プログラミングについて話しているとおり、同じ意見である。彼は、各種の言語 – 強い静的、弱い静的および動的 – にはそれぞれ強みと弱みがあり、実際あまりに違いがあり過ぎるため比較することはできないと考えている。目標に最適な機能を提供する言語を使用するべきである。
これらの言語はすべて別のことに対して役に立ちます。優秀なプログラマは常識を働かせて、可能な最高の価値を提供します。それには、仕事に最適な言語を選択することが含まれます。RubyがJavaよりも5倍早く同等の機能を提供することを可能にする場合、あなたはこれを受け入れ可能かどうか考える必要があります。一方、Javaには保守を容易にするIDEがありますが、Rubyコードベースでは結局Javaコードベースのサイズの5分の1を保守することになります。そのトレードオフを受け入れることができますか? イエスの場合と、ノーの場合があります。多くの場合において、最高のソリューションはハイブリッド（複合型）のものです。
Greg Young氏が言うには、静的vs動的言語に関する議論では「型だけではなく静的検証の概念」を考慮に入れるべきとのことであり、契約による設計アプローチによって提供される機会について話している。彼は、DbCを使用することの付加価値とは何かを説明し、それには静的言語がより適していることを示唆している。
[…] DLRの存在によって示されるように、それは一般に動的言語と静的言語ではかなり容易です。しかし、定理証明と動的言語の世界の間には、はるかに大きなずれがあります。動的言語はランタイムに定義された定義内、静的検証はコンパイル時に定義された定義内にあり、動的言語の使用は、コンパイル時にコードを静的に検証する概念を不可能にします。コンパイル時に動的コードの検証を試みることは、数多くの種類のツールを使用する場合と同じようにあなたを停止問題に直行させるでしょう。
静的検証および契約による設計は、ほとんどが決定論的アプローチに基づいた定理に頼っている。しかしSteve Yegge氏は、「ランタイムにはすべての情報がある」という事実を利用するノンヒューリスティック（非発見的）な方法で検証を実行できるということをプレゼンテーションで主張した。彼は、自然言語処理および文法チェックの例を使って、確率的なアプローチはより効果が高く計算コストが安いということを示している。
[… ]Microsoft Wordの文法チェッカーがそれを行う場所には、チョムスキー文法があります。[…] そして実際に、あなたはコンパイラが行うようなことを行い始め、センテンスの構造を導き出そうとします。
そのどれもが効果がありませんでした! すべてが、あまりに計算コストが高くなり過ぎ、言語、熟語やその他のものは変化し続けました。代わりに、[…] 彼ら [Google] は確率的な尺度ですべてを行います。
[…] あなたは、「確率的な尺度で翼のようなものをつけようとしているだけだ」と言って、10年間の研究を陳腐化しました。 — […] 非常に多くの言語に翻訳された文書の大きなデータセットを取得し、機械学習を実行し、実際にそこにあるセンテンスを、該当の翻訳になる確率が高いセンテンスと一致させることができます。
原文はこちらです：