动态打字的生产率预期提高了多少？[关闭]

我经常听到这样的说法：动态类型的语言比静态类型的语言更具生产力。提出索赔的原因是什么？难道不只是使用现代概念进行工具处理，例如约定优于配置，使用功能编程，高级编程模型以及使用一致的抽象吗？公认的是，由于不需要（例如在Java中）通常多余的类型声明，因此混乱程度较小，但是您也可以在使用类型推断的静态类型语言中省略大多数类型声明，而不会失去静态类型的其他优点。所有这些都可用于现代静态类型的语言，例如Scala。

那么：对于动态类型的生产力来说，这到底是类型模型本身的优势呢？

澄清：我对大型/中型项目比对快速黑客更感兴趣。:-)

我实际上认为这是一个非常接近的电话。动态类型和静态类型都有其优点。

动态类型产生更高效率的原因：

• 更简洁 -如果一切都是动态键入的，则可以删除很多无关的样板代码-类型声明，类型转换逻辑等。在所有其他条件相同的情况下，较短的代码编写速度稍快一些，但更重要的是，它可以更快地读取和编写代码。维护（因为您无需遍历许多代码页即可掌握正在发生的事情）
• 诸如鸭子打字和猴子修补之类的“黑客”技术更容易获得结果（尽管稍后可能会使您感到困惑...）
• 更具交互性 -动态类型可以说更适合于类似于REPL的交互式编程，以快速进行原型制作，对正在运行的程序实例进行实时调试，甚至实时编码。
• 测试用例可能会捕获运行时错误 -假设您正在使用TDD或至少具有良好的测试套件，这应该可以解决代码中的所有键入问题。
• 更好的多态性 -动态语言可能更可能鼓励创建多态函数和抽象，这可以提高生产力和代码重用。例如Clojure在其许多抽象中都充分利用了动态多态性。
• 原型 - 在我看来，基于原型的数据/对象模型比静态类型的继承层次结构更强大，更灵活。动态语言更可能允许或鼓励基于原型的方法，Javascript是一个很好的例子。

静态类型产生更高效率的原因：

• 更好的设计 -被迫预先考虑软件中值的类型可以促使您寻求更清洁，更合乎逻辑的解决方案。（我说可以 -仍然可以设计出非常糟糕的代码...）
• 更好的编译时检查 -静态类型可以使更多错误在编译时被捕获。这是一个巨大的优势，对于整个静态类型的语言来说，这无疑是最好的选择。
• 自动完成 -静态类型输入还可以向IDE提供更多信息，从而使代码或文档查找的自动完成更为有效。
• 不鼓励黑客攻击 -您必须在代码中保持类型约束，这可能是长期可维护性的优势。
• 类型推断 -在某些语言（例如Scala）中，这可以为您提供动态语言的许多简洁好处，而这些语言仍将保持类型规范。

平均而言，我的结论（经过多年的围栏工作经验）得出的结论是，动态键入在短期内可能会更有效率，但是除非您拥有非常好的测试套件和测试纪律，否则最终很难维护。

另一方面，实际上，我总体上更喜欢使用静态类型的方法，因为从长远来看，正确性的好处和工具支持可为您提供更高的生产率。

使用动态语言，您可以比使用键入的语言更快地编写cr脚的代码。

快速创建大量动态内容后，您就可以安全地移至另一个项目，而无需担心长期维护。

这是生产力的提高:)

我在开玩笑，但是在参与了使用“动态语言”的项目后，如果想要拥有一个有效的产品，必须处理的大量不必要的测试，文档和约定让我感到恐惧。
并有很多在编译时可能会捕获到的运行时错误的喜悦。
哦，我也忘记了元编程让您在代码中引入的所有这些黑道和伏都教徒！

因此，对于中型/大型项目，在整个生命周期中提高生产率可能是一个神话。

对于这个问题也有一个理论上的看法：静态类型系统本质上是一个专门的定理证明者，仅当它可以证明程序的类型正确性时才接受该程序。所有静态类型系统都拒绝某些有效程序，因为没有可判定的静态类型系统强大到足以证明所有可能的类型正确程序的能力。

有人可能会说那些不能由静态类型检查器证明的程序是骇客和/或不良样式，但是如果您已经有了一个有效的程序而类型检查器不接受它，那肯定会在短期内损害您的生产率。

在某些情况下，您可能会注意到类型检查器出现问题的情况是通用容器以及参数和返回类型的协方差/协方差。

我发现大多数动态语言的一个优点是，它们使编写更通用的代码更加容易。当您不必为类型系统而战时，在更高的抽象级别上编写要容易得多。

您不必花太多时间去思考-编写对Java中的任何对象都不重要的事情的代码很困难，并且可能需要进行反射，而该反射基本上是动态类型的。使用JavaScript之类的东西，写一个对所有对象都做一些有趣的事情的功能是第二天性。一个完美的例子是我最近编写的一个函数，该函数接受一个对象并将其所有方法替换为既执行相同操作又触发事件的方法。我不知道如何用Java处理这种事情。但是，我不确定其中有多少是由于类型系统引起的，有多少是由于其他语言差异引起的。

