深夜杂思

人类的世界发展到今天，真是无奇不有。最近看了一些关于计量经济学的贴子，发现了一个对于我们这一圈子的人来说，可能是极其陌生的计算机语言，叫做R。这个R语言的前身是S，是一种函数式脚本语言，主要就是为了做统计学，才特别被设计出来的。据了解，发明S语言的团队，还荣获了199X年的ACM最佳软件系统大奖，说是统计学软件中的唯一一个获此殊荣的。

当我看完这一堆堆的文章之后，不得不感慨，科学发展到今天，恐怕最大的鸿沟不是垂直意义上的知识深度问题。我相信知识深度问题应该是很好解决的，例如90年代初的时候，大多数国内的软件人才对于开发语言估计还停留在C上面，实际上此时C++都已经发展了十多年了。即便到了21世纪初，仍然会有某些学校的某些院系仍然停留在C，甚至是PASCAL这种古董级语言的教学上（注意：是“停留在”，这些老语言简单固然比较容易入门，但是接下来就没有教别的了）。当然了，今天国内也已经有很多人能够追上时代潮流，比如.NET 4.0还在CTP的时候就已经有很多人在学习研究了。所以，这真不是什么问题，毕竟在一个领域一直钻下去不难。

真正的Gap在于跨领域的时候所存在的问题，比如当经济领域需要使用到统计学方法，或者反过来说，统计学方法应用到经济领域的时候。具体讲，当一个纯粹的经济学需要用统计学方法来解决问题的时候，这些统计学方法对他来说可能就会变成新的、相对陌生的领域，需要花很多精力和时间去解决。而这个时候更麻烦的问题在于，他可能很难找到一个对经济学感兴趣的统计学大师来教他最新最先进的统计学方法，能找到一个能听懂最基本经济学术语的统计学菜鸟估计就已经很不错了。因此，这个时候通常只能从最简单的问题开始，慢慢的进行融合，直到两个学科都懂的人才出现，这种交叉学科才有可能出现大发展。当然，今天的计量经济学已经不是我所举例的那种状态了，但我敢肯定当这种交叉学科刚出现的时候，十之八九和我说的情景是相似的。

我之所以这么说，是因为我发现这个R语言被称之为先进，在我粗略看来却并非如此（姑且算是妄下论断吧）。有人号称这种语言是“面向对象的”，可我怎么看也并不觉得是真正现代意义的面向对象的。当然，这个语言中有“对象”这种概念确实是对的，这个先进在统计学圈子内也是能算得上的。关键是，在我粗略看到的信息里面，似乎很少R语言的使用者真正了解甚至关心R语言到底是一种什么样的语言，比如说是静态的还是动态的？强还是弱类型的？动态还是静态类型的？编译的还是解释的？等等。他们所关心的是这种语言能解决什么样的问题，我认为这是理所当然，也无可厚非的。但正如统计学中“不拒绝并不意味着可以接受”一样，关心能解决什么问题并不意味着一种语言的本身属性就不重要了。语言本身的属性决定着其各方面的性能，甚至决定了适合解决什么样的问题，以及编程解决这些问题的效率如何。就目前我的认知：R语言对于绝大多数统计学学者来说，应该是“Thanks god，there is a good *language* for me to use”这种的感受。我也不得不承认，就目前而言，这个语言用于解决目前的大多数问题，应该是足够了。不过，以开发人员的角度来衡量，这个语言仍然有一些缺陷：

1、并非现代意义上的面向对象，其实现方式有点像C语言的那种，需要自行封装分派的。此外成员也没有公有、私有、受保护的修饰，也没有不可重载或已经封闭等修饰，缺少接口（或者多继承），此外还有一些由于语言本身的设计所造成的、在我们看来很怪异的问题。我们举一个具体的例子，比如说下面这个求均值的函数：

mean <-function (x, ...)
     UseMethod("mean")

当我们具体调用这个函数的时候（结果是3）：

mean(1:5)

调用的时候，系统首先会将当前函数的名称mean放到上下文变量.Generic上，然后把x的类型Integer放入到.Class变量。而UseMethod函数在这一个例子中，会根据.Class以及UseMethod("mean")中的第一个参数的类型名称Integer来找合适的方法mean.Integer，然后再调用它（有点像C那种的派生继承吧）。实际上还可以写成UseMethod("mean",x)，或者UseMethod(,x)，或者UseMethod()。缺少的参数会从.Class和.Generic里面找。

好了，现在有两个很“奇怪”的问题。第一个是，如果有人直接通过mean.Integer(1:5)来调用，则.Generic不会有内容，因此UseMethod缺少第一个参数是很危险的。第二个是，UseMethod调用之后，即随便后面还有其他代码，也不会执行的（实在太怪了）。

