当前位置：文江博客话题详情

为什么解释语言大多是鸭子类型，而编译语言则具有强类型？

发布于 2024-07-09 18:34:37 字数 50 浏览 7 评论 0原文

我只是不知道，这有什么技术原因吗？为弱类型语言实现编译器是否更困难？它是什么？

原文

分享到QQ

分享到微博

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

发布评论

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

最偏执的依靠 2024-07-16 18:34:37

问题背后的前提有点狡猾。解释语言大多是鸭子类型的说法是不正确的。编译语言大多都具有强类型是不正确的。 类型系统是语言的一个属性。 编译与解释是实现的一个属性。

示例：

编程语言Scheme是动态类型的（又名鸭子类型），并且它有许多解释的实现，还包括一些优秀的本机代码编译器，包括 Larceny、Gambit 和 PLT Scheme（其中包括解释器和 JIT 编译器，可实现无缝转换）。
Haskell 编程语言是静态类型的；两个最著名的实现是解释器 HUGS 和编译器 GHC。还有其他几个值得尊敬的实现，它们在编译为本机代码 (yhc) 和解释 (Helium) 之间平均分配。
编程语言 Standard ML 是静态类型的，它有许多本机代码编译器，其中最好和最积极维护的编译器之一是 MLton，但最有用的实现之一是解释器莫斯科 ML
Objective Caml 编程语言是静态类型的。它仅附带一种实现（来自法国的 INRIA），但该实现包括解释器和本机代码编译器。
编程语言 Pascal 是静态类型的，但由于 UCSD 构建的基于 P 代码解释器的出色实现，它在 20 世纪 70 年代开始流行。在后来的几年里，出现了优秀的本机代码编译器，例如用于 370 系列计算机的 IBM Pascal/VS 编译器。
编程语言 C 是静态类型的，今天几乎所有实现都是编译的，但在 20 世纪 80 年代，我们这些有幸使用 Sabre C 的人使用的是解释器。

尽管如此，您的问题背后有一些道理，因此您应该得到更周到的答案。事实是，动态类型语言似乎确实与解释实现相关。为什么会这样？

许多新语言都是由实现定义的。构建解释器比构建编译器更容易。动态检查类型比静态检查更容易。如果您正在编写解释器，则静态类型检查几乎没有性能优势。
除非您正在创建或改编非常灵活的多态类型系统，否则静态类型系统可能会妨碍程序员。但是，如果您正在编写一个解释器，一个原因可能是创建一个小型、轻量级的实现，不妨碍程序员。
在某些解释性语言中，许多基本操作的开销非常大，因此在运行时检查类型的额外开销并不重要。PostScript 就是一个很好的例子：如果您要运行并立即栅格化贝塞尔曲线，您将毫不犹豫地在这里或那里检查类型标记。

顺便说一句，请警惕术语“强”和“弱”类型，因为它们没有普遍认可的技术含义。相比之下，静态类型意味着程序在执行之前会被检查，并且程序可能在启动之前被拒绝。 动态类型意味着值的类型在执行期间被检查，并且类型错误的操作可能会导致程序停止或以其他方式在运行时发出错误信号。静态类型的主要原因是排除可能存在此类“动态类型错误”的程序。（这是编写解释器的人通常对静态类型不太感兴趣的另一个原因；执行在类型检查后立即发生，因此保证的区别和性质并不那么明显。）

通常强类型意味着类型系统没有漏洞，而弱类型意味着类型系统可以被破坏（使任何保证无效）。这些术语经常被错误地用来表示静态类型和动态类型。
要了解其中的差异，请考虑 C：该语言在编译时进行类型检查（静态类型），但存在大量漏洞；您几乎可以将任何类型的值转换为相同大小的另一种类型——特别是，您可以自由地转换指针类型。 Pascal 是一种旨在强类型的语言，但众所周知，它有一个不可预见的漏洞：没有标签的变体记录。

