大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
现在谈论C++与Java的遗产是否有些为时过早？
作者 Abel Avram 译者 张龙 发布于 2009年4月3日
最近Bruce Eckel关于C++与Java遗产的博文引发了激烈的争论。在谈到了一些设计失误之后，他总结到：这两种语言对编程语言的发展都起到了非常重要的作用，同时也留下了宝贵的遗产。但此时来谈论这两种语言的遗产是否有些为时过早呢？
Eckel曾是C++标准委员会的成员，他回忆了当初C++采取对C语言向后兼容的决定：
要想明白为何C++那么难用、那么复杂及其设计中好的一面，你必须要清楚C++的设计原则：与C语言兼容。Stroustrup决定（看起来也是正确的）将众多的C程序员转向对象之路的过程透明化：可以不改变已有的C代码就能在C++下编译通过。
C++吸引了大量的C开发者并使其转向了C++，尽管在这方面取得了巨大的成功，但这种兼容的决策对语言的发展产生了严重的负面影响：
与C语言兼容会导致很大的局限性，但这也是C++最强大的地方，同时也是最让人诟病之处。该决策促使了C++的成功，同时也导致了其异常复杂。
他提到C++中的操作符重载很难用：
他们（对C++理解不深的那些家伙）认为程序员很难恰当地使用操作符重载，事实也基本如此，因为C++既有栈存储，也有堆存储，你需要重载操作符以处理所有情况且要保证不会导致内存泄漏。确实有些难啊。
毫无疑问，这么说肯定会引起争论。Archilleas Margaritis认为兼容C语言并没有什么问题：
我认为C++并没有因为兼容C而导致糟糕的设计。ADA也兼容于C，但却是非常棒的语言，其设计来源于久经考验的工程学实践。
对于C++来说，与C源码级的兼容才是问题的根源。C++保留了C的预处理系统来包含C headers，这导致了别扭的失去了上下文关系的自由语法，而这么做的目的只是为了与C兼容，实在是得不偿失啊。
Michele Costabirle认为从一开始就缺少标准的程序库是C++的一个败笔：
我觉得C++的一个严重问题就是缺少标准的程序库。
如果记得没错的话，Stroustroup在“C++的设计与演化”一书中说到他应该写一个标准程序库来支持多继承，我等无福消受啊。
关于C++有很多东西值得探讨，但确定的一点是：C++助力程序员在编程之梯上迈上了一个新台阶。
接下来Eckel又以同样的基调谈到了另一种编程语言：Java，他也揪出了Java的一些设计错误：
多年来，Java团队一直对“操作符重载太复杂”这个论调深信不疑。这一点以及其它很多决定导致我们在开发中困难重重，鉴于此，我对Gosling及其率领的Java团队的很多决定都嗤之以鼻...
他们说：“为了效率必须引入原生数据类型”。而我认为正确的做法应该是坚持“万物皆对象”这一理念，同时在需要考虑效率问题时提供“后门”来进行低层次的操作（这也需要考虑使用hotspot技术来透明地提高效率，最后的结果也是这样——引入了该技术）。最后我们发现无法使用浮点处理器直接计算超函数（结果使用软件实现了）...
我曾批评过泛型那糟糕的设计，结果得到的回复也一样：“我们需要对Java之前的决定（非常差劲的决定）保持向后兼容”。最后随着越来越多的人掌握了泛型编程的技巧，他们才发现泛型确实很难用。
Bill Venners所回忆的却与此不同：
我不知道你是怎么得到下面这个结论的：放弃操作符重载仅仅是因为它太复杂了。我记得在采访Gosling时曾问过他为何放弃操作符重载（我想该问题和答案还尚未公开过）。他的回答与其他场合下的说法也是如出一辙：Gosling看到在其他语言中操作符重载被大量滥用（我不知道这是否专指C++，但肯定包括C++），这已经超过了它能带给我们的好处。就是这些，这是主观上的设计决策。
James Watson对Java故意采取的那些限制表示支持：
Java值得称道之处就在于容易模仿。用任何语言你都能编写出难以维护的代码，但Java则不然。它没有像其他语言那样提供那么多容易滥用的特性。
从个人角度来看，这很可怕。如果我不想使用某个特性，那不用就好了。Sun提的那些建议与我何干？但如果你处在团队当中，每个人都有不同的想法，那情形就大不一样了。用有限的方法完成任务就很有意义了。
Noel Grandin也来劲了，他甚至还提到了其他语言，这让争论达到了白热化的程度：
大多数其它的“热门”语言，像Ruby、Scala等都没有随大流，因为他们更偏重于编写代码，而不是阅读代码。
Java完美的平衡了这一点——看起来Java很乏味且缺少“酷酷”的特性，但我们却能够轻松领会代码的意图。
最后，Eckel谈到了Java遗产：
Java将主流程序员带到了垃圾回收、虚拟机和一致的错误处理模型的世界中（特别是在你去掉checked异常时更是如此，这可以通过我在Thinking in Java第四版中提到的技术实现）。尽管它有很多缺陷，但却让我们提升了一个层次，将我们带到了更高层的语言中来。
最积极的因素就是为未来语言做好准备了：
C++曾经是最主要的语言，人们认为这会一直持续下去。很多人对Java也持有相同的观点，但实际上Java更容易被超越，原因在于JVM。现在我们是可以创建一门新的语言并且其效率也可以达到Java的水平...
这种情况正在上演——既有高层的静态语言如Scala，也有动态语言，包括新创建的和移植过来的，如Groovy、JRuby及Jython...
无心插柳柳成荫，即便Java本身已经走到头且不会再发展了，那它也为后继者铺平了道路。未来所有的语言都会了解到：要么创建一种可被模仿的文化（就像Python和Ruby那样），要么给竞争者创造成长的空间。
在出现之际Java就引起了很多争论，尤其是在C++与新的Java开发者之间的争论。从那以后，争吵声逐渐平息下来，我们也得以更清楚地看到自己所处的位置以及这两种语言的为我们所留下的遗产。或许现在谈论遗产问题有些为时过早？听起来好像他们已死或正在垂死挣扎（我们期盼你的意见）。
查看英文原文：Is It Premature to Talk About C++ and Java’s Legacy?
译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。
没有回复
关注此讨论 回复