对解释语言的优势感到困惑
Confused about advantage of interpreted language
我对 java 这样的解释型语言相对于编译型语言的优势感到困惑。
解释型语言（例如 java）优于编译型语言的标准解释是，同一个 .class 文件可以 运行 在不同类型的机器上架构。这如何为您节省工作？
对于每种不同的机器架构，您是否需要不同的编译器来将相同的 .class 文件解释为机器语言？因此，如果您需要针对每种不同的机器架构使用不同的编译器来将相同的 .class 文件解释为机器代码，这如何为您节省工作量？
为什么不直接制作一种编译语言，其中 .java 源文件立即编译成机器语言。当然，这将需要不同的编译器将 java 源文件编译为每种机器体系结构的机器语言，但这比必须为每台机器使用不同的编译器从 .[=27 编译更有效吗？ =] 文件到机器语言？
我的意思是这与编译语言相同——无论是将 java 源文件编译成机器代码还是将 class 文件编译成机器，您都需要针对每种机器架构的编译器代码。
谢谢。
首先，Java是一种编译型语言，也是一种解释型语言，因为你必须从.java编译到.class。
要获得问题的实质，通过（某种程度上）解释获得的优势 Java 是您只需要编译每个程序一次，并且它可以 运行 在任何计算机上，因为Java 运行时环境 (JRE) 预先编译以匹配本地 OS 和体系结构，可以弥合这一差距而无需（或最少）进一步编译。
然而，在一种未解释的语言中，您必须为每个 OS 和您希望它在 运行 上的每个体系结构编译每个程序，这比仅仅编译需要更多的努力和总编译时间JRE 为每个 OS 和体系结构编译一次，每个单独的程序只编译一次。
每次 运行s 都为本地体系结构编译的语言是不切实际的，因为编译是一个相当密集的过程。 Python 确实在每次 运行 时编译（尽管，像 Java 一样，它是为运行时环境而不是本地体系结构编译的）并且它是那里最慢的语言之一。
希望这有助于解决问题。
我喜欢sowrd299的回答。我的两分钱：
- 您在技术上拥有无穷无尽的不同目标架构
- 因此同时为 所有 目标编译代码并将其打包在一起将导致 infinite 大可执行文件
- 因此针对虚拟机字节码编译Java 是一个更好的解决方案：因为它只有一个目标架构
- 而开发人员可以分别为所有新旧架构添加 JVM，从而允许全部新东西（例如 Raspberry PI）运行 您的 java 代码是上个世纪编译的。
另一方面，"compile for multiple targets in advance" 并不是完全疯狂的事情。 Afaik Windows Universal Apps 以这种方式工作：它是同一个 exe 文件中的同一个应用程序，但实际上该 exe 包含为 80x86 和 ARM 目标编译的代码。这样一来，一个应用程序看起来可以在 windows 移动和桌面解决方案之间移植，无需任何进一步解释。
For each different machine architecture, wouldn't you need a different
compiler to interpret the same .class file into the machine language?
So if you need a different compiler for each different machine
architecture to interpret the same .class file into machine code, how
does this save you any work?
以上说法是你的核心误区。
应用程序开发人员 编写 Java 编译为字节码的代码，可以 运行 在任何兼容的 Java 虚拟机上。
Java 虚拟机解释（并可能编译）此字节码并执行应用程序。这些 JVM 是为主要体系结构和操作系统开发的，例如 Intel 上的 Windows/Mac/Linux。 JVM 开发人员 是一个相对较小的工程师群体，例如来自 Oracle 和 Sun 的工程师。
从应用程序开发人员的角度来看，他或她只需编译一次，因为字节代码（在 .class 文件中）可以在兼容的 JVM 上执行。应用程序开发人员无需担心底层架构或OS；他们只需要针对 JVM 的体系结构。 JVM开发人员是处理底层的人。
首先，"Java is interpreted" 的说法虽然有一定的事实依据，但非常具有误导性，最好从您的脑海中删除该概念。
Java 在构建时从源代码编译为中间表示（class 文件、字节码）。当 class 首次加载时，大多数 JVM 实现（包括 Oracle HotSpot 和 IBM J9）将经历一个短暂的解释阶段，但如果 class 将以任何频率使用， 动态编译器 (JIT) 将运行 编译为本机代码。 （一些 JVM，如 JRockit，直接进入本机，没有解释器。）
我认为 "Why isn't Java compiled directly to native code" 才是真正的问题。正如其他人所建议的那样，显而易见的答案是可移植性。但它比这更微妙：动态编译比静态编译产生更高质量的代码。当代码被动态编译时，JIT 知道静态编译器无法知道的事情：当前硬件的特性（CPU 版本、步进级别、缓存行大小等），以及当前 运行 的属性（感谢在解释期间收集的分析数据。）您的决策质量取决于质量您的信息；动态编译器比静态编译器拥有更多更好的可用信息，因此可以生成更好的代码。
此外，动态编译器有可能执行静态编译器做梦也想不到的优化。例如，动态编译器可以进行推测性优化，并在结果证明无效或假设后来变得不正确时将其撤消。 （参见 "Dynamic Deoptimization" 此处：http://www.ibm.com/developerworks/library/j-jtp12214/）。
我对 java 这样的解释型语言相对于编译型语言的优势感到困惑。
解释型语言（例如 java）优于编译型语言的标准解释是，同一个 .class 文件可以 运行 在不同类型的机器上架构。这如何为您节省工作？
对于每种不同的机器架构，您是否需要不同的编译器来将相同的 .class 文件解释为机器语言？因此，如果您需要针对每种不同的机器架构使用不同的编译器来将相同的 .class 文件解释为机器代码，这如何为您节省工作量？
为什么不直接制作一种编译语言，其中 .java 源文件立即编译成机器语言。当然，这将需要不同的编译器将 java 源文件编译为每种机器体系结构的机器语言，但这比必须为每台机器使用不同的编译器从 .[=27 编译更有效吗？ =] 文件到机器语言？
我的意思是这与编译语言相同——无论是将 java 源文件编译成机器代码还是将 class 文件编译成机器，您都需要针对每种机器架构的编译器代码。
谢谢。
首先，Java是一种编译型语言，也是一种解释型语言，因为你必须从.java编译到.class。
要获得问题的实质，通过（某种程度上）解释获得的优势 Java 是您只需要编译每个程序一次，并且它可以 运行 在任何计算机上，因为Java 运行时环境 (JRE) 预先编译以匹配本地 OS 和体系结构，可以弥合这一差距而无需（或最少）进一步编译。
然而，在一种未解释的语言中，您必须为每个 OS 和您希望它在 运行 上的每个体系结构编译每个程序，这比仅仅编译需要更多的努力和总编译时间JRE 为每个 OS 和体系结构编译一次，每个单独的程序只编译一次。
每次 运行s 都为本地体系结构编译的语言是不切实际的，因为编译是一个相当密集的过程。 Python 确实在每次 运行 时编译（尽管，像 Java 一样，它是为运行时环境而不是本地体系结构编译的）并且它是那里最慢的语言之一。
希望这有助于解决问题。
我喜欢sowrd299的回答。我的两分钱：
- 您在技术上拥有无穷无尽的不同目标架构
- 因此同时为 所有 目标编译代码并将其打包在一起将导致 infinite 大可执行文件
- 因此针对虚拟机字节码编译Java 是一个更好的解决方案：因为它只有一个目标架构
- 而开发人员可以分别为所有新旧架构添加 JVM，从而允许全部新东西（例如 Raspberry PI）运行 您的 java 代码是上个世纪编译的。
另一方面，"compile for multiple targets in advance" 并不是完全疯狂的事情。 Afaik Windows Universal Apps 以这种方式工作：它是同一个 exe 文件中的同一个应用程序，但实际上该 exe 包含为 80x86 和 ARM 目标编译的代码。这样一来，一个应用程序看起来可以在 windows 移动和桌面解决方案之间移植，无需任何进一步解释。
For each different machine architecture, wouldn't you need a different compiler to interpret the same .class file into the machine language? So if you need a different compiler for each different machine architecture to interpret the same .class file into machine code, how does this save you any work?
以上说法是你的核心误区。
应用程序开发人员 编写 Java 编译为字节码的代码，可以 运行 在任何兼容的 Java 虚拟机上。
Java 虚拟机解释（并可能编译）此字节码并执行应用程序。这些 JVM 是为主要体系结构和操作系统开发的，例如 Intel 上的 Windows/Mac/Linux。 JVM 开发人员 是一个相对较小的工程师群体，例如来自 Oracle 和 Sun 的工程师。
从应用程序开发人员的角度来看，他或她只需编译一次，因为字节代码（在 .class 文件中）可以在兼容的 JVM 上执行。应用程序开发人员无需担心底层架构或OS；他们只需要针对 JVM 的体系结构。 JVM开发人员是处理底层的人。
首先，"Java is interpreted" 的说法虽然有一定的事实依据，但非常具有误导性，最好从您的脑海中删除该概念。
Java 在构建时从源代码编译为中间表示（class 文件、字节码）。当 class 首次加载时，大多数 JVM 实现（包括 Oracle HotSpot 和 IBM J9）将经历一个短暂的解释阶段，但如果 class 将以任何频率使用， 动态编译器 (JIT) 将运行 编译为本机代码。 （一些 JVM，如 JRockit，直接进入本机，没有解释器。）
我认为 "Why isn't Java compiled directly to native code" 才是真正的问题。正如其他人所建议的那样，显而易见的答案是可移植性。但它比这更微妙：动态编译比静态编译产生更高质量的代码。当代码被动态编译时，JIT 知道静态编译器无法知道的事情：当前硬件的特性（CPU 版本、步进级别、缓存行大小等），以及当前 运行 的属性（感谢在解释期间收集的分析数据。）您的决策质量取决于质量您的信息；动态编译器比静态编译器拥有更多更好的可用信息，因此可以生成更好的代码。
此外，动态编译器有可能执行静态编译器做梦也想不到的优化。例如，动态编译器可以进行推测性优化，并在结果证明无效或假设后来变得不正确时将其撤消。 （参见 "Dynamic Deoptimization" 此处：http://www.ibm.com/developerworks/library/j-jtp12214/）。