但是，我最近开始使用Haskell。Haskell让我可以像使用过的任何动态类型化语言一样轻松地编写抽象的通用代码。我上面的Java / JavaScript示例在Haskell中没有任何意义，因为它没有对象，方法，事件甚至没有太多的变异，但是其他种类的通用代码确实很容易编写。

实际上，Haskell可以编写动态类型语言无法编写的一些通用代码；一个完美的例子是read函数，它与toString。您可以获取所需的an Int或a Double或任何类型（只要它在某个类型类中）。你甚至可以有多态性常数，因此maxBound可以最大Int，Double，Char...等等，所有这些都取决于什么类型的，它应该是。

我现在的理论是，与诸如Java之类的语言相比，使用动态语言所带来的生产力提高总是比它们的能力更低，更冗长且更不灵活。

但是，即使Haskell的类型系统也存在一些烦人的问题，而动态类型的语言则不会出现这种问题。我最烦恼的是数字的处理方式。例如，您必须弄乱类型系统才能将length（列表中的）类型用作双精度类型，如果没有类型系统，就不会有问题。我遇到的另一件烦人的事情是使用Word8期望的（无符号int类型）和函数Int。

因此，最终，没有类型系统将使编写通用代码变得更加容易，而无需考虑太多，并且避免了讨厌的类型系统陷阱。您不必使用动态语言来对抗类型系统，但是您也不能依赖它。

问：我经常听到有人说动态类型的语言比静态类型的语言生产力更高。提出索赔的原因是什么？”

这有历史原因。如果回溯几十年，动态语言无疑比静态语言生产力要高得多（同时速度也要慢得多）。如果您同时知道Perl和Perl，那么Perl显然比C生产率高得多。但是随着时间的流逝，语言之间已经相互借鉴了很多，更新的语言正在缩小两者之间的差距（在生产率和性能方面）。

这里有几点要考虑：

垃圾收集：垃圾收集极大地提高了生产力。我相信Java是GC的第一种主流静态语言。在此之前，静态基本上意味着手动内存管理。（注意：在这里和以下内容中，我仅考虑主流语言。存在​​许多实验性和特殊语言，它们将为我提出的任何观点提供反例。）

内存安全性：这是生产力的提高，您不必担心用脚射击。在使用诸如Java之类的“托管”静态语言之前，静态通常意味着直接内存访问。调试也是生产力的一部分，不安全的内存访问会导致真正难以理解的错误。

繁琐的类型系统。在以静态语言引入参数化类型（如模板或泛型）之前，静态类型系统的局限性通常是一个负担。例如，在Java中，每次从集合中选择一个项目时，您都必须显式地向下转换。因此，您获得了强制转换的语法开销，并且没有类型安全性。考虑到编程中集合的普遍性，这是一个主要缺点。
必须声明所有内容的类型是很多冗余类型，但是通过现代类型推断，可以显着减少这种类型。

大标准库。由于大型标准库，Python被著名地宣传为“包含电池”。与具有极简标准库的C相比。但是，随着Java和.net等平台的出现，庞大的标准库正在成为标准，而Scala和F＃等较新的语言正在“免费”继承此库。

一流的数据结构。诸如Perl和Python之类的动态语言具有内置的一流数据结构（如列表和映射），以及用于常规操作的便捷语法捷径。与此相比，C除了固定大小的数组外没有内置集合。

闭包和lambda语法 -动态语言通常从一开始就具有这种功能，但是静态语言采用了这种语言，最近才采用Java。

REPL具有以交互方式快速测试代码段的能力是一个很大的福音。但是，尽管使用了IDE工具，例如Visual Studio中的“立即”窗口，但是静态语言可以在某种程度上模拟它。

先进的工具 -除了上述静态语言越来越接近动态语言的便利性之外，现代编辑人员还以动态语言难以匹配的方式利用静态分析。例如，编辑人员可以提供安全的自动重构功能，这在动态语言中是严格不可能实现的。

底线：历史上确实如此，但是今天的答案还不那么明确。

问：那么，对于动态类型的生产力而言，这到底是类型模型本身的优势呢？

很难将动态类型化模型与动态语言区分开来，但是作为示例，C＃随着时间的流逝采用了更多的动态特性，即使它的核心是静态语言。这确实是动态类型模型的好处的证明。例子：

反思 反思从根本上说是一种动态打字功能。您可以在运行时评估程序而非编译时检查对象类型。引入它时，人们对此并不满意，但是在C＃中，反射的使用变得越来越普遍，例如ASP.Net MVC大量使用反射。

属性 属性是动态类型化的一个示例。您可以在编译时向类添加任意属性，然后在运行时检查（通过反射）并基于该对象操作对象。诸如MEP之类的东西基本上是基于动态类型模型的扩展框架。

Linq to SQL，EF mv。 各种Linq转换器将查询作为运行时对象进行检查，并即时生成sql。它没有比在运行时检查代码更动态。CodeDom是硬币的另一面，可以在运行时生成代码

