个人喜好:php ruby and java

看来我的好好回答下这个问题，
你说非常准确，我也明白。不至于是我脑子犯浑吧，呵呵
归并、快速排序都是分而治之的思想，如果采用的是两路排序，也可以叫做二分法。实在想不起来是在严蔚敏还是张铭的书上看得了，但这个概念应该不会错。
binary insert sort 叫做二分插入排序算法。和这个区别就大了。
http://en.wikipedia.org/wiki/Sorting_algorithm#Quicksort

我当时这么说也是觉得这个算法确实也是实现起来比较困难，某位大师好像说过现在能在一个小时内写出这个算法的人没几个了，呵呵。所以说是个意思就行了，我只是想说语言在解决某些复杂问题上的能力是等价的，而这些复杂问题是我们需要解决的主要问题。当然，robbin已经说了，这不是问题。虽然我还不是很赞同。。。

我的预言与选择

本文谈论了程序语言的发展趋势，以及我对程序语言未来发展的预言和选择。

第一章 什么是了解，什么是熟悉

charon想揭示我言语前后的"矛盾"，推理过程的要点如下(三句话):

axgle说:我对java不熟悉,不敢继续批判
axgle又说:公正的评价建立在了解的基础上，即使了解的过程也许不那么愉快
charon反驳道:既然axgle不了解java，因此axgle对java没有公正的评价

上面的三句话，包含的关键概念有三个:熟悉，了解，公正。

可见charon是在暗示“axgle不熟悉java,所以也就不了解java”----这个隐藏的"假设"是charon的推理所必须的。

遗憾的是，这个隐藏的"假设"是不成立的。"熟悉java"和"了解java"不是一回事情。

"我了解java,但对java不熟悉。"这个句子不矛盾，为什么？下面让我们一起来"精确"的讨论一些常见的问题:

IT招聘条件中常常出现"精通什么什么，熟悉什么什么，了解什么什么"这样的描绘。那么我想问一句，如何评判这三者的区别？

下面简单的给出一个我的定义："对某种编程语言的掌握程度"，可以分为三种：了解，熟悉和精通。

所谓了解，是说给定一段程序代码，能够读懂这段代码的含义或者知道它是干什么的。

所谓熟悉，则不但了解已有代码的含义，而且能够自己正常书写代码。

所谓精通，则不但熟悉如何写代码，而且能够写的很好。

我上面的定义，属于一种"递归的操作定义":'熟悉'建立在'了解'的基础上，'精通'又建立在'熟悉'的基础上，这是符合人们的直觉的。

这个定义同时又是可"操作的",也就是有客观的标准来验证：“基于'读'和'写'两者的难度是不等的” 这样的普遍事实。

不但对于编程语言是如此，而且对于"自然语言"同样如此：你可以读懂别人的英语，但你往往不会写，这就表明你只是了解英语。
而要是你又会读又会写，则可以说你熟悉英语了。进一步，你不但会读会写而且能够创作出优美的英语散文，OH,MY GOD,你完全可以宣称
你精通英语了！你看是不是这么一回事？是这么一回事！

我上面"对某种编程语言的掌握程度"的定义，你可能不认同，或者有更好的方式来定义什么是了解，什么是熟悉，什么是精通。

但无论这些定义将会是什么，"熟悉"和"了解"都不是一回事情。我敢说我了解Java，但我又承认不熟悉它。这是事实，而不是矛盾。

最后我想说的是:作为一个程序员，快乐也是一件很重要的事情。Ruby这门编程语言又好读又好写，要是精通它那就更好了，何乐而不为呢?

当然了，“别人送到我面前的金苹果我也不愿意接受，这也是完全有可能发生的事情”。所以顺其自然，不必强求。

第二章 好用与性能

好用与否是相对的，看和谁比。Java好不好用？好用!不信你用C++来比较一下,尤其是在需要跨平台的时候;C语言好不好用?好用!不信你就用汇编代码试试，保证你对C语言点头。
一般来讲，"易用性"与"性能"成反比。越好用性能越差。
所以在局部范围内，性能是首要的。Ruby的底层是C编写的，这就是事实。但从长远的观点来看，我们人的天性始终是“好用占上风的”:性能总有提高的一天，编程语言也将越来越好用同时性能也不错。

Java能够成功，不是因为性能优越而是因为好用，符合人的天性。PHP横扫web世界，首要的原因也不是因为性能而是因为好用。因此，如果ruby更好用的话，那么性能就完全不是问题。Ruby更好用吗？这需要另外的证明，或者理论上的，或者实践上的，等等.


第三章 对谁而言

有人说：“用户不会在意你选择的是什么编程语言”。那么，用户是谁？

可能的事实一:张三常常到某论坛罐水，他从来就不在意你用的是asp,jsp还是php编写的这个论坛，罐完水就走，想来的时候又来。
可能的事实二:李四是论坛的管理员，这个李四就在意编程语言了。是asp,php还是jsp论坛，哪个好哪个不好，我的主机支持什么语言？
可能的事实三：王五是程序员，绝对在意编程语言.要是说不在意，那去用汇编，最好用机器代码试试!

