java代码恐龙买票 java游戏

Java是否真的即将被取代?

对于最近有关 Java 即将退出历史舞台的传言，您可能想知道在这个时候放弃使用 Java 平台并转而使用更新的技术是否时机成熟？在作出您的判断之前，请先回顾并查看一下 Java 生态系统以及它的竞争者，看看这些传闻是否站得住脚。换而言之，了解整个 Java 世界目前的现状，并客观公正地评判这个平台。 在学生时代，我们可能会想起 Thomas Malthus 所做的预言，他认为人类赖以生存并继而形成人类文明的农业体系，可能无法再承受人口数量的不断攀升，另一方面，这种情况将不可避免地造成严重的后果，通常会引起巨大的灾难或其他自然灾害。他这样写道：若对人口数量不加限制，将呈几何比例增长。而人们赖以生存的物质则以算数比例增长。与后者相比较，如果稍微了解一下这些数字，就会意识到人口增长是多么惊人。这意味着，针对生存物质的匮乏，需要对人口增长进行严格而持久的控制。物质匮乏终究会发生在某些地方，并且必定会严重影响到大部分人类。 Thomas Malthus 在 1798 年发表了 “人口论”。从那时开始，我们一直在等待着验证有关人口增长的 “Malthusian 检验”。 编程人员，特别是使用 Java 平台和语言的人员，可能已经注意到，随着使用难度不断增加，人们的种种预测和统计暗示着他们所选择的平台即将没落。而大量候补接任者跃跃欲试：人们提名 .NET、Ruby 甚至是 Python 作为 “下一代重要技术”。 这两种 “Malthusian 学说” 之间存在着惊人的相似之处。 Malthus 认为，由于食物对人类的生存非常重要，而地球的产出有限，并且繁殖所需的生物体系是不会改变的，我们终将达到一个极限，那时地球将无法承受人口负担。换句话说，如果继续以现在这样的方式生存，将注定灭亡的结局。那么在 1798，很难推翻 Malthus 的学说。 同样，在过去十八个月中，Java 社区出现了一种新趋势：即预测 Java 平台的消亡日期。从一些低级的新闻杂志将其称为 90 年代的技术，到夸大其辞的技术演讲者宣传它的现状，再到各种书籍宣称我们正在 “超越” Java 时代，不难发现一点：通过合理的暗示、代码演示、逻辑或统计性说明，Java 正在走向没落。 Malthus 错过了工业革命，而后者引发了翻天覆地的变化。在 Malthus 一生中，他见证了人类农业生产力的巨大飞跃，这要得益于蒸汽机和轧棉机这些发明。这些设备为他的学说提供了重要的 “缺失的联系”，它们使粮食产量成倍增长，从而使农业系统能够战胜制造了大量人口的 “两性激情”。随后，人口控制方面的技术创新对降低人口增长起到了相同的作用，减轻了人口负担，从而造成了很多西方国家出现人口负 增长，因此情况与 Malthus 的相当合理的逻辑完全相悖。而所有这一切在 Malthus 撰写其论文时是无法预见的，使人类能够超过他所预测的农业系统的承受极限而继续存活，并且避免了由此而来的一系列灾难。 而技术批评家所忽略的则是 Java 虚拟机的替代语言的兴起引发了巨大的变化。不过不要轻易相信我的一家之言，让我们逐一查看支持这种说法的论证，看看它们是否站得住脚。 Malthusian 式的 Java 预测 一些人仅仅引用了一些统计性描述，说明 Java 不再是程序员中最重视的语言，就简单的判定 Java 已经在走下坡路。其他人指出 Java 缺乏其替代环境所提供的某些特殊特性，这些特性被标榜为用户及其应用程序的 “需求”。还有一些人发表（毫无事实依据）诸如 “大企业不会再使用 Java” 等言论，从而明确地暗示，如果大企业不使用 Java，那必定是因为这种技术不值得使用。 Java 语言，从更大的程度来讲，Java 平台及其生态系统，很早以前就超过了 Simon Peyton-Jones 所谓的 “生存阈值（The Threshold of Immortality）”，就像 C++、C、COBOL 和其他语言所经历的一样。这些工具几乎可以永远存在下去，这是因为它们将继续提供有用的功能，或者是因为重写代码的尝试可能要比继续按原样使用和维护系统付出更多的代价（有关特定语言或系统究竟属于这两个原因的哪一种，存在很多的争议，而这对于本文的目的则无关紧要）。 另一个论据让所有聪明人都放弃 Java 而转向平台 X 或语言 Y.在 2005 年的一篇 BusinessWeek 文章 “Java？ It's So Nineties”，引用了很久以前就倒闭的应用服务器公司 NetDynamics 的前 CTO Peter Yared 的话，“Java 像恐龙一样古老”。可是，还未来得及搞清楚利益冲突和推理逻辑，这篇文章就写到 Yared 所有的公司正在尝试在 LAMP（Linux？/Apache/MySQL/P-language）栈之上重新创建应用服务器体验。 （指出 Ruby 的构想实际上早于 Java，同样还包括 Perl 和 Python，这样做有些无礼，更不要说 Linux、Apache 和 MySQL……因此这里我就不便再多做解释了）。 引用我喜欢的一部电影，“生活是痛苦的，殿下。持不同观点的人一定有所企图”。或者，为了更恰当地解释这个主题，可以这样说：“过渡到一个新的平台是痛苦的，CTO 先生。持不同观点的人一定有所企图”。也许并不令人惊讶，对于一些已经重新定位到其他技术领域的 Java 专家来说，情况确实如此。 来看看另一个论据，它说 “Java 的顶级语言的位置已经不保，因此它的衰退必定非常悲惨，因此最好避开这场灾难”。这种论据所依据的是一个最基本的前提，即如果 Java 不再是世界上最畅销的技术，则不值得再提供该语言的支持。而这种说法若经过逻辑推理，则根本毫无道理。 统计信息很久以来一直被认为是不可靠的（如果使用不当的话），正如 Benjamin Disraeli 的巧妙解释，他说：“世界上有三种谎言：谎言，诅咒和统计”。统计信息可以用来论证最靠不住脚的论据，只需要根据论据仔细挑选所需的统计信息。注意 BusinessWeek 一文中使用的引用：“调查……显示 Java 的使用逐渐没落，而 LAMP 和 Microsoft？ 的 .NET 技术势头强劲”。喔，听上去情况不妙。但是，请继续读下去，“根据 Evans 的秋季调查显示，在北美使用 Java 作为其首选编程语言的开发人员的比例已下降到 47.9%，而 2002 年秋为 51.4%”。因此，在过去六年中，在使用 Java 作为其首选 编程语言的开发人员中，使用率下降了 3.5 个百分点。 请注意，这里使用了 “首选” 编程语言一词，这意味着开发人员自己需要区别什么是他们的 “首选” 语言。考虑到大量的 XML 配置，使用 Spring/Hibernate/JSP Java 栈的开发人员可能可以很好地判断出 Java 不再是他们的首选语言。 注意过去六年中 Java 平台之上兴起的动态语言（Jython、JRuby、Groovy 甚至是 JavaFX），根据我和我的同事（“No Fluff Just Stuff” 的演讲者）在 NFJS 活动的非正式投票中获得的应用数字，这些动态语言可以很轻松地解释这三个百分点的下降。 考虑同样摘取自同一篇文章的引用：“在另一份调查中，今天秋季，PHP 在北美的采用已经上升到 36.1%，而 2002 年同期为 26%.其增长速率几乎和欧洲和亚洲一样快”。考虑到这是一个不同的调查系列，它只是为了显示 PHP 的增长，而不是 Java 市场的萎缩。祝贺 PHP，但是任何研究过企业环境的开发人员都可以证明，生产软件部署并不像这篇文章的作者力图暗示的那样是一个零和（zero-sum）游戏。大型 IT 环境通常由种类繁多的工具、平台、语言和产品组成。事实上，我们几乎可以在这里实现 整合，特别是那些大型机组件。 谈到主机，事实上，COBOL 在几十年前就不再是最重要的语言了，但是，它现在仍然继续用于现金支付、转移存款、支付信用卡等业务并运行主要的金融网络，尽管很多行业权威早已经宣布了它的 “死亡”。对于本应在坟墓里腐烂的技术，这实在是不错；这使我想起 Mark Twain，当他看到家乡报纸上他的讣告时说：“先生们，关于我死亡的报道被严重夸大了。” 然而，撇开统计数字的问题不谈，第二个问题更严重：为什么仅仅因为所选的工具不是最好的就弃而不用？Java 占据软件开发的首要地位近十年，仅仅由于它 “下降” 到第二位，游戏就结束了？甚至认为仅仅因为人们的惰性就会阻止 Java 重新恢复首要语言的位置，事实是，10 个程序员里面有 4 个会继续使用这种语言，这将保证 Java 在未来几十年里仍然保持活跃的生命力。更荒谬的说法是，Java 的增长将面临急刹车，并且再也不会出现 Java 部署，然而，Java 目前在整个行业内得到了广泛的部署，这可以保证 Java 继续出现相当长的时间。 尽管COBOL 被宣布已经死亡，但是要求使用它的人每年达到 6 至 7 位数。 然而指出一个论点的缺点并不能证明另一个观点，对于本文也是一样的。相反地，我们应该用批评的眼光看待 Java 语言和平台，而其强项和劣势经受住了严格的分析。Java 之所以长寿在于它能满足未来十年的需求，而不是由任何作者或批评家来决定它的生死。 最后，我们考虑一下构成 Java 平台的那些组件： Java 编程语言。坦率地讲，这是平台中最能体现其长寿的部分，特别是与一些诸如 C#、Groovy、(j)Ruby 或 Scala 等更 “现代的” 语言比较时。近来涌现出大量关于改善该语言的建议，诸如为该语言添加闭包等极具竞争力的提议，证明了程序员非常渴望 Java 能够具备其他语言的一些特性。然而，Java 5 中最新语言增强功能所带来的联合成功应该成为所有新的重大语言变更的“注意刹车”的提示。某些增强，比如 for 循环或注释，得到（相对）普遍的支持。然而其他一些增强，比如泛型，则受到（相对）普遍的嘲笑和批评。事实是没有任何一种语言功能能得到它本应帮助的开发人员社区的普遍接受，这个事实告诉我们：为一个已存在十年多的语言添加新的语言特性是很棘手的事情，如果完成，也很可能会导致语言自身的崩溃。在 Java 平台的地图中，这个区域标注着“老水手”的警告：“此处有怪物！” 非Java JVM 编程语言。在Java 止步不前的地方，其他语言提供改进和增强的解决方法。Groovy 围绕 Java 对象提供了一个动态、客观的脚本解决方案。(j)Ruby 在 JVM 之上提供 Ruby 实现，为 Java 程序员开辟了 Rails 和 ActiveRecordoffers 的世界。Scala 和 Jaskell 给 JVM 引入了功能概念，为所出现的并发性问题提供可行的解决方案。诸如此类。由于所有这些语言要么编译成字节码，要么通过 javax.script API 作为解释语言在 JVM 上运行，因此 Java 生态系统的所有财富都是可以利用的— 而这是 Ruby 开发人员无法做出同等声明的一个方面。在 Java 平台的地图中，这个区域被标注为“机遇之国”。 Java 虚拟机。 幸运的是，Java 语言已经做出了重大修订和根本性的变化，而 JVM 作为 Java 平台的底层基础，变化并不多。近来，在博客世界中，许多人建议使 JVM 对动态语言更友好，这使 Sun 公司的一名工程师（John Rose）提供了 JVM 的修订版，最初称为多语言虚拟机（ Multi-language virtual machine，MLVM）, 现改名为 Da Vinci Machine（因为紧密地包装在代码中）。此处的关键在于被提议的 JVM 更改要避免任何有可能使 Sun 公司在 JVM 优化上的庞大投资作废的事件。那些提出建议的人在设计细节时一直将这一点牢记于心。 Java Standard Edition 库。 Java Standard Edition 附带了巨大的函数集，数量级比 C++ 标准库更大，甚至许多因素比它前身 Java 1.0 都大，并且这还没有考虑 Enterprise Edition 库（接下来讨论）。表面上，这看起来像 Java 开发人员的自然优势，但仔细考虑就会发现一些细微的问题。对初学者而言，库的庞大意味着许多 Java 开发人员认识不到他们在写一些实际已经存在的代码，这些代码收藏在一个在此之前未知的包中。根据存在时间的不同，库本身有时也会遇到 API 设计时间的烦恼，其中有许多 都源于 90 年代中期，那个时候开发人员设计类和库的方式与 2008 年的设计方法截然不同。一部分开发人员也深受抽象过多之苦，正如创建对象构建者的工厂所例证的一样，这些对象构建者创建的接口实例不一定能实现开发人员感兴趣的方法。然而，虽然 JSE 库有缺陷，但从整体来说 JSE 依然有优势，尤其是当它与像 Groovy 提供给 JDK 的扩展（称为 GDK）这样的语言支持增强结合时。 Java Enterprise Edition 库。 没有任何技术能够比 EJB 对其社区产生更大的冲击，并且幸运的是，Java 社区看到了轻量级替代方案的兴起，Spring 和 Hibernate 提供了最后的例证，对这些场景来说，轻量级替代方案是理想选择。然而，如果暂时不考虑 EJB，Java EE 库就是非常成功的 — servlets 和 servlet 容器为遍及 Internet 和企业内部网的大量 Web 应用程序提供动力，JMS 提供对多种面向消息中间件系统的访问，JEE 领域中其他不太知名的参与者（如 JNDI） 毫无怨言地执行自己相应的任务。JEE 库很有可能受益于 API 重新设计，JSE 库就是这样，总体来说 JEE 库将满足 Java 程序员的需要。最大的问题往往在于认识何时首先需要 JEE 库。我们将在另一篇文章中讨论相关内容。 Java-API-for-XML (JAX) 库。 尽管名义上是 JEE 库的一部分，但 JAX API 的数量和规模都在以与 JEE 其他部分不相称的速率增长，值得脱离 JEE 的上下文来考虑 JAX API。在近十年，尽管对 XML 支持的需求是巨大并且普遍的，但目前已经有所缓解，尤其是 Web services (WS-*) 周边领域和规范阵营（这些规范允许与其他技术之间实现普遍、轻松的互操作，包括 .NET）。在这里，Java 无疑需要某种类型的修订，由于 SAX、DOM 和 StAX API 经常需要更多的代码来完成重要任务，尤其是和具有更灵活的 XML 支持的语言相比时，比如 E4X、Ruby 或 Scala。此处，以 XML 为中心的思想有了明显的改变，从早期的 WS-* 实现中“不接触 XML”到基于 RESTful 方法的“我希望直接接触 XML 并将其定址为形式良好、有意义的 URI”，这种方法也强调了 JAX 领域内重构的必要性。在 Java 世界的地图中，这个区域被标注为“（应该）弃用的” 客户端 Java。Sun 公司最近修订的“Java客户端”系统的测试版有个相当糟糕的名字 “Java SE 6 Update 10 Beta”，它提供了增强的客户端特性，包括新的 Swing 外观，称为 Nimbus。遗憾的是，在客户端度量 Java 的使用一直都存在问题，主要是因为专门用于度量的 applet 在 Internet 上已经使用了很长一段时间，还因为众多对 Web 托管应用程序的设计和架构关注点都以 HTML 的生成为中心，而不是生成现在所说的“富客户端”应用程序。随着采用速率的提高，Java 要经过漫长的旅程，追赶它在这个领域中的主要竞争对手，Flash 和微软在该领域新引入的技术 Silverlight 使情况变得更加复杂。Java 可能也会彻底失去阵地，这并不代表着这种平台的“消亡”，但会使问题恶化，当业内学者和商业杂志将其称为“Java 技术弱点的明显例证”时，一定要鼓舞自己！ 服务器端 Java。 这实在不容争议：Java 毫无疑问是服务器领域内既定的参与者，特别是在查看非 Windows? 后端场的选项时。LAMP 系列产品可能提供一个前端或垂直筒仓替代方案，正如 Ruby on Rails 所做的一样，但观察重要的服务器计算基础设施时，Java 系列产品的形象十分突出。事实上，正是这种领先地位促使微软最先积极地寻求 WS-* 规范，以使 .NET 代码至少能调用和配合既定的 Java 基础设施。微软最近认可了使互操作性向更正式的水平发展，他们在剑桥大学设立的“Interoperability Lab”也体现了这一点。 生态系统。 没有其他的平台拥有像 Java 平台一样如此丰富多样的生态系统，然而这经常会给 Java 开发人员带来一些麻烦（“我该使用哪种 Web 框架？”），事实上，很多 Java 生态系统都渗入其他环境，尤其是.NET。考虑 .NET 近来在微软内外获得的进步：ObjectBuilder（依赖性注入框架）、ASP MVC（基于 MVC 的 Web 框架）、NHibernate（Hibernate 的一部分）、NAnt 和 MSBuild（在句法或概念上与 Ant 相似的基于 XML 的构建系统）甚至 Silverlight 本身（在浏览器内部托管 CLR，允许执行更丰富的客户端）。在许多方面，.NET 生态系统为 Java 社区做了将近五年的后盾，因为 .NET 开发人员发现了与 Java 开发人员在五年前遭遇的相同痛点。而 Java 仍然坚持向 .NET 社区学习（比如统一通信 API 的有用性或显式轻量级工作流引擎的强大力量）。这只用来说明这些环境都正在互相学习这一事实，而且也表明，.NET 并没有使 Java 成为不必要的能力。 毫无疑问，Java 开发人员可以将他们自己的条目添加到这个列表中，证明这个论点：在 Java 平台中留有太多的优良的东西被认为“消亡了”或“将要消亡”或者甚至在“崩溃的边缘”。 王者终将归来 最简单的事实是：Java、平台、生态系统、环境和开发社区与消亡相去甚远，至少和目前正在使用的其他语言或平台距离一样远。即使是最严格的统计事实筛选也不能否认 Java 的领先地位。 此外，即使 Sun Microsystems 公司倒闭，平台也不会消亡。全世界的 Java 的开发人员，联合起来！不要惧怕束缚的铁链：最终您将看到，这些铁链其实并不存在。多亏 Java 平台的开源，它现在被称为 OpenJDK，更不要说 Java 的其他开源“净室”实现（Apache Harmony 和 Soy Latte 只是其中之二），即使 Sun 公司彻底从地球上消失，包括 IBM?、Apache、BEA 和 Oracle 在内的其他实体也能继续提供 JVM、库和工具，来支持整体生态系统。 Java 总有一天会消亡？它甚至能比刚刚走出大学校园的第二代 Java 程序员走的更长 育路网

