MF高度评价DHH和RMH宣称J2EE将死

infoq今天有两个颇为引人注目的新闻：

一条是Martin Folwer对rails enterprise的评价，其中MF高度评价了DHH，甚至在某些方面抬到了和Kent Beck的高度；
http://www.infoq.com/news/Martin-Fowler-Enterprise-Rails
Martin Folwer原文：
http://martinfowler.com/bliki/EnterpriseRails.html

另一条是著名的畅销书《Enterprise JavaBean》作者，兼EJB3，Java EE JCP委员Richard Monson-Haefel最近的调查报告，宣称Java EE 5的发布也成为了Java EE走向衰亡的起点。
http://www.infoq.com/news/Java-EE-Demise-Report

这两篇文章都很有意思，值得一看，而且有很多值得启示的地方：

MF赞赏DHH对于rails偏执的简单性理念，拒绝复杂性。认为rails坚持做好自己单一领域的事情的理念是对的，每个简单的工具去解决自己单一的问题，而不是用一个超级复杂的工具企图解决所有的问题。

RMH批评JavaEE 5对简化编程做的还不够，改进太小，时间拖的太晚，并且企图用超级复杂的单一方案去解决所有的问题，并且预言更多的开发人员会转向其他解决方案。

我个人的看法：

似乎业界已经逐渐开始形成公认：rails即使在企业开发领域也开始得到越来越多的承认；Java亟待解决的问题就是太复杂，企图解决所有的问题导致它越来越复杂，而且改进的步伐太缓慢。

不过目前而且相当长一段时间内，Java仍然是企业解决方案的不二首选。不过可以尝试使用rails作为web应用层开发技术，一些比较复杂的后台技术，例如消息系统，搜索引擎，工作流等等使用Java，各取所长。

----- 我写的一段关于Java的感想

我用C++工作了2年左右，之后几年一直都用Java编程序。
C++最令我难受的地方是头文件include的包含比较复杂，需要定义ifdef, undef。超过几十个文件，我就不知道如何管理了；另外，当C++程序中的Object Graph结构复杂到一定程度，指针交织引用，内存管理的难度，借用时下的流行语，那可是相当的高。因此，用了Java之后，我并不是很怀念C++，除了偶尔想念一下C++ Template Library。
我主要用Java语言开发Web Application，而且我认为Java（J2SE, J2EE）比较适合这个领域。
Windows Desktop Application领域（包括Web Service和C/S 的smart client）用.net，Delphi等开发的好处在于，客户端的分发不需要另外安装一个Java虚拟机。
Web B/S结构只需要Browser瘦客户端就（除了有时候需要安装各种Flash、ActiveX等插件），免除了客户端分发的麻烦，也就不存在客户端支持Java虚拟机的问题。
Java是否适合所有的Web开发？
Web应用可以分为两种，
(1)内容服务Internet content service, 比如forum, bbs, blog, wiki, portal,etc.
(2)交互性比较强的（内部/外部）企业应用程序，比如，office，groupware，电子商务等。
第(1)类内容服务领域，主要是动态（解释/script）语言（如php, perl, ruby, python, 等）的天下。
第(2)类企业应用领域，尤其是比较大型的需要人头比较多的项目，比较适合用Java、C#等编译语言。
原因很有趣，不主要是因为性能，而主要是因为开发管理问题。这里有个很有趣的悖论。
我们都知道，动态语言灵活而强大，开发调试效率高出编译语言不少，但却不适合大型外包项目的管理。编译语言限制较多，不能随便写，虽然影响开发调式效率，但是相对容易管理。
当外包项目大到一定程度，需要使用非Windows Server，这时候，剩下的选择就是Java了。所以，Java在有限市场范围内，仍然保持了巨大的程序员数量。

