49 名程序员研究：静态类型系统对开发时间没有影响

导读

这项研究让 49 名程序员分别使用静态类型和动态类型语言完成相同任务，结果发现静态类型系统对开发时间没有显著影响。论文试图用受控实验为长期争论不休的静态 vs 动态类型之争提供实证数据。

HN 关注点：静态 vs 动态类型是 HN 上经久不衰的争论，而这篇论文用实验数据挑战了“静态类型提高开发效率”的常见假设，评论区的焦点在于实验设计是否公平、结论能否推广。

关键词　静态类型动态类型实证研究实验设计

HN 评论精选

这几条评论里：支持 1　质疑 2　补充 1

支持比起研究本身，社区对实证结果的抵触反应更值得关注；应该用实验而非空谈解决技术争论

这项研究可能有缺陷，但真正有趣的是人们的反应。我们的计算机科学需要更多科学，也就是更多实验和这样的结果。我们也应该坦然接受一个事实：我们使用喜欢的工具是因为喜欢它们，而不是因为它们在技术上更优越，尽管我们总是不厌其烦地把它们吹得好像技术更强。我曾读到英特尔通过改变风扇形状改善处理器散热的研究，转述给同事后，对方却断言这不可能，用关于空气和物理“必然如何”的即兴推理来反驳——英特尔确实做到了这一事实完全无法阻止他继续“辩论”。我很难相信自己用 Haskell 而非 Smalltalk 没有收益，但如果科学证据质疑这个信念，正确的做法是改变信念，而不是站在那里用想象中的第一性原理论证所有科学都是错的。闭嘴，设计实验去证明它！也许我们的计算机科学缺少这种真正的科学，因为这意味着要提出艰难的问题并接受艰难的真相。

fusiongyro查看英文原文

The study may or may not be flawed, but what's really interesting to me is the reaction. We need more science in our computer science, which means more experiments and more results like this. We should also be open to the truth that we use the tools we like because we like them rather than because they're technically superior, even though we pimp them ad nauseum as though they are. I once read an article about a technique Intel had developed for improving cooling of processors by changing the shape of the fan. I related this to some of my co-workers. One of them proceeded to tell me that this can't possibly work, backing up his argument with "reasoning" based on off-the-cuff remarks about the way air and physics "must" work. The fact that Intel had actually done this seemed to have no effect on his eagerness to continue the "debate" about this scientific fact. I have a hard time believing that I get no benefit from using Haskell over Smalltalk, but if a body of science were to appear that cast doubt on that belief, the appropriate thing to do is change the belief, not stand around debating from imagined first principles why all the science is wrong and can't be so. Shut up, design an experiment and go prove it! Perhaps there's little of this kind of actual science in our computer science because it would mean asking hard questions and accepting difficult truths. "The prisoner falls in love with his chains."

质疑实验设计错了：静态类型的真正价值在于大型团队协作和代码库维护，而非单人开发速度

研究个人是错误的实验设计。静态类型在工具层面的最大收益体现在大型团队协作、尤其是异步协作的场景。把自己写的代码的 mental model 记在脑子里并减少错误很容易，但要维护一个由许多程序员共同编写的大型程序的 mental model 就难得多。我希望看到他们把一个预先写好的、比如一万行的代码库交给一批学生，让他们对代码库做大规模修改或开发新功能。

cromwellian查看英文原文

Studying individuals is the wrong experiment. Static typing benefits tooling most when you have larger groups of programmers who much collaborate, often asynchronously. It's easy to hold a mental model of the code you write in your head and minimize mistakes, it's harder to hold a mental model of a larger program consisting of code written by many programmers. I'd like to see them hand a pre-written codebase of say, 10,000 lines to a bunch of students, and ask them to make large changes/new features to the codebase.

补充这项研究反而利好静态类型：既然不拖慢开发速度，静态类型就没有理由不用

如果说有什么的话，这项研究其实反而支持静态类型。为什么？动态类型的支持者大多声称它让开发更快，而静态类型的支持者大多承认这一点，但声称虽然会拖慢初期开发，却让维护容易得多。当然，这项研究相当有限，从中得出结论可能为时过早，我不会仅凭它做任何决策。但如果静态类型不会拖慢你，那么即使可维护性收益很小，也值得使用；即使收益不存在，用静态类型语言也不吃亏。

tikhonj查看英文原文

If anything, I think this study is actually in favor of static typing. Why? Well, most of the proponents of dynamic typing claim it makes development faster. Most proponents of static typing concede this point, but claim that while it may slow down initial development, it makes maintenance much easier. Of course, this study is fairly limited and drawing conclusions from it is probably premature. I would not base any policy decisions on it alone. But, if static typing does not slow you down, it seems worth using even if benefits to maintainability are slight. And if they're nonexistent, using a statically typed language over a dynamically typed one still doesn't hurt you. Besides, I think static typing is awesome. And I'm a college student--you can trust me! That should be all the validation you need :).

质疑实验设置偏向动态语言：API 太小、静态类型特性太弱、受试者成功率极低，结论不可靠

这是一篇有趣的论文，但我会否定它作为动态 vs 静态类型之争的有力论据。实验设置有点偏向动态语言的优势：整个 API 只有 14 个类，使得“静态类型无助于 API 可发现性”的结论意义不大；这里的静态类型语言没有泛型、没有封装支持、没有类型推断，远不是 Haskell、Scala 甚至 Java/C++ 风格的静态类型；IDE 支持也几乎为零。方法上还有一个问题：他们似乎回避了糟糕的成功率——只有一个人做到 100% 正确，超过一半的人根本无法实现一个有意义的解析器。说实话，受试者似乎被不熟悉的语法压垮了，而且大多非常缺乏经验（论文说他们中没人实现过 scanner 或 parser）。

thomasz查看英文原文

This is an interesting paper, but I'd dismiss the findings as a strong argument in the dynamic vs static typing debate. I think the setup is a little bit skewed as it's plays into the strengths of dynamic languages: * The whole api consisted of 14 classes, which makes the conclusion that static typing doesn't help with API discoverability somewhat moot. * We are not talking about Haskell, Scala or even Java/C++ flavor of static typing. The statically typed language offers no generics, no support for encapsulation, no type inference etc. * IDE support seems to be absolutely minimal. A methodical problem is that they seem to skip over the abysmal success rate: Only one(!) guy or gal was able to get 100%, more than halve of them was unable to implement a meaningful parser at all. To be honest, it looks a little bit like the subjects were overwhelmed by the unfamiliar syntax and/or most of them where really inexperienced (the paper says that none of them ever implemented a scanner or parser).

历次讨论

2012Hacker News 讨论帖155 分 · 187 评

HN 二十年，最值得读的论文。

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

49 名程序员研究：静态类型系统对开发时间没有影响

导读

HN 评论精选

相关资源

历次讨论

同领域还值得读

Google 的软件工程（2017）

Peter Naur：编程作为理论构建 (1985)

SciPy 1.0：Python 科学计算的基础算法

Lisp 的历史（1979）

使用 NumPy 进行数组编程

打赏支持

关注向阳乔木