随着时间的推移，强类型语言的实现经常会出现漏洞，通常使得运行时系统的一部分可以用高级语言来实现。例如，Objective Caml 有一个名为 Obj.magic 的函数，它具有简单返回其参数的运行时效果，但在编译时它将任何类型的值转换为任何其他类型之一。我最喜欢的例子是 Modula-3，其设计者将其类型转换构造称为“LOOPHOLE”。

总之：

静态与动态是语言。
编译与解释是实现。
原则上这两个选择可以并且是正交的，但出于合理的技术原因动态类型经常与解释相关。

The premises behind the question are a bit dodgy. It is not true that interpreted languages are mostly ducktyped. It is not true that compiled languages mostly have strong typing. The type system is a property of a language. Compiled versus interpreted is a property of an implementation.

Examples:

The programming language Scheme is dynamically typed (aka duck-typed), and it has many dozens of interpreted implementations, but also some fine native-code compilers including Larceny, Gambit, and PLT Scheme (which includes both an interpreter and a JIT compiler making seamless transitions).
The programming language Haskell is statically typed; the two most famous implementations are the interpreter HUGS and the compiler GHC. There are several other honorable implementations split about evenly between compiling to native code (yhc) and interpretation (Helium).
The programming language Standard ML is statically typed, and it has had many native-code compilers, of which one of the best and most actively maintained is MLton, but one of the most useful implementations is the interpreter Moscow ML
The programming language Objective Caml is statically typed. It comes with only one implementation (from INRIA in France) but this implementation includes both an interpreter and a native-code compiler.
The programming language Pascal is statically typed, but it became popular in the 1970s because of the excellent implementation built at UCSD, which was based on a P-code interpreter. In later years fine native-code compilers became available, such as the IBM Pascal/VS compiler for the 370 series of computers.
The programming language C is statically typed, and today almost all implementations are compiled, but in the 1980s those of us lucky enough to be using Saber C were using an interpreter.

Nevertheless there is some truth behind your question, so you deserve a more thoughtful answer. The truth is that dynamically typed languages do seem to be correlated with interpreted implementations. Why might that be?

Many new languages are defined by an implementation. It is easier to build an interpreter than to build a compiler. It is easier to check types dynamically than to check them statically. And if you are writing an interpreter, there is little performance benefit to static type-checking.
Unless you are creating or adapting a very flexible polymorphic type system, a static type system is likely to get in the programmer's way. But if you are writing an interpreter, one reason may be to create a small, lightweight implementation that stays out of the programmer's way.
In some interpreted languages, many fundamental operations are so expensive that the additional overhead of checking types at run time doesn't matter. A good example is PostScript: if you're going to run off and rasterize Bezier curves at the drop of a hat, you won't balk at checking a type tag here or there.

Incidentally, please be wary of the terms "strong" and "weak" typing, because they don't have a universally agreed technical meaning. By contrast, static typing means that programs are checked before being executed, and a program might be rejected before it starts. Dynamic typing means that the types of values are checked during execution, and a poorly typed operation might cause the program to halt or otherwise signal an error at run time. A primary reason for static typing is to rule out programs that might have such "dynamic type errors". (This is another reason people who write interpreters are often less interested in static typing; execution happens immediately after type checking, so the distinction and the nature of the guarantee aren't as obvious.)

Strong typing generally means that there are no loopholes in the type system, whereas weak typing means the type system can be subverted (invalidating any guarantees). The terms are often used incorrectly to mean static and dynamic typing.
To see the difference, think of C: the language is type-checked at compile time (static typing), but there are plenty of loopholes; you can pretty much cast a value of any type to another type of the same size---in particular, you can cast pointer types freely. Pascal was a language that was intended to be strongly typed but famously had an unforeseen loophole: a variant record with no tag.

