回答:
（私の知る限り）解釈された「言語」やコンパイルされた「言語」などはありません。
言語はコードのキーワード、フロー構成、その他のさまざまなものの構文と意味を指定しますが、言語仕様でコンパイルまたは解釈する必要があるかどうかを指定する言語はありません。
質問が言語コンパイラと言語インタープリターのどちらを使用するかという場合、実際にはコンパイラーとインタープリターの長所/短所とプロジェクトの目的に帰着します。
たとえば、MRI rubyインタープリターの代わりにJRubyコンパイラーを使用して、Javaライブラリーとの統合を容易にすることができます。また、JRubyでMRIルビーインタープリターを使用する理由がある可能性がありますが、私は言語に不慣れであり、これに話すことができません。
通訳の定評のある利点：
コンパイラーの定評ある利点：
ただし、90％のケースでは、これはもっと似たようなものになると思います。私は、このソフトウェアをよく知っているので、このソフトウェアをblubで書きたいと思っています。blubインタプリタ（またはコンパイラ）を使用します。これは、blubでソフトウェアを記述するための一般的に受け入れられている標準的な方法であるためです。
したがって、TL; DRは基本的に、特定のユースケースの場合のインタープリターとコンパイラのケースバイケース比較です。
また、FFI：Foreign Function Interface、つまり他の言語と相互運用するためのインターフェイス。ウィキペディアでもっと読む
ここで重要な点は、多くの言語実装が実際に両方のハイブリッドを何らかの形で行うことです。現在一般的に使用されている多くの言語は、プログラムをバイトコードなどの中間形式にコンパイルし、それをインタープリターで実行することで機能します。これが、Java、C＃、Python、Ruby、およびLuaの一般的な実装方法です。実際、これはほぼ間違いなく、現在使用されているほとんどの言語が実装されている方法です。そのため、今日の言語はコードを解釈およびコンパイルします。これらの言語の一部には、実行のためにバイトコードをネイティブコードに変換する追加のJITコンパイラがあります。
私の意見では、今日の言語実装の複雑さを区別するための有用なカテゴリではなくなったため、インタープリター言語とコンパイル言語について話すのをやめるべきです。
インタープリター言語とコンパイル言語のメリットについて尋ねると、おそらく何か別の意味があります。静的/動的型付けのメリット、ネイティブ実行可能ファイルの配布のメリット、JITおよびAOTコンパイルの相対的な利点について質問しているかもしれません。これらはすべて、解釈/コンパイルと混同される問題ですが、異なる問題です。
まず第一に、プログラミング言語は解釈もコンパイルもできます。解釈とコンパイルは、ソースコードから実行可能コードを生成する単なる方法です。インタープリターを使用すると、ソースコードはインタープリターによって読み取られて解釈され、インタープリターはコードを解釈しながら実行します。一方、コンパイラはソースコードを読み取り、ソースコードから実行可能なバイナリファイルを生成します。これにより、プログラムを独立したプロセスとして独立して実行できます。
誰もが疑問に思う前に...はい、C / C ++ / C＃/ Javaを解釈できます。そして、はい、JavaScriptとBashスクリプトをコンパイルできます。ただし、これらの言語用に動作するインタープリターまたはコンパイラーがあるかどうかは別の質問です。
「コンパイルされた言語」ではなく「解釈された言語」を使用する場合、実際に質問に答えます。質問自体はやや混乱しますが、コンパイルよりも解釈を優先するタイミングを意味していると思います。コンパイルの欠点の1つは、コンパイルプロセスのためにオーバーヘッドが発生することです。ソースコードを実行可能なマシンコードにコンパイルする必要があるため、ソースコードを呼び出してプログラムを実行するときに最小限の遅延が必要なタスクには適していません。一方、コンパイルされたソースコードは、コードの解釈に起因するオーバーヘッドのため、ほとんどの場合、同等の解釈されたソースコードよりも高速です。一方、通訳者はソースコードを呼び出して実行できます 呼び出しオーバーヘッドはほとんどありませんが、実行時のパフォーマンスが犠牲になります。
最終的に、次々に好む場合に明確なユースケースを述べることはほぼ不可能ですが、たとえば、（私のアンダーサンディングは非常に非現実的です）プログラムの呼び出しの間でプログラムのソースコードが動的に変化し、コンパイルのオーバーヘッドがあまりにも大きい場合です実行可能な選択であるために高い。その場合、コンパイルする代わりにソースコードを解釈することがおそらく望ましいでしょう。
ただし、実世界の例と見なすことができるものがあります。展開時のソースコードの隠蔽です。ネイティブ開発者がプログラムとデータの実行可能なmacineコードをデプロイするコンパイル済みコード。インタープリターコードでは、ソースコード自体を展開する必要があります。ソースコードは、ネイティブマシンコードをリバースエンジニアリングするよりもはるかに少ない労力で検査およびリバースエンジニアリングできます。これの1つの例外は、C＃やJavaのような言語で、即時言語/バイトコード（C＃のMSILおよびJavaのJavaバイトコード）にコンパイルされ、実行時に「ジャストインタイム」で展開およびコンパイルされます。ただし、元のソースコードを比較的正確に再構築できるMSILおよびJavaバイトコード用のいわゆる逆コンパイラーが存在します。そのような製品のリバースエンジニアリングは、ネイティブマシンコードで展開されるリバースエンジニアリング製品よりもはるかに簡単です。
インタプリタ言語を使用する場合、次のシナリオを考えることができます。
コードをコンパイルしたいときは、次のシナリオを考えることができます。
結局、大きなトレードオフは、生産性（コードの行数を記述する必要があります）とパフォーマンス（プログラムの実行速度）の間です。
ためインタプリタ言語 CPU情報に変換多くの情報を持っている、彼らが頼ることができる反射および動的型付け大幅に生産性を向上させます。インタープリター言語のもう1つの利点は、プラットフォーム用のインタープリターが存在する限り、プラットフォームに依存しないことです。
解釈された場合のように、CPUがマシンコードの言語コードを変換し、同時にコードを実行してはならないため、コンパイルされた言語はより高速なプログラムを生成します。また、コンパイルされた言語で構築されたシステムは、コンパイル時に問題を検出できるため、より安全です。これは、実際にプログラムを実行するときにのみ表示されるのではなく、入力時にエラーが表示されることを意味します（もちろん） 、これは論理エラーを修正しません）。
これを知って、インタプリタ言語は以下に適しています：
コンパイルされた言語は次の場合に適しています。
他の人が述べた理由に加えて、コンパイルまたはハイブリッドアプローチの形式よりもアドホックな解釈を選択するための1つの特に重要なユースケースがあります。
プログラミング言語が通信プロトコルとして使用されている場合、および応答の待ち時間が重要な場合、コンパイルおよび可能な前処理に時間を浪費しないようにする方が理にかなっています。
これは、たとえばエージェント言語、またはTcl / Tkの通常の使用方法などに適用されます。
解釈に固執するもう1つの考えられる理由は、言語インタープリターがそれ自体またはより複雑で高レベルの言語のブートストラップに使用され、その単純さがブートストラッププロセスのパフォーマンスよりも重要な場合です。
他のほぼすべての可能なユースケースでは、コンパイル（またはハイブリッドアプローチ）が適しています。