Java的开源作品众多，我从中受益非浅，自己也开发了一套（3个）Web开发开源框架：fastm（模板层项目），lightweb(MVC)，lightor（ORM）。
在当前freemarker/velocity + webwork + hibnerate + spring流行的大趋势下，完全从头开发基础框架，不免显得不自量力和不合时宜。
我自然有自己的理由，主要是两个方面。一个方面是出于自私的心理，另一个方面是出于崇高的目的。
为了找到一个适合的方案，我经常研究比较开源项目，都各有优势，也各有不如人意的地方。Web应用没有技术门槛，了解基本原理之后，写一个简单框架比提交patch更加容易，还可以随意实现自己的各种乱七八糟的理念。应用过程中，修补自己的框架代码总比修补别人的框架代码来的痛快。当然，用别人的框架有个好处，就是用的不爽的时候可以骂它出气。
以上说的是自私的心理，至于崇高的目的，自然是：以实际行动回报开源社区！

下面简述一下我的理念。
首先，我认为，JSP、以及因JSP产生的TagLib、以及因TagLib产生的TagLib Dreamweaver Plugin、TagLib IDE Plugin等一系列产业链的前景堪忧。这一系列产业都属于自产自销，自己产生问题，然后自己解决，乐此不疲。
其次，我看不惯Server Script污染HTML，SQL污染Java，Java污染SQL的情况。
我希望自己开发的这套框架能够根本上解决上述问题，而且具有如下优点：
(1) 优雅简洁性能好
(2) 清晰干净无污染
(3) 灵活强大可扩展，面向未来，面向Ajax, Web Service Smart Client等。XUL, XAML, whatever.

-- 下面是关于Ruby On Rails Agile Development 的粗浅读后感

（甘冒天下之大不韪）

首先，那肯定是一本好书。我寻找了不少关于Rails的资料。都不如这一本，深入浅出。这本书的水分还是比较少的。少部分章节是 install, reference。

ruby on raill 给我的感觉如下：

1. 高级动态解释语言的优势淋漓尽致

active record可以这么写。
finder.find_by_id_and_name

自动就根据method name拼出对应的sql。

另外，test scritp, web service方面给人的印象颇深。

从前到后，语言都是同一种，惊人的一致性。语言切换成本为 0.

我一直认为，Web Service 领域，至少是 Web Service Client领域，是动态语言的天下。
至于Web Server方面，这个不一定，后面再说。

2. 违反了所有Java领域人们痛苦了多年总结出来的经验．

主要是说 Active Record 对 POJO , Unobtrusiveness 的违反。
（好像有个RBatis解决这个问题）

Ruby Template就不多说了。<%= %> <% %>和jsp一样。
当然解释语法都简单了不少。

3. Active Record 距离 Hibernate的差距

这个差距还不小。Batch Fetch, lazy, cache, collection, explicit save, 等。

4. 潜力

不过有一点可以肯定。
动态语言做这些太容易了。天生的reflection, interpretation。
什么reflection API, Dynamic Proxy, CGLIb，通通不用。
OGNL,  Bean Utils 实现起来小菜一碟。
这些诱人的特性，令人很想用动态语言在开发框架和基础工具方面一展身手。

动态语言的共同特点：
上手容易，精通难。不过这才是能产生大师 master 的语言。
如javascript, python, ruby, FP languages.

5. Hype, Buzz, Fairy Story 神话

关于JSF，大家的观点都差不多。我个人以为，命运可能不如EJB2。
但是，sun的庞大复杂的规范，不能代表整个java world.
Java也有简化开发的神话。Spring 掀起了风暴。
Ruby更是从语言级别掀起了风暴。

这里是我的看法。
一般来说，简化的部分，是已经比较简单的重复的部分。
复杂定制部分，还是需要自己做。省不了的。
动态语言开发框架确实具有优势。因为需求固定，语法高级。

但是真正意义上的开发，是简化不了的。
Ruby庞大起来之后，路线也差不多。

开发速度比java快20倍。任何一个动态语言都可以做到。php, perl, python, ruby。只不过，那是trival test的情况。用pure jsp，也能够比采用框架快10倍。

单就这一点，我就可以看出来你没有仔细看Martin Folwer的那篇文章

那篇文章我倒是看了。
前面的 Anti Enterpricy,  Neo the one 看起来很有趣. 不过属于story范畴。

rbatis 我也是看那篇文章才知道的。不然根本不知道有这个东西。这是我关注的部分。the fact。

只是我的上面的帖子，不是看了Martin Folwer有感而发，而是看了那本RoR经典著作之后的读后感 （写的非常好，感到很畅快，觉得把RoR的特性展示的淋漓尽致）。
上面的帖子也主要是为了探讨RoR的可能性。

