Groovy Or JRuby

clipped from jroller.com To Groovy Or JRuby Currently, in the Java world, we have two main scripting languages, Groovy and JRuby. Learning the syntax is usually the simple task, but it is important to understand that it does not end there. In order to really know how to use the language, we need to know all the different popular frameworks that comes with it, idioms on how to use it, and so on. what should a developer learn? Should it be Groovy or JRuby? Both have a very active community and very interesting frameworks that come with them - Grails in Groovy and Ruby on Rails in JRuby/ruby. The question is an open question to the community, ruby it can be used both on the Java world using JRuby, and in future possible projects that will use only ruby, The main thing that I currently think about is this: with Groovy, moving from Java to Groovy seems to feel more natural, Groovy grew out of Java, which gives it a big boost in terms of learning curve (Grails feels like that as well).

体力和心理的肉搏战

刚刚看完2007斯诺克世锦赛希金斯和马奎尔的半决赛，最终希金斯凭借最后阶段的7:1，最终17:15逆转马奎尔率先进入决赛。马奎尔在前24局中表现得相当出色，但今天的8局比赛显然心理出现了松动，在曾经15：13的领先下，一个粉球关键失误葬送了后面的比赛，在第32局（希金斯的赛点局）中情绪低落到了屡屡失误的地步。而希金斯坚强的意志力最终让他笑到了最后。

世锦赛的赛制对每个选手都是极具挑战性的，像半决赛中33局17胜的漫长比赛，通常需要两位选手在两天内打完，能够走到半决赛的选手实力很接近，比分一直都很接近，可谓肉搏战，到了最后大家在体力和心理上都精辟历尽接近极限，真的是想赶快打完比赛，不管是赢还是输。

丁俊晖早早被奥沙利文扫地出门，使大家对他的心理素质产生了担心，要想成为顶级的斯诺克选手他还有漫长的路要走。

Java的未来是什么

clipped from www.eclipsezone.com Whilst Eclipse supports a variety of scripting-language environments (and the new Eclipse Dynamic Languages Toolkit), the code has to run ultimately on the JVM, or be spawned as an external process. Having it in-process means that the scripting language can interface much better with other code in the JVM (e.g. the somewhat defunct Eclipse Monkey project), but (for some reason) dynamic language proponents have often avoided running on a VM solution, preferring to roll-their-own. Languages like Groovy and BeanShell exist, of course, but those are primarily scripting languages created on top of Java rather than an existing scripting language like Python and Ruby (it will be interesting to see how Jython and JRuby work out, given that Jython's lack of news over 2006, it might be confused with being dead). My bet is that Microsoft is pouring more money in research into supporting for dynamic languages on the CLR than Sun have done for the JVM.

很早以前就看过一篇关于JVM和CLR的比较，认为CLR走的是一个虚拟机支持多套语言的路线，而JVM是只支持单一的Java语言规范，其它语言（更多的是脚本语言）和JVM的结合或者集成有两种方式（也是计算机语言的设计的模式）：1）编译型，其它语言经过和其相关的编译器编译成符合Java语言规范的Binaray Code（也就是class文件）在JVM中运行，这种方式需要不同的语言有各自的编译器（AOP和未来的DSL都采用这种方式），程序要经过两个明显的步骤才能运行（这显然不是主流Script Language主导的方式） 2）解释型，其它语言在JVM 中host一个解释器直接解释执行，并和JVM中Java对象实现无缝交互，sun在JDK6.0加入了Script Engine的Framework,内嵌了Java Script的Mozila的实现，正是希望让更多的脚本语言run on JVM，sun公司也拉拢了JRuby的两个创始人让他们全职实现Ruby和JVM的集成。

当然Java社区对Script language抛出的橄榄枝后并不意味着一帆风顺，因为像Python和Ruby这样的Script Language都有自己发展成熟的非Java的解释器，也有比较丰富的库和框架的支持，让它们放弃发展投入Java的怀抱是Java社区的一厢情愿。那好，新的一轮争夺开发者的竞争就这样进行着，看谁做的好就是了。至于微软的CLR支持更多Script Language的努力，本人并不看好，因为大多数Script Language都是开源社区的产物，微软和开源社区的关系，不会有多少人愿意为微软做贡献，微软自己来实现这些光靠金钱来砸是不现实的。