小册子，没什么技术难度，不用花一天时间可读完，书中将语言的成功归纳为几个方面（这里加上个人的总结）
①政治上的，像python ,ruby,或者说java就没有或很少有政治上的问题，而.net ，显然有
②语言上的，这显然是根本，当然，动态语言和静态语言都会有优势，这取决于项目的类型
③社区上的，是否有一个良好的社区。
④大量的类库，java 大量的开放源码的类库显然是吸引很多开发者的一个很大原因。
⑤催化剂，即语言是否有一个杀手级程序或特色，如当时vb在windows 开发上，java的applet和 servlet，目前的ruby on rials等。 在书中，java语言被视为笨重的东西，而如果加上解决这些笨重问题的方案，又显的学习坡度太大。事实上也得确如此，如你用spring+hibernate+webwork开发一个项目，简单的事情会搞得非常复杂。 当然，我觉的语言本身是有些问题，但很多地方，也取决于开发者，那些书作者的言论也没有必要当成圣经。当然，在开发时刻保持这样的认识是很重要的。 显然，作者是ruby 和ruby on rails的吹鼓手，我个人比较认同在一些小的web应用中使用ruby on rails开发和，这会使你的项目有效率而又保持一定规范。至于有人云 ，为了ruby on rails 放弃windows和sql server，是否值得之类的言论。我的第一反应，这是哪根哪啊。ruby/ruby on rails 现在的应用只是在某一方面(即ruby的shell编程和ruby on rails的web应用）， 在很多时候，我们更倾向于能在目前的环境中集成ruby(即jruby或是rubyclr/ruby.net之类的意义），但显然，目前这部分还远远不够。因此，在目前而言，很多地方无法完全取代当前任何流行的开发环境的。 摘录几段有感触的地方 p33 其实，java语言没有什么大问题，问题在Java的类库上，类库采用大而无用的设计。
个人感觉：结果造成在看起来一个简单的方法调用后面，类库做太多大而无用的工作。 这个直接导致最终系统的性能问题，在这种情况下，简单的语言级的性能测试并不能真正的说明问题。.net 也是如此。 p45 如果jvm 接受动态语言，在可见的未来它将成为部署平台的选择，如果jvm 不接受动态语言，新的虚拟机将会出现。
个人感觉：jvm 会在下个版本引入动态语言支持，jruby 快发布1.0版本了，或许不要多久，我们将会看到结果。 p175 任何语言只要拥抱ruby ,就会在政治上取得更有利的位置。
个人感觉：在.net 上,ironpython 已经比jpython 的实现要好的多的多，由于ms已经招募了rubyclr的开发者，或许过不了多久，我们会看到ruby on .net实现 。但是这条并不适合.net ，很多时候,.net 是政治斗争的牺牲品，而不是其本身的原因。 p182 Stuart Halloway是很尊重的java顾问，特别是在元编程和反射方面。他在NoFluffJustStuff研讨会上说，他强烈觉得微软将会是世界上最大的开放源码厂商，而Davee Thomas 似乎也同意这样的看法。
个人感觉： 虽然ms已经对.net 做了一些标准化的工作，但显然，还做的远远不够，mono 已经在某些方面促进了.net 的发展，如果ms 能够消除开发者心中的“政治”方面的困惑，我想.net 未来应该不可限量。 我比较喜欢文中的催化剂的说法，当我刚接触java时，java 只会在网页上创建一些炫目的效果，jdbc才刚刚提出，java在那时根本就是个玩具，很多使用applet开发企业应用的都失败了。servlet 改变了这个现状，直接造成了java 目前在服务器端的地位。ruby on rails 也是这样一个催化剂。 我觉得我们有必要学习一下ruby on rails ，虽然你未必真的使用其开发，请把注意力放在其如何将ruby 语言的特点发挥到极致的。我个人也在检讨，为什么我们老早就拥有不错的语言 javascript ，而在asp 开发中，我们却很少或者说根本没有创建出一个令人印象深刻的程序。我想，缺少思考和想像力，可能是主要的原因吧。 |
