动态语言，也叫动态编程语言：是指程序在运行时可以改变其结构：新的函数可以被引进，已有的函数可以被删除等在结构上的变化。比如众所周知的ECMAScript
(JavaScript)便是一个动态语言。除此之外如Ruby、Python等也都属于动态语言，而C、C++等语言则不属于动态语言。
这里需要澄清一下。很多人以为脚本语言就是动态语言。其实两者是不一样的——虽然两者有很大的交集。比如C#在4.0之后，就可以算是动态语言了，但它不能算是脚
本语言；另外，有很多Shell脚本语言，不能算是动态语言。
以下转自：http://www.eb163.com/blog/blog.php?blogid=27 说说动态语言 很不错的一篇文章
未来属于动态语言
五一长假之前，我跟好几个开发一线的朋友聊技术的发展，突出的一个感觉是大家都在关注动态语言。有的是使用多年，眼见发展态势不错，大有为自己的先见之明扬
眉吐气之感，有的则是刚刚使用，仍处在兴奋不已的状态之中，当然也有仍然保持观望态度的，不过即使是最“保守”的，也能够对动态语言表现出尊重。这与两三年
前相比，已经是很大的进步。记得两年前我与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的能力，也是令人惊羡的。使用这些动态语言，要先解放思想，之后就会有挣脱束缚，放开手脚的
感觉。对于程序员来说，这当然是很惬意的