标签：优势 机制 cms 文件 开发效率 游戏编程 虚拟 异常处理 相对
脚本语言区别于系统语言
http://it.taocms.org/08/4736.htm
“后者则在附加的抽象机器层运行，屏蔽了对计算机系统的直接掌控特性，正因此也造成执行效率相对低下”
脚本语言更接近于人，屏蔽了对计算机系统的直接掌控，要解释效率低下。理论上基本都是基于图灵机或者其等价的模型，所以脚本语言能办到的事情，系统语言肯定能办到，相反，系统语言能办到的事情，脚本语言就算能勉强完成，其执行效率也可谓相差甚远。比如操作系统、编译系统之类的软件，基本上只会选择系统语言作为开发工具。
系统语言与脚本语言各有优势，扬长避短，求同存异才是我们应有的态度。游戏编程完美融合了文学、绘画和音乐等多种艺术形式，并且技术层面的应用也是恰到好处。从游戏编程中，至少可以学到一点：区分主应用程序（游戏引擎）与模块应用程序（游戏内容）。也就是说用系统语言开发变化不大的核心逻辑模块，而使用脚本语言开发经常变化的一些乱七八糟的模块，最终集成二者，或者说是将脚本嵌入应用主程序。
但是这并不是什么新奇玩意儿，因为我们可以使用动态链接库链接模块，随便安装个大中型软件，看见一堆的dll很正常吧。他们就是一些系统语言程序段，被编译成本地的机器码，在主程序链接时装载。其执行效率和主程序是一样的，并且能够达到上述模块化的目的，这不是我们梦寐以求的银弹吗？
那么，为什么硬在系统语言编程中嵌入脚本？
对于软件公司的开发，软件的执行效率远不如开发效率重要，免去了繁杂的特性自然可以更加轻松地编程，甚至让压根没学过编程的人都可以快速部署开发，随时增加人手，而不会扰乱整个项目。所以越多采用脚本语言，越能让财源滚滚来，何乐而不为？
许多应用软件的功能和需求会随着项目的进展时刻发生变化，这可以说是项目开发的常态（比如，我今天想要看所有的特定的文件系统下的inode，我明天可能就要看目前系统下的所有的inode了，后天我可能还有什么需求这都是没准儿的事情）。虽然开发前会认真商量，多番询问，对需求弄得清清楚楚。不过计划赶不上变化，实际软件开发过程中不得不经常修改已经完成模块中的许多东西。
如果直接硬编码，在主程序中写死这些东西，即时是微不足道的一个修改也不得不完全重新编译整个工程。这在项目非常小时还可以接受；若是源文件就有几十上百兆，那就麻烦了，如果机子性能受限，还可能死机，一起付之东流。即使采用链接库，仍然需要重新编译那个模块，然后重新链接加载，这也是很麻烦的。
减小与主程序的耦合度：人非圣贤，使用系统语言开发犯错是常事儿，往往这些错误很隐晦，如果某个模块经常被更改，犯错的概率更大。使用动态链接库，耦合度在运行时并没有显著降低，而是链接成一个整体；但是脚本语言在解释器或者虚拟机中，隔离了真实的机器，并且往往都有异常处理机制，能够比较容易地捕捉到脚本执行的异常情况，并做出相应的处理，是软件运行不会因为一些小Bug而即刻崩溃。
阻碍用户做逆向工程：系统语言直接编译链接成可执行文件在本机上运行，就一定能够得知其运行逻辑，没有什么软件不能破解的，但是脚本语言往往被编译成自己码，而且还经过特殊地编码，至少没有现成的反汇编工具可以使用
标签：优势 机制 cms 文件 开发效率 游戏编程 虚拟 异常处理 相对
原文地址：http://www.cnblogs.com/honpey/p/6506472.html
