动态与静态类型语言研究[关闭]

69

是否有关于静态和动态类型语言有效性的研究？

尤其是：

  • 程序员生产力的度量
  • 缺陷率

还包括是否采用单元测试的影响。

我已经就双方的优点进行了很多讨论，但我想知道是否有人对此进行了研究。

productivity  comparison  type-systems  dynamic-typing  static-typing 
— 温斯顿·埃韦特
source
8
@bigown，在我看来，生产力和缺陷问题与计算机科学理论无关
— Winston Ewert 2010年
2
@温斯顿：研究这类问题是计算机科学家而不是程序员的工作。
— Maniero
9
@bigown，是的，这是计算机科学问题，但不是计算机科学理论问题。CS理论本质上涉及我们可以在数学上证明的有关程序和计算的内容。程序员生产力问题不是CS理论问题。在这里和在stackoverflow上都有关于动态类型的讨论。尚无理论。
— Winston Ewert
8
这个问题完全符合主题。这个问题讨论了我们用来编程的工具的最重要的属性之一。
— Frank Shearar
4
@温斯顿：键入系统的确属于CS理论，但实际研究却不属于CS理论。
— David Thornley 2010年

Answers:

42

一些建议阅读：

不完全是静态类型，而是相关的：

关于该主题或程序的静态分析的一些有趣的文章或文章：

对于那些想知道这到底是什么的人：

但是，我怀疑其中任何一个都不能直接给您答案，因为它们不能完全满足您的需求。他们将是有趣的读物。

亲身，我坚信静态类型优于动态类型有助于错误检测。我花太多的时间在JavaScript甚至Ruby代码中寻找拼写错误和诸如此类的小错误。关于动态键入可以提高生产率的观点，我认为这主要归功于工具。如果静态类型语言具有正确的工具来允许后台重新编译并提供REPL接口，那么您将获得两全其美的好处。例如，Scala提供了此功能，它使在交互式控制台中学习和原型化变得非常容易，但是却为您提供了静态类型化（以及比许多其他语言（除了ML语言）更强大的类型系统）的好处。同样，我也不认为使用Java或C ++会导致生产力下降（因为使用了静态类型），只要我使用可以帮助我的IDE。当我仅使用简单的配置（编辑器+编译器/解释器）恢复编码时，就会感到更加麻烦，动态语言似乎更易于使用。但是您仍然在寻找错误。我猜人们会说工具问题是一个可逆的论点，好像工具更适合动态语言，那么大多数错误和错别字都会在编码时指出，但这在我看来反映了系统的缺陷。尽管如此，我通常还是使用JRuby进行原型设计，并且稍后会用Java编写大多数代码。好像工具对于动态语言来说更好，那么大多数错误和错别字都会在编码时指出，但这在我看来反映了系统的缺陷。尽管如此，我通常还是使用JRuby进行原型设计，并且稍后会用Java编写大多数代码。好像工具对于动态语言来说更好，那么大多数错误和错别字都会在编码时指出，但这在我看来反映了系统的缺陷。尽管如此，我通常还是使用JRuby进行原型设计，并且稍后会用Java编写大多数代码。

警告：这些链接中的某些链接是不可靠的，有些链接通过各种计算协会的门户使用会员的收费访问方式。抱歉，我尝试为每个链接查找多个链接，但是它不如我希望的那样好。

