在文章的前面，先定义一下，这里谈的“语言”（A）指的是“语言以及使用该语言可以很容易调用的基本类库及可免费或低代价获得的第三方类库及开源类库”（B）。在很多情况下谈“语言”和谈“语言”的选择时的语境，都是指的B。
选择多语言混合开发的一个目的是为了使用其中某个语言的某个类库或重要特性。比如，在OpenCV中，计算量不大的部分使用了很多的C++的STL中的数据结构和算法，而不是自己用C去实现一份。
我最近在研究Sift算子。一份C#写的Sift代码处理一张600×600的图像的处理时间大概在一分钟上下，而一份用C写的Sift代码可以秒掉这样的图像，所以我不得不使用C+C#的混合编程：在应用层使用C#，在底层使用C。为了方便的使用C#调用C，又不得不用上C++/CLI。
我最后选择的工作模式是这样的：使用C#进行应用算法开发、原型开发和演示（Winform/Silverlight），使用C/C++进行最终产品开发（使用C#验证过的算法）。原型开发可以在Windows上进行，而最终的代码却不一定在Windows下跑。为了降低从原型到产品的代码翻译的成本，我必须保证原型开发的核心类和产品开发的核心类尽量类似。为此，我又引入了纯C++层，形成了下面的语言层次：
各层的作用：
1、C/C++层以C为主。有3个原因：
（1）可移植性。毕竟C#需要CLR，没CLR的地方，都没法用。
（2）性能和内存可控
（3）绝大部分核心算法都有C/C++版
2、纯C++层。C/C++层的API基本都是C风格的，难用，因此，需要封装成对象。我把底层封装成了一个大对象 SmartImage。用纯C++封装而不用C++/CLI封装是因为纯C++不需要复杂的运行时环境。
3、C++/CLI层。C++相对于C来说，好用多了，但相对于C#来说，则又难用多了。而很多图像处理项目，大部分工作量是算法参数选择、组合和验证，因此，有必要再度封装一下，方便上层调用。C++/CLI和纯C++层几乎是一对一的映射。
4、应用层。通过上面三层的工作，就可以使用优雅的C#来进行日常工作了。我是宅男，怎么演示Demo、演示案例、演示进度呢？一个很好的选择是使用Silverlight，调用C#写的WebService，然后再调用底层。怎样进行日常开发呢，下面是俺用Winform写的一个实验平台：
在几年前，我也是用过一次多语言开发，那次是C++ / TCL 混合开发——底层语言+胶水语言的开发模式。非常多的项目采用的是这种开发模式。游戏界多采用这种开发模式。Matlab也是这样一种模式。
这种开发模式存在两个好处：
（1） 可以综合底层语言的性能和胶水语言的强大生产力，损失小部分性能，来换取强大的生产力和更好的产品质量。
（2） 胶水语言可以隐藏复杂的细节问题，提供更友好的使用方式，从而扩大产品的使用面。
某书第五章所提的多语言开发，它举的例子，大多属于此类，这些例子我个人认为是合适的（那个测试的例子除外，因为我不懂老赵说的AAA，就跳过去没看）。很多情况下，出于综合考虑，人们并不是去扩充类库，而是直接选择其它语言了。
另一种很自然的多语言开发就是Web开发了，前台Html/Js，后台某语言，这种多语言开发太普遍了，以至于我们不把它当作多语言开发了。从这种多语言混合开发的场景可以看出，不同的语言除了语法之外，还有许多更重要的约束条件。比如，安装基础。用C#开发共享软件，一个局限就是目前的安装基础不够。Silverlight的安装基础也不够。Html/Js的安装基础非常大。再比如，运行环境的大小——lua的运行环境所需文件大小要远小于python——对于我这种不会Delphi，讨厌匈牙利命名法，讨厌Windows API，讨厌MFC的人，想要在Windows下开发只有一两兆的软件，lua恰好可用——D不成熟，Python太大。
再一种多语言开发的场景是集成旧系统，这个就不多说了。
多语言开发一般来说就是人们在工程约束的情况下所做的最优选择的结果。这种约束，有语法的约束、有平台和类库的约束、有运行环境大小的约束、有性能的约束、有成本的约束、有人的技能的约束。
每个人、每个公司、每个项目有自身的约束条件。还是以我自己为例子（宅男没别的例子——这也是我的约束条件），我选择多语言的目的有二：
（1） 出于综合成本考虑。比如前面的我的多语言开发的例子；
（2） 出于阅读代码的考虑。世界上有很多知识，有的用C实现了，有的用Python实现了，有的用Java实现了，会多种语言的话，方便掌握这些知识（很多时候，这些知识并没有很好的文档，只有阅读源代码才能最准确的了解它）。
而企业选择多语言的目的，除了技术约束之外，恐怕主要是考虑到成本吧。
Btw. 约束条件是一个非常重要的概念，任何推断都是有约束条件的。某书第五章的约束条件我认为有二：
（1） 语言是广义的语言（我文章第一段的定义B）
（2） 主要读者是大众程序员
在这两个约束条件下，我并不觉得该书第五章写的多差（测试的例子除外，本人无法评价），也不会给一般程序员造成什么严重的误解。至于写的有多好嘛，反正我是从中学不到任何东西的。
×××××××××××××××××××××××××××××××××××××××
关于约束条件，再讲些题外话。很多人认为茅于轼是人民公敌，认为任志强是人民公敌，实际上，如果你认真阅读了茅于轼的主要文章，阅读了任志强的大部分博客，了解了他们观点的“背景”，也即他们观点的“约束条件”，你就不会这样认为了。写这段话的目的是不希望我们成为吃袁崇焕肉的人。
有一篇非常著名的管理学文章《论希望B却奖励A的愚蠢》（《管理与组织行为经典文选》书中有这篇）。这篇文章指出了一个普遍现象：很多情况下，我们希望达到目的B，为了达到这个目的，我们制定了游戏规则，而这个游戏规则运行的最终结果（有意或无意的）却是奖励了与B相违背的行为A。
这种现象有时很复杂。下面是在网上搜到的一个例子：
美国某会想在飞机上为婴儿单开一些婴儿座，以减少飞机失事后这些婴儿的死亡率。但是研究后发现，当开婴儿座后因为票价的上升会导致许多航空公司的乘客转而去坐火车或其他交通工具，而火车和其他交通工具的出事死亡率比飞机乘客要高，计算结果是“当每拯救一个因飞机失事而死亡的婴儿的同时，将有3.5个乘客因换乘其他交通工具而死亡。”
本文转自xiaotie博客园博客，原文链接http://www.cnblogs.com/xiaotie/archive/2009/09/27/1574738.html如需转载请自行联系原作者
xiaotie 集异璧实验室(GEBLAB)
