这篇文章有趣的是，上做阐述，下为分解。原本因为时间所限，无法一天内译完，没想到，拆开后反而更符合作者的心境。
我也完全没有料到上篇所引起的争议，但我相信，看过上文的读者在读完下文之后，可以理解席拉库萨的苦心。
这是一篇能够打动人心的作品，至少对我来说是这样。我极少见到如此感人的科技文章，苹果能有这样的粉丝，足矣。不妨摘录一些片段：「我的诸多担忧是一种过激反应…」；「尽管苦闷挥之不去…」；「我曾经千思万想，希望苹果早日动手。」
须再次说，原文有许多参考链接，有助理解内容。另外，原文的近 300 条评论值得一看，质量很高。我觉得，就正反方数量之比，Apple4us 的读者与 Ars Technica 的读者相差不大。
比以往更紧迫
哦，我知道你在想什么。你们这些 Cocoa 开发者定会认为我失去了理智。你们说：Cocoa 和 Objective-C 是苹果最叼的东西，才不是定时炸弹！而且，尽管源于 C 语言，但 Objective-C 提供了 Java 都还不支持的动态性能和语言特性，因此，说它「低级」是不公平的。还有啊，不要忘了垃圾回收机制，iOS 总有一天会支持。
无论如何，你认为，这一切都不重要。何况空谈不如实践：谁的程序更好？谁的用户体验最棒？谁赚的钱更多？而且苹果的桌面或移动平台的种种缺陷没有影响到什么嘛，看起来一切正常！
开发界有句老生常谈，在程序员中奉作经典，不妨援引：你习惯何种抽象层级的编程语言，那么这种语言就是最合适你的语言。视低级语言过于原始，高级语言臃肿耗能。在全行业抽象度愈加高耸的今日，仍是如此。
首先，如今写 C 的同学大概没人会用汇编了，但 C++ 虚表调度的速度还是太慢，难于采纳。接着，C++ 党也许会懊恼的追忆起当年是如何将他们半残的对象系统嵌入 C 中的，但他们却很鄙视 Java。再后来，Java 党开始嘲笑指针和手动内存管理，但 JavaScript 却被讽刺为玩具级的脚本语言，干一些验证网页表单的粗活。诸如此类…
在短期内，在当下，他们大多是正确的。但，这是条不归之路，而且，正指向愈加抽象的层次。下一次跨越何时到来，不妨观察业界的前缘。苹果通过 iPhone 的成功为自己争取到了一些时间，但以目前竞争之惨烈，这也许仅仅是一厢情愿。
转换之难
尽管「2010」危机没有到来，苹果最终仍需面对该问题。我关注这个问题的原因，无论在 5 年前，还是现在，都是一样的，即：开发平台很难改变。首先，选择或开发一门新语言，并为其打造一套新的 API 存在技术难题。优秀的 API 需要多年的发展和累积。Cocoa 就是个好例子。
不幸的是，寄望将现有的 API 导入新的高级语言和运行环境，并能正常工作，几无可能。转用高级语言能减少原 API 复杂度。例如：
NSInteger myCount = [[myDict objectForKey:@"count"] integerValue];
NSArray *myArray = [myString componentsSeparatedByString:@","];
myItem = [myArray objectAtIndex:i];
不可能在这样的语言环境（假设）中运行：
myCount = myDict["count"];
myArray = myString.split(",");
myItem = myArray[i];
只有新的 API 才能更好的匹配新的语言。但与下一个问题作比，这还算简单的，即：劝导开发者转向新的语言和 API 而不影响现有平台的势头。即便技术选择完全正确，开发者也愿意随你前行，平台的转换仍需花费时间与精力，无论是平台供应方，还是开发方。与此同时，竞争对手的现有平台正值壮年，它们无需为平台转移而苦恼。而且，当你正辛苦的切换平台之时，它们还能借此获得增长。
如果你只是一个普通的用户，恐怕难以理解我对此的恐慌。如果你是开发人员，就像本文开篇谈到的那样，你也许对我嗤之以鼻。没有关系。我也同意，我的诸多担忧是一种过激反应，但这恰是因为我真实的经历过 1990 年代那场伤筋通骨的 Copland 危机，并且，眼睁睁的看着苹果因此近乎覆灭。
无疑，苹果今非昔比。但是这类技术问题，无论多么艰巨，一旦无法解决或被完全忽视，那就只会引发危机。过去的十多年间，一旦苹果开始解决某个问题，它就会做的非常非常好。因此，我们有理由乐观。但并非完全如此。
了解而又热爱 Objective-C 和 Cocoa 的最大群体在苹果公司里。而这些人亦可能不那么热衷于推动新的语言和 API。再加上苹果的脾性 — 例如其对软件商店的态度 — 不管外界争议如何，只要认定是最佳做法，便会一意孤行。而且，有许多因素妨碍着苹果深入思考这个问题。
虽然微软近年来的产品线不够协调，但它有所预见并愿意解决其最深层的技术问题，值得嘉许。微软早在苹果意识到这个问题数年前就开始研究现代操作系统，因而避免了 Copland 式的危机。微软开发了 Windows NT，并通过数次更新，细细雕琢，才将 NT 推向消费级操作系统。（编者：即 Windows XP。）
即便如此，微软还是来迟了。当时 Java 已崭露头角，而微软还牢牢的固守在 C++ 阵营，但微软应变极快，投入了可观的人力与资源，推广其 .NET 虚拟机和 C# 语言以弥补差距。技术上不够自信的公司也许会选择另一条道路。它们会争辩：我的语言和 API 有其优势，没什么要改进的啦。换言之，「忽略问题，问题便会消失。」
你有多了解苹果对 Objective-C 和 Cocoa 的态度？以上这些情景会让你想起什么吗？
实际的检验，之二
再一次的，让我猜猜你的反应吧。「别用你对技术的担忧吓唬我们。」微软不是很用功吗？开发了一整套多语言运行环境，也没能帮助他获得多少移动市场的份额嘛，而且除 Windows/Office 之外，这套体系也没能助其开疆扩土嘛。说的没错。像微软这样成功解决了技术问题，并不能保证其他方面也成功，也不能保证从此稳坐泰山。
让我们回顾上一节末尾的问题：对于我们这些身在苹果之外的人，有谁真正了解苹果对 Objective-C 和 Cocoa 的态度，有谁知道他们对未来的规划？在我发表 Copland 一文不久之后，有关苹果参与 LLVM 计划的细节开始浮出水面。那么 LLVM，抑或，目前的 Clang，是苹果平台演进的长期策略吗？虽然，苹果的状况尚可，但是，为达到目标，要做的改进远比这些多得多。也许他们已经动手了，我们只是不知道罢了。
我曾经千思万想，希望苹果早日动手。如果我有具体的解决办法，相信我，定当竭力推进。但是，目前我所了解的，苹果用于保护其老旧平台技术的办法是…
你寻到 Web，他会给你自由
采用其他平台供应方的 API，就等于将命数交于他人之手，苹果不会这么做。苹果大概不能忍受自家平台构建在，由竞争对手主导开发或完全控制的程序语言之上。那么只剩两种选择：要么自己从头做起，要么寻找一个无供应方的解决方案 — 即不受任何单方的控制。
现观之，苹果似乎选择了后者，它开始大力投资 Web 技术。啊！是的，Web，无可争议的自由平台！苹果得到了 Webkit，成功打入浏览器引擎之战（至少在移动市场是这样。）并借此宣扬，这才是先进的网页标准。（尽管有时候做错了）此外，苹果在其新近的网页程序中使用了 SproutCore HTML5 程序框架，还有 PastryKit，这是苹果研发的数款网页框架之一，现已开始部署。
采用 Web 技术巧妙解决了苹果的许多潜在问题。无须推出震惊世界的程序语言和 API，苹果已将整个行业引入它的轨道中来。Web 不由任何一方控制，但苹果似乎比任何一家公司都更尽心竭力。
不幸是，这意味着，苹果仍无法掌控一切。此外，Web 技术离目前 GUI 程序的水准还有很长的距离。大多数有经验的 Cocoa 开发者非常清楚二者差距，但他们多少会觉得有些不安。
这便是，为何我认为 Web 技术只是苹果的防御手段 — 它的第二选择。但倘若我知道它的首选是什么，必定会宽慰许多。
自作自受
尽管苦闷挥之不去，Copland 2010 终究没有到来。虽如此，我仍觉得这个问题并未消失，而且随时间流逝愈加严重。当然，作为一个在 5 年前已经因此吓破胆的人，我对「紧迫」的定义很可能与你的不同。
写这些不是用来离间 Cocoa 开发者的，更遑论 Mac OS X 和 iOS 用户。我亦无心冷嘲热讽，好比说，这个平台要完蛋啦，或者这个平台就是低人一等，未来已经注定之类的。我写苹果已有多年，好处是，可以时而回顾多年前的预测，我也愿意担负责任。我最痛恨是，技术专家无挂无碍的将多年前他们的可怖禁言弃之脑后。
我也试着帮助苹果，不管是公司决策者能读到我写的文章也好，或间接鼓励开发者，让他们至少想想这个问题也罢 — 即便他们的理念与我不同。我想善意的提示所有当事人，包括苹果。即这个问题依然存在，只是潜藏而已。
最后，我得承认，我亦喜欢身处迷局。五年前，我不知苹果的未来语言和 API，今天仍是。在这样的一个世界里，我们多年的期盼一个个成为现实 — 新的操作系统、我们的苹果手机、我们神话般的平板 — 但语言和 API 继任者的问题仍顽固的存续着。这一回，我不再加入年份，但请放心，我仍将观守并等待。我只是希望我不是唯一的一个。