这篇文章有趣的是，上做阐述，下为分解。原本因为时间所限，无法一天内译完，没想到，拆开后反而更符合作者的心境。
我也完全没有料到上篇所引起的争议，但我相信，看过上文的读者在读完下文之后，可以理解席拉库萨的苦心。
这是一篇能够打动人心的作品，至少对我来说是这样。我极少见到如此感人的科技文章，苹果能有这样的粉丝，足矣。不妨摘录一些片段：「我的诸多担忧是一种过激反应…」；「尽管苦闷挥之不去…」；「我曾经千思万想，希望苹果早日动手。」
须再次说，原文有许多参考链接，有助理解内容。另外，原文的近 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 继任者的问题仍顽固的存续着。这一回，我不再加入年份，但请放心，我仍将观守并等待。我只是希望我不是唯一的一个。
41 Comments so far
Leave a comment
Fields in bold are required. Email addresses are never published or distributed.
Some HTML code is allowed:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
URLs must be fully qualified (eg: http://apple4.us),and all tags must be properly closed.
Line breaks and paragraphs are automatically converted.
Please keep comments relevant. Off-topic, offensive or inappropriate comments may be edited or removed.
不错的文章，我觉得cocoa框架还是不错的，但是觉得objc的语法很多时候过于臃肿。
这话不假呢……就好像php足够简单始终做到web系开发的头把椅一样…
facebook的threee20库作者就曾经 说过objective c实在很一般从语法特性来说,我想java对android的好处还是很明显的大量的开发人员 ,api随着时间的强化最后还是会赶上来的….
苹果的话 如果可以用mac ruby ,这种类似 跑 scala 或者 jruby在jvm的方式来避开objc的弱点的话 应该还是很爽的.
上下两文都看过了。原著作者杞人忧天。
不要说手机平台，即使是桌面应用，动态内存管理的编程语言迄今没有办法成为主流。即使手机平台，无论是Android Dalvik还是WebOS，在强调性能的游戏应用上也表现乏力，需要借助更加底层的API。从编程效率而言，Android的Java也未见得比OC强到哪里去。
objective-c的引用计数的内存管理是当下必然明智之选，未来很多年后不排除主流应用会进化到动态内存管理的编程语言，但是目前没有这种苗头。
况且苹果也一直在寻找和探索高效率的动态内存管理语言，比方说以前的MacJava，现在的MacRuby。将来一旦时机成熟，不排除MacRuby迅速上位的可能性。
苹果啊
不要说手机平台，即使是桌面应用，动态内存管理的编程语言迄今没有办法成为主流。即使手机平台，无论是Android Dalvik还是WebOS，在强调性能的游戏应用上也表现乏力，需要借助更加底层的API。从编程效率而言，Android的Java也未见得比OC强到哪里去。
这个python gtk ruby gtk ruby gnoem之类的还是很无敌的
未来属于动态语言
你看看 nokia死守 qt的结果….
在web系已经整个天下都是动态 就连java的下一代scala都有大量的动态语言特性
包括C#在3.0之后大量加入var 匿名函数等语言特性
都是明显的对动态语言的倾斜….
在到最新的F#语言
实际上后端语言已经从 静态语言到动态语言在到同时拥有静态语言性能 动态语言编写方式语法..同时加入少量函数语言的时代了…
看看scala….这是真正的语言发展未来
微软开发了 Windows NT，并通过数次更新，细细雕琢，才将 NT 推向消费级操作系统。（编者：即 Windows XP。）
————–
是Windows 2000(NT 5.0)
to gakaki: 贻笑大方阿！
>>这个python gtk ruby gtk ruby gnoem之类的还是很无敌的
桌面开发这些编程语言现在都是扶不起的阿斗，也完全不是主流。
>>未来属于动态语言
未来也许是，但现在肯定不是，所以现在用Ruby/Python等语言写桌面GUI的无疑是傻X
>>你看看 nokia死守 qt的结果…
非得给你科普了，symbian得GUI不是QT，nokia正想用QT取代Symbian的GUI
>>在web系已经整个天下都是动态 就连java的下一代scala都有大量的动态语言特性
Scala是做服务器高性能并发编程用的，和GUI八竿子打不上，不要随便打灰机阿
>>包括C#在3.0之后大量加入var 匿名函数等语言特性
即便Wiindows平台桌面应用，C#迄今还不是主流。
这灰机打滴…
如果说未来属于动态语言，第一个要干屁的就应该是Java这个伪动态语言。
这个作者没有搞清开发语言／运行时和OS的区别就把二者浑为一潭。Objective C也许有缺陷，但是决不是Copland那种形式的crisis。
内存托管环境确实是趋势，不过成为主流尚需时日
那段代码比较就能把作者拍死。没看过Cocoa之前确实不喜欢方括号和长长的消息名，不过这种方式实际上很漂亮。这年头不是讲究self documentation么，还有代码是写给人看的么。机器可不在乎消息名有多长。
那段代码比较就能把作者拍死。没看过Cocoa之前确实不喜欢方括号和长长的消息名，不过这种方式实际上很漂亮。这年头不是讲究self documentation么，还有代码是写给人看的么。机器可不在乎消息名有多长。
下面那段代码还是清楚简洁许多，不过objc的方式习惯了也就好了，而且xcode也有代码自动完成功能，倒也不会多写多少代码
就编程语言来说，objc确实有些别扭的地方，要不是iphone这几年发展的好，用的人也不会这么多。但是我觉得对于开发者来说，API，类库，框架这些东西更加重要， 我总是觉得JDK的API设计的很复杂，用起来麻烦，而且搞得第三方的类库也设计的很麻烦，好像不用几个设计模式都不好意思拿出来似的。
原文作者的Copland危机之说，显得作者思维非常之混乱，逻辑也完全不通。
Copland之所以成为危机，那是因为MacOS Classic操作系统的功能缺失(虚拟内存管理，抢占式多任务)已经严重影响到了最终用户的使用体验了，迫使最终用户抛弃Mac，投向Windows。
而Objective-C是编程语言，无论OC比Java如何不堪(事实上还没有那么不堪)，都对iPhone的最终用户没有任何影响，甚至OC带了GC才会影响最终用户的使用体验。
至于对开发者来说，带不带GC，编程语言现代不现代，不是一个根本性的，决定开发者是否选择iPhone平台的理由。开发者不会因为OC不带GC，而Java带GC，就会抛弃iPhone选择开发Android应用。
作者逻辑不通之处就在于：拿操作系统功能缺失导致的最终用户流失来推断：编程语言功能特性的取舍会直接影响到最终用户的选择。而忘记了操作系统是最终用户直接使用的，而编程语言是开发者使用的，不是最终用户直接使用的。
同意robbin的观点。
原文作者整个就是一个头脑不清晰，一团浆糊。
决定苹果前景的是其产品的用户体验，而不是编程语言这个层面的东西。
细致的分析一个东西要讲投入产出率（ROI）。开发技术的投入是性能开销，产出是conplexity reduce。虽然GC的产出稍高，但是GC的ROI是要大大低于reference counting的。而C和汇编，OS的发展，都是绝对产出和ROI一起增长。写分析必须意识到这种ROI的拐点，不能带着恐龙的直线思维说：既然C代替了汇编，GC就要代替一切其它内存管理。
作者所担心的所关注的仍然是语言语法层面的东西，作者所关注的这些问题不仅在obj－c里存在，在java、c＃、cpp等语言里都存在，可是这些问题真的有那么重要吗，诚然，语法上的方便简洁确实能提高开发效率，但是核心的本质的东西是不会因为语法的改变而改变的，事实也证明语法糖是没有用的，我们非要关注一个语言好不好的话，更应该去关注这个语言本身的内部机制，它的运行时环境，它与操作系统的关系，去关注一些更本质的问题，而不是这些表面的东西，表面的再怎么变，万变不离其宗。如果大家感兴趣的话建议去看看这篇文章，个人感觉分析得比较透彻：http://blog.youxu.info/2010/02/28/why-mac-os-x-for-programmers/
“那段代码比较就能把作者拍死。没看过Cocoa之前确实不喜欢方括号和长长的消息名，不过这种方式实际上很漂亮。这年头不是讲究self documentation么，还有代码是写给人看的么。机器可不在乎消息名有多长”
很同意图@venj得观点！！！
作者对语言特性的比较很表浅，没有从更深的层面去分析，就这样得出那样的观点，确实是危言耸听、杞人忧天。
作者不是杞人忧天，一个系统的基础语言和 API 是很重要的。
Windows 之所以那么成功，除了对用户来说很受欢迎的 Office，对开发人员很亲近的 VC（大多用MFC）和 VB 功不可没。
对于一个操作系统，其开发人员的量变会引起其软件的质变，所以苹果确实也该考虑作者的观点。
@jlake 语言是很重要，但是要看看忧的程度。你要了解Copland是一场什么危机，那是那个年代PC业的特殊格局决定的。如今这种纯技术导致的危机很少了。更多是技术政治的危机（比如微软就是不用UNIX）。作者纯粹是忧天。
2010 终于来了。不管「未来」到达与否，开发者为了一个损坏的指针不断的遍历内存，多少是有些愚蠢的事情了。
——看了这段话，我真的怀疑作者到底是不是真正开发过大型商业软件。要知道，今天有各种调试工具和静态分析工具，想找到一个损坏的指针真的不是一件很难的事情了。而且，即使在C 下工作，如果能够保证使用shared_ptr几乎遇到的问题为零。
一群井底之蛙，robbin的回复尤为让人心寒
作者的良苦用心你们根本没有用心体会
似乎只要一谈到技术，就像立刻触动了你们那根脆弱自卑又敏感焦躁的神经。
你们觉得自己牛，你们在IT界已经摸爬滚打多年，你们做过很多所谓的大型项目，其结果却是——你们习惯了去接受，从未停下来去认真思考，骨子里又害怕改变，害怕学习，早已丧失初学者的心态，思想固化到不可逆转的地步，却还在此沾沾自喜。
不要从技术层面去反驳作者，作者提到的实际是一种编程思想的转变，这些数字工具是否真的适合现在这个时代？看看那些竞争者，看看他们在做怎样的努力和尝试。
面对一些问题，是否有更好的、更愉悦的方式去实现，我们是否该鼓足勇气从头开始等等， 你们从未思考过这些问题，想想苹果那句口号：think different.
你们用别人写出的语言，用别人设计的kpi，你们有否认真思考过如果现在是由你来创造一门语言，你们会怎样去动手？
而robbin提到的用户体验之说，似乎只有最终用户才面对，那么你们这些开发者的“开发体验”是否就不是一个问题，还是你们已经习惯了以中国惯有的奴性方式来对待。
即便作者之说存在辩驳，是否需要你们以批评者的身份来贬低作者，你们甚至都不是一个思考者。
非常感谢apple4us的转载，我本以为会有一些有思考的评论，不料却看到一堆自以为是的技术工程师们的个人偏见。
不得不感叹：中国何时能出一个Matz
同意411的观点，不除去“井底之蛙”部分，哈哈
robbin, middleware诸位似乎并没有看懂作者在说什么。让人贻笑大方的地方不在于此，而是，各位似乎都在用静止的观点看世界——用object-C等的已有特性证明它能够适应未来变化，关于这一点有多么可笑，原文作者已经用javascript用途等变化说明了。
此外关于编程语言对一个系统来说是否重要的话题，更加无须质疑，答案是理所当然的至关重要！硬件的发展可以说是日新月异，但是看看当下，编程语言的发展明显落后于硬件发展的速度，所谓“主流”编程语言竟然10多年没有变了！原文作者指出了一些问题，这种进化论的革新精神值得称赞。
用良好的用户体验来证明开发体验同样良好也不靠边，是真正的逻辑混乱。
此外关于所谓的“主流”编程语言，这个概念很难定义，某个领域也许有所谓的主流，但是用普通PC上的编程语言来代表“主流”就有失偏颇了。除了PC还有服务器，除了GUI程序还有WEB应用，除了X86还有ARM，谁是主流？大型商业系统上的核心程序还是corba，难道corba就是主流么？
object-c的语言特性相比java的确显得比较老旧，它现在的成功不能代表未来的成功。原文作者是不愿意睡在功劳簿上的那种人，而害怕变化的诸位却没有这个优点。Java已经不是只能用来写applet的那个java-语法简单，语言特性扩展迅速，采用Just-in-time compliation等技术让虚拟机性能不断提高等等，而是object-C却还是那个没有GC的object-c。
有人提到android，我的看法是java对于android的发展来说非常重要，也许android与iOS相比用户体验不是太好，但是只要有java在，用户体验的改善以及占领绝大多数市场份额只是时间问题。原因很简单，就像x86战胜其他体系结构的过程一样，简单直接而且恰好能满足用户要求的方法经常出现“长尾”，用户大大量使用保证了系统进化的速度。Java与Object-C相比恐怕更加“主流”一些。长尾就在这里摆着，其结果不言自明。
苹果用户的狂热并比惹人讨厌，但是，因为使用苹果而产生的优越感的确让人不舒服。使用优秀的产品不能代变使用产品的人同样优秀。同理，使用老旧的object-c的人也不需要和object-C一样固步自封。
此外，文中提到的那段Object-C代码丑陋的可以，这点不需要用不言自明的变量和IDE等辅助编辑来粉饰，丑就是丑，没有什么可说的。
关于Objective C的问题，我已经反复声明它并非完美。但我觉得楼上几位才没有看懂作者的意思，甚至是根本没有理解作者的标题。可以说，如果作者不把一个80年代不相关的事情硬联系的话，作为一篇比较各个平台的小文也就是随便看看。
80年代的那档子事是作者用来类比的，他要说明的情况正是这种固步自封的态度毁掉了当时的苹果。这条难道于现在仍然在为object-c的简陋辩护的人没有类似之处么？如果连类比都无法理解，那么……恐怕考不了GRE了，哈哈
作者在文中强调，“普通用户恐怕无法理解”，所以他说的问题不是面向普通用户的问题，而是在讨论开发者体验。robbin在上面的回复中将作者的意思曲解为“拿操作系统功能缺失导致的最终用户流失来推断”，这是诸位以一种理所当然的优越感得到的谬论——用户体验好所以一切都好。
即便Objective C被替代，用Java作为未来也不那么光明。如果说做了多年Java才逃离到Objective C是不是也算拒绝学习新东西？应该算恶意忘记先进技术了吧？Java的动态特性更丑陋，调用一个编译器未知的方法比Objective C繁琐的多。Byte code本来就是个坏主义，我不喜欢半吊子方案。要么动态，要么native，我从来不认为native的东西会千秋万岁。但是Java就是未来？还是算了吧。
给别人扣上故步自封很容易。但是没法证明别的平台如何先进一个世代也是枉然。说出当年.net 1.0 spec 那样的大话很容易。随之是开发社区的动荡。
Java是不是未来这事情很难说，至少在web上已经有python后来居上了。但显然2010不是终点，只是一个新时代的开端，所以，Java要走的路还很长。但是庞大的开发者数量以及简单易用的特性的确是Java社区的优势。
但是很显然，Object-C看上去没有Java那么有未来。注意，我和原文作者一样并不认为它会完全没有未来，只是，极力为现状辩护而不愿改变封闭系统大都会失去未来。也许替代Object-C的不会是Java，但是时代在变，它也需要变一下罢了。
To: middleware
本来我还不太确定你究竟有几把刷子，从你的回复看来，似乎数量不超过2，通常，有很多把刷子的人脾气都挺好。所以，这个回复我看没有继续跟下去的必要了。
Java和Object-C究竟谁更先进并不是我想要说的中心。我批评的是你所持有的这种态度，无视作者在原文中提出的看法，而根据自己的优越感和混乱逻辑给作者扣帽子。其目的似乎只想体现自己是大虾。也许并非如此吧，但是如很多写过几行程序的小孩一样，你的浮躁形象跃然“网”上。你的偏执损坏了你的名声。
你所批评的混蛋作者，在我看来，对软件的理解以及当下正在发生的事情比你的见识远的多。
@大头 作者说出了你所希望相信的。不过你辩护的方式还不如他有水平。你的偏执并不亚于任何人。既然你不想继续也不必再回。尽管这不是一个非有偶像的时代，我还是相信Jobs胜过你。
我从来没说过这个作者是混蛋。喜欢不对事的人也总是以此来看待别人的论点。我只是说这个作者在我看来实在是举例说理都不如一些评论。如果拿Copland类比。Windows那个内核态没有内存保护的GDI更适合吧。所以说一切都有比较，没有全面的比较，抛出一个类比难以信服。
另外，那些并非集中于我的技术论点而是质疑我的执着和不喜欢我的态度的人可以休息了。我在这篇文章以及相关讨论之外的人品可能确实不如这位作者。我的态度也不如那些言必称「这样也有道理」的大师老到。你觉得显然Java比ObjC有未来，你没细谈，认为不是重点。对不起，我也看不出来显然在哪里。我只看到Java社区还分裂在用OS toolkit还是自有toolkit上。显然这似乎是个更没前途的分裂。如果每个技术都有这样的软肋，单单把apple的拿来类比copland只能说是牵强历史的小聪明。至于我的态度是否降低了我的可信度，这要看读者的专业度，毕竟专业的人会分别哪些是个人风格，哪些是专业论述。Jobs和Linus的风格绝不同，但是在我看来都是大师。
干嘛删我的帖子。。。 如果middleware你是管理员之一，而且是你删的话，我真得要bs一下你了。现在都说中国没有言论自由，你就是这种反人类制度的维护者！
我修改了我的帖子，现在还有敏感内容吗？ 没有的话，就别乱删除好不好？
我虽然也比较喜欢apple的东西，但是我确实觉得很多产品也有它自己的一些小问题。我看到middleware兄在这里争辩，的确很没必要。
middleware的一些留言：
”
我遇到过n多内存泄露，Java这种有GC的环境带给我的麻烦更多。
我做了6年Java，3年Cpp，2年Cocoa。那些认为GC就是先进的人都只是名词党而已。
而gc是为防止内存泄漏设计的，虽然也能防止dangling pointer，未免overkilling。只有引用计数才是刚好够用的内存管理技术。gc是很傻瓜，但是引用计数才是商业级应用需要的方案。
“
第一. 别以自己用java开发遇到的什么内存问题，就说是gc的问题。因为很可能是你程序写得菜，不知道如何正确使用java罢了。
第二. 我碰到很多人喜欢批判新东西的好处，然后说自己喜欢用一些旧的,手动的东西来显示自己的水平。比如很多人说手动档好，自动档没水平。或者gc不行，自己用reference count才是王道。用windows不好，自己配置linux才是牛比。其实这些人都是井底之蛙，一般说来，都是在一些国内的什么不知名的ＩＴ小企业干过一些年，自以为有点什么经验，但是说句实话，就是做了一点作坊式的软件，把一年的经验用了差不多１０年。看得书籍多半是什么中文译本，根本没有一点国外大企业（比如google，微软）的美国总部的工作经历。然后就开始用自己那点破经历或者破代码来衡量一个语言或者一个框架的问题。如果放眼世界，你不得不承认java和gc的成功之处。java,c#还有拥有gc的程序的使用的确是占了大部分的比例。Apple在wwcd2006上面推出新的obj-c版本，就加入了gc,当时全场欢呼。足以见得你的论调都是个人的一些短浅见识。
再来看看历史。摆出「你不这样做我很担忧」表情都让我想到和Linus争论未来是微内核天下的教授。
还有RISC一定打败CISC（别说CISC是因为x86遗产，去看看关于低耗CPU的文章）。cout比printf强（英语中心思考，没做过国际化）…….
所以遇到先进生产力别那么激动。不是说不能尝试，只是平静点。别整什么copland。
别再喷「王道」「牛逼」。那根本我没说过。微内核未必差，但是别弄的跟那个喷Linus的教授似的。
经历遭到质疑也难免。不过即使是半瓶子醋，是不是copland还是能看出来一些。人是不是快死了不是非得医生。何况说我不是医生的人可信度最多也和我一样。
关于reference counting和GC
我不排斥GC。我质疑了一些使用GC不那么爽的情况，但我也声明可能有我不了解用GC爽的地方（单不爽的地方就是不爽，那些Java代码也不是我一个人写的，如果你觉得写这些代码的都是笨蛋，那你只能接受这个世界。而且，我不认为我的同事和前任比这里的任何人差。而且，似乎有人强调过Java就是给普通程序员准备的）。但如果一个技术和其它技术相比并不是利绝对利大于弊，我对于把它声明为绝对的未来实在怀疑。其实在接触Cocoa之初我打算使用GC，但是实际使用了reference counting之后，我放弃了这个打算。因为我发现，尽管reference counting的正确与否虽然需要人工检查，但是这种检查总是限制在一个函数之内，甚至是一个block之内（这是因为从文档到命名规范，ObjC都比COM时代的reference counting完善了太多）。在单个函数体内部就能分辨正确与否的技术，即使是人工检查，在大型项目里也已经和自动管理无异。如果它能比别的技术实现更简单，更有预测性，性能更好，几乎就是必然的选择。所以在GC和reference counting并存的环境，我会选择reference counting。这也是很多Objective C开发者的选择。
我没有下结论说用GC的人的选择不对，归根结底，用reference counting也不是一个没有道理的选择。如果再加上正确的因素，比如mobile环境，选择去掉GC是一个见仁见智的问题。但我不认为apple的前途是不是Copland是一个见仁见智的问题。因为，对于一个哗众的结论，仅仅有见仁见智的根据是不够的，如果你有一个见仁见智的理由，得出一个惊人的结论，那么这个结论就是没有根据的。
关于Copland
Copland有其特殊性。第一，硬件格局的特殊性，那是一个PC硬件不断追赶学术硬件环境的年代，而今天学术环境和个人环境的硬件已经趋同；第二，当时竞争对手大大在技术上超越，这在当时是无可置疑的，因为所谓的超越也就是是否能追赶学术环境的技术（比如内存保护，抢占多任务），而今天仅仅用一个有没有GC就来说明竞争对手已经超越，实在牵强。且不说上面见仁见智的问题，竞争对手也各有各的软肋，Windows的GDI，Java的toolkit和其它问题；Android的硬件差异问题（另外风闻它的API风格实在巴洛克，没有证实）。这样的环境让Copland重演令人怀疑。
关于经历
经历这个东西，有了的人就喜欢摆摆，我也如此。有利有弊吧。我尽量不光说自己干了多少年，也蜻蜓点水地说说都作了什么(当然有时后者还是不免被略掉)只是告诉大家，如果你还没做过这些，这些都是会遇到的。如果谁遇到的和我相反，说出来讨论一下比直接把我的经历扔到一个小公司作作坊开发恐怕对读者帮助更大。另外我只是说我的选择是经历过这些之后作出的。给大家一个参考。你可以选择同样思考那么久得出自己的相同或者相反的结论，也可以先参考我的。比如我就喜欢对有争议的事情相信写代码多，写代码久的人，Linus算一个吧。OS X的风格始终不离UNIX，所以我相信它的工程师。Jobs是NExT的推动者，我相信他为技术用户和普通用户作出的选择。当然我自己的经历除了我的蜻蜓点水地描述几个遇到过的问题没有他们那么公开的凭证。至于这是摆资历，还是说我用了这么久思考某些问题，自行认为吧。
Great Article!
讨论也很精彩，就是火药味太浓，不过也没什么。
长远来看，编程语言的动态性，更加进一步的抽象性，肯定是未来。内存管理是小case，随便找个程序员都OK，经历两个月的泄露，程序当机梦魇之后，在合适的地方release曾经alloc或retain或copy过的对象就成为本能。 线程管理才是更大的问题，相比简单的retain，release机制，线程间的同步，对资源的访问本身就难以掌握，更何况加上让他利用越来越多的CPU和GPU计算能力？苹果已经给出了它的解决方案，GCD和OpenCL，分别对应与应用级别的软件和大规模并行计算。其基本思想都是将底层硬件抽象一层，程序员拆分任务，将任务交给系统，系统负责创建线程，并在其上执行任务，程序员只需安排任务的先后逻辑，从而避免显式的创建线程，大大减轻了开发的难度。
在单CPU时代，编程不外乎就是操纵内存，但是这十分之简单，GC的出现虽然能够让一批初级程序员也能编程，但是只要有要需要榨干硬件最后一滴性能的需求，手动管理内存就必然存在也必将一直存在下去。但在如今，多核CPU，超级显卡（显卡的某些计算能力远超CPU）的出现，使得程序员面对新的难题。即使是一流的程序员也难保他的多线程程序没有问题，即便不会有死锁等问题，开发一个自适应硬件的程序也依然超出了普通程序员的能力范围，所以这个事情交给系统去做，再合适不过。
苹果为Objective-C增加了新的语法，block，也就是各种语言竞相支持的闭包特性，将其完美的应用于GCD和OpenCL。我认为这解决了一个很大的问题，是苹果下个十年的基础。
当然也许以后苹果会用更加灵活的MacRuby，或许是其他，但是这些真的不是问题。无疑，John想的更远，但是苹果真的一直在动作，一直在做一些伟大的工作，如果需要，我相信苹果可以用ruby或其他语言重写操作系统上层框架，对开发提供原生的ruby支持，但是现在真的还不是时候，因为更加灵活的语法和操作带来的好处抵消不了虚拟机的低效。那一天，也许要等到下个10年了