我想更好地理解其中的区别。我在网上找到了很多解释,但它们都倾向于抽象的差异,而不是实际的含义。
Most of my programming experiences has been with CPython (dynamic, interpreted), and Java (static, compiled). However, I understand that there are other kinds of interpreted and compiled languages. Aside from the fact that executable files can be distributed from programs written in compiled languages, are there any advantages/disadvantages to each type? Oftentimes, I hear people arguing that interpreted languages can be used interactively, but I believe that compiled languages can have interactive implementations as well, correct?
开始用“过去的冲击波”来思考
很久很久以前,有一个计算机王国
解释器和编译器。的优点引起了各种各样的争论
一个比另一个。当时的普遍意见是这样的:
解释器:快速开发(编辑和运行)。执行速度慢,因为每个语句都必须被解释为
每次执行的机器代码(想想这对于执行了数千次的循环意味着什么)。
编译器:开发(编辑、编译、链接和运行)缓慢。编译/链接步骤可能会花费大量时间)。快
来执行。整个程序已经是原生机器代码了。
运行时有一到两个数量级的差异
解释程序和编译程序之间存在性能差异。其他的区别
点,例如代码的运行时可变性,也有一些兴趣,但主要是
区别围绕着运行时性能问题。
今天的情况已经发展到这样的程度,编译/解释的区别是
几乎无关紧要。许多
编译语言调用的运行时服务并非如此
完全基于机器代码。而且,大多数解释型语言都被“编译”成字节码
之前执行。字节码解释器非常高效,可以与一些编译器生成的解释器相匹敌
从执行速度的角度来看代码。
典型的区别是编译器生成本机机器码,解释器读取源代码
使用某种运行时系统动态生成机器代码。
如今,经典的诠释者已所剩无几——几乎全部
编译成字节码(或其他一些半编译状态),然后在虚拟“机器”上运行。
首先,澄清一下,Java不是完全静态编译和以c++的方式链接的。它被编译成字节码,然后由JVM解释。JVM可以对本机机器语言进行即时编译,但不必这样做。
更重要的是:我认为交互性是主要的实际区别。由于所有内容都是解释的,所以您可以截取一小段代码,解析并根据环境的当前状态运行它。因此,如果您已经执行了初始化变量的代码,则可以访问该变量,等等。它真的很适合函数式风格。
然而,解释成本很高,特别是当您有一个包含大量引用和上下文的大型系统时。根据定义,这是一种浪费,因为相同的代码可能必须解释和优化两次(尽管大多数运行时都为此进行了缓存和优化)。不过,您仍然需要支付运行时成本,并且经常需要运行时环境。您也不太可能看到复杂的过程间优化,因为目前它们的性能还没有充分的交互性。
因此,对于不会有太大变化的大型系统,以及某些语言,更有意义的是预编译和预链接所有内容,做所有可以做的优化。最终会得到一个非常精简的运行时,该运行时已经针对目标机器进行了优化。
至于生成可执行文件,恕我直言,这一点关系不大。通常可以从编译语言创建可执行文件。但是您也可以使用解释语言创建可执行文件,只不过解释器和运行时已经打包在可执行文件中,并且对您隐藏了。这意味着您通常仍然需要支付运行时成本(尽管我确信对于某些语言,有方法将所有内容转换为可执行树)。
我不同意所有的语言都可以互动。某些语言,如C语言,与机器和整个链接结构紧密相连,我不确定您是否能够构建一个有意义的完整的交互式版本