---------

为了避免误解。这里说明一下。
Batch Fetch, lazy, cache, collection, explicit save,
之类的特性，并不是非要把SQL包装成HQL, EQL，加上一大堆配置文件才能做到。也不是非要Proxy , CGLib包装才能做到。
就是说，做到这些，并不需要 Hide。

At the recent RailsConf, PragDave's opening keynote highlighted a bunch of unsolved issues with Rails, several of which involved dealing with some of these enterprisey concerns. An example of this was his call for support of more varied database structures, such as having compound primary keys.

DHH's response to this could not have been a more emphatic refusal. ....... Applying this principle to compound keys, the reaction is "no way". Rails will do what it does, and will not complicate itself to support things it doesn't like.

Here is a solid example of what makes Rails "opinionated software". In the Rails mindset, life is much simpler if you keep your tables isomorphic to your objects, and give your tables surrogate, integer, primary keys. If you play the Rails way - life is easy; if not - use something else.

这个确实没想到，因为KentBeck是MartinFowler的偶像


在Ruby的编程中，OO不是最主要的能力，所以POJO根本没有任何意义

Ruby的核心能力之一，是创造DSL或者mini-language，OO和OpenClass、MixIn一样，是创造语言的工具而已，没有那么特殊的地位。

另外，我现在的认识是Lambda和动态代码生成能力以及singleton class非常非常重要。因为有了singleton class，也就是具备了每个对象同一个方法具有不同代码的能力，这和Lisp Macro的先用S-expression扩展，再编译为Lisp form实在是有异曲同工之妙。

不久我将以Routing System为例详细解释我的理解

前面提到了，这段 Anti Enterprisy, Neo the one, 我一开始就看到了，有趣的story。
不过，我没有在意。因为，这种反应是很常见的，合情合理的。
javaeye论坛里面很多自己做东西的人，也都是这种反应。
RoR作者现在的地位和名声，当然更有资格了。
任何一个工具都只是做好最擅长的领域。美其名曰，不媚俗。

要说到技术细节。
compound key，我也很少见到。支持不支持，无所谓。
我也没有提到compound key这一项。我自己做的orm 小玩意儿，也不支持compound key。

我前面提出的一些特性，是那些能够在每次调用db的地方都节省一两句code的地方。

------------------

撇开这些技术细节。
谈谈 Java将死 这个话题。

贴一下以前的讨论。既然我只是有感而发，自说自话，就只贴自己的言论了。
http://forum.iteye.com/viewtopic.php?p=92513#92513
http://forum.iteye.com/viewtopic.php?p=92523#92523
http://forum.iteye.com/viewtopic.php?p=92560#92560



Java 的优势，现在被笨重而庞大的框架和语法新特性，埋没了。不过，还没有完全丧失活力。不知道java1.6能不能赶回来一点。


-----------------------------



POJO不只是为了Domain Object, DDD之类。
重要的达到 Unobtrusivess，无侵入性，用户代码不依赖于框架代码。只要在Glue的地方才需要处理和框架代码的组合。
目前Ruby领域，RoR独此一家，别无分店，问题还不严重，可以不用考虑这个问题。和.net目前的垄断地位一样。



Interpreted Dynamic Type Functional Language 有这样的优势。 Schema, Common Lisp 等。(and JavaScript)

期待以Ruby为例子的这类高级用法。

为什么不依赖于框架，难道Hibernate的对象在脱离了Hibernate还有那样的能力吗，如果不从servlet继承或者从Action继承你的控制类就能够在Web容器里面跑吗？关键是什么地方不依赖于框架?

倒是TrustNo1上次讲过的声明性顺序问题更加值得考虑。如果你讲的是继承的问题，ActiveController,ActiveRecord完全可以不继承。不过mixin的能力让这些都无所谓了、没有什么意义了。


Common Lisp（Schema我不知道，应该也是一样的）的Macro能力本质上和是否函数型语言无关，和动态类型也无关，是一种自底向上的编程思路

另外，在Ruby中类和类型是完全不同的事情，类只是响应消息的一个模版而已，所以respond_to更加重要。我随时可以undef所有的方法，我可以delegate到另外一个类，我可以mixin。在Smalltalk中消息和方法就是两个截然不同的概念。消息是指接受的过程，而方法是执行的过程。