在可能的事实三中，我想表明的是“程序员也是用户”，是编程语言本身的用户。因此“对用户友好”的原则，同样适用于程序员。

第四章 Ruby是友好的

Ruby是对程序员友好的。因此基于前面的分析，就可以解释为什么Ruby on rails会流行的现象。并且也可以初步"预言":它将更加流行。

第五章 "预言"不准

我的脑袋里有这样的一个假设:"对任何社会现象未来趋势的预言，常常是不准确的"，简称"预言"不准原则。为什么说"社会性的预言"常常不准呢？
其实这个"预言"不准原则,是西方哲学家波谱尔提出并且论证的。

所以我在"第四章"的预言，就有可能是不准确的。简单的自我反驳一下:当我正在敲打这几个字的时候，黑洞吞噬了地球，一切灰飞烟灭，什么流行不流行，都化为乌有。
这是很夸张的说法,你也可以把这当作是搞笑，但我想表明的是一些人类不可预先预测的因素会左右事物发展的进程，所以会让预言失效。

而哲学家波谱尔则指出预言本身作为了一个原因，影响了事物发展的进程。并不是预言很对或者很错，而是一旦人们相信某个预言，那么这个预言就成为了一个推动的力量。

那么具体到Ruby来说，Ruby在中国会大面积的流行吗？注意，是在“中国”！会，不会？我只想说的是，"预言"不准。

我的结论，管它流不流行，反正我喜欢就行。^_^

hehe.给个链接
http://jakarta.apache.org/velocity/tools/view/CookieTool.html
虽然我确实不了解php和rails
但velocity中cookie的设置

$cookie.add("bar","woogie")

和访问

$cookie.bar.value

的写法，我想象不出php/rails与之相比具有无法企及的更简便的方法.
jstl2.0之前，velocity/freemarker是java web应用中最好的模板语言,jstl2.0之后就不知道了。

在Java编程中，并不是只有简单的在页面显示cookie内容的操作而已，还经常需要你在Action/Intercepter代码中对cookie进行操作，这时候你咋办？你给我写写Java存取cookie的代码。

不懂，在这里的cookie的操作不仅仅是显示，也可以设置。并没必要写Java存取cookie的代码，在php里面怎么干，自然在velocity/freemarker中怎么干就行了.
用了java，不一定非要分层,部分控制逻辑也可以写在view端(大部分php程序都这样).这样，用jsp/velocity/freemarker加上一摞java helper类就可以了。

我不是和你抬杠，但是我估计你很少进行Java Web编程。

使用cookie的场合主要是在登录，注册，用户登录验证，加载权限等等地方。你总不会告诉我你准备把这许多逻辑统统用velocity写在页面里面吧？如果你真的这么想，那就没有啥好说的了，看来你把JSP当做PHP,ASP来用了。

难道你用php就不处理登录，注册，用户登录验证，加载权限等等了?
我的意思很明确,既然要拿java和php比,就要用类似的结构和实现方式.否则,光一个MVC就带来了很多额外的开销,还比个什么啊.
至于我是不是进行java web编程,这个倒不是重点.不过,未必每个java web项目,都允许自动登录的.而cookie这个玩意儿,除了对自动登录而言是必须的,别的地方(比如购物车),还真是鸡肋.

靠，受不了了你，抬杠，转移话题加胡搅蛮缠。

PHP一样要处理权限，但是PHP无论在什么地方操作cookie，都是那么一个简单的变量引用。但是Java在Action/Interceptor里面操作cookie就是很麻烦的事情，而你用Java编程的时候，无法避免这一点。

很奇怪,难道只有是java和php裸奔才算是不抬杠? 那我得承认,不用那么些框架和第三方包或者不用OO的方式,用java生写web程序,那开发效率是比php差的不是一点半点.
如果允许使用这些资源或者可以抽象和封装,那么就cookie而言,根本不存在不可想象的差别.简单的情形如velocity + spring,足以以php的方式来应付.
如果非要在action/interceptor中存取cookie,尽可以封装一个简单的cookie接口啊,就像velocity的http://svn.apache.org/viewvc/jakarta/velocity/tools/trunk/src/java/org/apache/velocity/tools/view/tools/CookieTool.java?revision=385122&view=markup这样的弄一个Adapter(实在不行拿CookieTool也能凑活),最方便的莫过于把这样一个实例用链头的interceptor扔到request里面去,需要的时候就拿出来用,多上一句:

cookie = (CookieAdapter)request.getAttribute('cookie')

难道就很了不起? 后面的使用,cookie.add/get就一点都不烦琐了
或者如果只需要访问/设置cookie一次,也可以直接

new CookieAdapter(request,response).add/get 

这类封装都是一次性的开销,只需要这样的一个适配器类,所有的地方都简便了.
所谓的这类烦琐,如果只是光秃秃比较语言的场合,大体可以用一下. 但是在项目实践中并不能成立,很难想象项目团队不会找一个或者做一个helper类来便利自己一下. 既然是做java web项目的,你的工具箱里面难道没有这类东西?

给我的感觉，严蔚敏的书写的是很严谨的，但不一定讲的透彻了。如果觉得不好，推荐你看the art of computing programming，唯一的缺点就是书太厚了。