Answers:
（据我所知）没有解释的“语言”或编译的“语言”之类的东西。
语言指定了代码关键字，流结构和各种其他东西的语法和含义，但是我知道没有语言指定必须在语言规范中对其进行编译或解释。
现在，如果您要问的是，何时使用语言编译器和语言解释器，这实际上取决于编译器与解释器的优缺点，以及项目的目的。
例如，您可以使用JRuby编译器而不是MRI ruby解释器来更轻松地与java库集成。也有可能在JRuby上使用MRI ruby解释器的原因，尽管我不熟悉该语言，并且无法对此进行交谈。
吹捧口译员的好处：
吹捧的编译器优势：
但是，我敢打赌，在90％的情况下它会更像这样：我想用blub编写该软件，因为我很了解它，它应该做得很好。我将使用blub解释器（或编译器），因为它是在blub中编写软件的公认方法。
因此，TL; DR基本上是针对您的特定用例，对解释器与编译器进行了逐案比较。
同样，FFI：外来功能接口，换句话说就是用于与其他语言进行互操作的接口。在Wikipedia上阅读更多内容
这里重要的一点是，许多语言实现实际上都是两者的某种混合。今天，许多常用语言的工作方式是将程序编译为中间格式（例如字节码），然后在解释器中执行。这就是通常实现Java，C＃，Python，Ruby和Lua的方式。实际上，这可以说是当今大多数语言的实现方式。因此，事实是，当今的语言既可以解释也可以编译其代码。这些语言中的某些具有附加的JIT编译器，可将字节码转换为本地代码以执行。
我认为，我们应该停止谈论解释型和编译型语言，因为它们已不再是区分当今语言实现复杂性的有用类别。
当您询问解释型和编译型语言的优点时，您可能会说其他的意思。您可能会询问静态/动态类型的优点，分发本机可执行文件的优点，JIT和AOT编译的相对优势。这些都是与解释/编译混为一谈的问题，但是是不同的问题。
首先，可以同时理解和编译一种编程语言。解释和编译只是从源代码生成可执行代码的方法。使用解释器，解释器读取和解释源代码，然后解释器在解释代码时执行代码。另一方面，编译器读取源代码并从源代码生成可执行的二进制文件-以便可以独立地将程序作为单独的进程运行。
现在，在任何人都知道之前……是的，可以解释C / C ++ / C＃/ Java，是的，可以编译JavaScript和Bash脚本。但是，对于这些语言，是否有可用的解释器或编译器是另一个问题。
现在要实际回答这个问题，我们何时将使用“解释语言”而不是“编译语言”。这个问题本身有点令人困惑，但是我认为这意味着什么时候应该首选解释而不是编译。编译的缺点之一是由于编译过程会产生一些开销-源代码必须编译为可执行的机器代码，因此它不适合在调用源代码执行程序时需要最小延迟的任务。另一方面，由于解释源代码的开销，编译后的源代码几乎总是比等效的解释源代码更快。另一方面，解释器可以调用和运行源代码 具有很少的调用开销，但以运行时性能为代价。
最后，几乎不可能提及任何确定的用例何时一个接一个地使用，但是例如（对于我来说，这是非常不现实的）情况是当程序源代码在程序调用之间动态变化时，并且编译的开销也是高是可行的选择。在那种情况下，可能需要解释源代码而不是编译。
但是，有些事情可以视为真实示例：部署后的hidnig源代码。与本机开发人员使用已编译的代码来部署程序和数据的可执行Macine代码。使用解释后的代码，必须部署源代码本身，然后可以对源代码本身进行检查和反向工程，而所需的工作要比对本机机器代码进行反向工程的工作量少得多。一个例外是像C＃和Java这样的语言，它们会编译为即时语言/字节码（对于C＃为MSIL，对于Java为Java字节码），然后在运行时“及时”部署和编译语言，就像解释器一样。但是，存在用于MSIL和Java字节码的所谓反编译器，它们可以以相对较高的精度重构原始源代码，因此，对此类产品进行逆向工程要比在本机机器代码中部署的逆向工程产品小得多。
当您使用解释语言时，我可以想到以下情形：
当您要编译代码时，我可以想到以下情形：
最后，最大的权衡是在生产率（您必须编写多少行代码）和性能（程序将执行多快）之间进行权衡。
因为解释语言在转换为CPU信息时具有更多信息，所以它们可以依赖反射和动态类型，从而大大提高了生产率。解释语言的另一个优点是，它们独立于平台，因此只要有平台的解释器即可。
由于CPU不得将语言代码转换为机器代码并同时运行代码，因此在解释的情况下，编译后的语言将产生更快的程序。同样，使用编译语言构建的系统更安全，因为它可以在编译时检测到问题，这基本上意味着您在键入错误时（使用现代IDE）会看到错误，而不是仅在实际运行程序时看到错误（当然，这不能解决逻辑错误）。
知道这一点，解释语言适用于：
编译语言在以下情况下适用：