再谈静态语言对动态语言的优势

在以前的讨论中，robbin曾经发起过关于静态语言和动态语言优势比较的帖子：

http://www.iteye.com/topic/33971

关于静态语言和动态语言的定义请看上面的帖子。

我想谈一下自己的观点。

我个人觉得，静态语言相对于动态语言有如下几个优势：

1.  运行的性能优势
2.  代码的可读性
3.  代码质量的安全、可靠和可预测性

而这些优势决定了静态语言更适合用于开发大型系统。

先看第一点，运行性能。尽管现在许多动态语言可以使用类似JIT的技术来优化运行效率，但是由于其动态变化的能力（如动态增加方法、属性等）使得其性能的优化无法达到象Java这种动态优化的程度。而对于很多大型软件系统来说，性能无疑是非常重要的质量要素。

再看第二点，代码的可读性。这里的代码可读性并不是指代码量多少的问题，有的时候代码少并不一定好读，而代码多也不一定难度。举一个简单的例子，用Java定义一个类如下：

public class People {
    String name;
    int age;
    List addresses;

    public String getName() {
        return name;
    }

    ......
}

在其他类的方法中，可以使用该类：

public void printPeople(People people) {
    String name = people.getName();
    ......
}

而在一些动态语言中，我们可以动态生成People类（譬如从数据库的元数据中，或者某些配置文件中），并且也可以使用如下：

function void printPeople(people) {
    String name = people.name;
    ......
}

显然，动态语言使得我们可以不定义People，不过这时问题来了，我们除了从上面的方法参数名字上知道可能是一个People实例以外，很难获得更多的信息，并且，即时知道了这是一个People实例，我们也不知道这个类到底有什么属性可以访问，有什么方法可以调用，我们可能需要去查阅数据库的表定义，或者相关文档，但是直接从代码中我们无法知道这些信息。

对于大型系统来说，代码可读性的重要程度有时并不比文档和测试低，系统要能够很好的维护，就需要有较好的可读性。

第三点是代码质量的安全、可靠和可预测性。其实这一条是最重要的。代码的可靠和结果可预测对大型的软件系统来说至关重要。但是为什么说动态语言会在这方面存在问题呢？并且即使测试也无法解决呢？因为动态语言太灵活了，以至于你无法预测很多的行为。

我们还是以上面的printPeople函数作为例子，简单的一个people参数，我们来看看到底有多少情况是我们无法确定的：
1. people真的是People的实例吗？
2. People类真的是我们期望的People类吗？没有别的程序修改了它的属性定义或者方法的定义？如果有别的程序在运行时修改了这个类的定义怎么办？
3. 随着整个系统的发展，People类本身会发生怎样的变化，这个变化和printPeople这个函数相关吗？

显然这些不确定是我们无法用单元测试解决的，而集成测试我们通常只能遍历最常见的组合路径，所以测试无法有效的覆盖这些不确定性。

为什么会有这么多的无法确定的事情呢，因为动态语言缺乏强制的约定（或者协议），这种约定的缺乏形成了动态语言的动态特性。而在静态语言中，静态类型的约束的重要性不在于它在编译时的的类型检查，而在于它在使用者和定义者两者之间建立了一种约定，而这种约定保证了他们之间的行为的可预测性。

当然，对动态语言来说，这三个缺点并不是没有办法，有一些办法可以缓解这些问题，如果性能问题可以通过增加硬件的方法缓解，可读性问题可以通过注释和文档来缓解，而可靠和可预测性可以通过统一的约定以及组建一个开发风格一致的团队来缓解。

然而总体来言，这些缺陷制约了动态语言用于大型系统的可能，试想一个代码行数超过几十万行，生命周期为5-10年或者更长的软件系统，用动态语言来实现还是需要承担相当大的风险的。

语言之争挺没意思的，静态语言和动态语言各有各的优势，所以也就有其各自擅长的领域，我们要做的就是在正确的时候用正确的语言。对于小型的B/S结构来说，动态语言是有优势的，这也是为什么ror在java社区引起轰动的原因，但对于大型的、mission critical的B/S结构，Java EE仍具有统治意义

