ruby里面嵌入C代码

在smart client端，现在还没有东西，将来估计也不会有东西对MS造成什么打击。以前倒是有过，比如powerbuilder,delphi等等，现在基本上都已经挂了.
这个地方不在于语言怎么样，只要够简单就行，不需要太过强大。但是IDE必须够牛，lib必须够全。vb,delphi从语言角度来说，在流行的那个时候都算不上先进，甚至比较烂了，还不照样各领风骚


这哥们是个咨询师/讲师，不是干实际活的，所以当然不会有太强烈的具体分析。看起来有点象微软金牌讲师之类的。通常会在一门技术新鲜的时候自己实验性的做一些东西，总结出一叠best practices之类的. 至于这门技术是不是有前途，那是另说
他关于middleware的说法在
http://www.infoq.com/news/Can-Ruby-Live-Without-Rails


这个主要看middleware的定义了。不同的人可能有不同的定义。
其实很多地方优势也是缺点。就像这个ruby内嵌入C的做法，本质上和jsp里面搞一些java代码没啥区别。一定程度上的使用聊胜于无。

这个地方，我也有个一贯的错觉。:D
我觉得，Web Service Client，终将是 Script, 动态语言的天下。
MS Smart Client 目前确实独霸一方。
但是铺好的路，可能让Script, 动态语言占了便宜。
统一用XAML表述Winform UI widget，Web Service Binding，都是松耦合的领域，动态语言处理起来，都是小菜一碟。
lib的问题，动态语言或者直接访问CLR，或者自己编译为CLR。
IDE方面的问题，动态语言的meta class支持更好，动态语言的语法树，能够比编译语言更容易的当作资源树。配合XML的UI widget资源。实现的难度也要比编译语言小。



看到了。thanks charon.
he said.
I can't see Ruby as a platform for building middleware or operating systems.

Operating System 性能要求很高，java, c#也不能胜任。驱动程序，杀毒软件等也是。
middleware 应该主要是指 Distributed Transaction Management (OTS, JTS) , corba, ejb等。目前主要是C++ 和 Java 的实现。Java的强项在于Scalable,  secure, memory management. 动态语言也都有类似的特性。

wxPython发展的很好，很适合用来做跨操作系统的客户端软件。不过具体到Windows操作系统，目前还是Delphi是最好的选择吧

直接访问CLR的话，立马就平台绑定了. 用过jython,看过jruby. 给我最大的感觉是这类移植过去的语言有两个问题，一个是和源语言有一定的差异(与VM的内在的支持度有点关系)，另一个是lib上有很大的差别，这类语言只能说是以源语言类似的语法给熟悉这类语言的人一个快速切入新平台的途径.但是以前也看到有个哥们说过,包括我自己也体会到,学习一门语言,在语法入门之后,大部分的时间都花在标准库和稳定的第三方库的熟悉和查找上. 语法上的类似带来的真实收益并不多

ruby给我有两个迷惑,一个是太强大和灵活,大规模应用很难说会有什么后果. 比如Rails中最吸引其他阵营web开发者眼球最震撼的scaffoldding,在主流rails应用中有逐渐淡出的趋势.

第二个,就是ruby看起来好像哪儿都很强,从前面到后面,但是具体起来,除了像rails那样快速建站之外,别的地方还真的看不出来具体强在那里
B/S的browser端,ruby有抽象的优势,但大家还是得用javascript.
C/S的smart client端,除非出现杀手级的ide,否则也没戏.而这个圈子里面,要想玩过MS,不是一点两点的难
而dsl. 最难的不是表达,而是要表达的内容是怎么来的.现在所有的开发效率5X,10X速的演示,最重要的一点是演示者明确知道自己的最终目标是什么
就拿我这儿一个10几个人的团队2年时间做的项目,如果现在立马重头再来,使用同样的队伍,工具和语言,半年足可以搞定而且可以做得更好. 但这并不能说明整个开发团队的效率有了4X速的提高.只说明整个团队对同一个问题域比以前有了超过4X的了解
那种现有一个别种语言的实现,然后临摹一个ruby实现的做法本来就是不公平的. 而对于公共问题域的东西,如RPetStore对比与JPetStore,认可的开发增效是1.5X.