— 海姆
source
该错误查找-主要是由于变量名，方法名或两者之间的错误拼写？（正是出于这个原因，我讨厌隐式变量声明：在Smalltalk中，您将所有变量都声明在顶部，这样您就可以立即知道何时输错了变量名。（如果方法名从不，有时也会捕获方法名错字）之前的图像中已经使用））。
— 弗兰克Shearar
关于重新工具，我不得不说这取决于您的语言-Smalltalk具有出色的工具，其中包括Eclipse尚未赶上的Refactoring Browser。
— Frank Shearar
@Frank Shearar，自从我开始使用Ruby（来自Java）以来，我已经意识到@haylem的说法可能不适用于Smalltalk。我的口头禅也不是在动​​态类型的lang中不可能实现自动重构。我完全同意haylem的“个人”部分。...当然忽略了SmallTalk ：）这在一定程度上是公平的，因为SmallTalk虽然没有死，但绝对没有像Python或Ruby那样受欢迎（现在是2010年10月） ）。
— Dan Rosenstark 2010年
3
@haylem，我个人感谢您使我感到自己不是世界上唯一使用动态语言的人，但是如果可以选择的话，我会多次选择静态类型的语言（相同情况下，Java与JRuby或Groovy）。
— Dan Rosenstark 2010年
4
这很有趣，因为我自己对动态类型的偏爱是出于完全不同的原因。我的意思是快速编译和交互式解释器很有用，但这不是我喜欢动态类型的原因。我喜欢动态类型化，因为我发现在许多情况下静态类型化语言只会使难以描述特定概念变得困难。
— Winston Ewert 2010年
19

就在昨天，我发现了这项研究：单元测试还不够。您还需要静态输入。

基本上，作者使用的工具能够将项目从非静态类型的语言自动转换为静态类型的语言（Python到Haskell）

然后，他选择了许多开源Python项目，这些项目还包括相当数量的测试单元，并自动将它们转换为haskell。

Haskell的翻译揭示了一系列与变量类型有关的错误：测试单元未发现这些错误。

— 布兰多
source
4
动态打字的真相令人不安。
— 2014年
6
“对Haskell的翻译揭示了一系列与变量类型有关的错误：测试单元未发现这些错误。”：使用动态类型的语言，您必须以静态方式手动测试代码的属性类型的语言由编译器自动检查。这既耗时又容易出错。+1
— 乔治
4
我在Reddit上对此链接的帖子进行了回复。我认为本文得出的结论不合理。
— Veedrac
两种打字系统都有优点/缺点及其用法。这就像在讨论如何将机关枪进行肉搏战。那是一场宗教战争，远远没有结束。也就是说，我同意Veedrac。非静态语言需要更多的测试用例来捕获由类型引起的错误。这就是他们的本质和缺点。但是，程序员需要编写测试来捕获由输入的意外状态引起的代码错误，而不必对输入类型进行详尽的测试。
— 安德烈·菲盖雷多
10
  • 链接到Stephan Hanenberg文章（由Lorin Hochstein在先前的帖子中引用）对ACM论文“ 关于静态和动态类型系统的实验 ”（2010年）的讨论。
  • 结论：使用动态语言，具有类似质量的生产率更高。
  • 潜在的偏见/有效性问题：实验对象均为学生。同样，编程任务的种类也很有限（要求对象实施扫描仪和解析器）。
  • ACM的论文“ 编程语言会影响生产率吗？ ”（2007年），由Delorey，Knudson和Chun撰写。
  • 结论：JavaScript，Tcl，Perl比C＃C ++和Java更具生产力。Python和PHP位于中间。
  • 潜在的偏差/有效性问题：无法衡量质量（例如发布后发现的错误）。无法衡量可靠性（用静态类型语言编写的软件是否更可靠？）。样本偏差-所有项目都是开放的，均来自开源CVS存储库。同样，弱类型语言和强类型语言（即指针）之间也没有区别。
  • Michael F. Siok撰写的论文“ 软件生产率和质量的实证研究 ”（2008年）
  • 结论：编程语言的选择不会显着影响生产率或质量。但是，它确实会影响人工成本和“整个软件项目组合的质量”。
  • 潜在的偏见/有效性问题：仅限于航空电子领域。编程语言可能全部都是静态类型的。我没有读过论文，所以我无法评估它的严格性。
    我的意见。尽管鲜有证据表明动态类型的语言更具生产力，但这不是结论性的。（1）有许多不受控制的因素，（2）研究太少，（3）关于什么是合适的测试方法的讨论很少或没有。
— Ahoffer
source
6

这是一个起点：

本文挑战了普遍接受的观点，即在其他条件相同的情况下，程序员每次编写相同数量的代码行，而与语言无关。换句话说，本文应作为经验证据，证明机械生产率（编写的代码行）不是衡量功能生产率的好方法，并且至少必须通过语言对其进行规范化。

