编译语言与解释语言

发布于 2024-09-10 00:39:26 字数 216 浏览 4 评论 0原文

我试图更好地理解其中的差异。我在网上找到了很多解释,但它们倾向于抽象的差异而不是实际的含义。

我的大部分编程经验都是使用 CPython(动态、解释型)和 Java(静态、编译型)。但是,我知道还有其他类型的解释和编译语言。除了可以从用编译语言编写的程序分发可执行文件这一事实之外,每种类型还有什么优点/缺点吗?我经常听到人们争论解释型语言可以交互式使用,但我相信编译型语言也可以具有交互式实现,对吗?

I'm trying to get a better understanding of the difference. I've found a lot of explanations online, but they tend towards the abstract differences rather than the practical implications.

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(13

不甘平庸 2024-09-17 00:39:26

编译语言是一种程序一旦编译后就用目标机器的指令来表达的语言。例如,源代码中的加法“+”操作可以直接转换为机器代码中的“ADD”指令。

解释型语言是一种指令不直接由目标机器执行,而是由其他程序读取和执行的语言(通常是用本机机器的语言编写的)。例如,相同的“+”操作将在运行时被解释器识别,然后解释器将使用适当的参数调用自己的“add(a,b)”函数,然后执行机器代码“ADD”指令。

你可以用编译语言做任何你能用解释语言做的事情,反之亦然——它们都是图灵完备的。然而,两者在实施和使用方面都有优点和缺点。

我将完全概括(纯粹主义者请原谅我!)但是,粗略地说,以下是编译语言的优点:

  • 通过直接使用目标机器的本机代码获得更快的性能
  • 在编译阶段应用非常强大的优化的机会

以下是解释型语言的优点:

  • 更容易实现(编写好的编译器非常困难!!)
  • 不需要运行编译阶段: 可以直接“即时”执行代码
  • 对于动态语言可以更方便

请注意现代技术,例如字节码编译增加了一些额外的复杂性 - 这里发生的是编译器的目标是与底层硬件不同的“虚拟机”。然后可以在稍后阶段再次编译这些虚拟机指令以获得本机代码(例如,由 Java JVM JIT 编译器完成)。

A compiled language is one where the program, once compiled, is expressed in the instructions of the target machine. For example, an addition "+" operation in your source code could be translated directly to the "ADD" instruction in machine code.

An interpreted language is one where the instructions are not directly executed by the target machine, but instead read and executed by some other program (which normally is written in the language of the native machine). For example, the same "+" operation would be recognised by the interpreter at run time, which would then call its own "add(a,b)" function with the appropriate arguments, which would then execute the machine code "ADD" instruction.

You can do anything that you can do in an interpreted language in a compiled language and vice-versa - they are both Turing complete. Both however have advantages and disadvantages for implementation and use.

I'm going to completely generalise (purists forgive me!) but, roughly, here are the advantages of compiled languages:

  • Faster performance by directly using the native code of the target machine
  • Opportunity to apply quite powerful optimisations during the compile stage

And here are the advantages of interpreted languages:

  • Easier to implement (writing good compilers is very hard!!)
  • No need to run a compilation stage: can execute code directly "on the fly"
  • Can be more convenient for dynamic languages

Note that modern techniques such as bytecode compilation add some extra complexity - what happens here is that the compiler targets a "virtual machine" which is not the same as the underlying hardware. These virtual machine instructions can then be compiled again at a later stage to get native code (e.g. as done by the Java JVM JIT compiler).

桜花祭 2024-09-17 00:39:26

语言本身既不被编译也不被解释,只有语言的特定实现才是。 Java 就是一个完美的例子。有一个基于字节码的平台(JVM)、一个本机编译器(gcj)和一个 Java 超集的解释器(bsh)。那么现在Java是什么?字节码编译、本机编译还是解释型?

其他既可编译又可解释的语言有 Scala、Haskell 或 Ocaml。这些语言中的每一种都有一个交互式解释器,以及一个字节码或本机机器代码的编译器。

因此,通常按“编译”和“解释”对语言进行分类并没有多大意义。

A language itself is neither compiled nor interpreted, only a specific implementation of a language is. Java is a perfect example. There is a bytecode-based platform (the JVM), a native compiler (gcj) and an interpeter for a superset of Java (bsh). So what is Java now? Bytecode-compiled, native-compiled or interpreted?

Other languages, which are compiled as well as interpreted, are Scala, Haskell or Ocaml. Each of these languages has an interactive interpreter, as well as a compiler to byte-code or native machine code.

So generally categorizing languages by "compiled" and "interpreted" doesn't make much sense.

心安伴我暖 2024-09-17 00:39:26

开始思考:来自过去的爆炸

很久以前,很久以前,有一个计算领域的人
解释器和编译器。随之而来的是各种关于其优点的争论
一个比另一个。当时的普遍看法是这样的:

  • 解释器:快速开发(编辑和运行)。执行速度很慢,因为每个语句都必须解释为
    每次执行时的机器代码(想想这对于执行数千次的循环意味着什么)。
  • 编译器:开发速度慢(编辑、编译、链接和运行。编译/链接步骤可能需要很长时间)。快速地
    执行。整个程序已经是本机机器代码了。

运行时间相差一两个数量级
性能介于解释程序和编译程序之间。其他区分
点,例如代码的运行时可变性,也引起了一些兴趣,但主要
区别围绕着运行时性能问题。

今天,景观已经发展到这样的程度,编译/解释的区别是
几乎无关紧要。许多
编译语言调用非编译语言的运行时服务
完全基于机器代码。此外,大多数解释性语言都被“编译”成字节码
执行前。字节码解释器非常高效,可以与某些编译器生成的相媲美
从执行速度的角度来看代码。

典型的区别在于编译器生成本机机器代码,解释器读取源代码并
使用某种运行时系统动态生成机器代码。
如今,经典诠释者已所剩无几——几乎全部
编译成字节码(或其他一些半编译状态),然后在虚拟“机器”上运行。

Start thinking in terms of a: blast from the past

Once upon a time, long long ago, there lived in the land of computing
interpreters and compilers. All kinds of fuss ensued over the merits of
one over the other. The general opinion at that time was something along the lines of:

  • Interpreter: Fast to develop (edit and run). Slow to execute because each statement had to be interpreted into
    machine code every time it was executed (think of what this meant for a loop executed thousands of times).
  • Compiler: Slow to develop (edit, compile, link and run. The compile/link steps could take serious time). Fast
    to execute. The whole program was already in native machine code.

A one or two order of magnitude difference in the runtime
performance existed between an interpreted program and a compiled program. Other distinguishing
points, run-time mutability of the code for example, were also of some interest but the major
distinction revolved around the run-time performance issues.

Today the landscape has evolved to such an extent that the compiled/interpreted distinction is
pretty much irrelevant. Many
compiled languages call upon run-time services that are not
completely machine code based. Also, most interpreted languages are "compiled" into byte-code
before execution. Byte-code interpreters can be very efficient and rival some compiler generated
code from an execution speed point of view.

The classic difference is that compilers generated native machine code, interpreters read source code and
generated machine code on the fly using some sort of run-time system.
Today there are very few classic interpreters left - almost all of them
compile into byte-code (or some other semi-compiled state) which then runs on a virtual "machine".

于我来说 2024-09-17 00:39:26

极端和简单的情况:

  • 编译器将以目标机器的本机可执行格式生成二进制可执行文件。该二进制文件包含除系统库之外的所有必需资源;它已准备好运行,无需进一步的准备和处理,并且运行起来像闪电一样,因为该代码是目标计算机上 CPU 的本机代码。

  • 解释器将在循环中向用户提供提示,用户可以在其中输入语句或代码,并且在点击 RUN 或等效项后,解释器将检查、扫描、解析并解释性执行每一行直到程序运行到停止点或出现错误。因为每一行都是单独处理的,并且解释器不会从之前看到的行中“学习”任何东西,所以每次将每一行都需要将人类可读语言转换为机器指令,所以速度非常慢。好的一面是,用户可以通过各种方式检查程序并与之交互:更改变量、更改代码、在跟踪或调试模式下运行......等等。

抛开这些,让我解释一下,生活不再那么简单了。例如,

  • 许多解释器会预编译他们给出的代码,这样翻译步骤就不必一次又一次重复。
  • 有些编译器不编译为特定于 CPU 的机器指令,而是编译为字节码,这是一种虚拟机器的人造机器代码。这使得编译后的程序更加可移植,但在每个目标系统上都需要一个字节码解释器。
  • 字节码解释器(我在这里关注的是 Java)最近倾向于在执行之前重新编译它们为目标部分的 CPU 获得的字节码(称为 JIT)。为了节省时间,这通常只针对经常运行的代码(热点)进行。
  • 一些看起来和行为都像解释器的系统(例如 Clojure)会立即编译它们获得的任何代码,但允许交互式访问程序环境。这基本上就是解释器的便利性和二进制编译的速度。
  • 有些编译器并不真正编译,它们只是预消化和压缩代码。不久前我听说 Perl 就是这样工作的。所以有时编译器只是做了一些工作,大部分工作仍然是解释。

最后,如今,解释与编译是一种权衡,花费(一次)编译的时间通常会得到更好的运行时性能的回报,但解释环境提供了更多的交互机会。编译与解释主要是“理解”程序的工作如何在不同进程之间划分的问题,而如今,随着语言和产品试图提供两全其美的功能,界限有点模糊。

The extreme and simple cases:

  • A compiler will produce a binary executable in the target machine's native executable format. This binary file contains all required resources except for system libraries; it's ready to run with no further preparation and processing and it runs like lightning because the code is the native code for the CPU on the target machine.

  • An interpreter will present the user with a prompt in a loop where he can enter statements or code, and upon hitting RUN or the equivalent the interpreter will examine, scan, parse and interpretatively execute each line until the program runs to a stopping point or an error. Because each line is treated on its own and the interpreter doesn't "learn" anything from having seen the line before, the effort of converting human-readable language to machine instructions is incurred every time for every line, so it's dog slow. On the bright side, the user can inspect and otherwise interact with his program in all kinds of ways: Changing variables, changing code, running in trace or debug modes... whatever.

With those out of the way, let me explain that life ain't so simple any more. For instance,

  • Many interpreters will pre-compile the code they're given so the translation step doesn't have to be repeated again and again.
  • Some compilers compile not to CPU-specific machine instructions but to bytecode, a kind of artificial machine code for a ficticious machine. This makes the compiled program a bit more portable, but requires a bytecode interpreter on every target system.
  • The bytecode interpreters (I'm looking at Java here) recently tend to re-compile the bytecode they get for the CPU of the target section just before execution (called JIT). To save time, this is often only done for code that runs often (hotspots).
  • Some systems that look and act like interpreters (Clojure, for instance) compile any code they get, immediately, but allow interactive access to the program's environment. That's basically the convenience of interpreters with the speed of binary compilation.
  • Some compilers don't really compile, they just pre-digest and compress code. I heard a while back that's how Perl works. So sometimes the compiler is just doing a bit of the work and most of it is still interpretation.

In the end, these days, interpreting vs. compiling is a trade-off, with time spent (once) compiling often being rewarded by better runtime performance, but an interpretative environment giving more opportunities for interaction. Compiling vs. interpreting is mostly a matter of how the work of "understanding" the program is divided up between different processes, and the line is a bit blurry these days as languages and products try to offer the best of both worlds.

暖伴 2024-09-17 00:39:26

来自 http://www.quora.com/What-is -编译型编程语言和解释型编程语言之间的差异

没有区别,因为“编译型编程语言”和
“解释型编程语言”不是有意义的概念。任何
编程语言,我真正的意思是任何可以解释或
编译。因此,解释和编译都是实现
技术,而不是语言的属性。

解释是一种技术,通过它另一个程序,
解释器,代表程序执行操作
解释以便运行它。如果你能想象阅读一个程序
并按照它所说的一步一步去做,说是从头开始
纸,这也正是口译员所做的。一个常见的原因
解释程序的一个特点是解释器相对容易
写。另一个原因是口译员可以监控口译员的内容。
程序试图在运行时执行某项策略,例如
安全。

编译是一种用一种语言编写程序的技术
(“源语言”)被翻译成另一种语言的程序
语言(“对象语言”),希望这意味着同样的事情
和原来的程序一样。在翻译过程中,经常会遇到这样的情况:
编译器还尝试以以下方式转换程序:
使目标程序更快(不改变其含义!)。一个
编译程序的常见原因是有一些好方法
快速且无开销地运行对象语言中的程序
一路解释​​源语言。

根据上面的定义,你可能已经猜到,这两个
实现技术并不相互排斥,甚至可以是
补充。传统上,编译器的目标语言是
机器代码或类似的东西,指的是任意数量的
特定计算机 CPU 能够理解的编程语言。这
然后机器代码将在“金属上”运行(尽管人们可能会看到,如果
仔细一看,“金属”的工作原理很像
翻译)。然而如今,使用编译器来执行任务已经很常见了。
生成需要解释的目标代码,例如,
这就是 Java 过去(有时仍然)的工作方式。有
将其他语言翻译为 JavaScript 的编译器,然后
通常在 Web 浏览器中运行,该浏览器可能会解释 JavaScript,或者
将其编译为虚拟机或本机代码。我们还有口译员
用于机器代码,可用于模拟一种硬件
其他。或者,可以使用编译器生成目标代码
然后是另一个编译器的源代码,它甚至可能编译
内存中的代码正好赶上它的运行,这反过来又是。 。 。你得到
这个想法。有很多方法可以结合这些概念。

From http://www.quora.com/What-is-the-difference-between-compiled-and-interpreted-programming-languages

There is no difference, because “compiled programming language” and
“interpreted programming language” aren’t meaningful concepts. Any
programming language, and I really mean any, can be interpreted or
compiled. Thus, interpretation and compilation are implementation
techniques, not attributes of languages.

Interpretation is a technique whereby another program, the
interpreter, performs operations on behalf of the program being
interpreted in order to run it. If you can imagine reading a program
and doing what it says to do step-by-step, say on a piece of scratch
paper, that’s just what an interpreter does as well. A common reason
to interpret a program is that interpreters are relatively easy to
write. Another reason is that an interpreter can monitor what a
program tries to do as it runs, to enforce a policy, say, for
security.

Compilation is a technique whereby a program written in one language
(the “source language”) is translated into a program in another
language (the “object language”), which hopefully means the same thing
as the original program. While doing the translation, it is common for
the compiler to also try to transform the program in ways that will
make the object program faster (without changing its meaning!). A
common reason to compile a program is that there’s some good way to
run programs in the object language quickly and without the overhead
of interpreting the source language along the way.

You may have guessed, based on the above definitions, that these two
implementation techniques are not mutually exclusive, and may even be
complementary. Traditionally, the object language of a compiler was
machine code or something similar, which refers to any number of
programming languages understood by particular computer CPUs. The
machine code would then run “on the metal” (though one might see, if
one looks closely enough, that the “metal” works a lot like an
interpreter). Today, however, it’s very common to use a compiler to
generate object code that is meant to be interpreted—for example, this
is how Java used to (and sometimes still does) work. There are
compilers that translate other languages to JavaScript, which is then
often run in a web browser, which might interpret the JavaScript, or
compile it a virtual machine or native code. We also have interpreters
for machine code, which can be used to emulate one kind of hardware on
another. Or, one might use a compiler to generate object code that is
then the source code for another compiler, which might even compile
code in memory just in time for it to run, which in turn . . . you get
the idea. There are many ways to combine these concepts.

秋叶绚丽 2024-09-17 00:39:26

解释型源代码相对于编译型源代码的最大优势是可移植性

如果您的源代码已编译,则需要为您希望程序运行的每种类型的处理器和/或平台编译不同的可执行文件(例如,一个用于 Windows x86,一个用于 Windows x64,一个用于 Linux x64,等等在)。此外,除非您的代码完全符合标准并且不使用任何特定于平台的函数/库,否则您实际上需要编写和维护多个代码库!

如果您的源代码是解释型的,您只需编写一次,就可以在任何平台上由适当的解释器解释并执行!它便携式!请注意,解释器本身是一个可执行程序,是为特定平台编写和编译的。

编译代码的优点是它对最终用户隐藏源代码(这可能是知识产权),因为您无需部署原始的人类可读源代码,而是部署一个不起眼的二进制可执行文件。

The biggest advantage of interpreted source code over compiled source code is PORTABILITY.

If your source code is compiled, you need to compile a different executable for each type of processor and/or platform that you want your program to run on (e.g. one for Windows x86, one for Windows x64, one for Linux x64, and so on). Furthermore, unless your code is completely standards compliant and does not use any platform-specific functions/libraries, you will actually need to write and maintain multiple code bases!

If your source code is interpreted, you only need to write it once and it can be interpreted and executed by an appropriate interpreter on any platform! It's portable! Note that an interpreter itself is an executable program that is written and compiled for a specific platform.

An advantage of compiled code is that it hides the source code from the end user (which might be intellectual property) because instead of deploying the original human-readable source code, you deploy an obscure binary executable file.

对你再特殊 2024-09-17 00:39:26

编译器和解释器执行相同的工作:将编程语言翻译为另一种编程语言,通常更接近硬件,通常是直接可执行的机器代码。

传统上,“编译”意味着这种翻译一次性完成,由开发人员完成,并将生成的可执行文件分发给用户。纯例子:C++。
编译通常需要相当长的时间,并尝试进行大量昂贵的优化,以便生成的可执行文件运行得更快。最终用户没有工具和知识来自己编译东西,并且可执行文件通常必须在各种硬件上运行,因此您无法进行许多特定于硬件的优化。在开发过程中,单独的编译步骤意味着更长的反馈周期。

传统上,“解释”意味着当用户想要运行程序时,翻译会“即时”发生。纯示例:普通 PHP。一个幼稚的解释器必须在每次运行时解析和翻译每一段代码,这使得它非常慢。它无法进行复杂且成本高昂的优化,因为它们花费的时间比执行中节省的时间更长。但它可以充分利用其运行的硬件的功能。缺少单独的编译步骤减少了开发期间的反馈时间。

但如今“编译与解释”并不是一个非黑即白的问题,中间存在着一些阴影。天真的、简单的解释者几乎已经绝迹了。许多语言使用两步过程,将高级代码转换为独立于平台的字节码(解释速度要快得多)。然后,您将拥有“及时编译器”,它在每个程序运行时最多编译一次代码,有时会缓存结果,甚至智能地决定解释很少运行的代码,并对运行频繁的代码进行强大的优化。在开发过程中,即使对于传统编译语言,调试器也能够在正在运行的程序内切换代码。

A compiler and an interpreter do the same job: translating a programming language to another pgoramming language, usually closer to the hardware, often direct executable machine code.

Traditionally, "compiled" means that this translation happens all in one go, is done by a developer, and the resulting executable is distributed to users. Pure example: C++.
Compilation usually takes pretty long and tries to do lots of expensive optmization so that the resulting executable runs faster. End users don't have the tools and knowledge to compile stuff themselves, and the executable often has to run on a variety of hardware, so you can't do many hardware-specific optimizations. During development, the separate compilation step means a longer feedback cycle.

Traditionally, "interpreted" means that the translation happens "on the fly", when the user wants to run the program. Pure example: vanilla PHP. A naive interpreter has to parse and translate every piece of code every time it runs, which makes it very slow. It can't do complex, costly optimizations because they'd take longer than the time saved in execution. But it can fully use the capabilities of the hardware it runs on. The lack of a separrate compilation step reduces feedback time during development.

But nowadays "compiled vs. interpreted" is not a black-or-white issue, there are shades in between. Naive, simple interpreters are pretty much extinct. Many languages use a two-step process where the high-level code is translated to a platform-independant bytecode (which is much faster to interpret). Then you have "just in time compilers" which compile code at most once per program run, sometimes cache results, and even intelligently decide to interpret code that's run rarely, and do powerful optimizations for code that runs a lot. During development, debuggers are capable of switching code inside a running program even for traditionally compiled languages.

听闻余生 2024-09-17 00:39:26

我猜这是计算机科学中最大的误解之一。
因为解释和编译是完全不同的两个东西,我们不能这样比较。

编译是将一种语言翻译成另一种语言的过程。编译的类型很少。

  • 编译 - 将高级语言翻译成机器/字节代码(例如:C/C++/Java)
  • 转换 - 将高级语言翻译成另一种高级语言(例如:TypeScript)

解释是实际执行程序的过程。这可能以几种不同的方式发生。

  • 机器级解释 - 这种解释发生在编译成机器代码的代码上。指令由处理器直接解释。 C/C++ 等编程语言生成可由处理器执行的机器代码。因此处理器可以直接执行这些指令。

  • 虚拟机级别解释 - 这种解释发生在未编译为机器级别(处理器支持)代码,而是编译为某些中间级别代码的代码中。该执行是由另一个软件完成的,该软件由处理器执行。此时实际上处理器并没有看到我们的应用程序。它只是执行虚拟机,虚拟机正在执行我们的应用程序。 Java、Python、C# 等编程语言生成字节码,可由虚拟解释器/机器执行。

因此,归根结底,我们必须明白的是,世界上所有的编程语言都应该在某个时间被解释。这可能是由处理器完成的(硬件)或虚拟机。

编译只是将我们编写的人类可理解的高级代码提升到某种硬件/软件机器可理解的级别的过程。

这是完全不同的两个事情,我们无法比较。但这个术语对于教导初学者编程语言如何工作非常有用。

PS:
某些编程语言(例如 Java)采用混合方法来执行此操作。首先,将高级代码编译为虚拟机可读的字节代码。一个称为 JIT 编译器的组件会即时将字节码编译为机器代码。具体来说,多次执行的代码行会被翻译成机器语言,这使得解释过程更快。因为硬件处理器总是比虚拟解释器/处理器快得多。

Java JIT 编译器的工作原理

This is one of the biggest misunderstood things in computer science as I guess.
Because interpretation and compilation are completely two different things, which we can't compare in this way.

The compilation is the process of translating one language into another language. There are few types of compilations.

  • Compiling - Translate high-level language into machine/byte code (ex: C/C++/Java)
  • Transpiling - Translate high-level language into another high-level language (ex: TypeScript)

Interpretation is the process of actually executing the program. This may happen in few different ways.

  • Machine level interpretation - This interpretation happens to the code which is compiled into machine code. Instructions are directly interpreted by the processor. Programming languages like C/C++ generate machine code, which is executable by the processor. So the processor can directly execute these instructions.

  • Virtual machine level interpretation - This interpretation happens to the code which is not compiled into the machine level (processor support) code, but into some intermediate-level code. This execution is done by another software, which is executed by the processor. At this time actually processor doesn't see our application. It just executing the virtual machine, which is executing our application. Programming languages like Java, Python, C# generate a byte code, which is executable by the virtual interpreter/machine.

So at the end of the day what we have to understand is, all the programming languages in the world should be interpreted at some time. It may be done by a processor(hardware) or a virtual machine.

The compilation is just the process of bringing the high-level code we write that is human-understandable into some hardware/software machine-understandable level.

These are completely two different things, which we can't compare. But that terminology is pretty much good to teach beginners how programming languages work.

PS:
Some programming languages like Java have a hybrid approach to do this. First, compile the high-level code into byte code which is virtual-machine readable. And on the fly, a component called the JIT compiler compiles byte-code into machine code. Specifically, code lines that are executed again and again many times are get translated into the machine language, which makes the interpretation process much faster. Because hardware processor is always much faster than virtual interpreter/processor.

How Java JIT compiler works

掩饰不了的爱 2024-09-17 00:39:26

首先澄清一下,Java 并不像 C++ 那样完全静态编译和链接。它被编译成字节码,然后由 JVM 解释。 JVM 可以对本机机器语言进行即时编译,但不是必须这样做。

更重要的是:我认为交互性是主要的实际差异。由于所有内容都是解释的,因此您可以摘录一小段代码,解析并根据环境的当前状态运行它。因此,如果您已经执行了初始化变量的代码,您就可以访问该变量等。它确实适合诸如函数式风格之类的东西。

然而,解释的成本很高,尤其是当您拥有一个包含大量引用和上下文的大型系统时。根据定义,这是浪费的,因为相同的代码可能需要解释和优化两次(尽管大多数运行时对此有一些缓存和优化)。尽管如此,您还是要付出运行时成本,并且通常需要运行时环境。您也不太可能看到复杂的过程间优化,因为目前它们的性能还不够交互。

因此,对于不会发生太大变化的大型系统,以及对于某些语言,预编译和预链接所有内容、执行所有可以执行的优化更有意义。这最终会带来非常精简的运行时间,并且已经针对目标机器进行了优化。

至于生成可执行文件,这与它无关,恕我直言。您通常可以从编译语言创建可执行文件。但您也可以从解释性语言创建可执行文件,只不过解释器和运行时已打包在可执行文件中并对您隐藏。这意味着您通常仍然需要支付运行时成本(尽管我确信对于某些语言来说,有办法将所有内容转换为树可执行文件)。

我不同意所有语言都可以交互。某些语言,如 C,与机器和整个链接结构紧密相关,我不确定您是否可以构建一个有意义的、成熟的交互式版本

First, a clarification, Java is not fully static-compiled and linked in the way C++. It is compiled into bytecode, which is then interpreted by a JVM. The JVM can go and do just-in-time compilation to the native machine language, but doesn't have to do it.

More to the point: I think interactivity is the main practical difference. Since everything is interpreted, you can take a small excerpt of code, parse and run it against the current state of the environment. Thus, if you had already executed code that initialized a variable, you would have access to that variable, etc. It really lends itself way to things like the functional style.

Interpretation, however, costs a lot, especially when you have a large system with a lot of references and context. By definition, it is wasteful because identical code may have to be interpreted and optimized twice (although most runtimes have some caching and optimizations for that). Still, you pay a runtime cost and often need a runtime environment. You are also less likely to see complex interprocedural optimizations because at present their performance is not sufficiently interactive.

Therefore, for large systems that are not going to change much, and for certain languages, it makes more sense to precompile and prelink everything, do all the optimizations that you can do. This ends up with a very lean runtime that is already optimized for the target machine.

As for generating executables, that has little to do with it, IMHO. You can often create an executable from a compiled language. But you can also create an executable from an interpreted language, except that the interpreter and runtime is already packaged in the exectuable and hidden from you. This means that you generally still pay the runtime costs (although I am sure that for some language there are ways to translate everything to a tree executable).

I disagree that all languages could be made interactive. Certain languages, like C, are so tied to the machine and the entire link structure that I'm not sure you can build a meaningful fully-fledged interactive version

纵性 2024-09-17 00:39:26

Python Book © 2015 Imagine Publishing Ltd,通过第 10 页中提到的以下提示简单地区分了差异:

诸如 Python 之类的解释语言是将源代码转换为机器代码,然后在每次程序运行时执行的语言。这与 C 等编译语言不同,其中源代码仅转换为机器代码一次 - 然后每次程序运行时都会执行生成的机器代码。

The Python Book © 2015 Imagine Publishing Ltd, simply distunguishes the difference by the following hint mentioned in page 10 as:

An interpreted language such as Python is one where the source code is converted to machine code and then executed each time the program runs. This is different from a compiled language such as C, where the source code is only converted to machine code once – the resulting machine code is then executed each time the program runs.

最好是你 2024-09-17 00:39:26

给出一个实际的答案相当困难,因为差异在于语言定义本身。可以为每种编译语言构建解释器,但不可能为每种解释语言构建编译器。这很大程度上与语言的正式定义有关。所以大学里没有人喜欢理论信息学的东西。

It's rather difficult to give a practical answer because the difference is about the language definition itself. It's possible to build an interpreter for every compiled language, but it's not possible to build an compiler for every interpreted language. It's very much about the formal definition of a language. So that theoretical informatics stuff noboby likes at university.

撧情箌佬 2024-09-17 00:39:26

编译是从用已编译的编程语言编写的代码创建可执行程序的过程。编译允许计算机运行和理解程序,而不需要用于创建程序的编程软件。当一个程序被编译时,它通常是针对与IBM兼容计算机一起工作的特定平台(例如IBM平台)进行编译,而不是针对其他平台(例如Apple平台)进行编译。
第一个编译器是由 Grace Hopper 在哈佛 Mark I 计算机上工作时开发的。如今,大多数高级语言都包含自己的编译器或提供可用于编译程序的工具包。与 Java 一起使用的编译器的一个很好的例子是 Eclipse,与 C 和 C++ 一起使用的编译器的一个例子是 gcc 命令。根据程序的大小,编译应该需要几秒钟或几分钟,如果编译时没有遇到错误,则会创建可执行文件。检查此信息

Compile is the process of creating an executable program from code written in a compiled programming language. Compiling allows the computer to run and understand the program without the need of the programming software used to create it. When a program is compiled it is often compiled for a specific platform (e.g. IBM platform) that works with IBM compatible computers, but not other platforms (e.g. Apple platform).
The first compiler was developed by Grace Hopper while working on the Harvard Mark I computer. Today, most high-level languages will include their own compiler or have toolkits available that can be used to compile the program. A good example of a compiler used with Java is Eclipse and an example of a compiler used with C and C++ is the gcc command. Depending on how big the program is it should take a few seconds or minutes to compile and if no errors are encountered while being compiled an executable file is created.check this information

╭⌒浅淡时光〆 2024-09-17 00:39:26

简短(不精确)的定义:

编译语言:整个程序立即翻译为机器代码,然后由 CPU 运行机器代码。

解释语言:程序是逐行读取的,一旦读取一行,CPU 就会执行该行的机器指令。

但实际上,如今很少有语言是纯粹编译或纯粹解释的,它通常是混合的。有关图片的更详细说明,请参阅此线程:

编译和解释有什么区别?

或者我后来的博文:

https://orangejuiceliberationfront.com/the-difference- Between-compiler-and-interpreter/

Short (un-precise) definition:

Compiled language: Entire program is translated to machine code at once, then the machine code is run by the CPU.

Interpreted language: Program is read line-by-line and as soon as a line is read the machine instructions for that line are executed by the CPU.

But really, few languages these days are purely compiled or purely interpreted, it often is a mix. For a more detailed description with pictures, see this thread:

What is the difference between compilation and interpretation?

Or my later blog post:

https://orangejuiceliberationfront.com/the-difference-between-compiler-and-interpreter/

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文