大きなプログラムでスクリプト言語を使用すると便利なのはいつですか。
C＃で記述されたプログラム内でJavaScriptやPython（または何か）など）を使用している人々のいくつかの状況を聞いたことがあります。JavaScriptなどの言語を使用してC＃プログラムで何かを行うと、 C＃でそれをやるより良いですか？
変更するためにプログラムを再コンパイルする必要がない動作がある場合。これがまさに、多くのゲームがLuaをスクリプト/改造言語として使用する理由です。
この手法は、異なる言語環境間で簡単に移植できるコアロジックを実装するために使用できます。たとえば、 電卓シミュレータ があり、すべての内部電卓ロジックが100％JavaScriptで実装されています。もちろん、ユーザーインターフェイスコードはプラットフォームごとに異なります。
- Webブラウザー（JavaScript）
- iOS（Objective-C）
- Windows（C++とQt）
- Mac OS X（C++ with Qt）
- Java Swing（Java）
この配置により、さまざまなオペレーティング環境に合わせてプログラムのバージョンを作成し、特にそれらを最新の状態に保つことが、はるかに簡単になります。
非常に広くは、このパターンを適用する2つの状況があります。
- これは、組み込み言語の品質を活用するために内部的に使用されます。
- これは、外部プログラマビリティを提供するために使用されます。
内部で
- 通常、組み込み言語が解釈されるため、再コンパイルすることなく、変更を加えてすばやくテストできます。
- 組み込み言語は、コアアプリケーションが記述されている言語よりも表現力が高く、開発をより速くすることができます。
- この言語は、汎用言語と比較して、特定の domain に適している場合があります。
- この言語は、「より単純な」プログラミング言語/環境を必要とする内部ユーザーによって使用されます。短いプログラムは、比較的単純な構文/ APIを使用するソフトウェア開発者ではない人々によって書かれています。
ここでの例は、Adobe Lightroomで使用されるLuaです。
したがって、Luaで行うことは、UIの実行からデータベースで実際に行うことの管理まで、基本的にすべてのアプリケーションロジックです。意思決定や機能の実装として説明できるアプリのコードのほとんどすべては、C++の生の処理に取り掛かるまでLuaにあります。 （ Mark Hamburgインタビュー：Adobe Photoshop Lightroom ）
外部
- ユーザーが特別なツールやライブラリ、ソースコードへのアクセスを必要とせずに、アプリケーションの動作を拡張できるようにします。
- それらのユーザーに明確に定義されたAPIとサンドボックス環境を提供します。これはアプリケーションの言語で行うこともできますが、インタープリターを組み込むとこれが簡単になります。
IBMは、メインフレームオペレーティングシステムでスクリプト言語を非常にうまく使用しました VM-CMS 。 [〜＃〜] exec [〜＃〜] 、 EXEC/2 以降 Rexx は、システムの内部および外部の両方で使用されました。異なるアプリケーション（例 [〜＃〜] xedit [〜＃〜] ）は、同じ言語を使用してスクリプト化可能であり、内部アプリケーション/ユーティリティ（例：電子メール）はスクリプト言語で記述され、 OSおよびその他のツールとの統合。顧客は多くのスクリプトツールとアプリケーションを作成して共有しました。 DECは [〜＃〜] dcl [〜＃〜] も提供しました。後でマイクロソフトでは、ほとんどのアプリケーションでスクリプト言語として VBscript をサポートし、最近では PowerShell （MS/DOS batch ファイル）もサポートしています。 Unixシェルにも scripting があります。
今日の傾向は、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で行われます。
統合されたIronPythonの最大のポイント：ビッグデータモデルをロードしたとしましょう（約1時間のロード時間）。次に、手動で情報を収集し、物事を調べます。 Pythonインタラクティブコンソールからのスクリプトを使用してこれを行うと、デバッガーでデータモデルをクリックするよりもはるかに優れています（さらに、再生可能です）。