— Piet Delport
source
5
对于非IEEE人士，基本摘要是什么？
— Frank Shearar
1
@Frank Shearar，他们得出的结论是编程语言确实会影响生产力。他们每年都在评估每种程序员每种语言的代码行，但我不确定这是否是衡量生产率的好方法。
— 温斯顿·埃韦特2010年
3
@温斯顿：这绝对是一个有缺陷的指标。您会发现COBOL是一门非常有生产力的语言：做很多有用的事情需要花费很多行，但是它们很容易编写。
— David Thornley 2010年
温斯顿，戴维：我很确定作者没有暗示代码行生产力是对功能生产力的度量。相反，本文正在挑战普遍接受的观点，即在所有其他条件相同的情况下，程序员每次编写相同数量的代码行，而与语言无关。换句话说，该论文应作为经验证据，证明机械生产率（编写的代码行）不是衡量功能生产率的好方法，并且至少必须通过语言对其进行规范化。
— Pi Delport
我同意这一点。但这并不能回答我最初的问题。
— Winston Ewert 2010年
1

我发现了静态语言与动态语言：文献综述，其中列出了有关该主题的一些研究，并对每项研究给出了很好的总结。

这是执行摘要：

在对照实验中，只有三个实验显示出足够大的作用，对任何实际意义都没有。Prechelt研究比较了C，C ++，Java，Perl，Python，Rexx和Tcl；Endrikat的研究比较了Java和Dart；和Cooley的VHDL和Verilog实验。不幸的是，它们都有问题，很难得出一个真正有力的结论。

在Prechelt研究中，动态语言和打字语言的总体有所不同，任务的条件也有所不同。有一项后续研究通过邀请Lispers提出自己的解决方案来说明该问题，其中包括将Darius Bacon等人与随机的本科生进行比较。从字面上看，后续工作涉及将Peter Norvig的代码与随机大学生的代码进行比较。

在Endrikat的研究中，他们特别选择了一项任务，他们认为静态打字会有所作为，并且他们从每个人都使用静态打字语言上课的人群中吸取了他们的研究对象。他们没有评论学生是否有使用动态类型语言的经验，但是可以肯定的是，假设大多数或所有人对动态类型语言的经验较少。

库利的实验是少数吸引非学生人群的实验之一，这很棒。但是，与所有其他实验一样，该任务是一件琐碎的玩具任务。尽管似乎很遗憾，没有VHDL（静态语言）参与者能够按时完成任务，但要在学校项目以外的任何地方花1.5个小时完成硬件设计是非常不寻常的。您可能会争辩说，一个大型任务可以分解为许多较小的任务，但是似乎可以反驳的是，使用VHDL的固定成本可以分摊到许多任务中。

至于其余的实验，我从中得到的主要结论是，在研究中描述的特定情况下，任何影响（如果存在的话）都是很小的。

继续进行案例研究，发现两个bug的案例研究引人入胜，但它们并没有真正为类型辩护。一个例子表明，将Python程序转录到Haskell会发现非零数量的严重性未知的错误，而这些错误可能是通过面向行覆盖率的单元测试发现的。这对Erlang论文表明，您可以使用静态分析找到通过任何类型的测试都很难发现的错误，其中一些是严重的。

作为用户，当我的编译器在运行单独的静态分析工具之前给我一个错误时，我觉得很方便，但这是次要的，甚至可能比上面列出的受控研究的效果还小。

我发现0install案例研究（将各种语言与Python进行了比较，最终选择了Ocaml）是我遇到的更有趣的事情之一，但这是每个人都会以不同的方式主观理解的东西，您可以通过观察。

这符合我的印象（在我的世界的小角落，ACL2，Isabelle / HOL和PVS是最常用的证明，并且人们在解决行业问题时会更喜欢自动化，这是有道理的）也很主观。

然后有一些研究可以从现有项目中挖掘数据。不幸的是，我找不到任何为确定因果关系做任何事情的人（例如，找到合适的工具变量），因此他们只是测量相关性。一些相关性是出乎意料的，但是没有足够的信息来确定原因。