从上面的描述可以看出来，这种面向对象是一种比较不正规的，揉合了泛型的对象模型。甚至根据我目前的理解，“面向对象”的函数都必须首先要有开放泛型函数的存在。而UseMethod的特殊行为，导致了每一个“面向对象”的函数都必须要写且仅写一句废话。

（注意：我确实没有用过R语言，因此其实我并不确定上面那个例子中的.Class会是什么，也许不是Integer，但概念应该是没有理解错的。具体请见http://cran.r-project.org/doc/manuals/R-lang.html#UseMethod）

 

2、没有命名空间的概念。这个设计缺陷必然会导致命名污染的问题，同上，没有一段足够长的时间，这种问题是不会被注意到的。

3、缺少很多其他先进的语言特性，这里就不详再一一列举了。因为这是很自然的事情，毕竟我们不可能期待一个目标是要解决统计问题的语言，能够在出现后短短的时间内跟上通用语言的发展步伐。

需要特别说明的是，我这么说也许会给大家带来误解，认为R语言就一定很落后。非也，R语言也有自己的垃圾收集器实现，而且和.NET的类似，是分代标记收集法（具体分3代，说不定还是.NET 参考了R或者类似的语言设计的）。 其实其内核算不上最前沿的，但也绝对不能说是土得掉渣的。目前的情况之所以如前面说到的那样，语言设计本身并不先进，其实也是因为统计学领域确实缺乏能够很好的解决他们的问题的语言，包括相应的函数库或者模块。我估计，就其目前的发展阶段，该语言的侧重点应该还是“能很方便的解决多少统计学问题”，而不是这种语言在解决这些问题时所面临的计算机语言本身的缺陷。可以这么说，我这里所做的推断也许要十年左右之后才会得到印证。当然，我希望能够更早一些。因为从我的角度看，这语言对我来说还真是有点丑，预计用起来会比较的不爽，而这种不爽并不是因为我对统计学知识的缺乏导致的（也许统计学研究人员未必能体会到，也许会坚持认为那还是因为我对统计学知识的不了解导致的，对此我也不想过多地争论，因为我也确实是缺乏此类知识）。

关于计算机领域和统计学领域之间仍然存在鸿沟的另一个印证是，在我们这一个领域里面，对统计学的认知是极端匮乏。我估计博客园的博主中至少50%以上不熟悉回归分析（甚至可能都没听说过），75%的博主可能不知道偏最小二乘法，这都包括我在内。我相信我的估计已经是相当相当的保守了，同时我也相信，这里的博主和统计学中使用R语言的大部分人比起来，在计算机语言、软件工程等方面都要强得多。理由前面提到过了，通过互联网搜索就可以发现，讨论R语言本质的人相对是比较少的，讨论R语言的软件工程方面问题的也是比较少。

对此，我有一个有趣的想法，即F#能否承担类似的工作。

关于好的方面，首先是F#在语言级别上会显得更先进一些，也许有可能会更快一些。这方面我就不多举例了，至少面向对象的概念更完整和严谨一些，底层核心也应该是更先进一些才对。

在F#上面做统计学框架， 还有一个很大的好处，就是由一些统计学无关或者关系较小的内容，可以很容易的由专业Coding的人或者公司来完成。比如说，数据库访问、页面展示、并行运算、负载均衡等。

不好的地方有，现在F#上面估计没有多少可以供使用的统计学函数库，而且R上面已经有不少现成的代码在被世界各地的学者所使用。这种积累性的问题，不是一天两天就能抹平的，就如java和.net之间的差距，至今仍然没有被抹平。（我在想，F#至少已经出现了，也具备一定的挑战能力了，java阵营呢？）

另外一个痛处在于M$的$上面。IDE要钱，Windows要钱等等，之前看了一个PHP的问题，我都不想说什么了。说实话还真不是要不要钱的问题，这个世界上很多问题都是源自于“恐惧”。有多少人会真正的仔细想想所有的成本，多数都只是对某种比较让人敏感的数据产生化学反应。这个问题就不多讲了，随便举一个SRSS好了，据说是按年租用，费用多是几十K美刀计的，这个成本呢？可能和Linux上面跑R比起来是要买一个Windows的License，不过这似乎也不是一般学者所负担不起的。如果把IDE的好处抹掉，光用免费的.NET Framework和Notepad，估计$的差距应该不会太大。（我确实承认，在大数量级系统上，Windows上的免费资源，甚至是收费资源都比Linux上少、差，但至少个人使用应该不是太大问题。）

 

P.S.:

已经有人用F#搞统计方向的研究了（http://cs.hubfs.net/forums/permalink/326/335/ShowThread.aspx），似乎评价不差 。

此外在F#使用R也已经有方案了(http://cs.hubfs.net/blogs/thepopeofthehub/archive/2007/11/06/FSharpWithR.aspx)，似乎问题不是太大。

搜索有关R的东西实在太难了，因为R这个字母实在是太常见了。