相关问答

Q1: 用java开发的大型游戏有哪些

Java开发java代码恐龙买票的大型游戏有：俄罗斯方块、超级泡泡龙、贪吃蛇、钻石情迷、祖玛等。学习Java开发推荐千锋教育，教育培训业务分为大学生技能培训和职后技能培训java代码恐龙买票；高校服务业务主要提供校企合作全解决方案与定制服务java代码恐龙买票；企业服务业务主要为企业提供专业化综合服务，值得信赖。

用java开发的大型游戏有以下几个：

1、俄罗斯方块(Tetris)

经典的益智游戏，几乎是世界上最有影响力的益智游戏之一，游戏本身也很简单，只要不断消减掉落的方块就可以了。这个游戏被模仿了很多个版本，java代码恐龙买票我这里的是EA出的疯狂俄罗斯方块(Tetris Mania)。

2、超级泡泡龙(Super Bubble Bobble)

Taito公司开发的游戏，主角是两只绿色和蓝色的小恐龙，通过吐出泡泡来消减屏幕上的彩球，游戏本身简单易学、妙趣横生，女孩子玩起来会上瘾的。

3、贪吃蛇(Retro Snaker)

诺基亚手机上的一个元老级游戏，这个游戏短小精悍，很具可玩性，特别适合在手机上玩。据称，已经有超过十亿人玩过这个游戏。