仅有的数据挖掘研究无需进一步研究即可显示可能有趣的数据，这是Smallshire对Python错误的回顾，但有关方法的信息不足以弄清楚他的研究的真正意义，并且不清楚他为什么暗示要研究其他语言的数据而不显示数据3。

研究中的一些显着遗漏是使用经验丰富的程序员进行的综合研究，更不用说拥有大量“好”或“坏”程序员的研究，着眼于任何接近重大项目的项目（在我工作过的地方，三个月的项目会被认为很小，但比对照研究中使用的任何项目大多个数量级），使用“现代”静态类型语言，使用渐进/可选类型，使用现代主流IDE（例如VS和Eclipse），使用现代基本IDE （例如LightTable），使用老式的编辑器（例如Emacs和vim），在不重要的代码库上进行维护，使用类似于实际环境的任何内容进行维护，在您已经熟悉的代码库上进行维护等。

如果您查看有关这些研究的互联网评论，其中大多数都是为了证明一种观点或另一种观点是正确的。关于动态与静态的Prechelt研究以及对Lisp的后续研究一直是动态语言倡导者的长期偏爱，并且github挖掘研究最近在函数式程序员中变得很流行。

— 敬拜先生
source
0

老实说，我认为静态与动态类型不是真正的问题。

我认为应该首先考虑两个参数：

  • 语言的专业知识水平：您越有经验，就对“陷阱”越了解，您越有可能避免/轻松地找到它们。您正在处理的特定应用程序/程序也是如此
  • 测试：我喜欢静态类型（我喜欢用C ++编程：p），但是编译器/静态分析器可以为您做很多事情。未经测试就不可能对程序充满信心。而且，我全力进行模糊测试（如果适用），因为您根本无法考虑所有可能的输入组合。

如果您熟悉该语言，则可以编写代码，并轻松查找错误。

如果您编写解耦的代码并广泛地测试每个功能，那么您将产生完善的代码，从而提高了工作效率（因为如果您不评估产品的质量就无法达到生产效率的标准吗？ ）

因此，我认为关于生产率的静态与动态辩论是没有争议的，或者至少在很大程度上被其他考虑所取代。

— 马修·M。
source
2
如果这是一个反问题，那么问题在哪里？:)我同意其他因素比静态类型和动态类型更重要。但是，动态类型主张者声称具有更高的生产率，而静态类型主张者主张具有更高的代码质量。我想知道是否有人有实际证据支持他们的主张。
— Winston Ewert
@温斯顿：我删除了计数器位：p正如您提到的，它主要是声明。我认为大多数动态类型的拥护者都将易用性与动态类型混合在一起，而易用性主要与工具有关。我确实同意可以编写快速扔掉的原型并使用解释器进行简短命令的实验可以提高生产率，但是即使Haskell（也许是目前使用最令人印象深刻的类型系统的语言）也可以使用解释器进行快速实验： ）
— Matthieu M.
但是直到有人真正进行了一个研究这个问题的研究之前-方法，工具是否比语言对缺陷率和生产率产生更大的影响-我们最终还是比较了轶事。
— Frank Shearar
0

这里有一些：

  • Stefan Hanenberg。2010。关于静态和动态类型系统的实验：对静态类型系统对开发时间的积极影响的怀疑。在面向对象编程系统语言和应用程序的ACM国际会议论文集（OOPSLA '10）中。美国纽约州纽约市，ACM，22-35。DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Daniel P. Delorey，Charles D. Knutson，Scott Chun，“编程语言会影响生产力吗？使用开源项目数据进行案例研究”，牙线，第8页，第一届FLOSS研究与开发的新兴趋势国际研讨会（FLOSS '07：ICSE Workshops 2007），2007

  • 戴利 Sazawal，V.，Foster，J .：《进行中的工作：Ruby中的静态类型的实证研究》，编程语言和工具的评估和可用性研讨会（PLATEAU），位于ON-WARD 2009。

  • Lutz Prechelt和Walter F. Tichy。1998.评估过程参数类型检查好处的受控实验。IEEE Trans。软。。24，4（1998年4月），302-312。DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186

— 洛林·霍希斯坦（Lorin Hochstein）
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.