技术开发 频道

动态语言如何随需应变

  【IT168 技术文档】两年前动态语言刚刚出现的时候,内内外外都还有不少质疑的声音,用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就像癌细胞一样在程序里扩散,这样的系统只能用恶心来形容。

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

0
相关文章