4、钻石情迷(Bejeweled)

一个很好玩的益智游戏，有点像“对对碰”，游戏规则很简单，移动相邻的两个钻石，使任一排产生有三个或以上的相同钻石，即消去，上面的钻石靠重力落下。

5、祖玛(Zuma)

一款休闲益智游戏，玩法很像QQ龙珠，将中间吐出来的珠子向着周围连环滚出的同色珠子射打，够三个就能炸裂消除，简单有趣。

想要了解更多有关Java开发的相关信息，推荐咨询千锋教育。千锋教育总部位于北京，目前已在20个城市成立分公司，现有教研讲师团队300余人。公司目前已与国内20000余家IT相关企业建立人才输送合作关系，每年培养泛IT人才近2万人，十年间累计培养超10余万泛IT人才，累计向互联网输出免费教学视频950余套，累积播放量超9800万余次，实力强大，值得选择。

Q2: 关于C加加和JAVA

C++之父评论C++与Java

Linux之父炮轰C++：

Java之父评价C语言之父：我用尽java代码恐龙买票了形容词

 

C++之父评论C++与Java

如果人们非要拿C++和Java来作比较，我建议他们去阅读The Design and Evolution of C++，看看C++为什么是今天这个样子，用我在设计C++时遵从java代码恐龙买票的原则来检验这两种语言。这些原则与SUN的Java开发小组所持的理念显然是不同的。除了表面语法的相似性之外，C++与Java是截然不同的语言。在很多方面，Java更像Smalltalk。（Sun的培训教材清楚地写道：Java在设计上采用了与C++相似的语法，与Smalltalk相似的语义。所以可以说Java与C++是貌合神离，与Smalltalk才是心有灵犀。）Java语言相对简单，这部分是一种错觉，部分是因为这种语言还不完整。随着时间的推移，Java在体积和复杂程度上都会大大增长。在体积上它会增长两到三倍，而且会出现一些实现相关的扩展或者库。这是一条每个成功的商业语言都必须走过的发展之路。随便分析一种你认为在很大范围内取得了成功的语言，我知道肯定是无有例外者，而且实际上这非常有道理。

