孟岩《来自巴西的Lua语言新星让我脸红》及网友评论

一种自由软件的脚本语言 Lua ，由于在游戏界日益成为主流脚本语言（得到著名的卢卡斯艺术公司两款游戏采用，并在GameDev.net的调查中高居脚本语言榜首），最近引起了业界的广泛关注。
Lua （葡萄牙语，义为月亮）是一种轻量级的强大的扩展语言，用纯ANSI C编写，最初版本只有6000行代码，却实现了垃圾收集、反射、面向对象等机制。Lua 是由巴西里约热内卢天主教大学计算机系的Roberto Ierusalimschy 等人于1993年开发的。
最近，Roberto Ierusalimschy 撰写的《Programming in Lua》一书也已经出版
---tangl_99

Python是荷兰人写的，Ruby是日本人写的，Lua是巴西人写的，我这个中国人只能在这里脸红。
---孟岩

不必人人制轮胎，难道你不想躺在轮胎做的吊床上休息？
---牡蛎

只选对的，不选贵的。
---路人甲

转载自tangl_99的blog和孟岩的blog

Python是荷兰人写的，Ruby是日本人写的，Lua是巴西人写的，我这个中国人只能在这里脸红。
Lua是所有动态语言中间平均效率最高的一个。它最初是以Library的形式存在，纯粹只是用作C/C++的一个扩展。现在不仅发展出了解释器，还发展 出了编译器。游戏开发里Lua是使用最广泛的脚本语言。当世界上第一本Lua图书上市销售的时候，一位读者评价道："Lua is a real gem."
（牡蛎到没有听过Lua、Python或者Ruby的编译器——.NET的冒牌货除外）

Lua很棒，Lua是巴西人发明的，这些都令我不爽，但是还不至于脸红，最多眼红。
让我脸红的是Lua的源代码，百分之一百的ANSI C，一点都不掺杂。在任何支持ANSI C编译器的平台上都可以轻松编译通过。我试过，真是一点废话都没有。
我1996年就学会了C，1997年就跑去研究Win32 API，后来是C++，STL，Java... 直到2002年看到C Interfaces and Implementations，才知道仅仅用ANSI C就可以实现一个强大的优美的library，直到2004年看到Lua的源代码才知道仅仅用ANSI C就可以实现一个非常快的虚拟机、非常棒的解释器/编译器和非常漂亮的语言实现。
这8年我都干什么去了？
---孟岩

http://www.chinaitpower.com/2005September/2005-09-13/204728.html

赖勇浩:动态大比拼Python、Lua和Ruby

So which of the three languages is the best to use on your project? That depends a great deal on what you want to accomplish. To wrap up the book, I've outlined some of the pros and cons of each language in this section.

这三种语言中的哪一种更合适你的项目？很大程度取决于你想达到什么样的目标。作为一书的结尾，在这一节里，我会描述一下它们各自的优点和不足。

Python Pros and Cons

Python的优点和不足

The pros of Python are as follows:

Python的优点如下：

· Python has more extension modules than the other languages.

· Python比其它语言有更多扩展模块。

· Many online Python tutorials exist. There are also plenty of English books and reference materials, many sample scripts exist online, and there is a wealth of introductory material. The Python.org Website is a good place to start looking for these because it has sections for beginners, tutorials, guides organized by topic, and lists of links and references.

· 在网上可以找到很多Python教程。不仅如此，还有大量的英文书籍和资料。Python.org有很多为初学者准备的依主题组织的资料、教程和编程指南，此外还有很多链接和参考。

· Most folks really enjoy the syntax of the Python language because it appears clean and is easy to read.

· 很多人都喜欢Python语言的语法，因为它清晰易读。

· Python has an edge where libraries are concerned. There are many libraries, and, for the most part, they are well documented.

· Python在支持库上大占优势，因为它有很多库，而且大部分都有完善的文档支持。

· Lots of tools that tie into Python are available, and they are often easier to find than the tools for Lua and Ruby.