Roslyn Roslyn基本实现eval，曾经被认为是一种真正的动态语言的定义特征。

动态 的dynamic型是在C＃中最明确的动态特征，并使得外部物体和简单和更富有成效的语言交互广告。但是为了方便起见，它也用于Asp.net MVC中。

所有上述特征的好处表明，即使在具有参数化类型，结构类型和类型推断的静态语言中，动态模型也具有明显的优势。

所有现代语言功能的整体是如此之大，以至于静态和动态类型都不占很大的分量。

规则是，语言功能越好，代码越短。那很简单。Java展示了静态类型输入如何严重错误，这给对手带来了很多麻烦。设计不良的语言功能通常要付出代价，而Java中的静态类型首先是必需的功能（否则，大多数人甚至可能不会使用它），其次是执行不力。
相比之下，这就是为什么大多数动态语言都闪耀的原因，尽管我会认为PHP并不能真正使您的生活总体上更好（至少直到最近），因为其他许多与类型系统无关的怪癖。

另一方面，您有很多具有表达类型系统的语言不会妨碍您，甚至不是强制性的。每当您需要对类型系统进行转义时，其中的一些甚至还允许嵌入未类型化的代码。

就我个人而言，我使用haXe，这是一种具有类型推断功能的语言，包括名义和结构子类型，可选的非类型化代码，一流的函数类型，代数数据类型以及（不是很成熟但功能非常强大的）词法宏，同时避免了奥秘的语法。在使用haXe大约3年之后，我得出一个简单的结论：

当您的语言不会让您陷入关于范式的宗教选择中，而只是成为一个好工具时，编程就变得容易得多。有许多静态和动态语言以及混合语言可以成功地做到这一点。其中一些很容易学习，最难掌握。
它们的强大功能来自于其各个特征的组合方式，可以轻松地为复杂问题创建简单的解决方案。这排除了一定的正交性，只有通过对到目前为止探索的所有语言功能进行包含或省略的微妙平衡才能实现。如果您尝试向Ruby添加静态类型，则会削弱它，如果您尝试将其从Haskell中删除，则会对其进行粉碎。与此相反：如果您将它从C那里拿走，人们几乎不会注意到；如果您从Java那里把它拿走，有些人可能会感谢您。

从我的亲身经历，我可以告诉你这一点：我喜欢Ruby。它拓宽了我的视野和设计系统的方式。恕我直言，它应该首先用来教人们编程。它不显眼，功能强大，简洁，有趣。我了解为什么来自正统语言的人会喜欢它。
但是从长远来看，静态类型允许将工作推迟到静态分析器中进行，并且通过类型推断，这基本上是免费的。结果是易于维护且通常运行速度更快的代码。

但同样，仅静态类型无法完成任何工作。这是结合的问题。我认为在F＃，Scala，Nemerle，OCaml或haXe之间，您可以找到自己的最佳选择。但这最终取决于您，因为该语言应允许您毫不费力地嵌入自己的思想，而不是强迫您将思想转弯。毕竟，如果编程很有趣，那么没有什么比生产率更高。

就个人而言，动态键入会有所帮助的唯一原因是，如果您是一位非常慢的打字员，或者您构建了庞大的功能/方法/难以导航的内容。您还必须解决整个单元测试问题。动态类型需要（除非您喜欢编写残破的代码）剧烈的单元测试（以确保您的动态类型不会意外爆炸（即，变量主要是鸭子，但有时偶然是dcuk））。静态方法将更加努力地防止这种情况的发生（是的，您可以为进行严格的单元测试提供参数）

我认为首先您需要定义“生产力”。“生产力”是什么意思和包括什么？

如果说“提高生产力”是指编写更少的代码行来实现相同的功能，那么可以，动态类型编程语言比静态类型语言更“高效”。

但是，如果您还考虑花费在调试和错误修复上的时间，那么动态类型化的语言可能没有那么高效，因为动态类型化的语言倾向于将错误检查推到运行时，而静态类型化的语言则相反。可以在编译时执行一些错误检查。众所周知，通常，发现错误的时间越晚，修复该错误的成本就越高。因此，与静态键入代码相比，动态键入代码可能会导致生产率总体上相等或更低。

动态键入的最大优点是生产率。

Python，Ruby等除了动态类型（默认参数，内置类型的字典等）以外，还具有许多其他提高生产力的作用，对程序员生产力的累积影响是令人印象深刻的。

在速度（或缺乏速度）和资源消耗方面的惩罚并没有您期望的那么糟糕，并且在大多数情况下，开发速度和灵活性可以弥补这些损失。

有一个（很老！）纸放在这里的主题。这是对程序员生产力进行的为数不多的适当研究之一，许多结论仍然有效。

今天可能要进行的研究（可能）不同：

1. Java JVM的改进令人难以置信。
2. 现代的IDE可以提高C ++和Java编码器的生产率，但是对脚本语言的影响很小。
3. C＃将被包括在内，可能与Java处于同一个领域，但略胜一筹。

因此，传达的信息是，除非性能是一个非常严重的问题，否则动态语言将提高您的生产率。