php,rails和java的有趣比较

关于RoR维护成本，TTS上的讨论也热火朝天。http://www.theserverside.com/news/thread.tss?thread_id=43020
目前国内除了JavaEye还有没有其他比较成熟的RoR应用？如果有的话，robbin兄可以联络大家聚在一起讨论一下目前系统的可维护性究竟如何。

我做设计时，经常借构建一套DSL的思路来类推——有意把class和方法设计成DSL的样子。不论用什么语言，我都尽量这么做，......

什么时候需要把DSL和主语言划清界线，我认为这个问题的答案因主语言而异，用Smalltalk时我几乎从没感觉有必要分离出一种DSL来，而这种需求在用C++/Java/C#时则非常常见。

......

...我喜欢用Smalltalk和Ruby的程度比喜欢用Java或C#的程度高那么多，其原因我总是觉得难以言传，最常听到的解释是静态类型与动态类型的区别所致，但我总觉得这个说法并没有抓住要害，更接近两者区别本质的是它们对构建内部DSL友好程度的差异。

我想这可以从两方面来看。
一是工具支持，包括设计工具、IDE工具、白盒测试工具等。动态语言在这方面我想和静态语言能向工具提供的信息量上还是有差距的。（是不是RoR采取了某种巧妙的思路，可以很好的解决这个问题？因为我还没有对RoR的运行机制做了解，所以不好轻易说RoR在这点上有先天的劣势，姑且从另一个角度，也就是目前的确还没有得到充分的支持这个层面上说吧）
二是第三方开发包的支持。像Java，C等语言之所以取得辉煌的成功，和它提供的丰富的第三方开发包是有很大的关系的。而静态语言相对比较封闭的特点，使得第三方开发包对代码的侵害性可以降到很低。动态语言在这点上表现的就比较差，我想大家都有过从网上下载某个JS包，然后放到项目代码里发生冲突的经历。RoR是否能很好的解决这个问题呢？
再次声明，本人刚刚接触RoR，只是有比较多的PHP、JSP和JavaScript的经验而已。

再回答一下robbin兄的几个问题。

我想robbin兄说的“Java编程带来的次要复杂度就是50，RoR把次要复杂度降低到了10”这个观点师针对原始的Java语言和原始的RoR进行比较的。的确，如今的Java语言体系太过庞大，如果不采用任何framework开发项目，Java的学习成本和使用成本都比较高。但是目前估计没有哪种语言会有Java这么多的framework，在确定好使用适当的framework开发适当的项目之后（确定适当的framework并不是件轻松的工作。还好，一般的公司做从事的项目都有一定的延续性，前一个项目确定好了framework，后续的项目基本上可以拿来用），我想语言本身的复杂度应该没有50比10这么高吧？当然，我没有用RoR开发过正规的东西，这点上没有什么强有力的发言权。


我想这可以从两方面来看。
一是工具支持，包括设计工具、IDE工具、白盒测试工具等。动态语言在这方面我想和静态语言能向工具提供的信息量上还是有差距的。（是不是RoR采取了某种巧妙的思路，可以很好的解决这个问题？因为我还没有对RoR的运行机制做了解，所以不好轻易说RoR在这点上有先天的劣势，姑且从另一个角度，也就是目前的确还没有得到充分的支持这个层面上说吧）
二是第三方开发包的支持。像Java，C等语言之所以取得辉煌的成功，和它提供的丰富的第三方开发包是有很大的关系的。而静态语言相对比较封闭的特点，使得第三方开发包对代码的侵害性可以降到很低。动态语言在这点上表现的就比较差，我想大家都有过从网上下载某个JS包，然后放到项目代码里发生冲突的经历。RoR是否能很好的解决这个问题呢？
再次声明，本人刚刚接触RoR，只是有比较多的PHP、JSP和JavaScript的经验而已。

很抱歉，我一直对robbin的说法将信将疑，但似乎你很确认。如果你认为这是Sun的人做的，数据可信度不高，这没什么问题。我也没有说会相信Tim Bray的数据，只是请robbin帮分析下。为什么会有这种差距，
摆事实讲道理才能让人信服。相比较来说，我更相信Tim一点。

BTW, It is funny that the people who imediately jump to Java's defense have never tried any of the alternatives, like PHP or RoR. We all need to keep an open mind.

如同上面这句话所说，似乎你一直以一个java的支持者看待我所提出的问题，很抱歉，不是这样的。

似乎我应该退出这些关于ruby,java,php的讨论，自最初我也没觉得讨论这些从纯技术角度有什么重要意义。
说太露骨就是利益集团的政治斗争，已有的既得利益者和未来的争食者。看java能不能倒下、ruby这杆大旗谁能先扛起来了。呵呵。静观其变吧。

至于第三方库，你说的冲突和命名域有关，和动静态没什么关系。

这里的常客都知道我几乎不在java版发言，我的钻石都是在ruby版赚的。被你说成’一直支持java'实在有够郁闷。

既然你已经意识到这种X vs Y的讨论技术的因素是次要的何必还计较那些数字呢？呵呵，相信自己的感觉吧。

真的和动静态没有关系吗?似乎没有哪个静态语言的包管理会出现混乱的情况.从这点上至少说明静态语言的包管理要比动态语言容易些吧.

真的和动静态没有关系吗?似乎没有哪个静态语言的包管理会出现混乱的情况.从这点上至少说明静态语言的包管理要比动态语言容易些吧.

An Interpositioning Bug in SunOS

Under SunOS 4.0.3, the printing program /usr/ucb/lpr occasionally issued the error message "out of memory" and refused to print. The fault appeared randomly, and it was very hard to track down. Finally, it was traced to an unintended interpositioning bug.

The programmer had implemented lpr with a routine, global by default, called mktemp(), which expected three arguments. Unknown to the programmer, that duplicated a name already present in the (pre-ANSI) C library, which did a similar job but only took one argument.

Unfortunately, lpr also invoked the library routine getwd(), which expects to use the library version of mktemp. Instead, it was bound to lpr's version! Thus, when getwd() called mktemp, it put one argument on the stack, but the lpr version of mktemp retrieved three. Depending on the random values it found, lpr failed with the "out of memory" error.

C语言是静态语言，（尽管是弱类型的），可是连命名域的概念都没有，一冲突糊涂到底。可见动静态和LZ说的冲突没什么关系。