重磅级科技文章大多出自有软件开发背景的作者，须渗入底层才知道事情的始末，计算机世界绝对是这样的。平台技术横向比较的文章我所见不多，也许开发 者都清楚，但少有人写出来吧。

2005年John Siracusa连发三文，预测苹果将会遭遇平台危机。未想iPhone的兴起延迟了危机的发生，5年后，他发文检讨，但仍认为，不跨越内存管理的障碍， 危机仍将隐现。(这是上篇，下篇将于随后发出。)

苹果如不跨越内存管理的障碍危机仍将隐现

预测科技业的未来是件棘手的事情—不妨看看比尔·盖茨十五年前的预测结果—虽如此，预言 的诱惑总是强烈的。我亦因此闻名。有时候我猜的挺准，2008年时我说“苹果和Adobe之间只有战争”。含 糊、幽默式夸张、不明确的时间表是成功预测的基本要素。
其他时候，我就没有这么幸运了。五年前，我写了题为《别在2010年重蹈 Copland的覆辙》的系列文章，分三篇发出。但这一次，预测的内容既严肃又具体，而且标题中还有年份。换言之， 想不失败都难了。好吧，2010年已经来到—曾经的那个未来！—所以，是时候挨批了…或者，这可以算乌鸦嘴的胜利么？但重要的是，“Copland 2010”究竟说的是什么呢？

• 背景

苹果曾数次尝试开发新一代操作系统，Copland是几个项目中最声名 狼藉的一个。Copland始于上世纪90年代，「新一代」是指支持内存保护和抢先式多任务，当时的Mac OS不支持这两项功能。从那时起，Copland见证了苹果从近乎崩溃，到承认并及时解决其软件平台重大的技术差 距。通过这次不可思议的收购—一款独立发展的现代操作系统、一个被驱逐的公司创始人—苹果得以留存下来。
在《别…》的第一部分， 我提出了我的论点：Objective-C语言和Cocoa API是Mac OS X中最危险的部分，因为它们落后于竞争，而到2010年，苹果会发现自己面临着另一个Copland式 的危机，因为它缺少内存托管语言和API。在第二部分， 我详述了我的假设。分别是：

• 桌面操作系统的开发环境终将提供全自动内存管理功能。
• 到2010年，其他对手将会采用支持全自动内存管理的语言和API。
• 而现有的技术（2005）与可能的演进，无法充分满足苹果对内存托管语言和API的需要。

这些假设受到了强烈的质疑。
在第三部分， 我评述了那些有可能超越Objective-C和Cocoa的语言及API。我也试着鼓励质疑「2010年」的人们，观其大局。
毕竟，人人同意Cocoa和Objective-C总会过时。好吧，也许有人认为，这一天得等到2050年，但总有一天，对不对？用什么替代 Cocoa？有什么可以替代Cocoa？苹果在编程语言和API之战中的新动向是什么？
在文章中，我认为支持垃圾收集机制的Objective- C，Java/JVM，C#/.NET/Mono，抑或之前苹果鲜为人知的尝试（例如Dylan） 皆因种种实际的、技术的或派系的原因，无法承此重任。那么，我认为，苹果便只能尽快并独辟蹊径的寻求或开创Cocoa/Objective的继任者了。

• 未来已至

那么，结果如何？若逐字对照，结论很明确：苹果并未经历Copland式的平台危机。虽 然它或许处在另一类非常特殊的危机之中，不过，这是另一回事了。就华尔街的态度（以及苹果的资产负债表）而言，未来仍旧是光明的。
是我大错特错了吗？还是没有？不妨再看看我的假设。自动内存管理已经普及了吗？大多数Mac OS X开发者并不这么认为。Objective-C确实加入了垃圾收集机制，苹果也很努力的推广。但是，五年前我提到的「二等公民问题」并未消散。大多数 Cocoa开发者，包括苹果自己，在多数程序中，仍旧采用手控维持与释放式的内存管理。对时下的麦金塔开发者而言，垃圾收集并非上选，并可能危及性能。
微软在.NET框架和C#语言上使用默认的内存管理代码，其他的内存管理代码则视为存在风险，并以「unsafe」为关键字标注在源代码中。
尽管如此，开发者和用户并没有像Copland时代那样的恐慌。如果危机正待，那绝不是 现在。这就是所谓「2010」。但仅此而已么？

