编译语言和解释语言的区别_编译语言和解释语言之间的区别-CSDN博客

编译语言和解释语言的区别

你好，世界(Hello World)

Here’s a question that stumps plenty of smart people. Is JavaScript a compiled or interpreted language? Are you sure?

这是一个困扰许多聪明人的问题。 JavaScript是编译语言还是解释语言？你确定吗？

Over the years, clever people have blurred the boundaries between the two ways programs are built. We’ll get to JavaScript in a moment. But first, here’s how things started.

多年来，聪明的人已经模糊了程序的两种构建方式之间的界限。稍后我们将介绍JavaScript。但是首先，这是事情的开始。

编译代码：OG (Compiled code: The OG)

When you write code, you write it in a language of your choice. You can use Visual Basic or C++. Java or JavaScript. COBOL or Brainf***. We won’t judge.

编写代码时，将以您选择的语言编写代码。您可以使用Visual Basic或C ++。 Java或JavaScript。 COBOL或Brainf ***。我们不会判断。

With very few exceptions, all the languages you use to write code are high-level languages. Computers can’t run their code directly. Instead, you need a translation step that converts your high-level code into lower-level machine code that can be funneled straight to the computer’s CPU.

除了极少数例外，用于编写代码的所有语言都是高级语言。计算机无法直接运行其代码。相反，您需要一个翻译步骤，将您的高级代码转换为可以直接传递到计算机CPU的较低级机器代码。

So how do you translate your code from high-level to low-level? In a compiled language, you use a step called compilation as soon as you finish programming. The compilation translates your source code into machine instructions.

那么，如何将代码从高级转换为低级？在编译语言中，一旦完成编程，便会使用称为编译的步骤。该编译将您的源代码转换为机器指令。

Once you’ve finished compiling your code, you’ve got a ready-to-use program that you can share with all your friends… because they’re all using the same operating system and processor architecture as you, right? Wait, they aren’t?

完成代码编译后，您便可以使用一个可以与所有朋友共享的程序……因为他们都使用与您相同的操作系统和处理器体系结构，对吗？等等，不是吗？

The problem with compiled code is that it has some hardware details baked in. For example, you can’t compile code on a 32-bit CPU and expect to run that same file on a 64-bit CPU. And you definitely can’t port a compiled application from one operating system (like Windows) to another (like macOS).

编译代码的问题在于它包含了一些硬件细节。例如，您不能在32位CPU上编译代码，而期望在64位CPU上运行同一文件。而且，您绝对不能将已编译的应用程序从一个操作系统(例如Windows)移植到另一个操作系统(例如macOS)。

Because compiled code is barebones down-to-the-metal 1s and 0s, it’s fast. (Or at least as fast as possible, assuming you’ve written good code.) However, the process of compiling your code takes time. Years ago, big software products could compile for minutes or more, which gave everyone a good excuse to go drink a fourth cup of coffee or buy some more candy from the company vending machine.

因为编译后的代码是准1和0的准系统，所以速度很快。 (或者，如果您编写了不错的代码，则至少要尽可能快。)但是，编译代码的过程需要时间。几年前，大型软件产品可以编译几分钟或更长时间，这给每个人一个很好的借口，可以喝第四杯咖啡或从公司的自动售货机购买更多糖果。

解释的代码(过去) (Interpreted code (in the old days))

There’s another pathway to get your high-level code running. Instead of using a compiler to transform it, you can use an interpreter.

还有另一种途径可以使您的高级代码运行。您可以使用解释器，而不是使用编译器对其进行转换。

The interpreter looks at your code (line by line, in the simplest case) and makes it happen. For example, if you click a button in your program, the interpreter reads the code for that event and executes just that bit of logic. Under the hood, the interpreter is doing the same job a compiler does — translating higher-level code to lower-level instructions. But compilers do their job on the whole program, and they work ahead of time. Interpreters work on smaller sections as you run your program. (And here’s a bigger difference — compilers run once to create a finished ready-to-use program, while an interpreter needs to jump into action every single time you run the program.)

