Zed Shaw ，Mongrel 的开发人，分析了如何依靠项目对语言的适应性来运用包括 Ruby 在内的各种开发语言。针对 Ruby 在企业计算项目的开发，他提出七个有用的做法，并且指出了六个有害的用法。
CIO magazine 已经对 Zed Shaw 所写企业项目需用适用的语言开发这个系列的文章所了连续的报道。如果你关注 Ruby ，你可以查看 You Used Ruby to Write What?! 一文。
Shaw 以 Mongrel (Mongrel是一种快速的针对Ruby的Http 服务器，专门为部署发布rails应用而产生的) 的开发闻名于 Ruby 社区。在采访中，Shaw 针对 Ruby 在企业开发中的运用指出了七个有用的方面和六个有害的做法。
文章的开始，Shaw 指出，有两个问题使得很多项目中选择哪种语言变成了一个越来越技术性的问题，即多语言虚拟计算机和各种语言高效率库的一般利用率：
“当你考虑用哪种语言开发下一个项目时，记住，你最重要的目标并不是独断地，只考虑到执行性或者可测量性等等。而是，你是否能维持一群稳定而且优秀的开发者继续工作下去，直到整个项目获得成功……
“这大概已经远远超越了人们从表面上去鼓吹 Ruby 开发的优点：只要你用 Ruby，或者 Python，或者 Erlang，Haskell，Lisp 等等语言建立了一套软件，年轻人就愿意为你工作。事实上他们学习 Ruby 和其他的语言都是为了兴趣：比如现实一个有趣的想法，比如与朋友们在线冲浪……”
再回到 Ruby ，Shaw 指出了企业开发项目中的七益六害。考虑到 Ruby 在益处方面的介绍已经广为人知，这里只列出他所说的六个有负面作用的地方，想必这也是大家比较感兴趣的：
大量数据碎片
“虽然很无奈，但是不得不承认 Ruby (可用于开发的所有版本，特别是1.9版)已经因为大量垃圾收集器，I/O进程操作等等受到严重冲击。”
图形处理
“我认为很多语言在图形处理这个问题上都没有优势，但是 Ruby 却是在这个问题上显得相当糟糕。Ruby 最初可用于图形处理的库是基于 Image Magick 的，这个库很臃肿，运行速度慢，而且总是需要在各种系统中安装后才可使用。后来，Ruby 又选用了 RMagick ，但是 Magick 又有内存泄漏，很多操作都会产生多余不被发现进程，难以安装（除非你的电脑和笔者的一模一样）等等问题。其它的库就更不要说了。”
繁重的数学计算和处理
“与其他的语言相比，Ruyb 的计算执行率很差。很多时候，开发者必须用 C 或者 Java 重写好几次算法来优化最初的 Ruby 程序。而且这个深度优化算法哪怕是下一个阶段的开发者都很难应用，以至于又不得不重写。”
新语言的发展
“ Ruby 确实可以写出非常漂亮的 DSL (深散射层)，但是在其他语言里都不会指出的 DSL 错误却被 Ruby 指出来了，这个就是很奇怪了。如果你的目的是提供一种可供经济分析家处理日常任务的语言(软件)，那么“undefined local variable 'var' for main:Object”之类的错误毫无益处。在这种情况下，你真正需要的是一个有实际错误检查的剖析器，和一个不依赖 Ruby 的更好的算法。在实际应用中，Ruyb 在这方面可以算是失败了。”
E-mail 处理
“其他任何一种语言的电子邮件处理功能都比 Ruby 要强，用于 Ruby 相关的库只能算是半成品：老旧的 bug ，兼容性不好，速度慢，臃肿……这一切都不能称之为可用。”
服务协议
“ Ruyb 在I/O进程上的问题就是，写一个真正的升级服务简直就是浪费时间。我认识的很多人都放弃了用 Ruby 写服务程序的工作，其它人则是用 Ruby 和 C 混合着写着，要么就直接转向了另一种程序。
“我本来想就 Ruby 的执行速度写一份新的协议原型，但是如果我只想用几个操作，就能实现在每秒种内把这分协议原型发送到小几百人的时候，我就得马上转向另一种语言了。Ruby 中确实有解决这个问题的库，但是很多都因为 Ruby 的 I/O 事件循环而变得别扭起来。”
你对于 Shaw 对 Ruby 在企业计算任务中的评论有什么看法呢？
相关文章