Rails中最吸眼球的怎么会是scaffoldding呢？scaffold生成的东西不过就是个demo，toy罢了。只有自己细心去用了才能体会到ruby/rails的优雅强大，我反正是再也不要回到java了...

语法的强大复杂，容易上手，容易写得优雅和迅速，有多种选择，满足个性化要求。
不足之处是，语法树比简洁的语法要复杂，分析起来不如简洁语法容易（比如，第三方的Interpreter，语法加速器等）。

提到这个scaffoldding（url -> db object CURD）的震撼效果，真是完全超出了我的理解能力。
zope也有类似的url pattern直接捅到 db obeject的convention。

convertion over configuration. 简单就是美。我也赞成。
但令我不解的是，有些东西明明是java领域里面的反模式。在rails里面大行其道。难道动态语言和编译语言的差别真这么大？
scaffoldding的弊病，和 asp.net 的数据库UI组件大同小异。都是 page/url 和 db data 直接 binding。唉，这也叫做 convention。
DAO 和 Domain Object 放在一起，Obtrusive。这也引起一片叫好。叫做the pursue of beauty。

Active Record里面确实有很美好的东西。
find_by_xx 直接映射为对应的 sql, 如此简洁有力。
参数的设置，都是 参数名: 参数值，非常清晰好看。
这些都是令人击节叹赏、值得借鉴的地方。

-----

唉，陷入Java世界太久了，头脑狭窄，墨守陈规，对其他编成领域的理解严重脱节。

to  charon

不要光是纸上谈兵，dip进去好好用用rails做做项目。你站在Java的彼岸望向对岸的ruby，怎么置疑都不过分，可惜的是，你所有的置疑都是意淫而已。

关于scaffolding，core team从来也没有回应过任何要求增强这个功能的呼声，比如做成像django的admin界面（看来不止是中国人喜欢说‘不’阿），所以我们也即用即丢好了。当然也有人喜欢强大的scaffolding,比如ajax scaffolding插件和几个正在开发中的CMS，这个就各取所需了。。。

AR是obtrusive的，因为你只用AR，不需要像Java那样考虑JDBC, Hibernate,iBatis,JDO。。。一碗水端平，还得搞接口和实现分离。至于beauty嘛，既然User.find很好，就不用麻烦写成User.DAO.find了。

module include, meta class多做些工作，倒是可以缓解obtrusive问题。

只是，Unobtrusive不仅是对 user domain object 有好处，对 Unobtrusive 对框架本身的发展也有好处。
obtrusive框架的升级和修改，必须考虑到用户已经存在的很多Domain Object对自己的依赖，那么这些遍布到各个Domain Object的 base class name, method signature之类，就不能随意更动。
如果 Domain Object 是POJO的，不需要依赖于框架。那么，Unobtrusive框架自身的发展也会更轻松，不用考虑很多兼容问题。需要考虑兼容问题的地方只是glue, integrate part。一般来说，这些地方只集中存在于用户系统的某一个point, 而不是分散在各个Domain Object中。

我现在的自己干活的首选工具是python.
至于工作上面，我这里不存在那种可以另起炉灶而不集成其它数据库的应用，所以也不可能用到rails之类的东西。
我发现python能够显著降低我敲键盘的时间(因为我一般不用eclipse写java程序，所以写java程序敲键盘比较多)。但并没有有效降低任何思考更抽象一点的问题的时间。期间因为一些出现的诡异问题也显著降低过开发效率,而在java平台上这类实际表现与手册不相一致的诡异问题出现的概率非常小。
而且，我前面说的那些东西称得上质疑的，基本上都是别人经过实证的东西(比如ruby的1.5X增效)。