最近在 ActiveRecord 与 Hibernate 之间的争论当中，Google 的 Bob Lee 用了“持续负担（continuous tax）”这个词，来形容使用 Ruby 这样的动态类型语言相对于 Java 这类静态类型语言的优缺点：
一般来说 Java 的学习曲线比 Ruby 要陡峭，特别是如果你考虑到泛型和学习最大限度地发挥语言的能力。Java 的类型系统对长期的可维护性和可用性有好处。而利用 Ruby 你可以抄捷径省掉这些步骤，更快地顺利得到结果，但你也要付出持续负担（continuous tax）。
Google 员工以及 TestNG 的作者 Cedric Beust 也注意到了这个词：
“持续负担”这个词是说，当你需要维护或使用用 Ruby 或 Python 这样的语言编写的 API，你能够得到的信息很少，即便你通过查看测试代码理解了 API 的含义（有谁这样做过吗？），这种理解和知识也是短暂的，一年之后你需要再次修改同一段代码的时候，你还要再重复一次这样的过程……
Brian Doll 将讨论引向了测试与“持续负担”的关系，Beust对此回应说：
实际上我并不认为编写测试属于我先前提到的持续负担。虽然我同意用静态类型语言的时候比用动态类型语言通常要少写一些测试，但是代码行数或者测试数量的差异还没有大到能够真正影响开发过程。持续负担是由代码明确性方面的损失引起的，动态语言写出来的代码通常要蒙受这种损失。虽然看起来无关痛痒，实际上丢失类型信息对代码的可维护性和可读性有可怕的影响，因为你看不出传给方法的一个对象到底是什么类型，更糟的是使得连最简单的自动重构也没法应用，比如重命名一个公开方法。
Dion Almaer 根据他自己使用动态和静态类型语言的经验进行了反击：
- 动态语言编写的项目代码较少，团队维护起来更容易。
- 动态语言项目的团队较小，因此我们更容易维护（我们可以用更少的人做更多的事）。
- Java 项目通常是过度设计的（不是 Java 本身的问题，而是传染了社区中很大一部分人的流行病）。
暂无签名
中国开源发展研究分析 2022
本次报告为开发者，技术管理者，开源社区运营、市场，开源办公室工作人员带来信息上的增量以及对开源趋势、...
评论