上边这段话是在Java 1.1推出之前写的。我确信Java需要类似模板的机制，并且需要增强对于固有类型的支持。简单地说，就是为了基本的完整性也应该做这些工作。另外还需要做很多小的改动，大部分是扩展。1998年秋，我从James Gosling（Java语言的创始人）那里得到一份建议书，说是要在Java中增加固有类型、操作符重载以及数学计算支持。

还有一篇论文，是数学分析领域的世界级大师，伯克利大学的W. Kahan教授所写的How Java's Floating-Point Hurts Everyone Everywhere（且看Java的浮点运算如何危害了普天下的芸芸众生），揭露了Java的一些秘密。我发现在电视和出版物中关于Java的鼓吹是不准确的，而且气势汹汹，让人讨厌。大肆叫嚣凡是非Java的代码都是垃圾，这是对程序员的侮辱；建议把所有的保留代码都用Java重写，这是丧心病狂，既不现实也不负责任。Sun和他的追随者似乎觉得为了对付微软罪恶的“帝国时代”，就必须如此自吹自擂。但是侮辱和欺诈只会把那些喜欢使用不同编程语言的程序员逼到微软阵营里去。

Java并非平台无关，它本身就是平台。跟Windows一样，它也是一个专有的商业平台。也就是说，你可以为Windows/Intel编写代码，也可以为Java/JVM编写代码，在任何一种情况下，你都是在为一个属于某个公司的平台写代码，这些代码都是与该公司的商业利益扯在一起的。当然你可以使用任何一种语言，结合操作系统的机制来编写可供JVM执行的程序，但是JVM之类的东西是强烈地偏向于Java语言的。它一点也不像是通用的、公平的、语言中立的VM/OS。私下里，我会坚持使用可移植的C++作大部分工作，用不同的语言作余下的工作。