Implementations of strongly typed languages often acquire loopholes over time, usually so that part of the run-time system can be implemented in the high-level language. For example, Objective Caml has a function called Obj.magic which has the run-time effect of simply returning its argument, but at compile time it converts a value of any type to one of any other type. My favorite example is Modula-3, whose designers called their type-casting construct LOOPHOLE.

In summary:

Static vs dynamic is the language.
Compiled vs interpreted is the implementation.
In principle the two choices can be and are made orthogonally, but for sound technical reasons dynamic typing frequently correlates with interpretation.

回复收藏 0 原文

英雄似剑 2024-07-16 18:34:37

进行早期绑定（强类型）的原因是性能。通过早期绑定，您可以在编译时找到方法的位置，以便在运行时它已经知道它所在的位置。

然而，对于后期绑定，您必须去寻找一个看起来像客户端代码调用的方法的方法。当然，程序中的方法调用有很多很多，这就是动态语言变得“慢”的原因。

但当然，您可以创建一种进行后期绑定的静态编译语言，这会抵消静态编译的许多优点。

回复收藏 0 原文

不乱于心 2024-07-16 18:34:37

这很大程度上是因为编写和使用解释语言的人往往更喜欢鸭子类型，而开发和使用编译语言的人更喜欢强显式类型。（我认为对此达成共识的原因是 90% 是为了防止错误，10% 是为了性能。）对于今天编写的大多数程序来说，速度差异是微不足道的。 Microsoft Word 已经在 p 代码（未编译）上运行了 - 什么 - 15 年了？

我能想到的最好的例子。经典 Visual Basic（VB6/VBA/等）可以用 VB 编写相同的程序，并以相同的结果和可比较的速度运行，无论是编译还是解释。此外，您可以选择是否进行类型声明（实际上是变量声明）。大多数人更喜欢类型声明，通常是为了防止错误。我从未在任何地方听说过或读到过使用类型声明来提高速度。这至少可以追溯到硬件速度和容量的两倍数量级。

Google 最近受到了很多关注，因为他们在 JavaScript 的 JIT 编译器上所做的工作 - 这不需要对语言进行任何更改，也不需要程序员进行任何额外的考虑。在这种情况下，唯一的好处就是速度。

回复收藏 0 原文

晌融 2024-07-16 18:34:37

因为编译型语言在编译时需要考虑所使用的内存量。

当您看到类似以下内容时：

int a

在 C++ 中，编译器会输出保留四个字节内存的代码，然后分配局部符号“a”以指向该内存。如果您有像 javascript 这样的无类型脚本语言，解释器会在幕后分配所需的内存。你可以这样做：

var a = 10;  // a is probably a four byte int here
a = "hello world"; // now a is a 12 byte char array

在这两条线之间发生了很多事情。解释器删除 a 处的内存，为字符分配新的缓冲区，然后分配 a var 指向该新内存。在强类型语言中，没有解释器为您管理它，因此编译器必须编写考虑类型的指令。

int a = 10; // we now have four bytes on the stack.
a = "hello world"; // wtf? we cant push 12 bytes into a four byte variable! Throw an error!

因此编译器会停止编译该代码，这样 CPU 就不会盲目地将 12 字节写入 4 字节缓冲区并造成痛苦。

编译器编写额外指令来处理类型所增加的开销会显着减慢语言速度，并消除 C++ 等语言的优势。

-nelson

编辑回应评论

我对Python了解不多，所以我不能对此说太多。但松散类型会大大减慢运行时间。解释器 (VM) 调用的每条指令都必须进行评估，并在必要时将 var 强制转换为预期类型。如果：

mov a, 10
mov b, "34"
div a, b

那么解释器必须确保 a 是变量和数字，然后在处理指令之前必须将 b 强制转换为数字。再加上虚拟机执行的每条指令的开销，你的手上就会一团糟:)

Because compiled languages need to take the amount of memory used in account when they are compiled.

When you see something like:

int a

