在QCon中了解到的一些有关Groovy和F#的内容
2010-04-24 01:39 by 老赵, 4627 visits今天参加了QCon Beijing 2010的活动，第一天采访了Groovy和F#两种语言的技术领袖，在交流的过程中也了解了不少内容，趁着还有一些印象就记点下来吧。Groovy方面这次来的是社区中贡献最多（没有之一）的Paul King，他也是《Groovy in Action》的作者之一。F#方面参加QCon的是Timothy Ng，年轻高大帅气，生于香港，四岁去加拿大，毕业后加入微软至今，目前是F#开发团队的Senior Dev Lead。与Tim晚餐时聊了许多，最大的收获是……发现我的英语也不是太哑巴嘛。
关于Groovy
在和Paul的交流过程中，我主要把关注点集中在Groovy语言本身的特点上。对于JVM平台上的语言来说，我个人最喜欢的是Scala，因为它足够灵活，把生产力交还给了程序员，更重要的是这是一门静态语言。静态这点很关键，因为如果要作为Java语言长期的替代者，它必须要在二进制层面做到和Java的对象模型保持一致。这样，只要能用Java的地方就可以用Scala。但对于JRuby，Jython，Groovy，Clojure等动态语言来说（奇怪，JVM上为什么没有什么静态语言呢？），假设，它的一个“类型”并不一定是个标准的Java类，它的“函数”也并非是标准的方法，更没法定义接口，那么这样对于一些面向Java对象模型的执行环境/框架/平台来说，就不能“打保票”说一定也可以执行了。就好比Android平台开发可以使用Java语言，那么我们便可以“不加思索”地确定它也可以使用Scala进行开发（因为它的对象模型和Java可以完全一致，只是代码表现方式不同），但是对于是否能够使用JRuby，就要进一步考察了（自然也不是一定不行）。
当然，对象模型和静态还是动态语言并没有绝对必然的联系，不过JVM上的静态语言基本都会使用Java的对象模型。而动态语言，尤其是语言特性并非Java超集的动态语言，必然需要有所折衷，此时就不一定了。
只是我也不得不承认，相对于Scala来说，Java程序员可能更容易接受Groovy。在Paul看来，Groovy本身便是一门更容易使用，有更多高级特性，且没有那么多“语法噪音”的Java语言。就基本语法来说，一段Java程序可能只需要稍作修改便可以变成一段合法的Groovy代码了。然后，再把Java的各类信息，如类型申明等等一点点删除，便成为了一段更“标准”的Groovy程序。看的出来，从Java语言过渡时学习难度也是Groovy语言设计中思考的一部分。在今天的“Groovy Power Features”中，一开始Paul就开始拿一段Java代码出来进行简化，巨大的差距便一点点体现出来了。
但是对于Groovy毕竟还是一门动态类型的语言，它在编译的二进制形式上，静态检查及性能等方面还是不如Java或Scala。Paul告诉我，其实Groovy本身也还在不断改进，例如在未来的Groovy 1.8和2.0中，其中一个方面便是在Groovy中加入“静态”的特性，例如通过一些强制指定的类型标识或参数，这样便可以获得一部分静态语言的特性，例如编译期的检查及执行性能。对于Groovy来说，对自身的不断演变也是非常重视的，这是我认为一门富有活力的语言所必需的特性。对于Java语言的评价，Paul也认为说Java好比是JVM平台上的汇编语言，这和我的观点一致。
关于F#
关于F#，我主要关注它的历史和文化，倒并非语言本身的特性。例如F#为什么叫作F#——因为F表示“Fun”。F#的创始人是微软剑桥研究院的Don Syme。Don是函数式编程的支持者，因为他认为函数式编程语言可以用简单的方法解决复杂的问题。Don的主要研究目标是ML，直到现在它也是学术界的宠儿之一。早在微软.NET平台发布时，Don便希望在.NET平台上实现一个ML语言。后来在实现上发现没有运行时上的泛型支持实在是不便，因此他又将主要精力放在了CLR的泛型支持上，因此他也是CLR泛型功能的主要设计者之一。而CLR 2.0发布之后，他实现一个.NET平台上的OCaml语言也是顺理成章的事情了。选用OCaml作为F#语言的“基础”的主要原因，主要在于Don认为OCaml的语言表现力更强，更为简单，也是一种静态语言，且带有面向对象的特性……那么还有比它更适合CLR的语言吗？Tim说，由于Don参与了CLR的设计，因此对于CLR本身能力十分了解，因此F#可以生成非常高效的IL代码。
F#的第一个编译器是用OCaml语言实现的，猜猜看这是为什么？这是因为，在使用了OCaml实现了F#编译器之后，便可以使用这个编译器重新编译“编译器自身”——F#可以识得OCaml代码。于是在接下来的改进中，直到现在，F#语言的编译器是用F#自身编写的。F#的编译器和核心库的代码可以在微软研究院的网站上获得，使用MSR-SSLA协议发布，简单地说便是种只能看不能碰的协议。Tim说他们的目标是将F#以MS-PL协议发布，也就是真正的开源。目前F# PowerPack增强包的源代码已经开源了，托管在CodePlex网站上。
Tim说，其实微软内部也知道一些问题。例如微软也明白，在许多高校里的教授并不喜欢微软，主要是因为不开源。教授的工作是研究，而不开源就难以深入研究，自然就不受欢迎了。而教授的研究内容往往也会影响其讲课内容的选择，因此这对于微软技术的发展也是不利的。为了设法改变这一点，微软也采取了一些行动，例如主动联系高校，赞助一些学术研究，并邀请教授们参与微软的学术交流，并向部分高校开放一部分源代码——如Windows内核，允许学生们进行改写与尝试。还有便是慢慢变得开放，例如F#，争取成为一个真正开源的语言。现在就有一些类似于这样的情况，因为不开源的缘故，教授会拒绝使用C#或VB.NET教学，但是不少人也表示出对F#的兴趣。
F#其实在微软内部已经进行了一定程度的使用和推广，我们可以发现如今随VS 2010发布的F#是2.0版，那么1.0版呢？其实都是微软内部在交流与尝试。后来微软发现，.NET平台上缺少一门成熟的函数式编程语言，而函数式编程，尤其是F#自身，对于如今不少领域，如金融，数据处理，异步编程等方面的确有许多帮助，因此决定将其真正产品化。有趣的是，F#团队正在招聘跨平台的F#开发人员，这个职位最主要的工作便是提高F#在非Windows平台上的运行质量。Tim说，其实说白了就是改进mono，使其能够更好地作为F#的运行环境。这意味着微软官方已经开始对mono进行了一定的支持，事实上这才是最令我感到高兴的事情。
关于Groovy和F#就先记录这么多吧，如果回忆起新的内容我再进行补充。至于对Paul和Tim的采访，我想InfoQ中文站也会尽快发表，欢迎大家保持关注。
推荐本经典的算法入门书籍吧（java或C#都行，c也可以），赵哥 最好不要涉及汇编，现在还没看到