解释还是编译：有用的区别？

在这里，有关解释型和编译型语言工具的问题很多。我想知道区别实际上是否有意义。（实际上，问题通常是关于语言的，但是他们实际上是在考虑那些语言的最流行实现）。

今天，几乎没有任何实现被严格解释。即几乎没有人解析并一次运行一行代码。另外，编译成机器代码的实现也越来越不常见。编译器越来越多地将目标对准某种虚拟机。

实际上，大多数实施都集中在相同的基本策略上。编译器生成字节码，该字节码通过JIT解释或编译为本地代码。它实际上是传统的编译和解释思想的结合。

因此，我问：如今，解释的实现和编译的实现之间是否有有用的区别？

重要的是要记住，解释和编译不仅是彼此的替代。最后，您编写的任何程序（包括编译为机器代码的一个程序）都将得到解释。解释代码仅意味着采取一组指令并返回答案。

另一方面，编译意味着将一种语言的程序转换为另一种语言。通常，假定在进行编译时，会将代码编译为“低级”语言（例如，机器代码，某种VM字节码等）。以后仍会解释此编译代码。

关于解释语言和编译语言之间是否存在有用区别的问题，我个人认为每个人都应该对他们在解释过程中编写的代码所发生的事情有基本的了解。因此，如果他们的代码是JIT编译的或字节码缓存的，等等，那么程序员至少应该对这意味着什么有基本的了解。

这种区别具有深远的意义，因为编译的语言不一定以解释的语言来限制语义。有些解释技术很难（实际上是不可能）进行编译的。

解释后的代码可以执行类似的操作，例如在运行时生成代码，并使该代码对现有范围的词法绑定具有可见性。那是一个例子。另一个是，解释器可以使用解释后的代码扩展，这些代码可以控制代码的评估方式。这是古老的Lisp“ fexprs”的基础：使用未评估的参数调用并决定如何处理这些函数（可以完全访问必要的环境以遍历代码和评估变量等）。在编译语言中，您不能真正使用该技术。您改用宏：在编译时使用未经评估的参数调用的函数，然后翻译代码而不是解释。

围绕这些技术构建了一些语言实现。他们的作者拒绝将编译视为重要目标，而是接受这种灵活性。

作为引导编译器的一种技术，解释将始终是有用的。作为一个具体的例子，请看CLISP（Common Lisp的流行实现）。CLISP具有本身编写的编译器。当您构建CLISP时，将在早期构建步骤中解释该编译器。它用于自身编译，然后在编译后使用编译后的编译器进行编译。

没有解释器内核，您将需要使用一些现有的Lisp进行引导，就像SBCL一样。

通过解释，您可以从汇编语言开始，从头开始开发一种语言。开发基本的I / O和核心例程，然后编写一种评估的静态机器语言。评估后，请使用高级语言进行写作；机器代码内核进行评估。使用此功能可以使用更多例程来扩展库，并还可以编写编译器。使用编译器来编译那些例程和编译器本身。

解释：通往编译之路的重要垫脚石！

实际上，语言的许多实现仍然严格地进行了解释，您可能还不知道它们。仅举几例：UNIX shell语言，Windows cmd和PowerScript shell，Perl，awk，sed，MATLAB，Mathematica等。

我认为：绝对可以。

实际上，大多数实施都集中在相同的基本策略上

实际上，C ++旨在将通常传递给解释器的一些高级概念移植到编译器领域，但它只占少数地位。

有用的区别：解释程序可以通过在运行时添加或更改函数来修改自身。