• 未来未来

微软从十年前开始着手.NET的通用语言运行库。期间发布了四个主要的版本，显著拓展了C#的功能，亦提供了对动态语言，如Python和Ruby的支持。如果这是开发平台间的竞争，那么从技术上讲，苹果处下风。
尽管如此，开发者仍无动于衷。原因可概括为三个词：移动，移动，移动。iOS（原iPhone OS）的崛起令人头晕目眩。在台式机上多年不见得配置重新出现：128至256MB内存，1GHz定序处理器，无虚拟内存。十几年来，苹果 从没在台式机和笔记本电脑上用过这么小的内存，不支持虚拟内存？那是多遥远的事情啊（编者：1991年System7开始支持虚拟内存，作者意指，初代麦 金塔不支持虚拟内存也就罢了，现在已经过去26年了还……）。哦，对了，iOS不支持Objective-C的垃圾回收。
硬件受限，习惯了高级语言的苹果开发者必感不便，而Objective-C乃C的超集，趁此终可大显身手。当你的程序持续不断的收到系统发送的低内存 警告；当你不得不与低级语言、字节级精度的指针与C结构打交道的时候，你怎么嗨的起来？
苹果夸大了移动设备用户界面响应能力的重要性。为维持直观流畅的用户界面，苹果无所不用其极，这招让iPhone脱颖而出。即使在今天，那滚动列表或 划过屏幕的短暂延迟，虽然难以捉摸，却能显而易见的将iPhone与其他手机区分开来。内存受限，开发者虽无能为力，但似乎暗喻了畅快的界面与iOS原生 API的底层特性之间的某种联系。（编者：苹果：赶快学习低级语言啦。）

• 实际的检验

还有一个问题。就像它在桌面端最大的竞争对手（编者：微软），苹果在移动市场中最强力的挑战者也提供了内存托管语言和API。毫无疑 问，Android最新版的Dalvik虚拟机速 度很快。（我曾预言寄存器型虚拟机将成主流，现在是不是能讨点赏了？）
更糟糕是，谷歌甚至利用了苹果开发多年的底层库，增强自家设备的性能，还在Google IO上用Android手机修理了一把看似无比强大的iPad。是的，WebKit是用C++写的。这正是要点：提供高级API并不能阻碍 高性能底层库的应用。
不仅是谷歌。微软也不出所料，推出移动.NET平台，并为Windows Phone 7增加了更高层级的语言和API。即便不幸 如Palm，亦为开发者提供了更为抽象以及安全的开发环境。这正是苹果所面临的竞争图景。
显然，在衡量成败方面，技术细节并非如此重要。即便Mojo SDK闪耀一时，也难以避免Palm的惨淡结局。但是，最能挑战苹果一枝独秀的用户界面的，仍然是WebOS。谷歌仍然健在，当然，它不会好到哪去。而微 软…嘿，你永远不会了解的，对不对？
个别竞争者的命运暂且不论。事实上，这些最危险的对手手中，都有领先苹果一世代的语言和API，这才是最危险的信号。而且，这还是发生在内存食紧、处 理器受限的移动世界。在桌面平台，苹果落后更多。
2010终于来了。不管“未来”到达与否，开发者为了一个损坏的指针不断的遍历内存，多少是有些愚蠢的事情了。世界已经改变，苹果亦应顺势而为。

本文来源于：(http://blog.sina.com.cn/s/blog_5c57b5190100j7ia.html)

相关英文报道：

Copland 2010 revisited: Apple’s language and API future

http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars