编译型语言与解释型语言有何区别( 二 ) _语言

操作系统和编译器是紧密相连的，不同操作系统所提供的编译环境不同。Linux和GCC编译器密不可分，Windows有自家研发的MSVC（Microsoft Visual C++）。不同操作系统在管理网络、读写硬盘、图形化等具体的实现方式不同，库函数连接方式不同…可执行文件一般需要调用这些操作系统接口，所以最终连接生成的可执行文件会截然不同。了解了编译知识，就不难明白为什么很多软件提供商对同一个软件会提供Windows、Mac OS、Linux、iOS、Android等多个版本的下载。因为不同平台的硬件、编译器和操作系统存在着巨大差异，可执行文件完全不同。所以，也就不难理解Windows软件为什么不可能在Mac OS上运行。
实际构建一个大型项目时，编译要考虑的问题会更多。比如我自己编写了多个文件，文件1会被文件2调用，所以要先编译文件1，后编译文件2，否则会因为顺序颠倒而报错；还比如编译型语言对所以依赖的库函数非常挑剔，如果版本过低，有可能出现编译错误。类似的问题会很多，因此编译型语言在编程和调试时更麻烦，实际操作中一般会使用构建工具链（toolchain），根据一定的顺序，从前到后串起来地去编译。
解释型语言：Java、Python、R…
既然可以将01组成的机器语言抽象成容易编写的C语言，那为什么不能继续再用类似的办法，再做一次包装呢？IT圈的一句名言就是：计算机科学任何领域的问题都可以通过增加一个中间层来解决。一些大牛忍受不了C语言这样编写和调试太慢，系统平台之间无法共享移植的问题，于是开始自立门户，创建了新的编程语言，最有名的要数Java和Python，这类语言不需要每次都编译，因此被称为解释型语言。matlab、R、Javascript也是解释语言。

解释型语言一般是使用C语言等偏底层的语言做一个或者，编程人员需要先在自己的计算机上安装这个解释器，接下来就只用关心自己的源代码，其他的事情都交给解释器去做。如果把编译型语言的编译过程比作将源代码“翻译”成机器语言的话，那么解释型语言就是同声传译。编译型语言是一篇提前就“翻译”好的稿子，拿过来就能被读出来，这样肯定更快；解释型语言要等翻译边“听”边“翻译”，速度当然慢很多。

不同编程语言的性能测试 - ***/benchmarks/
C语言和相应编译器经过了几十年的发展，在性能优化上已经达到了极致，一般是所有高级语言中速度最快的。上图展示了一个对不同编程语言在不同任务上的测试，数据以C语言为基准，可以看到Python、R等语言在部分任务上要比C语言慢10倍到100倍。Julia语言是解释语言中的“奇葩”，它刚刚诞生没几年，语言的设计上使用了更多新技术，属于长江后浪推前浪了。
有了解释器，我们可以在任何安装了Python的机器上运行同样一份源代码文件。像Python这样的解释语言就像一个高级计算器，非常容易上手，有一些理工基础的朋友，半天时间就能学会。
其实，这就是一个妥协的过程，解释语言放弃了速度，取得了易用性和可移植性。
【编译型语言与解释型语言有何区别】如果我还是关心速度呢？当然还是要回归底层，拒绝中间商赚差价嘛！
以Python为例，为了保证性能，大部分高性能科学计算库其实都是使用编译型语言编写的。比如，感兴趣的朋友可以前往numpy的源码地址（***/numpy/numpy）查看，会发现很多C语言编写的代码。对于一些计算密集型的函数和方法，Python用户自己可以使用这样的工具，R语言可以使用。我最近在使用Java的jni来调用C++代码，发现速度有成倍提升。