大きなプログラム内でスクリプト言語を使用すると便利なのはいつですか？

C＃で書かれたプログラム内でJavaScriptやPython（または何か）を使用している人々の状況をいくつか聞いたことがあります。JavaScriptのような言語を使用してC＃プログラムで何かをする方が、C＃でそれを行うよりも優れているのはいつですか？

変更するためにプログラムを再コンパイルする必要がない動作がある場合。これがまさに、多くのゲームがスクリプト/改造言語としてLuaを使用する理由です。

この手法を使用して、異なる言語環境間で簡単に移植できるコアロジックを実装できます。たとえば、すべての内部計算機ロジックが100％JavaScriptで実装されている計算機シミュレーターがあります。もちろん、ユーザーインターフェイスコードはプラットフォームごとに異なります。

• Webブラウザー（JavaScript）
• iOS（Objective-C）
• Windows（C ++とQt）
• Mac OS X（Qtを使用したC ++）
• Java Swing（Java）

この配置により、さまざまなオペレーティング環境用にプログラムのバージョンを作成し、特にそれらを最新の状態に保つことがはるかに簡単になります。

このパターンを適用する状況は大まかに2つあります。

1. これは、埋め込み言語の品質を活用するために内部的に使用されます。
2. これは、外部プログラマビリティを提供するために使用されます。

内部的に

• 通常、埋め込み言語は解釈されるため、再コンパイルせずに変更をすばやく実行してテストできます。
• 埋め込まれた言語は、コアアプリケーションが記述されている言語よりも表現力が高い場合があります。これにより、開発を高速化できます。
• この言語は、汎用言語と比較して、特定のドメインにより適している場合があります。
• この言語は、「より簡単な」プログラミング言語/環境を必要とする内部ユーザーによって使用されます。短いプログラムは、比較的単純な構文/ APIを使用して、ソフトウェア開発者ではない人々によって作成されます。

ここでの例は、Adobe Lightroomで使用されるLuaです。

したがって、Luaで行うことは、UIの実行からデータベースで実際に行うことの管理まで、本質的にすべてのアプリケーションロジックです。C ++での生の処理に取りかかるまで、意思決定や機能の実装と説明できるアプリのコードのほとんどすべてがLuaにあります。（マークハンブルクインタビュー：Adobe Photoshop Lightroom）

外部的に

• 特別なツールやライブラリ、ソースコードへのアクセスを必要とせずに、ユーザーがアプリケーションの動作を拡張できるようにします。
• これらのユーザーに、明確に定義されたAPIとサンドボックス環境を提供します。これはアプリケーションの言語で行うこともできますが、インタープリターを埋め込むことで簡単になります。

IBMは、メインフレームオペレーティングシステムVM-CMSでスクリプト言語を非常にうまく使用しました。 EXEC、EXEC / 2およびそれ以降のRexxは、内部および外部の両方でシステム全体で使用されました。異なるアプリケーション（XEDITなど）は同じ言語を使用してスクリプト可能であり、内部アプリケーション/ユーティリティ（電子メールなど）はスクリプト言語で記述され、OSや他のツールとの緊密な統合を活用しました。顧客は、多くのスクリプトツールおよびアプリケーションを作成および共有しました。DECはDCLも提供しました。後にMicrosoftは、ほとんどのアプリケーションでスクリプト言語としてVBscriptをサポートし、最近ではPowerShellをサポートしました（MS / DOS バッチファイルも）。Unixシェルは持っているスクリプトを同様。

今日の傾向は、何らかの方法でAPIを公開し、異なるバインディングまたはAPIにアクセスする他の手段を利用できるユーザーにスクリプト言語の選択を任せているようです。

実世界の例は次のとおりです。

• 埋め込みJavaScriptをサポートするほとんどのWebブラウザー。

• Microsoft Officeスイート-Excel Wordなどはすべて、埋め込みVBAスクリプトをサポートしています。

• 多くのネットワークルーターには、さまざまな言語のTCL、Perl、LuaのスクリプトAPIが含まれています。

多くの組み込みデバイスは、Luaなどのスクリプト言語を使用して結合された非常に小さなコアC関数のセットを使用して実装されます。したがって、ハードウェアとやり取りする小さく高速なC関数のセットと、柔軟で修正しやすいスクリプト言語のほとんどの制御ロジックがあります。

スクリプトは、他の開発者がホストアプリケーションを拡張する手段であるため、アプリケーションに埋め込まれることがあります。可能な限り幅広いプログラミング言語スキルを獲得するために、ホストは複数のスクリプト言語をサポートできます。たとえば、JVMには、Python、Ruby、JavaScriptなど、JSR-223に準拠した言語を大量に埋め込むことができます。

まだ言及されていないもう1つの理由は、埋め込み言語には、ホスト言語では簡単に複製できない1つ以上の優れた機能があるためです。この例としては、Rebolのような言語で見つかるParse機能や楽なDSL（ドメイン固有の言語/方言）の作成があります。

アプリケーション内でスクリプト言語を使用する興味深い方法が1つありますが、他の人はまだ言及していません。

ホスト言語にリッチでリフレクトなランタイムがある場合、REPLを使用した単純な言語をアプリケーションに埋め込み、ソケットにフックして、システム全体にアクセスできるようにすると便利です。