· 很多工具可以用于Python，但难以找到适用于Lua和Ruby的。

The cons of Python are as follows:

Python的不足：

· Existing Python debuggers are considered quirky and slow. Debugging support on Macintosh and consoles is even weaker.

· 现有的Python调试器诡异而且效率低下。在Macintosh（苹果计算机）和控制台下进行调试是一个梦魇。

· It can be difficult to bundle Python with other languages. There are lots of binary DLLs, and Python has (compared to the other languages) a large standard distribution.

· Python难以与其它语言集成，它有太多的二进制DLL，而且Python带了巨大的标准发布包。

· Lots of folks really dislike the white space sensitivity of Python syntax.

· 同样的，也有很多人不喜欢Python对空白符敏感的语法。

· Python can be quite slow at times, as everything is an object on the heap.

· 因为栈上的任何东西都是对象，所以Python有时候会慢得难以忍受。

Lua Pros and Cons

Lua的优点和不足

The pros of Lua are as follows:

Lua的优点：

· Lua is probably the fastest of the three languages and usually uses the least amount of runtime memory.

· Lua在这三种语言中是运行时速度最快而且占内在最少的。

· Lau has the smallest memory footprint for bundling.

· 集成Lua只会增加极少的内存占用率。

· The Lau C API is very well documented and has good examples for integrating with C.

· Lua的C API有着完备着文档和很好的例子，可以容易地通过C集成在软件里。

The cons of Lua are as follows:

Lua的不足：

· The documentation has improved but is still a bit sketchy overall. Of the three languages, Lua it is probably the least documented (the API being the exception), with the least amount of code comments. This makes for the largest ramp-up time to learn, and there isn't much in the way of introductory Lua material.

· 尽管Lua的文档已经增进不少，但仍然有所不足。三种语言中，Lua可能是文档最少的（API方面是个例外），因为代码中极少注释，这也增加了学习的难度。另外，对Lua的本质也没有什么介绍。

· There isn't a lot of built-in functionality for Lua. There is little support if you need to create a large, complex application.

· Lua内建的功能很少，并没有对创建大型的复杂应用程序提供足够支持。

· Lua could use a better garbage collectorthe current development is moving towards that now. Right now, Lua GC uses a very simple and traditional simple mark and sweep.

· Lua应该使用更好的垃圾收集机制，Lua现在的GC仍然使用非常简单而且传统的“标记和清除”方式。

Pros and Cons of Ruby

Ruby的优点和不足

The pros of Ruby are as follows:

Ruby的优点：

· Ruby possesses fairly good advanced debuggers.

· Ruby有极好的高级调试器。

· Ruby is object oriented from the ground up, and programmers who are OOP enthusiasts or who are used to the OOP paradigm will find the language extremely comfortable.

· Ruby是最彻底的面向对象语言，对于OOP狂热者和惯于使用OOP范式的程序员，他们将会发现Ruby是最适合他们的语言。

· Ruby has arguably the simplest syntax, with no real rules exceptions. Especially true for OOP enthusiasts.

· Ruby的语法极为简单，没有让人出乎意料规则，特别适合OOP行家的习惯。

The cons of Ruby are as follows:

Ruby的不足：

· Lack of English documentation.

· 英文文档极度缺乏。

· Fewer existing works and samples for games than with the other languages.

· 与其它语言相比，在游戏方面所作的工作和实例都少得多。

http://soft.zdnet.com.cn/software_zone/2007/0702/415264.shtml

ruby on rails为什么暂时无法成为企业应用开发的主流？

作者robbin

今天上午和庄表伟在msn上交流了一些看法，下午和JavaEye2.0的主力开发人员jerry讨论了关于ruby on rails在企业应用开发和团队协作的问题。通过讨论，有了一些初步的想法和观点，虽然还不是很清晰，但是现在总结和记录下来，留待今后的实践来验证。

ozzzzzz在Java将死？中提出了一个衡量未来主流工业语言的标准，其中有一条很有意思：

