动态输入的假定生产力增益是多少？

Question

我经常听到这样的说法:动态类型化语言比静态类型化语言更有生产力。这一说法的理由是什么？它不只是使用现代概念，如约定而不是配置、使用函数式编程、高级编程模型和使用一致的抽象--所有这些都可以在静态类型化语言中使用？诚然，由于(例如，在Java中)不需要冗余类型声明，所以没有那么复杂，但您也可以在使用类型推断的静态类型化语言中省略大多数类型声明，而不会失去静态类型的其他优点。所有这些都适用于像Scala这样的现代静态类型化语言。

那么:对于真正是类型模型本身优势的动态类型，对于生产率有什么可说的呢？

澄清:我更感兴趣的是大中型项目，而不是速成黑客。:-)

Answer 1

我真的认为这是一个相当近的距离。动态类型和静态类型都有各自的优点。

动态输入效率更高的原因：

• 它更简洁--如果所有东西都是动态类型的，那么可以删除许多无关的样板代码--类型声明、类型转换逻辑等等。在所有其他条件相同的情况下，较短的代码编写起来稍微快一些，但更重要的是，它可以更快地读取和维护(因为您不需要费力地浏览许多页代码来掌握正在发生的事情)。
• 更容易“黑客”的技术，如鸭子打字和猴子补丁可以很快获得结果(虽然可能会混淆你以后.)
• 更交互式的动态类型可以说更适合交互式的、类似REPL的快速原型化编程、运行程序实例的实时调试，甚至是实时编码。
• 测试用例可以捕获运行时错误--假设您使用的是TDD，或者至少有一个很好的测试套件，这应该会解决代码中的任何类型问题。
• 更好的多态-动态语言更有可能鼓励多态函数和抽象的创建，这可以提高生产力和代码重用。例如，Clojure在它的许多抽象中充分利用了动态多态性。
• 原型--在我看来，原型基础数据/对象模型比静态类型继承继承更加强大和灵活。动态语言更可能允许或鼓励基于原型的方法，Javascript就是一个很好的例子。

静态输入效率更高的原因：

• 更好的设计--被迫预先考虑软件中的价值类型，可以推动您走向更干净、更符合逻辑的解决方案。(我说可以-仍然有可能设计出非常糟糕的代码.)
• 更好的编译时间检查-静态类型可以在编译时捕获更多错误。这是一个巨大的优势，可以说是静态类型化语言的最佳之处。
• 自动完成-静态类型还可以向IDE提供更多信息，以便自动完成代码或文档查找更加有效。
• 阻止黑客攻击--您必须在代码中保持类型纪律，这可能是长期可维护性的一个优势。
• 类型推断--在某些语言(例如Scala)中，这可以给您带来许多简洁的好处，动态语言的好处仍然可以维持类型规则。

平均而言，我的结论(经过多年的经验，双方的栅栏)是，动态类型可以更有效率在短期内，但它最终变得很难维护，除非您有非常好的测试套件和测试纪律。

另一方面，总的来说，我更喜欢静态类型的方法，因为我认为从长远来看，正确性的好处和工具的支持会给您带来更好的生产力。

Answer 2

使用动态语言，可以比使用类型化语言时更快地编写糟糕的代码。

一旦您快速创建了大量动态的东西，您就可以安全地转移到另一个项目，而不必关心长期的维护。

这是生产力的提高:)

我在开玩笑，但在参与了一个使用“动态语言”的项目之后，我被大量不必要的测试、文档和约定吓坏了，如果你想要一个工作的产品的话。

还有喜悦的大量运行时错误，这些错误可能会在编译时捕捉到。

哦，我还忘了抱怨元编程让你在代码中引入的那些黑客和巫毒！

因此，生产率的提高可能是中、大型项目在其生命周期中的一个神话。

Answer 3

对于这个问题也有一种理论观点:静态类型系统本质上是一个专门的定理证明器，它只在能够证明程序的类型正确性时才接受它。所有静态类型系统都拒绝一些有效的程序，因为没有一个可判定的静态类型系统强大到足以证明所有可能的类型正确的程序。

有人可能会说，那些静态打字机无法证明的程序是黑客和/或糟糕的风格，但如果你已经有了一个有效的程序，而打字机不接受它，它肯定会损害你的生产力在短期内。

在某些情况下，您可能会注意到类型检查器会遇到泛型容器以及参数和返回类型的协/反方差。