用户业务代码不需要依赖于框架。
另外，Domain Object, or Database Object。还有controller代码也确实不应该从 Action 继承。
每个URL对应一个Action controller。等到web框架要变了，所有的action controller就成为了Legacy code。
Struts, WebWork的这些Action就是如此。
如果没有这种依赖，Struts, WebWork的 controller code都可以是通用的。我采用的方法就可以做到这一点，可以随意引入其他的web framework的action。
脱离了这些框架，有了配套的service, 仍然有这样的能力。JDO, JPA, 还有很多其他OR。
这看框架和用户代码之间的协议。如果协议很松散。那么，只需要一个地方，集中提供adapter, glue就可以了。
根本不用把框架的package imports遍布在所有的用户代码中。

我前面提到了，Ruby的语法做到这些简直是轻而易举。
但是，至少从RoR的那本书里面看，它没有这么做。
这是我的意思，RoR并不在乎违反Java领域人们获取的经验教训。
从现在的情况来看，这是一个正确的选择。趁还没有强有力的竞争对手。



我说到的DSL支持，主要的意思是，Common Lisp,  Schema 可以重定义解释器的一些行为，重定义关键字，操作符，macro。
这样就可以定义新的Language，达到DSL的效果。
可能就是你说的意思，我毕竟没有使用过这两门语言，只是赶时髦，学习了一下常见的FP语言。

Java Reflection只提供了类型数据的Read Only方法。
动态类型，作为数据操作的能力更强。可以读，也可以写。
静态类型，动态类型之间的比较。以前大家也讨论过。动态更加灵活。
类型本身就是数据。可以读，也可以写。静态类型只读，不能写。
静态类型类似于 db table 的 column 定义。定死了，就不能动了。
动态类型类似于 db table里面的扩展属性，用row data代表column.
id,  propertyName, propertyValue
11,   "columnExt1",  "myValue1"
12,   "columnExt2",  "myValue1"

从方法的调用角度来讲。
静态类型的method dispatch是根据vtable的数组索引(entry index)来进行调用 (bind by relative memory address)。这是一个编译行为。
entry 1 -> method 1
entry 2 -> method 2

动态类型的method dispatch是根据类似map结构来查找对应method。（bind by name）这是一个运行时候的动态查询行为。
"method 1" -> method 1
"method 2" -> method 2

动态类型的好处，就不说了，灵活强大，简直罄竹难书。
静态类型的好处，很少。几乎没有。代码提示，重构，编译期类型检查。就没有了。我目前的水平，勉强可以驾驭静态类型系统，甚至可以说Master，至少Partial Master。动态类型系统入门容易，谈到Master，对我来说，还有相当难度。

---------

smalltalk 我不了解。不过也很有兴趣。
"在Smalltalk中消息和方法就是两个截然不同的概念。消息是指接受的过程，而方法是执行的过程。"
这个很有意思。

让我想起另外一个有趣的语言，ErLang。concurrent FP。T1曾经推荐过。据说，ErLang写的web server，负载量是apache的几百倍。
ErLang也是, Send and Pray, 另一头 Receive。

---------

摘抄一段，一个教授ErLang语言的老师记录的学生们的感受。



意思是，学生们一接触 Type Freedom (这个类型更自由，动态类型都不用，就是无类型)，就开始喜欢这门语言。
但是，当接触到更复杂的问题，他们非常想念类型系统，指出缺乏类型是ErLang的最重要的问题。
(主要是和Ocaml, Haskell另外两门静态类型Functional Proramming 课程语言相比)

------------------- 

说一下自己尝试JavaScript的感受。（有点跑题了。随意想起来的）
已经习惯了用interface相同的method name来进行编程。
比如是这样。
serviceImpl1.doService(...)
serviceImpl2.doService(...)

到了JavaScript，如果不用Prototype，而采用JavaScript的FP特性来编程的话，应该习惯采用Function Name来编程。
比如是这样。
serviceImpl1(...)
serviceImpl2(...)

后来有些习惯了，感觉两种方式是一个意思。FP还节省了不少代码。