“Java is not platform-independent, it is the platform”，B. S的这句评语对于C++用户有着很大的影响，有些C++高手甚至把这句话作为自己的签名档，以表明对Java的态度和誓死捍卫C++的决心。

Linux之父炮轰C++：

糟糕程序员的垃圾语言(1)2007-09-09 13:33 刘江 刘江@图灵 我要评论(14) 字号：T | TLinux之父为Linux内核开发而专门打造的版本控制软件Git已经引起了业界的广泛关注。Dmitry Kakurin查看源代码之后，发现使用的是纯C而非C++，表示不可理解。引起了Linux之父炮轰C++：糟糕程序员的垃圾语言。AD： 2013大数据全球技术峰会低价抢票中

Linux之父炮轰C++：糟糕程序员的垃圾语言Linux之父话糙理不糙不得不看的两次从C++回归C的高手评论C++C语言是否该扔进垃圾桶为什么每个程序员都应该学习C语言？每个程序员都应该学习C语言？我可不这么认为C语言已经死了，5个需要忘却它的理由用C设计 用C++编码为什么使用C++C++0x：崭新的C++，还是另一个Java？编程语言的三大定理动态语言为何难堪重任动态语言面面观Linux之父Linus Torvalds为了Linux内核开发而专门打造的版本控制软件Git已经引起了业界的广泛关注。昨天，有一位Dmitry Kakurin老兄在查看了源代码之后，发现使用的是纯C而非C++，表示不可理解，他直言：“别拿可移植性说事儿，这是屁话（BS，bullshit）。“（此外，他还批评Git蛮力地直接操作文本，既啰嗦又易错，而且很难跟上高层代码逻辑。）”这个BS引起了Torvalds的强烈反应，他用“*YOU* are full of bullshit.”（你才满嘴屁话呢）作为自己反驳的开场白。接着，他先转向了对C++的罕见的火药味十足的炮轰：“C++是一种糟糕的（horrible）语言。而且因为有大量不够标准的程序员在使用而使情况更糟，以至于极容易产生彻头彻尾的垃圾（total and utter crap）。老实说，选择C就是为了把C++程序员踢出去。……我有这样的结论，任何喜欢用C++而不是C开发项目的程序员可能都是我希望踢出去的人，免得他们来搞乱我参与的项目。C++会导致非常非常糟糕的设计选择。你们这些C++程序员总是一上来就用语言的那些‘漂亮的’库特性比如STL、Boost和其他彻头彻尾的垃圾，这可能对你们的程序有所‘帮助’，但是却会导致：

