标签：
本文内容摘自http://blog.csdn.net/turingbook/article/details/1775488
C++是一种糟糕的（horrible）语言。而且因为有大量不够标准的程序员在使用而使情况更糟，以至于极容易产生彻头彻尾的垃圾（total and utter crap）。老实说，选择C就是为了把C++程序员踢出去。……我有这样的结论，任何喜欢用C++而不是C开发项目的程序员可能都是我希望踢出去的人，免得他们来搞乱我参与的项目。C++会导致非常非常糟糕的设计选择。你们这些C++程序员总是一上来就用语言的那些"漂亮的"库特性比如STL、Boost和其他彻头彻尾的垃圾，这可能对你们的程序有所"帮助"，但是却会导致：
——当库无法工作时无穷无尽的折磨（别跟我说什么STL尤其是Boost很稳定而且可移植性很好，那全是屁话，而且一点都不可笑）
——低效的抽象编程模型，可能在两年之后你会注意到有些抽象效果不怎么样，但是所有代码已经依赖于围绕它设计的‘漂亮’对象模型了，如果不重写应用程序，就无法改正。
也就是说，使用优秀的、高效的、系统级的和可移植的C++的唯一方式，最终还是限于使用C本身具有的所有特性。项目限制只用C，意味着参与的人不会捣乱，也意味着会得到许多真正懂得底层问题，而不会折腾那些白痴"对象模型"垃圾的程序员。
所以，我很抱歉，但是对于Git这样效率是主要目标的软件，C++的所谓优点只是巨大的错误。而我们将看不到这一点的人排除在外却成了一个巨大的附加优势。
如果你想要用C++写的版本控制系统，去玩Monotone吧。他们确实使用了"真格的数据库"，使用了"漂亮的面向对象库"、使用了"漂亮的C++抽象"。可是说老实话，所有这些对某些计算机专业人士而言富于吸引力的设计决定，其最终结果确是一堆可怕、难以维护的垃圾。
事实上，Git比其他软件配置管理软件都要好，而好的品味（taste）和C正是原因之一。说得更具体一些：
——简单和清晰的核心数据结构， 非常精益（lean）且颇具雄心的代码管理着它们，将”简单胜于花哨”这一方法发挥到极致。
——有意识地不抽象数据结构和算法，因为它们恰恰是Git核心的全部要素（whole point）。
如果你想用更花哨的语言，C++绝对是最糟糕的选择。如果想要真正的高级特性，那就选择有垃圾回收或者好的系统集成的，而不是既缺乏C的简约（sparseness）又缺乏C的直接而且没有重要概念的高层 绑定（high-level bindings to important concepts）的东西。
一言以蔽之，C++正处在困境当中，它既无法帮助原型化或者简单的GUI编程足够简化从而真正可用，又 不是C那样积极地鼓励你使用简单和直接的语言构造的精益系统编程语言。
好的品味永远不会过时。将C与汇编语言相提并论，恰恰说明你对自己所讨论的问题缺乏起码的概念（don‘t have a friggin idea）。"
字符串/内存管理根本无关紧要。还是去看看源代码吧（我敢打赌你没有看过）。这不是重要的部分，而且也不复杂。唯一真正重要的部分是设计。有些部分之所以是用 "原型化语言"编写，恰恰是因为它们不是核心部分，而且会被C慢慢地替换掉。C++可没有办法替换shell脚本或者Perl代码。而且C++也没办法让真正核心的部分变得更好。
C在很多方面都远远优于C++（更优于C#），包括可移植性，还有接口和低层支持。
你当然可以用任何语言编写糟糕的代码。但是，有些语言，尤其是带有一些心理（mental）包袱的语言本身就非常糟糕。你这样的新手跑来指出一些绝对无关紧要的补丁特性（此处应该指C++对C的增强特性），用它们作为一种语言优越的论据（这些东西语言原作者都不喜欢），这一事实本身恰恰说明你满脑子都是糊涂概念，应该好好醒悟一下了。
对于Git核心代码真正重要的，是诸如这样的事情：编写自己的对象分配代码，使内存占用尽可能小，从而能够高效地记录百万对象的标志。这实际上是为树形关系的多个对象编写本质上非常优化的分析程序，因为这里没有任何抽象。这绝对是在原始内存字节一级上的。
这些事情能够用C之外的语言编写吗？当然可以。但是那些认为C++字符串处理这样的高级特性很重要的人肯定是写不出来的。
事实上，这正是C擅长的事情。不仅指语言本身，还包括一种必需的心态（mentality）。C最大的优点之一，就是它不会使你认为程序是什么高层的东西。正是后一种心态会使你明显偏向其他语言，但实际上从Git的角度看来，所谓“高层”恰恰是错误的。
标签：
原文地址：http://www.cnblogs.com/rudeway/p/5694521.html
