Linus说...
时间：2010-06-14 来源：delectate
Linux内核的创始人Linus Torvalds最 近在一封邮件中说明了内核开发需要使用C语言而非C++的理由。
Name: Linus Torvalds ([email protected]) 6/8/10
>
>效率对于内核的开发是个至关重要的问题。
>大部分志愿者为内核贡献代码，所以在相
>同条件下，使用更高效的语言能让你的工
>作效率提升，从而更快更出色的完成开发。
事实上，你错了
志愿者贡献的代码很优秀，而且他们似乎没有觉得语言的效率是个障碍。如果改换语言真的能提高效率，那么这将是使大众受益的事情——不仅仅是经济方面 的。一行行的写代码，而不和用户交流，即使使用再有效率的语言都是无用的，很多大型项目都有这个问题的。
内核方面，我们有大约1000个志愿者者为每一个内核的释出做着贡献（3个月前统计的结果）。现在有更多的人加入，但是我更为担心的不是代码，而是 编码方面的持续性和linux内核的发展方向。现在，我已不写代码很多年。我目前主管志愿者的代码是否进入内核，如果代码可以进入内核，我就说ok，进去 吧；如果不能，我就说No——当然这种情况比较少。
如果想做好一个产品，最重要的就是要与客户进行交流。内核的编写也是如此，缺乏交流是整个项目的瓶颈……避免交流缺失最好的办法就是拥有共同的 “culture”（信仰吧……），或者拥有共同的默契感（原文：潜规则，汗之～）。我们有很多文档指导人们如何去做以及怎样去做，但是在不同文化背景的 人们面前，这些文档是那么苍白无力……
（有很多书在介绍文化，你甚至可以在大学取得一个相关的PhD学位，然后穷极一生去学习，但是，但是你却从来没有深入了解过自己……）
c语言呢，也有自己的“文化”（Unix也是如此——让我想起了KISS）。一个语言，就应该简单而明确，而不是复杂冗余。c++有一个绝对让我不 爽的“特性”—— context-dependent，这只是意味着， 当你阅读代码时，本地视图（local view）却不能给你任何帮助。
这，在交流上可是个大问题……在庞大的项目中，人们对不是自己开发的模块并不了解，能快速理解其他模块中函数的确切含义才能提高开发效率，而C++ 引入的各种抽象则使代码变得晦涩难读。
如果你想提交代码（或者补丁），是不是感觉 “sctp_connect()” 比 “connect()” 简洁而且明了呢？（匈牙利命名？） ，剩下的交给编译器吧，编译器能知道你写的是sctp协议模块的，并完成一切。
项目开发中，我们尽量使用补丁和分支，邮件列表等形式，而不是对源码进行整体修改，这是因为唯一重要的在于改变，而不是结果。所以，这也是我们避免 歧义和代码关联性（context）的根本原因。——尤其是在内核项目上，绝对不能有半点马虎。绝大多数软件工程上都是如此，其实在日常交往中也应该如 此：说话含糊不正常的得不到好处。
因此，一个语言应该简单而明确。你不必顾虑过多，也不用学习冗长的语法和你不需要的东西。如果每个人都是项目专家，那么隐含方式调用函数 （implicit context）是个不错的主意——这就是为什么真正深奥的科学文献，基本上都是晦涩难懂的，除非你是一个专家，拥有大量的背景知识以及要素，才能有所了 解。但是如果是一个多人参与的大型项目，呃，这几乎是不可能的。
例如，我非常了解 VM 部分的代码，但我仍然需要读取各文件系统和网络的代码。即使像我这样了解的人，仍然把代码写的简明扼要，绝不会有任何“隐藏代码”。c就是这样一个语言， 读代码，就能知道它的作用。一个函数用来做一件事，而这个函数也只作这一件事情，不会再出现一些“微妙的问题”——这是“哪个版本的一个函数调用”。
这也就是为什么我认为c语言“简约而不简单”——尤其是对于一个os的内核来说，尤为重要；在特定的编程或系统亦是如此。这也是为什么我不认为在所 有项目中c都适合的原因。
不过，c++……我真得不认为它有什么出色的地方。垃圾回收和并发等等，这些才是真正重要的特性。可是c++……完全落在了c后边……
linus
（业余翻译，不当之处恳请指出，谢谢！）
原文： http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&threadid=110549&roomid=2
译 者：delectate
相关阅读 更多 +
