Java、Ruby和持续负担

作者 Scott Delap 译者 郭晓刚 发布于 2007年10月9日 下午6时31分

社区

Architecture,

Ruby,

Java

主题

动态语言,

领域特定语言

标签

语言特性,

语言

最近在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

1. 返回顶部

   连续累进税

   2007年10月9日 下午7时31分 发表人 Dali Wang

   连续累进税率不是中国的个人所得税方式，Infoq中国也不应当成为推出新词的消息队列，整点大家熟悉的可以理解的术语吧 或者注释些相关的背景知识让中国的开发者明白超额累进税率和连续累进税率的分别

   回复

2. 返回顶部

   不敢认同

   2007年10月9日 下午7时41分 发表人 dennis zane

   这种理解和知识也是短暂的，一年之后你需要再次修改同一段代码的时候，你还要再重复一次这样的过程…… --------------------------- 难道java不一样？一年之后你同样要重新去理解，这个不成为理由。类型信息是很多情况下并没有想象中的重要。

   回复

3. 返回顶部

   Re: 不敢认同

   2007年10月9日 下午10时15分 发表人 Solomon Zaoldyeck

   确实像dennis说的一样，我国现在开发绝大多数并不注意类型信息的使用，所以动态语言这点上也不一定比Java损失更大。不过不知道国外这点做得怎么样。不过我感觉这至少是一种理念，我们应该时刻朝着方便和可复用性好的方向努力。

   回复

4. 返回顶部

   问题在于设计

   2007年10月9日 下午11时49分 发表人 edge wang

   正如Dion Almaer所说，“Java项目通常是过度设计的（不是Java本身的问题，而是传染了社区中很大一部分人的流行病）。” 所谓的“一年之后你需要再次修改同一段代码的时候，你还要再重复一次这样的过程……”，对于一个过度设计的的Java系统同样适用

   回复

5. 返回顶部

   Re: 连续累进税

   2007年10月15日 上午3时34分 发表人 Xiaogang Guo

   这里并不是continuous progressive tax rate，不知道“连续累进税率”从何而来。能不能请你说说你的理解？

   回复

6. 返回顶部

   使用静态语言的人总是忧虑这个问题

   2007年10月15日 下午6时48分 发表人 乐 田

   使用静态语言的人总是担忧项目的维护问题，担心项目规模变大或者时间很久以后代码会因为退化而变得难以维护。其实静态语言的编译起检查的确能带来一些作用，但不是决定性的。更好的方法还是通过不断的重构和测试，尤其是测试。 考虑到测试的代码，动态语言与静态语言的代码量差距会缩小一些。

   回复

• 更早的 >