Java、Ruby和持续负担

最近在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本身的问题，而是传染了社区中很大一部分人的流行病）。

查看英文原文：Java, Ruby, and the Continuous Tax