インタラクティブなデバッグ（通常のデバッガよりもはるかに強力です）、ホットコードパッチ、さまざまな監視目的、さらにはバックドア（使用できない場合）に使用できます。

主要なアプリケーションでインタープリタ型スクリプト言語を使用するときの私の特定の状況：

いくつかの機能を実行する外部デバイスがあります。測定、制御、読み出し。それはかなり「馬鹿げた」ものであり、多くの待機状態や制御メカニズム側でのアドホックな意思決定など、段階的な正確な制御が必要です。

デバイスのさまざまな機能は、メインアプリケーションのさまざまな時点で、さまざまな時点で、多くの場合オンデマンドで必要です。メインアプリは待機状態を許可しないため、すべてを有限状態マシンで実行する必要があります。

有限状態マシンを作成した人は誰でも、待機状態の実装がマシンの少なくとも2つ、多くの場合3つまたは4つの内部状態であることを知っています。外部デバイスのさまざまな機能に対して20個の待機状態を実装する（およびそれらの応答を待機し、それに応じて反応する）ことは、非常にイライラする経験になります。

そのため、代わりに、有限状態マシンには「待機なし関数の実行」、「ブロッキング関数の実行」、「分岐/条件付き/ジャンプの実行」関数の状態があり、合計で6つの状態になります。また、実行のためにスケジュールされた制御スクリプトがあり、外部デバイスを制御するインタープリターによって実行され、その結果が必要な場所に配置されます。

要約すると、アプリケーション：RTOSでは、内部解釈スクリプト言語を使用すると、待機状態（ブロッキング関数）で豊富なタスクを実行する複雑さが大幅に軽減される可能性があります。

私の経験から、「古代」言語のソースコードをユニコード互換に書き換える大きなアプリケーションを開発しました。これはC＃で行われました。最終的には、C＃で（データモデルを作成し、書き換えプロセスに必要な手順を実行する手段を提供する）エンジンのみを記述しました。

統合されたIronPythonの最大のポイント：ビッグデータモデルをロードしたと仮定します（ロード時間は約1時間）。次に、手動で情報を収集し、物事を検索します。対話型コンソールからPythonスクリプトを使用してこれを行うことは、デバッガーでデータモデルをクリックするよりもはるかに優れています（さらに、再生可能です）。

いくつかの理由があります。

• 学習曲線。事実上誰もがjavascriptで学び、書くことができます。
• セキュリティ。C＃またはJavaでスクリプトコードのセキュリティコンテキストを制御するのは困難です。Javascriptはこれに最適です。スクリプト作成者は、許可しない限り、ディスクまたはどこにもアクセスできません。コアjavascriptエンジンは単なる高度な計算機です。
• 品質。スクリプトコードに非常に厚い制限を設定します。「スパゲッティコード」レベルは、JavascriptとC＃/ Javaで大きく異なります。（これは地獄の門を開くことを妨げます）
• 型安全。C＃/ Javaはタイプセーフな環境であり、スクリプト環境ではほとんど使用しません。"12" + 3のような式はjavascriptで "123"を返しますが、C＃/ Javaはコンパイルさえしません。スクリプトライターは、ほとんどの場合、「タイプ」とは何でもありません
• 動的。すべてのオブジェクトには、任意のプロパティ/メソッドを含めることができ、時間の経過とともにタイプを変更できます。たとえば、XMLノードをプロパティとして公開するスクリプト環境にプロキシC＃オブジェクトを提供できます。
• 生産性。通常、スクリプトの記述はC＃/ Javaよりはるかに簡単です。コンパイルや「プラグインの登録」は必要ありません。アプリケーション内でスクリプトの内容を直接編集して、すぐに結果を得ることができます。
• 管理します。C＃/ Javaを使用するには、内部クラスを世界に公開するプラグインにリンクするSDKが必要です。このプラグインアーキテクチャには、古いSDKバージョンの「後方互換性」が必要です。このアーキテクチャでは、ドメインコンテキストでアプリケーションの内部メカニズムを提供する「仮想」ドメインオブジェクトを作成する必要があります。APIを公開するよりも管理しやすく、柔軟性があります。

いつ？1948年から2008年の間-最初にコンパイルされた言語は、コンパイルとリンクにかなりの時間を要したため、ユーザーのカスタマイズと構成を可能にするスクリプト言語を作成するのが一般的でした。AutoLispの歴史を見ると、最初はAutoCADにスクリプト言語が同梱されていましたが、これは段階的に廃止され、スクリプト可能なインターフェイスをVBA、次に.netに公開することになりました。

CLRを使用すると、C＃プログラムまたは既存のシステムへのLuaプログラム呼び出しを有効にしても開発コストに大きな違いはありません。また、.netランタイムには、オンザフライで生成およびコンパイルするツールが付属しています。

大きなプログラム内にスクリプト言語を用意する必要はなくなりましたが、代わりに、大きなプログラムをランタイムのスクリプト機能に公開します。

オンザフライでコードの生成とコンパイルを提供せず、ドメイン固有の言語ではなく汎用自動化言語を提供することが望ましいと思われる環境では、LuaまたはPythonスクリプトを使用できます。COMインターフェイスを提供するツールの場合、そのスクリプト言語はC＃またはVB.net（MS Office、Sparx Enterprise Architect）です。したがって、それ自体がスクリプト言語になるのに十分単純な言語で書かれたプログラム用のスクリプト言語を持つことは不要です。