——当库无法工作时无穷无尽的折磨（别跟我说什么STL尤其是Boost很稳定而且可移植性很好，那全是屁话，而且一点都不可笑）

——低效的抽象编程模型，可能在两年之后你会注意到有些抽象效果不怎么样，但是所有代码已经依赖于围绕它设计的‘漂亮’对象模型了，如果不重写应用程序，就无法改正。也就是说，使用优秀的、高效的、系统级的和可移植的C++的唯一方式，最终还是限于使用C本身具有的所有特性。项目限制只用C，意味着参与的人不会捣乱，也意味着会得到许多真正懂得底层问题，而不会折腾那些白痴‘对象模型’垃圾的程序员。

所以，我很抱歉，但是对于Git这样效率是主要目标的软件，C++的所谓优点只是巨大的错误。而我们将看不到这一点的人排除在外却成了一个巨大的附加优势。如果你想要用C++写的版本控制系统，去玩Monotone吧。他们确实使用了‘真格的数据库’，使用了‘漂亮的面向对象库’、使用了‘漂亮的C++抽象’。可是说老实话，所有这些对某些计算机专业人士而言富于吸引力的设计决定，其最终结果确是一堆可怕、难以维护的垃圾。”【070907更新】Torvalds和Dmitry Kakurin争论继续中。对Torvalds的回击，Dmitry反唇相讥：“随着只用C编程的恐龙们逐渐灭绝，你很快就会发现只剩下自己一个人在固执己见。用Git贡献者的数量是说明不了问题的。显然C++开发者也能够贡献C代码。但是以为他们喜欢这种方式，那可就错了。