ozzzzzz 写道

1. 应该能规范书写，而不是像c那样可以造就多种不同的风格。

Java明显是一个编程风格非常容易统一起来的语言，而ruby则很明显是一个难以统一编程风格的语言。JavaEye论坛里面有人曾经说过：

引用

Java语言，高手和低手写出来的代码都差不多，而ruby则不同，高手和低手的代码，高下立判

Java编程语言的语法非常简单，规范比较严密，这样规范化带来的好处就是，一旦程序员具有比较良好的面向对象编程基础和设计模式的掌握，那么编写出来的代码几乎是大同小异的。

为什么优秀的Java开源框架的源代码我们读起来都比较容易呢？为什么Java那么容易写出来无二义性，相似度那么高的代码风格呢？为什么用 Java做同样一件事情，往往只有一种最优的写法呢？为什么Java很难搞出来奇技淫巧呢？为什么Java语言一直被人认为是大巧若拙呢？我们再想想，为 什么JDK5.0引入的技巧颇高的泛型编程到现在也有三年，为什么还是没有被广泛采用？再想想Java语言被设计出来是用在什么场合的呢？

想清楚这些问题，那么我们就会发现Java成为企业应用开发主流的一个内在原因(外因也很多，这里不谈)，因为Java语言足够死板！

所以写Java程序没有什么花巧，所以为了弄出来点花巧，逼的Java社区搞出来动态反射，搞出来AOP，抄袭了泛型，其目的都是增加Java语言的灵活性。

那么Java这种死板而简单的语言有什么好处呢？好处就是适合作为工业语言！

那么我们分析一下工业语言在语法上面有着什么样的要求呢？

1、语法足够简单而且强壮
2、语法足够死板、做同样的事情，只有一种最优解
3、足够的语法障碍，抑制你的随意发挥，给我规规矩矩的编码

工业语言为什么有这种内在的要求呢？

1、团队协作的需要
大规模的项目需要几十人以上的协作，甚至是异地协作。这种大规模的团队协作要求程序员的代码风格必须高度一致，并且代码块之间的依赖性降到最低。显然死板而容易解藕的Java非常的合格

2、批量生产的需要
现在的软件外包产业体现的尤为明显！不需要你的创意，不需要你的设计，就需要你的coding，而且coding风格，功能已经规定死了。Java显然又非常合适。


好了，上面分析了从语法特点角度，为什么Java成为了工业语言，那么再分析一下为什么ruby不能成为工业语言：

1、ruby的语法过于灵活，发挥的余地太大，导致每个人的代码风格迥异

我刚开始学习ruby的时候非常不适应，被ruby五花八门的语法糖衣搞晕了，同样的一件事情，你有无数种做法，笨拙的，普通的，聪明的，天才的，各式各样，甚至有本《ruby quiz》的书专门讲解ruby编程的各种奇技淫巧。ruby这种内在语法特性直接造就了ruby on rails奇迹。在ruby on rails框架里面，有无数的ruby magic，好用之极又让你惊喜万分，没有ruby这么多灵活的语法支持，rails变不出来这么多魔术。

但是ruby的语法灵活性恰恰是成为工业语言的一大障碍！Java绝顶高手和Java普通高手的代码在风格上不会有大的差别(我就不觉得Rod Johnson代码比我高明到哪里去)，但是ruby绝顶高手和ruby普通高手的代码简直判若云泥！高下立判！绝顶高手如DHH把ruby用的出神入化叹服之余，也让你我之辈根本无法写出来符合DHH风格的ruby代码。

在我们JavaEye2.0网站开发中，也出现了这种问题，两个人写的ruby代码，互相之间理解起来存在困难。而由于做一件事情有很多ruby写法，不同性格的人甚至都会选择不同的实现方法，在一个团队中，要统一编码风格，实在难乎其难！而在Java项目中，基本可以杜绝此类问题。

由于代码风格难以统一，因此在大规模的团队中使用ruby编程，会造成合作上面的障碍！