用Java你就能知道？
就算Eclipse给你提示，你就知道这些方法都是干什么用的？就不用查文档？

证据？
没有证据之前，我的直觉是：代码越少越容易维护。
另一方面的证据表明，同样功能的web应用，用Ruby on Rails开发所需的代码量大约是Java的10%~15%。换句话说，代码行数几十万行的Rails应用，其对应的J2EE应用将有几百万行代码。
那么问题一：维护几百万行规模的J2EE应用，风险又是如何？
问题二：你干嘛要把一个应用做那么大？

补充：99%的考虑采用Ruby on Rails开发的web应用，根本就不会有持续发展5~10年、堆积几十万行代码的机会。它们需要考虑的问题是能不能在第一个半年里活下来。
再补充：robbin会告诉你，就算JavaEye活到10年，它也堆不出几十万行代码。

现在的 IDE 对动态语言的支持已经相当不错了。大项目也应该不成问题。

语言之争的目的本来就不是说哪个语言好，哪个语言不好，语言本身没有好坏之分；语言之争的目的是通过比较，了解各种语言本身的优点和缺点，使得架构师在决策的适合能够选择适合项目的语言而已。另外，世界是变化的，所以现在Java EE具有统治地位，并不说明过几年还是如此，只有通过了解其背后的原因，我们才更有可能预测今后会有怎样的发展。

确实如此，对方法的理解首先是根据方法的名称和参数名称来的，只有通过名称无法准确了解其含义的时候，我们才会去查相关文档或者注释。另外我指的是如果People类是动态生成的会产生这个问题，如果是静态产生的或者自动代码产生的，就不存在这个问题，因为和静态语言一样，你可以找到它的定义。



代码越少越容易维护，当然我也这么认为。不过：
第一，我们讨论的是静态语言和动态语言的优势和劣势对开发大型系统的影响，而不是框架。因为语言是相对稳定的，而框架的发展却是太快了。今天Rails开发在工作量上很有优势，但是借助于明确的约定和代码生成，用Java开发一个类似或者接近Rails的框架真的是不可能的吗？在这种情况下，代码量的差别就不会那么大了吧。

第二，应用大并不是因为我们希望把它做大，而是因为业务复杂，对一般的互联网应用来说，功能相对简单，但是对于一些企业业务系统，其业务逻辑的复杂度还是相当高的。



可能是我们对大型系统的理解有一些不一致，我说的大型系统是类似银行核心业务系统这样的系统，这种系统运行5-10年是很正常的，可能还会更长。

另外，我一点也没有贬低Rails的意思，相反我很喜欢Rails，不过只是希望没有偏见的来讨论一下在面对大型系统的时候，静态语言和动态语言各自的优势而已。

你去看看MonoRails就知道了。这种事情不需要猜，事实证据都摆在那里。

这样的系统就会一直用它现在的工具来开发，就好像嵌入式系统就会一直用C来开发一样
问题是，这样的系统开发会越来越少，越来越机械化

我说过，我们讨论的是语言，不是框架。

另外在网上能够看到的各自开源的Java框架都是通用的框架，特别是经过几个版本之后，会增加很多看似有用，实际没有的功能，这种框架用于特定行业的系统开发其实效率并不高，相反很多公司都有自己的Java开发框架，经过多年的积累后，使用这些框架的开发效率并不低。

逻辑，同志，注意逻辑。
Rails和MonoRails，同样的框架设计，用不同的语言做出来，使用的代码量仍然有明显的差距。这不是语言的差距，是什么？
我在做语言之间的比较，你却非要扯到框架上，非要把很多公司内部使用的Java开发框架拿出来说事。第一我不确定这些框架是不是真的有效提高开发效率。就算是吧，要和它们做比较的话，你就得找到对等的、公司内部使用的、针对特定应用场景优化的动态语言框架来比较才行。
开源通用框架对比开源通用框架，内部专用框架对比内部专用框架，你才能看到在同样的框架底下，语言能带来多大的影响。我们讨论的是语言，不是框架。

lz，发这种帖子，讲道理，用心是好的，但是没用的，这种言论属于不受欢迎行列。省省心干点有用的吧。