动态语言如何随需应变

两年前动态语言刚刚出现的时候，内内外外都还有不少质疑的声音，用J2EE的挥舞着“企业级”的大棒质疑动态语言的“严肃性”，对于动态语言嗤之以鼻。

从开发人员的角度来说，使用动态语言编程要比使用传统的编译语言，尤其是编译型面向对象语言轻松自如的多，从而也有趣得多。没有那么多条条框框，没有那么多城府沟壑。

动态语言的优势自然也得到了像微软这样的厂商的重视，但是显然微软不会放弃他们已经建立多年的.net平台，于是原有的静态语言动态化成了一种必须。

于是我们就会产生这样一种疑问，动态语言是否能够顶住静态语言动态化的压力继续发展壮大，还是仅仅只是历史发展的一个注脚？这个问题值得我们关注……

最近，我跟好几个开发一线的朋友聊技术的发展，突出的一个感觉是大家都在关注动态语言。有的是使用多年，眼见发展态势不错，大有为自己的先见之明扬眉吐气之感，有的则是刚刚使用，仍处在兴奋不已的状态之中，当然也有仍然保持观望态度的，不过即使是最“保守”的，也能够对动态语言表现出尊重。这与两三年前相比，已经是很大的进步。

但是现在的企业应用跟两年前可是大不一样了，需求不断变化，修改没完没了。而互联网应用呢？在变化的剧烈和频繁方面，与企业应用相比可谓有过之而无不及。这本质上是因为企业在迅速变化，消费者在迅速变化，人们的需求在迅速变化，世界在迅速变化。现在经验比较丰富的企业开发者越来越达成共识，即事先分析企业应用、对抗需求变更，几乎肯定是死路一条。

既然无法避免变化，不如适应变化。与其想办法预见变化，不如让自己有能力迅速随需应变，提高自己对变化的反应能力，降低变化带来的成本。

这已经是共识了，问题在于怎么随需应变。分歧就在这里了。今天做ASP.NET、J2EE开发的离不开XML，就是为了“随需应变”，在变更发生时用XML来重新配置系统。以J2EE为例，高水平的J2EE开发者把XML文件越写越复杂，最后根本就是把XML当成领域语言来用。说白了，就是把J2EE往上扩展成一个面向领域的引擎，再用一层标准化的、薄博的XML来最后的编程，我称之为“强引擎，弱脚本”方案。这样做是有原因的，Java/C#好歹是个编译语言，变更修改重新部署的成本比较大，所以要配合XML使用。但结果怎么样？并不理想。首先系统设计难度还是很大，你还是要设计一个强劲的引擎，设计得不好就带不动XML脚本。而设计这个强劲的引擎还是挺难的，设计错了修改起来还是挺麻烦的，发布以后也难免还要花大力气维护的，这问题没解决多少。

其次，也是我个人最反感的，就是XML的滥用。XML那东西本质上是用来在程序之间进行数据交换用的，是给程序读写的，不是给人读写的。无论从哪个角度来看，XML对人的阅读和创作都是非常不友好的。结果为了配合J2EE，硬是赶鸭子上架，让XML充当DSL，逼程序员去学习读写XML这种非常没有趣味的“语言”，真是不人道。更有甚者，为了使用各种框架、面向各个领域，开发者还很可能要学会多种不同语义的XML方言，而且很多这样的XML方言根本就没有经过设计，是土法炮制出来的。两种截然不同的语言搅和在一个系统里已经够糟了，更糟的是多种土法炮制的XML方言土语一起搅和在系统里，结果搞得各种语义不同的XML就像癌细胞一样在程序里扩散，这样的系统只能用恶心来形容。

总之，这种“强引擎，弱脚本”的方式，笔者认为是没有前途的。