2、ruby on rails会导致你的代码藕合度非常高，不利于团队协作开发

由于rails规定死你的代码框架，不论是横向的功能解藕，还是纵向的分层解藕，都比较困难。

首先来说纵向的分层解藕，这是Java大规模项目常用的办法，但是在ruby on rails中基本不可能。因为ruby on rails各层之间的隐式约定太多了，你不可能分层开发。目前ruby on rails项目都是建议横向功能解藕，不建议纵向分层解藕的。

再说横向功能解藕：首先每个人必须承担足够大颗粒度的功能模块，不能拆分的太细了。因为rails的一个Controller文件就代表一大块功能了。

例如JavaEye2.0中，整个forum就只有一个controller，整个blog也就只有一个controller。当然你惊叹，整个forum代码就一个文件搞定了啊，代码太少了！但是反过来，你也可以说，论坛这个功能只能交给一个人来做了，没有办法再拆分功能了。这就带来了一个问题，团队协作变的困难了，如果两个人同时做论坛模块，就会出现经常性的该controller文件冲突合并。即使妥协一下，每个人只负责一个大功能块，但是底层的model代码都是互相关联在一起的。又难以避免的并发修改和文件冲突合并。

但是Java不存在这个问题，为什么呢？因为Java把一个Controller分解成为了无数个小Action，把一个Model分解成为了PO，DAO，Service，进行了充分的功能职责的解藕，每个人的工作基本不会互相干扰，那么团队协作的问题就好办了。

在JavaEye2.0开发过程中，就遇到了这个问题，即使是分出来一小部分任务，也经常性导致文件冲突合并，最后只能把大部分的程序任务压到了 jerry一个人身上。可敬的jerry同学几乎以一人之力编写了整个JavaEye2.0的绝大多数代码。在惊叹jerry以一个人月的高效率完成整个 JavaEye2.0编码工作的同时，我们也不得不反思，为什么ruby on rails这样难以团队协作开发呢？

在我最推崇的《Getting Real》这本书里面建议一个开发团队3个人足够了，一个人设计规划产品功能，一个人设计界面，一个人编写代码。我们现在也是这样的：robbin设计产 品功能，ouspec负责界面，jerry编写代码，然后robbin和ouspec负责测试。但并不是所有的项目都可以靠3个人搞定的，大规模应用项目 团队协作进行开发，我们目前还没有答案。

jerry有个观点我非常赞同，他认为目前我们没有找到合适的团队协作方法是因为现在的软件开发方法都不适合ruby on rails开发团队。而真正适合ruby on rails的软件开发方法究竟是什么样子，现在还没有出现，恐怕需要人们的探索了。ruby on rails流行必须伴随着适合ruby on rails的软件开发方法一起出现才行。

因此在人们总结出来这种适合ruby on rails的软件开发方法之前，ruby on rails仍然会被局限在web2.0开发领域，在这个领域，ruby on rails的所有优点将发挥的淋漓尽致，而缺点将会被回避开。不过一旦涉及到企业应用开发领域，我们将面临这些问题。

因此，我的结论就是ruby on rails目前尚且不适合企业应用项目的开发。当然如果有适合ruby on rails的软件开发指导方法的出现，或者企业应用本身的定义已经发生了彻底的改变，那么我的结论也就不复存在了。

用一句话来总结就是：

ruby on rails是武林高手的绝世宝剑，却不是两军对垒中士兵使用的常规作战武器(Java却是这种常规武器)。

BTW：我抛出来这个结论，并不代表我的想法已经很成熟了，事实上这也只是我们第一次尝试使用ruby on rails，在不熟悉不了解的情况下做出结论，未免过于草率，但是我之目的在于抛砖引玉，目前我们在开发中遇到了这些团队协作方面的问题，希望我的抛砖能够引出来好玉，解决这些我们还没有想到很好解决办法的问题，多谢啦，哈哈！


http://www.javaeye.com/topic/24499