in C++, the compiler spits out code that reserves four bytes of memory and then assigns the local symbol "a" to point to that memory. If you had a typeless scripting language like javascript, the interpreter, behind the scenes, allocates the memory required. You can do:

var a = 10;  // a is probably a four byte int here
a = "hello world"; // now a is a 12 byte char array

There is a lot that happens between those two lines. The interpreter deletes the memory at a, allocates the new buffer for the chars, then assigns the a var to point to that new memory. In a strongly typed language, there is no interpreter that manages that for you and thus the compiler must write instructions that take into account type.

int a = 10; // we now have four bytes on the stack.
a = "hello world"; // wtf? we cant push 12 bytes into a four byte variable! Throw an error!

So the compilers stops that code from compiling so the CPU dosn't blindly write 12 bytes into a four byte buffer and cause misery.

The added overhead for a compiler writing extra instructions to take care of type would slow down the language significantly and remove the benefit of languages like C++.

-nelson

EDIT in response to comment

I don't know much about Python, so I can't say much about that. But loosely typedness slows down runtime considerably. Each instruction that the interpreter (VM) calls has to evaulate, and if necessary, coerce the var into the expected type. If you have:

mov a, 10
mov b, "34"
div a, b

Then the interpreter has to make sure that a is a variable and a number, then it would have to coerce b into a number before processing the instruction. Add that overhead for every instruction that the VM executes and you have a mess on your hands :)

回复收藏 0 原文

小…红帽 2024-07-16 18:34:37

我猜测具有动态（鸭子）类型的语言采用惰性求值，这受到惰性程序员的青睐，而惰性程序员不喜欢编写编译器;-)

回复收藏 0 原文

夜司空 2024-07-16 18:34:37

使用静态类型而不是鸭子类型基本上有两个原因：

静态错误检查。
性能

如果您使用解释型语言，则无需编译时间即可进行静态错误检查。有一个优势。此外，如果您已经有解释器的开销，那么该语言已经不会用于任何性能关键的事情，因此性能参数变得无关紧要。这解释了为什么静态类型解释语言很少见。

另一方面，鸭子类型可以在很大程度上用静态类型语言进行模拟，而无需完全放弃静态类型的好处。这可以通过以下任一方式完成：

模板。在这种情况下，如果实例化模板所使用的类型支持从模板内调用的所有方法，则您的代码将编译并运行。否则会给出编译时错误。这有点像编译时鸭子类型。
反射。您尝试按名称调用方法，它要么起作用，要么抛出异常。
标记为工会。这些基本上是其他类型的容器类，包含一些内存空间和描述当前包含的类型的字段。这些用于代数类型之类的东西。当调用一个方法时，它要么起作用，要么抛出异常，具体取决于当前包含的类型是否支持它。

这解释了为什么动态类型编译语言很少。

回复收藏 0 原文

只是一片海 2024-07-16 18:34:37

弱类型的语言是可以编译的，例如 Perl5 和大多数版本的 Lisp 都是编译语言。然而，编译的性能优势通常会丢失，因为语言运行时必须执行的大部分工作都是确定动态变量在特定时间的实际类型。

以 Perl 中的以下代码为例：

$x=1;
$x="hello";
print $x;

编译器显然很难确定 $x 在给定时间点的实际类型。在打印语句时，需要做一些工作来弄清楚这一点。在静态类型语言中，类型是完全已知的，因此可以提高运行时的性能。

Languages with weak typing can be compiled, for example, Perl5 and most versions of Lisp are compiled languages. However, the performance benefits of compiling are often lost because much of the work that the language runtime has to perform is to do with determining what type a dynamic variable really has at a particular time.

Take for example the following code in Perl:

$x=1;
$x="hello";
print $x;

It is obviously pretty difficult for the compiler to determine what type $x really has at a given point in time. At the time of the print statement, work needs to be done to figure that out. In a statically typed language, the type is fully known so performance at runtime can be increased.

回复收藏 0 原文