说说动态语言

转载 2006年06月17日 18:26:00
五一长假之前,我跟好几个开发一线的朋友聊技术的发展,突出的一个感觉是大家都在关注动态语言。有的是使用多年,眼见发展态势不错,大有为自己的先见之明扬眉吐气之感,有的则是刚刚使用,仍处在兴奋不已的状态之中,当然也有仍然保持观望态度的,不过即使是最“保守”的,也能够对动态语言表现出尊重。这与两三年前相比,已经是很大的进步。记得两年前我与Python爱好者tangtao合作策划《程序员》的第一个“动态语言专题”的时候,内内外外都还有不少质疑的声音,用J2EE的挥舞着“企业级”的大棒质疑动态语言的“严肃性”,用ASP.NET则沉醉于拖拖拽拽的GUI构造方式,自以为开发效率老子天下第一,对于动态语言嗤之以鼻。当时我们感到,动态语在中国的发展时机还不成熟,所以最后给专题起了一个很有些无奈的名字:《动态语言:隔岸观火》。两年之后的现在,是业界的朋友反过来批评我们的杂志和网站对于动态语言的关注过于薄弱,落后于工业实践。惭愧之余,我这个动态语言的一贯拥护者不禁喜从中来:想不到形式会发展得这样快!

从最近得到的印象来看,我大胆地预言,动态语言在中国的大流行,不会是太远的事情了。首先是在Web开发领域PHP的迅速推广,很快应该会在互联网产业(面向公众的Internet应用)中广泛使用动态语言。这是一大类应用,而且是最活跃、增长最迅速的领域。在这个领域中,动态语言与开源系统结合起来,已经取得了巨大的进展,而且肯定还会取得更大的成功。往下是企业应用,这是主战场,相对来说在这个领域传统力量还是相当强大。动态语言在企业应用领域的道路还很比较长,不过机会仍然很大。在往下是PC软件开发领域,在国外,动态语言正在沁入,不过这个领域基本饱和,不太受关注。国内的软件产品开发,规模小,类型单一,影响力更是可怜,不提也罢。总之,几年之内,动态语言一定会像野火一样蔓延开,势不可挡。

我这个看法不仅仅是对于形式发展的总结,也来自于对软件技术发展趋势的认识。节前在CSDN跟gigix和xjy做过一个视频访谈,就谈了这个问题。我们觉得,广泛采用动态语言是互联网和企业迅速变化的现实所决定的一个趋势。

现在的企业应用跟十年前的MIS可是大不一样了,需求不断变化,修改没完没了。而互联网应用呢?在变化的剧烈和频繁方面,与企业应用相比可谓有过之而无不及。这本质上是因为企业在迅速变化,消费者在迅速变化,人们的需求在迅速变化,世界在迅速变化。现在经验比较丰富的企业开发者越来越达成共识,即事先分析企业应用、对抗需求变更,几乎肯定是死路一条,不管你采用什么先进的软件工程方法、建模工具、UML语言,都无法根本解决问题。你所服务的对象自己都天天在变,你怎么可能实现量好人家的需求然后慢吞吞地去添砖加瓦呢?既然无法避免变化,不如适应变化。与其想办法预见变化,不如让自己有能力迅速随需应变,提高自己对变化的反应能力,降低变化带来的成本。

这已经是共识了,问题在于怎么随需应变。分歧就在这里了。今天做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就像癌细胞一样在程序里扩散,这样的系统只能用恶心来形容。

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

相反,动态语言解决问题的方式是提供相对小而灵活的引擎,强大的语言机制,极其庞大丰富的可复用模块。你基本上在动态语言的范畴之内搭建整个系统,脚本与核心对象浑然一体,解决问题直截了当,无须转弯抹角,无须看似精妙其实无奈的一大堆架构、模式。动态语言一般实现了数据和程序的统一,基本不需要XML,程序易于变化,任何一处均可随时修改。语言的动态性也赋予你模拟领域语言的便利条件。结果便是,适应变化的能力大大增强,变化成本大大降低。很多以前的不可能将成为可能。

所以我觉得,是变化的世界要求我们使用对变化友好的动态语言。这就是结论。

另外,从程序员的角度来说,使用动态语言编程要比使用传统的编译语言,尤其是编译型面向对象语言轻松自如的多,从而也有趣得多。没有那么多条条框框,没有那么多城府沟壑。比如C++/Java/C#都极力反对用异常作为正常情况下程序跳转的工具,所谓“只在异常情况下使用异常”,说来容易,做起来常大费周章。而Python/Ruby都纵容甚至鼓励你使用异常作为正常程序流控制手段。比如Python中for循环的终止,在内部就是通过引发StopIteration异常实现的。能随意用异常作为流程控制手段,真是能省下不少脑细胞。比如我们平常津津乐道的不少设计模式,在动态语言里根本就是多此一举,一切来得直截了当,根本不用如此拐弯抹角。再比如Ruby可以在一个class被定义并且在系统中已经被应用的情况下,在系统运行时随意修改这个类的定义,Python中只要略施小计也可以做到,这在传统OOP语言中根本不可能。而Ruby在其招牌项目Rails中表现出来的declarative language的能力,也是令人惊羡的。使用这些动态语言,要先解放思想,之后就会有挣脱束缚,放开手脚的感觉。对于程序员来说,这当然是很惬意的

相关文章推荐

C#的动态语言运行时DLR

一、关于dynamic关键字 1、dynamic该类型的作用是绕过编译时类型检查, 改为在运行时解析这些操作,即对象到底属于什么类型是在运行时才确定的,而在编译时并没有确定 2、dynamic类型...

微软在动态语言支持上超越了Java?

当.net在2000/2001年第一次发布的时候,java社区认为它仅仅是从语言以及标准库上对java的一个“克隆”。我们把二者的简单实例代码进行比较以后就可以很轻易地得出这样一个感受。不过,微软从它...

2017-01-09 笔记 OC动态语言特性以及与C的对比 上

OC动态语言特性以及僵尸调试模式原理 OC的消息转发流程 1:在C++中调用一个对象不具有的方法将导致崩溃,但在OC中却并不一定。如果向一OC对象发送其不能响应的消息,则会触发OC的消息转发流程:...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)