没有C的时候我用汇编编程。然后在C++诞生之前，我转向了C。现在我使用C++和C#，而且不再走回头路。差劲的程序员用任何语言都写不出好程序。但是为了将差劲的贡献者拒之门外这样一个没谱的理由而惩罚优秀的开发者，这简直是胡闹。”只过了10几分钟，Torvalds就回贴了：“和你不同的是，我实实在在地给出了不喜欢C++的原因，而且指出了它可能导致的各种问题的一些例子。而你呢，没有给出一条像样的使用C++的理由。事实上，Git比其他软件配置管理软件都要好，而好的品味（taste）和C正是原因之一。”

对上面的最后一句话，Torvalds后来又做了如下补充：

“说得更具体一些：

——简单和清晰的核心数据结构， 非常精益（lean）且颇具雄心的暧昧管理着它们，将“简单胜于花哨”这一方法发挥到极致。

——有意识地不抽象数据结构和算法，因为它们恰恰是Git核心的全部要素（whole point）。        如果你想用更花哨的语言，C++绝对是最糟糕的选择。如果想要真正的高级特性，那就选择有垃圾回收或者好的系统集成的，而不是既缺乏C的简约（sparseness）又缺乏C的直接而且没有重要概念的高层 绑定（high-level bindings to important concepts）的东西。        一言以蔽之，C++正处在困境当中，它既无法帮助原型化或者简单的GUI编程足够简化从而真正可用，不是C那样积极地鼓励你使用简单和直接的语言构造的精益系统编程语言。”      （另一位同学插了一句：这还没有提到很难找到两个C++编译器支持同样的特性。）“这与什么恐龙毫无关系。好的品味永远不会过时。将C与汇编语言相提并论，恰恰说明你对自己所讨论的问题缺乏起码的概念（don't have a friggin idea）。”