解释器查看您的代码(在最简单的情况下，逐行查看)并将其实现。例如，如果您单击程序中的按钮，则解释器将读取该事件的代码并仅执行该部分逻辑。在后台，解释器执行的工作与编译器相同—将高级代码转换为低级指令。但是编译器会在整个程序上完成工作，并且会提前工作。在您运行程序时，口译员会在较小的部分上工作。 (这是一个更大的差异-编译器运行一次以创建完成的即用型程序，而解释器则需要在每次运行该程序时立即采取行动。)

A traditional rule of thumb is that interpreted code is at least ten times slower than already compiled code. At first glance, that seems like a lot. And it is a lot. Interpreters are wayyy slower than compilers.

传统的经验法则是，已解释的代码比已编译的代码至少慢十倍。乍一看，这似乎很多。它是很多。解释器比编译器慢很多。

But interpreted code does have the advantage that it can work anywhere. As long as a computer (or device) has an interpreter for your language, it can interpret the source code and run your program. That was a really exciting idea when interpreters were first invented.

但是解释型代码确实具有可以在任何地方运行的优点。只要计算机(或设备)具有针对您的语言的解释器，它就可以解释源代码并运行您的程序。当口译员第一次发明时，这是一个非常令人兴奋的想法。

可是等等… (But wait…)

Hold on, we’ve sort of been lying a teeny bit. People usually talk about compiled languages and interpreted languages — for example, C++, Rust, and Go are compiled languages, while Python and old-school BASIC are interpreted. But this is just a convenient simplification (read: total lie). In most cases, a language is free to work with whatever kind of tools and in whatever kind of runtime environment someone builds.

等等，我们有点说谎了。人们通常谈论编译语言和解释语言，例如C ++，Rust和Go是编译语言，而Python和老式BASIC被解释。但这只是一个方便的简化(阅读：全面谎言)。在大多数情况下，一种语言可以自由使用某人构建的任何类型的工具和任何类型的运行时环境。

People expect C++ to be compiled, and most implementations of C++ use a compiler. But there’s nothing stopping someone from building an interpreter that understands C++ code — and people have! The reverse is true as well. Someone can write a compiler for an interpreted language, like they have for Python and classic Visual Basic. Language implementations evolve.

人们期望C ++能够被编译，并且大多数C ++实现都使用编译器。但是，没有什么可以阻止某人构建能够理解C ++代码的解释器的，而人们却拥有！反之亦然。有人可以为解释性语言编写编译器，就像对Python和经典Visual Basic一样。语言实现不断发展。

即时编译：现代解决方案 (Just-in-time compilation: the modern solution)

Remember when we said compilation used to take a lot of time? When computers became a million times faster and compilation shrunk down to a few fractions of a second, the balance between compiled and interpreted languages changed. Clever people blurred the boundaries between the two with a technique called JIT (just-in-time compilation). And that paved the way for most of the modern runtimes we use today.

还记得我们说编译过去要花费很多时间吗？当计算机的速度提高一百万倍，编译速度缩小到几分之一秒时，编译语言和解释语言之间的平衡就发生了变化。聪明的人使用称为JIT(即时编译)的技术模糊了两者之间的界限。这就为我们今天使用的大多数现代运行时铺平了道路。

The basic idea was this: Since compilers have godly powers of optimization, and seeing as compiled code is so much faster than interpreted code, why not just compile everything? The trick is to compile is just before you run it. That way there’s no problem with compatibility, because your code is compiled on the same computer that’s going to run it.

基本思想是：既然编译器具有敬畏的优化能力，并且看到编译后的代码比解释后的代码快得多，那么为什么不编译所有内容呢？诀窍是在运行它之前就进行编译。这样，兼容性就不会有问题，因为您的代码是在将要运行它的同一台计算机上编译的。

JIT really took off with Java. Later on, it was used for the .NET family of languages (like C# and VB.NET). On both these platforms, there are actually two compilation steps:

JIT确实与Java接轨。后来，它被用于.NET语言家族(例如C＃和VB.NET)。在这两个平台上，实际上都有两个编译步骤：

The first step turns your high-level code into medium-level code that’s somewhat optimized and much more compact. (In .NET, that medium-level code is called IL, for Intermediate Language.)
第一步将您的高级代码转换为经过某种程度优化和紧凑的中级代码。 (在.NET中，该中间级代码称为中间语言IL)。
The second step is the JIT that turns your medium-level code into traditional low-level code. It takes place when you run the program.
第二步是将您的中级代码转换为传统的低级代码的JIT。它在您运行程序时发生。

Often, these two compilation steps happen on different computers. For example, if it’s a desktop program, the high-to-medium step happens on your computer and the medium-to-low step happens on the user’s computer. If it’s a server-side web application, the high-to-medium step happens on your computer and the medium-to-low step happens on the web server.

通常，这两个编译步骤发生在不同的计算机上。例如，如果它是一个桌面程序，则高中步骤在您的计算机上发生，中低步骤在用户的计算机上发生。如果它是服务器端Web应用程序，则高中步骤在您的计算机上发生，中低步骤在Web服务器上发生。

JavaScript和WebAssembly中的编译 (Compilation in JavaScript and WebAssembly)

These days, nearly everything that used to be interpreted is now JIT-compiled, including the language everyone loves (and sometimes loves to hate), JavaScript.

这些天来，几乎所有以前解释过的东西现在都经过JIT编译，包括每个人都喜欢(有时也喜欢讨厌)，JavaScript的语言。

Over the years, the JavaScript compilation model has been extensively optimized by genius-level programmers. Browsers use another component, called a profiler, to make compilation decisions about JavaScript. For example, the profiler might interpret the first bit of code in a page, but then choose to compile another more substantial block of code. And if a particular piece of code is being used a lot, the profiler may decide it’s worth taking the time to recompile it with more optimizations, so the code becomes faster. If you want to learn more about all the tricks the JavaScript compiler and profiler have up their sleeves, check out this explanation.

多年来，天才级程序员对JavaScript编译模型进行了广泛的优化。浏览器使用另一个称为探查器的组件来做出有关JavaScript的编译决定。例如，事件探查器可能会解释页面中代码的第一位，但随后选择编译另一个更重要的代码块。而且，如果大量使用特定代码，则探查器可能会认为值得花时间通过更多优化来重新编译它，因此代码变得更快。如果您想进一步了解JavaScript编译器和事件探查器的所有技巧，请查看此说明。

And here’s one more curve ball. You may have heard of the next New Shiny Thing, WebAssembly. Now that you’ve read this story, you’ll have an easier time understanding how it works. Basically, WebAssembly is a medium-level language. The idea is that you will write your code in a high-level language (there are plenty of options — maybe you use Rust, or C, or Python). Then you compile that to WebAssembly, and put it on a website. When someone visits your page, their browser gets the partly optimized WebAssembly code and then compiles the medium-level down to the low-level. The more things change, the more they stay the same.

这里还有一个曲线球。您可能已经听说了下一个New Shiny Thing WebAssembly 。现在，您已经阅读了这个故事，您将可以更轻松地了解它的工作原理。基本上，WebAssembly是一种中级语言。这个想法是，您将使用高级语言编写代码(有很多选择-可能使用Rust，C或Python)。然后，将其编译为WebAssembly，并将其放在网站上。当有人访问您的页面时，他们的浏览器会获得部分优化的WebAssembly代码，然后将中级编译为低级。变化越多，它们保持不变的可能性就越大。

Have a suggestion for a future programming topic you’d like to see illustrated? Drop a comment below! And if you liked this article and want a once-a-month newsletter with links to our best new content, why not subscribe to the Young Coder newsletter?

对您希望看到的未来编程主题有何建议？ 在下面发表评论！ 并且，如果您喜欢这篇文章，并希望获得每月一次的新闻通讯，其中包含指向我们最佳新内容的链接，那么为什么不订阅Young Coder新闻通讯呢？