编译和解释的组合

    编译和解释两种代码生成方式在计算机程序发展过程中分分合合，各领风骚。在很长一段时间内，由于编译在执行速度上的优势，占据更重要的位置。但随着计算机性能提高，代码的性能适当的降低仍然可以接受，或者处理逻辑比较简单，这时解释这种方式就被大量应用。
    编译方式最典型的就是c语言。c语言写的程序编译后的性能仅略低于汇编，被广泛于各种系统。解释方式很多，但个人感觉最典型可以算是HTML。HTML是标记语言，由浏览器负责解释，虽然不是严格意义的解释语言，但具备完整的解释语言的特征。而javascript就是一个解释语言集。解释在执行性能上要弱上很多，但在编程方便性或者使用方便性上，都有很大的优势。解释语言多数源码都是可见的，比如javascript，以文本方式存在，很容易修改，并且不需要编译，修改后可以直接执行。
    不论什么样的编译或者解释语言，性能、方便是选择上的2个重要考量。但两者之间界面已经在悄悄地模糊了。从java开始，就是编译和解释的一种组合体。 java源码被编译成一种机器码，这种机器码是虚拟机的机器码，但不能完全地在实体机器上运行，而只能在虚拟机上解释运行。机器码通过虚拟机，实现跨平台地目的。源码编译，机器码解释执行，将两者结合使用。
     另外一种方式，如TCL，将C语言以库的方式提供给TCL语言。TCL以脚本方式编写源码，通过解释器来执行TCL源码，但是，当遇到需要调用外部接口时，就调用C编写的库来实现功能。SHELL也是以这种方式。利用C的高性能，结合脚本的方便性达到性能和方便的平衡和统一。
    还有一种方式，是将解释嵌入到编译中，如LUA。LUA脚本是解释执行的，用来编写很多业务逻辑。业务逻辑的可变性，对很多系统来说是很头疼的，但解释性的脚本处理这类逻辑相对于编译性来说要适合地多。LUA通过一种嵌入性解释执行器嵌入到c语言中。在c语言中调用Lua脚本。
    不管使用那种方式，都有他的优点和适用领域。但编译和解释的融合已经越成为一种趋势。编译和解释的最佳组合方式，就是通过虚拟机作为中介来完成的，java如此、tcl、Lua都是这样。甚至其他动态语言也是如此。
    但是，个人认为，两者的结合应该把握一个度。不应该追求极端的性能或者极端的方面。以java为例子，通过java实现的tomcat的性能要远低于 apache，有人认为可以将tomcat做apache一个模块来实现。这个方案反而证明了我的观点，在度上面的把握方式。
    将易变的业务逻辑以解释方式实现，便于修改。牺牲部分性能是可以接受。但大部分功能模块都是相对比较固定的，以编译方式更为合理。我更倾向于Lua的那种方式，在c语言中嵌入Lua，那么大多数执行代码是在C中编译执行的，而Lua脚本通过嵌入式的虚拟机来执行。而Lua中的函数又可以以C的方式来完成，比如strstr来查找子串。
   这种情况应该比较广泛，但也不完全，仍然有许多项目代码要求简单、快捷、方便，所以解释性代码仍然有他最佳的应用领域。