Programming languages 动态类型语言与静态类型语言

与静态类型语言相比，动态类型语言有哪些优点和局限性

---

另请参见：（一个更具争议性的线程…

解释器推断类型和类型转换的能力使开发时间更快，但它也会引发运行时失败，这在静态类型语言中是无法得到的，在编译时您会捕获它们。但是，哪一个更好（或者即使这一直是真的）最近在社区中被热烈讨论（并且已经很久了）

微软的Erik Meijer和Peter Drayton对这个问题有一个很好的理解：

静态类型的拥护者认为 静态类型的优点 包括早期检测到 编程错误（例如防止 将整数添加到布尔值）， 以 类型签名（例如，包含 参数的数量和类型 解析名称），更多机会 用于编译器优化（例如。 用直接呼叫取代虚拟呼叫 当 接收器静态已知）， 提高运行效率（例如，不 所有值都需要带有动态 类型），以及更好的设计时间 开发人员经验（例如了解 接收器的类型，IDE可以 显示所有项目的下拉菜单 适用成员）。静态类型 狂热分子试图让我们相信这一点 “类型良好的程序不会出错”。 虽然这听起来确实不错 令人印象深刻的是，这是一个相当空洞的概念 陈述静态类型检查是一种 的编译时抽象 程序的运行时行为，以及 因此，它必然只是部分 健全和不完整。这意味着 程序仍然可能出错，因为 属性未跟踪的属性 输入checker，并且有 当他们不能去的时候 不能检查错误的类型。这个 减少静态输入的冲动 部分和更完整的原因类型 系统变得过于复杂 和异国情调的概念见证 例如“幻影类型”[11]和 “摆动类型”[10]。这就像 试着用球跑马拉松 把链子绑在你的腿上 得意洋洋地叫喊着，你差一点就来了 即使你保释了也能成功 第一英里后

动态类型的拥护者 语言认为静态类型是 太僵硬了，那柔软的 动态语言使它们 非常适合原型系统 需求不断变化或未知， 或者与其他系统交互 不可预测的变化（数据和数据） 应用程序集成）。当然 动态类型语言是 处理真正的问题必不可少 动态程序行为，例如

---

方法拦截，动态加载， 移动代码、运行时反射等。 在所有的报纸上 John Ousterhout认为，编写脚本[16] 静态类型系统 编程语言使代码更少 可重复使用，更详细，而不是更安全， 表现力不如动态 类型化脚本语言。这 许多人逐字逐句地重复这一论点 动态类型的支持者 脚本语言。我们认为 这是一种谬论，属于逻辑范畴 与辩称 声明式编程的本质是 消除任务。还是约翰 休斯说[8]，这是合乎逻辑的 不可能使一种语言更复杂 通过省略功能而强大。 为拖延一切的事实辩护 对运行时进行类型检查是一个好方法 事情，就是玩鸵鸟战术 错误应该被发现的事实 在开发过程的早期 可能

来自Artima的文章：

强类型防止在不匹配的类型之间混合操作。为了混合类型，必须使用显式转换

弱类型意味着您可以在没有显式转换的情况下混合类型

---

在Pascal Costanza的论文（PDF）中，他声称在某些情况下，静态类型比动态类型更容易出错。一些静态类型的语言强制您手动模拟动态类型，以便执行“正确的操作”。关于静态语言和动态语言有很多不同的方面。对我来说，主要的区别是在动态语言中变量没有固定的类型；相反，类型与值绑定。因此，直到运行时，执行的确切代码才确定

---

在早期或幼稚的实现中，这是一个巨大的性能拖累，但是现代JIT非常接近优化静态编译器所能达到的最佳性能。（在某些边缘情况下，甚至比这更好）。

静态类型系统寻求静态消除某些错误，在不运行程序的情况下检查程序，并试图证明某些方面的可靠性。某些类型的系统比其他类型的系统能够捕获更多的错误。例如，C#可以在正确使用时消除空指针异常，而Java没有这种能力。Twelf有一个类型系统，它实际上“解决”了这个问题

然而，没有一种类型系统是完美的。为了消除特定类别的错误，他们还必须拒绝某些完全有效的违反规则的程序。这就是为什么Twelf没有真正解决停止问题，它只是通过抛出大量完全有效的证明来避免它，这些证明恰好以奇怪的方式终止。同样，Java的类型系统拒绝Clojure的

PersistentVector

实现，因为它使用了异构数组。它在运行时工作，但类型系统无法验证它

出于这个原因，大多数类型系统都提供了“转义”，即覆盖静态检查器的方法。对于大多数语言来说，这些模式都采取强制转换的形式，尽管有些（如C#和Haskell）具有标记为“不安全”的完整模式

主观上，我喜欢静态打字。实现pro