Java之父评价C语言之父：我用尽了形容词

摘要：Java 之父James Gosling在上周发布了关于讨论C语言之父Dennis Ritchie的简短博文称：C语言撑起了一切，他的影响巨大，并超越了科技世界。

Java之父詹姆斯·高斯林（James Gosling）在上周发布了关于讨论C语言之父丹尼斯·里奇（Dennis Ritchie）的简短博文：丹尼斯·里奇辞世的新闻如五雷轰顶。过去几天已经有很多资讯报道此事。他的影响巨大，并超越了科技世界，虽然他的大多影响都不为人知，但完全可以感受到。C语言撑起了一切。我的整个职业生涯也是从C语言和Unix中发展而来。对当今的大多数工程师而言，很难理解我在20世纪70年代感受到的幸福愉快感。当一种编程语言最终出现，我（其他人也）可以从汇编语言提升到一种真正的编程语言。我们可以做任何一切，过去我们得编写所有低级位系统。在C语言之前，编程语言达不到任务：开销太大了。系统的复杂性是真的阻碍了用汇编语言编写大型软件。C语言就像代码的JATO。（编注：“JATO”是“Jet-fuel assisted take off”的缩写，字面意思：“辅助起飞的喷气燃料”。这个系统通过小型火箭提供辅助动力，以帮助超载的飞机起飞升空。）下面是詹姆斯·高斯林此文的一些评论：Truely James. For every Computer professional in the world, the first language they come across is C. With so much of wonderfulness and which also makes the learning experience so fun and entertaining. RIP Ritchie!!!说的很对，詹姆斯java代码恐龙买票！对于每个计算机专业人士，他们所接触的第一种编程语言就是C语言。（C语言）有着如此多的令人惊奇的地方，这也使得学习过程非常有趣。安息，里奇！！！Great ones are falling. I still love C. So simple. So powerful.一位巨星的陨落。我仍然爱着C语言。如此简单，如此强大。I remember C being like Adventure for programmers: lots of little pits for the unwary to fall into. Even after many years there were a few I hadn't found. It was a good time.我记得C语言就是程序员的冒险：有很多小坑，一不小心就陷进去。即便很多年过后，还有一些我没有发现的。那是个美好时刻。The equation is quite simple : Richie is like Einstein, pure Genius. All the IT is built on Kamp;R works. Thanks man, and RIP...等式非常简单：里奇就像爱因斯坦，纯粹的天才。IT业的所有都基于肯贝汉和里奇的成果。感谢，安息……文章出自：nighthacks译文来自：伯乐在线

关于java代码恐龙买票和java游戏的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。