例如，维基百科说好处是
- 跨平台
- 逐步跟踪（调试）
- 动态类型
看起来一切都是绝对合乎逻辑的，但我们可以假设我们可以在执行编译程序之前简单地组装它，即 粗略地说，从这个假设出发，将有一个汇编+执行命令，而不是执行命令，我按照问题来这几点
- 如果有一天我们必须根据我们的 OS + 架构等安装解释器。为什么我们不能在我们的操作系统下也安装编译器并每次都从源代码构建项目，例如 c++
- 目前，我们可以逐步调试 C++ 代码吗？我不太明白这一点。
- 动态类型似乎与解释语言没有严格的联系。可以在编译的中实现吗？
编译+运行会比解释花费更长的时间吗？那些。是否可以说其中哪个更快？
Java是一种跨平台的强类型编译语言。
编译也可以防止在解释语言中进行调试。使用生成器的复杂嵌套列表推导式很难一步一步调试，因为它们是具有复杂规则的复杂构造（尽管它们希望看起来简单漂亮）。
Lisp编译成机器码并且是动态类型的。编译语言Julia具有动态类型，编译器生成的过程变体与输入参数类型的变体一样多。
一切都一样，几乎没有区别。本质的区别在于：Python有一个内置的编译器（你可以从文本中执行代码），而C++没有。但是有内置编译器的编译语言——Lisp。
如果您没有使用积极的优化，您可以。代码优化得越多，源代码和机器指令的对应关系就越弱。我注意到C有纯解释器，尽管由于语言缺乏可移植性，它们在调试中几乎没有用处。
是的，上面有例子。
解释器通常启动得更快，因为他们有没有深度优化的简单编译器。但是Pascal被编译为机器代码（Turbo Pascal）。Pascal 源代码是为一次性编译而设计的。IDE 比 QBasic 快。
解释器/编译器拆分具有历史根源。第一个解释语言没有编译（BASIC）。BASIC 语言本身具有面向行的语法，是为逐行解释而设计的。
Turbo Pascal 编译器一次生成机器代码，没有引入中间表示来消耗更少的内存（它通常完全在内存中工作而不访问磁盘 - 磁盘是一张慢速软盘）。
后来，随着内存和处理器的增多，编译器和解释器开始相互借鉴技术。一切都混在一起了。
我提出了另一种分类：动态/静态类型以及在程序执行期间执行任意代码的可能性。