Jon Skeet 发布了这篇博文,其中他说他将要问为什么语言的动态部分如此出色。所以我想我会代表他先发制人地问:是什么让他们这么好?
5 回答
编程语言中两种根本不同的类型方法是静态类型和动态类型。它们支持非常不同的编程范式,并且它们都有自己的优点和缺点。
我强烈推荐 Chris Smith 的优秀文章What to Know Before Debating Type Systems以获得更多关于该主题的背景知识。
从那篇文章:
静态类型系统是一种机制,编译器通过该机制检查源代码并将标签(称为“类型”)分配给语法片段,然后使用它们来推断程序的行为。动态类型系统是一种机制,编译器通过该机制生成代码以跟踪程序使用的数据类型(巧合的是,也称为“类型”)。当然,在这两个系统中使用同一个词“类型”并非完全巧合。但最好将其理解为具有某种微弱的历史意义。试图找到一种世界观,其中“类型”在两个系统中真正意味着相同的东西,导致了极大的混乱。它没有。解决这个问题的更好方法是认识到:
- 很多时候,程序员都试图用静态和动态类型来解决同样的问题。
- 然而,静态类型并不局限于动态类型解决的问题。
- 动态类型也不限于可以用静态类型解决的问题。
- 从本质上讲,这两种技术根本不是一回事。
主要的是,您避免了让程序员“声明”这个、那个和另一个而产生的大量冗余。通过类型推断可以获得类似的优势(例如boo就是这样做的),但并不那么便宜和灵活。正如我过去所写的......:
完整的类型检查或推理需要对整个程序进行分析,这可能是非常不切实际的——并且阻止了 Van Roy 和 Haridi 在他们的杰作“计算机编程的概念、技术和模型”中所说的“完全开放的编程”。引用我 2004 年的一篇文章:“”“我喜欢 Van Roy 和 Haridi 的解释,他们的书第 104-106 页,尽管我可能同意也可能不同意他们的结论(基本上是内在差异很小-- 他们分别指出 Oz 和 Alice 是不带和带静态类型的互操作语言),他们提出的所有观点都很好。最重要的是,我相信,动态类型允许真正的模块化(静态类型更难,
“推荐使用动态类型”,他们总结道,“当程序必须尽可能灵活时”。我建议阅读敏捷宣言,以了解为什么在大多数现实世界的应用程序编程中最大的灵活性是至关重要的——以及为什么在所说的现实世界中,而不是在更多的学术圈中,Van Roy 博士和 Hadidi 博士进入动态类型通常是可取的,而不是像它们产生差异那样的小问题。尽管如此,他们至少表现出对这些问题的更多认识,花了 3 页关于它的优秀讨论,利弊,比我见过的几乎任何其他书都要多——大多数书都以一种或另一种方式清楚地描绘和预先确定了优先级,所以讨论很少像那样平衡;)。
我首先推荐阅读Steve Yegge 在 Is Weak Typing Strong Enough 上的帖子,然后是他在 Dynamic Languages Strike Back 上的帖子。这至少应该让你开始!
让我们做一些优点/缺点比较:
动态语言:
- 可以以最小的代码影响更改类型决策。
- 代码可以单独编写/编译。我不需要实现,甚至不需要类型的正式描述来编写代码。
- 必须依靠单元测试来发现任何类型错误。
- 语言更简洁。少打字。
- 可以在运行时修改类型。
- 编辑和继续更容易实现。
静态语言:
- 编译器告诉所有类型错误。
- 编辑器可以更丰富地提供诸如 Intellisense 之类的提示。
- 更严格的语法可能令人沮丧。
- (通常)需要更多的打字。
- 如果编译器提前知道类型,它可以进行更好的优化。
更复杂一点的是,考虑到诸如 C# 之类的语言使用 var 结构或像 Haskell 等静态类型但由于类型推断而感觉动态的语言正在部分动态(无论如何感觉上)。
动态编程语言基本上在运行时做其他语言在编译时做的事情。这包括通过添加新代码、扩展对象和定义或修改类型系统来扩展程序,所有这些都在程序执行期间而不是编译期间进行。
http://en.wikipedia.org/wiki/Dynamic_programming_language
下面是一些常见的例子
http://en.wikipedia.org/wiki/Category:Dynamic_programming_languages
并回答你原来的问题:
它们很慢,您需要使用基本的文本编辑器来编写它们 - 没有 Intellisense 或代码提示,它们往往是编写和维护的一大难题。但是最著名的一个(javascript)几乎可以在世界上的每个浏览器上运行——我猜这是一件好事。让我们称之为“广泛的兼容性”。我认为您可能可以获得适用于大多数操作系统的动态语言解释器,但您肯定无法获得适用于大多数操作系统的非动态语言的编译器。