由于Gutmans的特殊地位，他的这篇长文已经在技术界引发了强烈争议。参见其blog上和TSS上的讨论1，2。

下面是对全文的一个编译版本，基本反映了原貌。其中对多核环境中多线程（JVM）与多进程（LAMP）的比较，C语言生态系统以及开源语言与Java等厂商语言和技术的比较，感觉都是非常有价值的。

翻译全文

Gutmans 回忆自己几 年前参与的一个基于IBM Websphere的大型企业级项目。项目团队中无论开发还是架构人员都非常出色，但其中最优秀的人与Andi谈起PHP和动态语言时，还是将之视为玩具 语言。这在当时正是Java界对动态语言的典型心态。但是，他们恰恰忽视了Web，因此Java EE设计时并没有以Web为中心，而且关注在企业集成、事务管理和其他后端处理上。虽然Java EE通过servlet和JSP支持Web开发也有不短的历史，但是掌握标准发展的大公司们忽视了Web的RESTful本质，仍然在向通用平台的方向上 走。

而与此同时，建于C语言库和工具的生态系统之上的LAMP架构，则成了Web程序最流行的开发平台。其中最常用的语言是PHP。由于 PHP专注于Web开发，而且为此不断演变，它简直就是为Web范型（paradigm）量身打造的，能够快速和容易地解决常见的Web问题，因此获得了 最大的市场份额。根据Ajaxian.com的调查，大约50%的RIA开发人员都使用PHP。由于各种PHP程序如Wordpress, Drupal, mediaWiki, osCommerce, SugarCRM的流行，这种趋势更加明显。

随着大多数业务应用程序包 括CRM、ERP、报表、文档管理等等也都转向了Web，那些大的Java厂商都意识到，Java对Web范型的形成和发展影响甚微，因此他们开始支持各 种标准和非标准的Java Web框架（JSF、Struts、Spring MVC等等），要使Java适应Web。这些框架虽然有些也取得了一定成功，但是它们都无法解决Java在Web上的主要问题：由于严格的类型化和架构过 度复杂，开发时间和开发人员的技能要求都更高，也就是说，总成本无法令人满意。

而且，大的Java厂商还什么都想占着。一方面想融入Web，一方面又不肯放弃自己已经在Java上建立起来的数十亿计的生意。甚至动态语言的广泛流行都未能显著改变他们的行为模式。但是随着微软雄心勃勃的多语言运行环境.NET的出现，大势又变了。

成 功的动态语言包括PHP, Perl, Python和Ruby都是用C写的，充分利用了C语言库生态系统的广泛性和深入性。而且它们都是社区驱动的，没有什么正八经的语言规范，发展不会被公司 政治所阻碍。这些语言都是由使用者自己开发的，他们只有一个目的：快速搞定工作。因此语言可能在小的版本更新时就加入重要的改进。这种敏捷本质正是适应 Web应用快速变化必需的。

而且，LAMP的部署方式有显著的优势。在多进程架构中，Web服务器和动态语言软件中的故障一般不会使网站 垮掉。虽然会有某个进程崩溃，但其他服务Web 请求的进程仍然可以继续运行。这与JVM这种多线程的环境中软件故障包括崩溃和死锁通常都会使系统垮掉，形成了鲜明对比。而且在特定时间后回收进程的能力 能够防止内存泄漏和内存碎片化这两种常见的内存问题使软件随着时间推移性能降低。LAMP上软件更新时，可以轻松和渐增地推到服务器，无需冗长的构建和打 包。虽然有时这会带来不规范、不严格的问题，但是只要正确实施，开发人员和运营人员的日子都会好过得多。

相比之下，Java厂商受困于与 Java绑定太紧对多种语言的支持很少的JVM。他们并没有转向能够使其客户两全其美的LAMP和Java技术松耦合的模型，而是患得患失，怕失去对客户 的控制，竞相在JVM上提供动态语言。无论是微软这个强敌，还是Java中互相竞争的厂商，都在实施自己的动态语言策略。

现在，Sun正 在其Java EE解决方案上支持JRuby和Jython而投入；IBM Websphere集团则认识到Java EE平台运行现代Web应用的无效，在Project Zero上大力投入，该项目的目的是使IBM在Web 2.0世界中也能有一席之地，目前支持Groovy和PHP；BEA也有一些孵化项目，但是被Oracle并购后，这些项目是否能有结果目前不明。 Project Zero的首席架构师是IBM公司里最先公开承认Java现在可以认为只是一种系统语言而不适合构建RESTful Web应用的几个人之一。而构建RESTful Web应用正是Project Zero的目的。Java堡垒花了10年多时间才承认Java在Web上投资回报不佳，而目前的趋势，将有更多的客户做出更明智的选择。动态语言将有大的 提升。与大型机一样，Java已经在企业级IT和关键业务应用中根深叶茂，因此不会很快消失。但是在Web应用上，Java语言很可能会在市场份额上急剧 下降。

问题在于，非微软的Web市场是会采用动态语言的JVM实现，还是容纳这些语言事实标准实现的LAMP架构。虽然我认为会有客户被前者吸引，但是市场主流还是会选择LAMP。原因在于：

1. 标准实现更新速度很快，而JVM版本总是滞后，会带来兼容性问题。这与Mono跟不上.NET的问题类似。

2. JVM最初设计时并没有考虑支持动态语言，因此在可见的将来，要满足实际需求，挑战非常大。像闭包、间接方法调用和类型juggling等动态特性就不容 易解决，这从目前JRuby与Ruby的C版本的比较中可以看出。而且，硬件厂商是否有兴趣跟上也是有待观察的。而开源技术就没有这种问题。

3. 现代Web的可伸缩需求对Web层的处理强度的要求越来越大。基于C的架构更可能与操作系统底层（原文为primitives）最有效地互操作，提供高 效、内存占用小的架构，满足这种强度。高性能的Web服务器比如lighttpd, Zeus, IIS 7，高性能的缓存系统比如Facebook等最大的网站使用的memcached，还有其他性能关键的子系统比如内存管理，都是例子。

4. 多核系统非常适合LAMP架构的多进程方式。随着芯片业现在把主要精力都放在了多核而不是超线程技术上，JVM这样的多线程环境的优点在今天的硬件上将无法充分发挥。而多进程方式将提供更多稳定性和可靠性。

5. 由于LAMP的简单性，它对于开发人员而言进入门槛非常低，而又能够提供很好的伸缩性，包括Yahoo和Facebook这样的大规模产品系统。

总 而言之，越来越清楚的是，动态语言将逐渐成为Web开发的标准。微软和Java厂商都认识到这个趋势，现在正在各自的软件平台之大力投入，给出解决方案。 但是，因为主要动态语言社区都是在.NET CLR和Java JVM软件平台之外发展起来的，这些厂商如果只是想依靠将成功的动态语言复制到自己的平台上而反败为胜，他们将处于困难的境地。有些厂商已经意识到这一情 况，采用了一些混合策略，同时为客户提供动态语言的标准实现，虽然还没有完全与其解决方案组合配合起来。微软在PHP上的投入就是如此，Sun也开始为客 户提供原生的Ruby和PHP实现。我相信虽然JVM向动态语言抛出的橄榄枝可能会吸引一些Java客户，但是这无法跟上开源社区开发原生动态语言实现的 步伐。JVM的动态语言实现对于Java厂商与时俱进是不够的，它们需要全面地拥抱原生的事实标准的社区驱动的动态语言。