重磅级科技文章大多出自有软件开发背景的作者，须渗入底层才知道事情的始末——电脑世界绝对是这样的。平台技术横向比较的文章我所见不多，也许开发者都清楚，但少有人写出来吧。
2005 年，约翰·席拉库萨（John Siracusa）连发三文，预测苹果将会遭遇平台危机。未想 iPhone 的兴起延迟了危机的发生，五年后，他发文检讨，但仍认为，不跨越内存管理的障碍，危机仍将隐现。
这是上篇，下篇将于明日发出。原文链接甚多，译文不便一一列出，见谅。
预测科技业的未来是件棘手的事情 — 不妨看看比尔·盖茨十五年前的预测结果 — 虽如此，预言的诱惑总是强烈的。我亦因此闻名。有时候我猜的挺准，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 年 System 7 开始支持虚拟内存，作者意指，初代麦金塔不支持虚拟内存也就罢了，现在已经过去 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 终于来了。不管「未来」到达与否，开发者为了一个损坏的指针不断的遍历内存，多少是有些愚蠢的事情了。世界已经改变，苹果亦应顺势而为。
69 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.
没有原文链接啊，想去看看下篇呢。
http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars
这篇原文属于很扯淡的论点和很小题大做的论据的组合，里面的胡说八道多到无法一一列举。。。个人觉得译者的辛苦略有不值。
我同事有2款android软件 2款iphone客户端
从事as工作 平时也用ruby on rails 和php
确实没说错 objective c真的是一门很一般的语言。。。。
就是不断的要考虑内存泄露
webOS v.s. mobileOS，值得思考。
ruby和php等都是动态的脚本语言，根本不需要编译。这点和Objective-C是不一样的。Objective-C更象是拥有动态特性的高级编程语言。
Objective-C也在发展，2.0的特性都很不错。其实Objective-C和Java非常相似。
至于Cocoa的api，iPhone的成功足以说明Cocoa的api设计是优秀的。
比较扯. 你用ruby去搞一套ui framework同样要解决cocoa解决的所有问题. 语言和框架, 根本就不是同一层次的东西.
Objective-C比C 先进多了, 何来落后之说. 不知道这个作者是不是真的了解Objective-C. 而Cocoa框架无疑是成功且稳定的, 否则就不会有iPhone的成功.
汗, 我本来说的是”Objective-C比CPP先进多了”. 系统把加号吃掉了~
补充一下, Objective-C既有CPP没有的运行时特性, 又不像Java和C#那样臃肿. 如果我没理解错这个作者的意思的话, 那么采用Java的Android要比iPhone更先进? 另外作者想把程序员从指针里解脱出来的想法是好的, 但却是很不现实的. 因为这必然要以性能损失为代价. 而iOS没有虚拟内存也很正常啊, 闪存又不是硬盘, 禁不起频繁读写的折腾的.
有些道理，写了7年Java，最近娄了一眼obj-c的书，觉得内存管理这块的确很麻烦。另外，最近sunpinyin的team正在打算将sunpinyin移植到iphone上，内存管理者块需要做很大调整
不知道楼上有没有人用过mac ruby
静态语言之中也有scala这样的强大合体语言
硬件还没快到那种程度, android使用java其中还有许可证的原因,
当然还推出了NDK
另外还世界上还有很多开发者是使用C/C 的, 转换到Objective-C
基本上很快就能适应.
@ Bono “补充一下, Objective-C既有CPP没有的运行时特性, 又不像Java和C#那样臃肿.”
大哥，你说话能不能客观一点。你的意思就是说ob-Ｃ最好罗？或者比CPP,Java,C#都优秀？有没有搞错，你看看obj-C的使用率才多少。而且很多时候，很多人想做iphone的开发，但是就是不喜欢obj-c这语言。另外，其他喜欢Java或者Cpp的人是不是又可以按你的逻辑来喷你，说：”Obj-C即没有Java和C#有那么成熟的内存管理以及强大的内库，又不像CPP那样灵活和被广泛使用，还比C语言要臃肿。”
受不了，总有一些人，对自己喜欢的东西只说好，然后还千方百计地贬低其他同类东西。我也喜欢mac，但是很多时候我知道苹果做出来很酷的东西的目的就是为了赚我们的钱。
作了好几年cpp的开发，其实内存管理的重点并不像一般人想的那样在于克服内存泄漏，内存泄漏这个问题在cpp里用很多工具都能很快解决。相反，cpp最严重的问题是内存过早被释放，也就是dangling pointer。dangling pointer很多时候很难解决，甚至知道了root cause一清二楚都很难找到solution。而solution其实很简单，就是用引用计数或者gc，但是这两者在cpp里都很难（我知道cpp有shared_ptr，但是因为它不是语言特性，所以很难在一个项目中完全贯彻）。而gc是为防止内存泄漏设计的，虽然也能防止dangling pointer，未免overkilling。只有引用计数才是刚好够用的内存管理技术。gc是很傻瓜，但是引用计数才是商业级应用需要的方案。
其实这篇文章的出发点就是错误的。它的出发点是Apple历史上犯的错误会重演。其实Copland这个危机从本质上说是不可能重演的。因为Copland是当年企业计算和个人计算平台差异过大，导致各个PC厂商寻找自己的quick and dirty方案，然后在硬件差异缩小的时候又开始改进方案，而这时微软跟进的比较好，Apple产生了滞后。现在的情况不同，即便是手机也已经具备了运行完整UNIX的能力，这种滞后的危机很难再重现。
好吧, 我的意思其实是, Obj-C的运行时比CPP先进~ 而CPP本身确实很先进, 先进过了头, 有时甚至是为了先进而先进. 而对于富UI的客户端应用, Obj-C明显更加适合.
按照这篇作者的观点CPP现在应该没人用了。另外，如果你是一个那么厌恶指针的程序员，你大可以大可以学习JavaScript开发Web应用也能有能多东西可以做，Web应用也代表了未来。就个人而言，你可以纯粹等待这个Web的大未来，你也可以一边学习指针，Objective C, CPP等等，在不断学习中等待这个未来。
而且，所谓的垃圾回收技术真的那么难么？Apple没有这样的技术么？不是的。正如iPhone不支持复制粘帖，不支持多任务一样，非不能也，是不为也。Apple也不是没有试过对Java寄予厚望，Jobs刚刚回到苹果的时候苹果对Java的投资也是很大的，结果怎样？正如Tweetie的作者所说，Java和Air都支持跨平台（垃圾回收更不用说了），但是大家没有看到Java和Air开发出了具有好的用户体验的产品？一味地追求新技术并不能做出不入俗流的产品的。
最近从java出来改写cpp代码，确实经常遇到指针的问题，但是看看GC这东西对性能的消耗就知道了，只要手持设备还不能做到台式机这样的高性能（其实就是做到高性能了，耗电怎么办，JOBS一定会说“支持GC，待只机一个月你们选一个吧”）这种机制就还无法普及，但是在mac开发方面确实要有这样的枝术了！其实好技术是要大厂商引导和标准化的
我个人也认为 John Siracusa 这次有点小题大作，他提的这些东西没多重要。
你盖房子的钢筋拧的再牛,砖头再好,地基再牢固,也只能建造出个猪圈.不是人住的.向苹果学习巴.回头是岸.
其实Java也没有想像的那么完美。我曾经为了一个Java app的内存泄漏调试了两个月。
Java就是一坨……
Object-C基于引用计数的内存管理很好用啊，至少对C/C 程序员不是问题，另外苹果自带的Instruments工具可以很方便的定位内存泄露。
我以前是写C/C 的，现在做的是Symbian C ，至少我挺享受Object-C的，————当然，也可能是因为Symbian C 太烂的缘故-_-!
认为Java没有指针的都是缺乏对Java基本理解的代码民工。Java没指针你怎么拿到的Obj？？？？Java没有的是指针的移动。
iPhone上写Obj-C没有GC而的引用计数器是非常原始的内存管理机制。引用计数的问题很多，尤其是涉及同时操作共享资源的情况下。如果这是好东西，那么Mac上可以开GC就&^%^%$@#!@~~~~了。
Obj-C不能算特性最优秀的语言，苹果利用规范和审查来保证实现的质量，这无疑比Java,Py等在语言的特性上直接约束要低级。
构架和语言要分开看。
Cocoa强大优美和高效。程序员可以做出非常快的做出漂亮的效果。但是这和Obj-C关系不大。WebOS已经证明了不用Obj-C也可以。Android在改进UI后会是个新例子。
实现也要和语言分开看。
苹果自己写了非常漂亮的实现。同时也利用文档规范，审查，提供金钱激励来保证第三方开发者的实现质量。但是这些就不单单是语言的问题了。
苹果动用他能动用的资源来达到目的：漂亮好用的程序。而Obj-C充其量只能算一个还算过得去的地基。不是烂泥而已。
如果JavaRubyPy或者别的什么语言调用同样的功能有多少人会选择Obj-C？
如果几年后手机的内存和电力都在硬件上有突破，有多少人还会认为没有GC和C的速度是优点？
TO Huajun 所谓的垃圾回收技术真的那么难么？Apple没有这样的技术么？不是的。正如iPhone不支持复制粘帖，不支持多任务一样，非不能也，是不为也。
又见典型果粉式推理,能而不为其本身也只是一种不太常见的战术,该不该和有没有都需要事实论证,就是真的以前每次都玩这手,这次是也不一定成立,而且能而不为动机还可以很灵活.直接拿来用就有逃避举证的嫌疑.
再说本文作者只是想提醒apple改进api,并没有说apple什么不好,大家讨论下c和java孰优孰劣也就罢了.如果这样非要向一切对jobs提出要求的人发动攻击的话,万一将来要.求实现了的话,估计就只能一概以能而不为.
总结 难怪apple有这么多的事能而不为
那些鼓吹某某技术制胜的都是井底之蛙的代码民工。
殊不知，多数情况下起决定作用的都不是技术，市场定位、工业设计、营销策略、企业形象都远比这个重要。
只要能带来好的用户体验，用户谁会关心你用什么语言实现的啊？用户知道这些吗？用户犯得着知道这些吗？
其实我感觉是作者在为写iPhone程序要手动管理内存发闹骚，有内存管理机制的语言开发起来确实很舒服，但是其开发的程序性能有时真的不咋的，看看c＃，java写的桌面程序就知道了。obj－c里用引用计数的方式管理内存是最好的折衷，及避免了c/cpp里内存管理的大问题，也避免了像java/c＃因引入GC导致性能下降的问题，这方面其实obj－c更胜一筹。
说来说去Objective C不过就是少了个GC而已（而且只是mobile版少）。GC不是什么银弹。而且GC在多线程环境开销巨大。GC对程序开发的complexity reduction并不比reference counting有数量级的提高。所有这些都说明，研究GC不是不可以，建议加入GC也好，可是给一个拥有成熟的rc管理方式和其它优势的平台写这么一篇东西实在是小题大做。
强调计算机性能的人往往就忘了这些东西如何扼杀人的性能。虽然偶尔有反复但是几十年来语言的发展史都在不停的扇计算机性能派的耳光~~~~
如果没有Android的话计数器这种原始的内存管理方式还真容易被说成是移动设备开发的先进之处。好在有竞争者的技术可以比较。所以我们在忍受计数器的同时也知道有更好的办法。所以脑残的单键鼠标能欺骗用户一时但是却不能长久。
我觉得APPLE看得很清楚：开发人员的水平比所谓语言特性等等东西重要得多！能够充分发挥高水平程序员能力的语言就是一个好的语言。
纠缠技术细节没有意义而Obj-C和C的关系太密切很多地方落后不是今天大家才知道的事情。
AppStore巨大成功让一些技术不牢靠的人开始用美元来怀疑自己的知识体系了。
作者无疑保持了清醒，苹果有很多技术之外的办法帮他在一块一般的地基上构筑漂亮的建筑。但是面对将会越来越激烈的竞争和地基本身的老化等因素。向苹果很久前把MacOS迁移到Unix上一样，开始为自己寻找一块岩石来为将来奠基是一种明智的大局观。
苹果从系统角度看，开发者从自己app的角度看，难免有冲突。mac os x上，苹果在objc 2.0上引入gc都非常犹豫 即使现在还是默认关闭的。到底是把成熟的技术用到极致还是用更先进的技术，一直是问题。当时盖茨要把windows vista用c sharpe 重写 结果vista慢的没人用 反而当时16位dos内核的win 95（当时不算先进）成功。
如果新技术能带来用户体验的改变，苹果一定会上比如unibody，multi touch，反之则会很犹豫。所以苹果的保守我可以理解。
估计这个作者有一次要吃瘪了。有点庸人自扰。
我做了6年Java，3年Cpp，2年Cocoa。那些认为GC就是先进的人都只是名词党而已。
这篇文章出人意料的引发了巨大争议，文章本身还是很精彩的，这样站在开发者角度的文章很不错
不是Obj-C缺GC，是iOS缺GC而已。拿高级脚本语言来比较Obj-C没什么意义。AppleScript是最接近英语语法的语言，不如直接用AppleScript来写程序得了？
编程语言从早期的机器语言发展到现在，每增加一个特性就需要额外的开销，没有免费的午餐。而我们对于编程语言的取舍就象滑轮一样，要想省力就得浪费距离，要想省距离就得多出力。
有人说，现在得计算机硬件发展很快啊，已经可以无视高级脚本语言得开销。但问题是，现在得程序得复杂度也在增加啊。
一篇很扯淡 胡说八道的文章，可惜了辛苦了译者。
CoreFoundation是苹果的核心类库，对应的类似库有glib，STL等，objective-c提供了方便的语法来使用这个类库，其动态运行时特征结合的静态、动态语言的优点，AppleScript充分利用了这一点来实现对GUI程序的操控，目前只有Apple实现了全系统范围一致的操作性，就像unix下的通过管道来实现多个程序的互联完成特定的工作。iOS也提供了类似的特征，可惜这个特征还在发展中，并没有提供给用户。
要说iOS有什么不爽的地方的话，就是Cocoa Touch只提供了Object-c的API，不想ＭＡＣ ＯＳＸ同时提供了Carbon API，可以只用C、C 开发。
内存管理一直是大问题，同时也一直不是问题，GC并不是包打天下的方案，objective-c同时提供了引用计数的方案和GC的方案。
作者说的没错啊，的确iPhone上的大多数App都应该通过某种类型的高级语言来实现，但是现在只能用Objective-C，对开发者的门槛高了很多…至少[myArray objectAtIndex:i]比myArray[i]要多打好多字吧
这篇文章的技术方面有可圈可点之处–但也并非无懈可击。反而起了一个标题党的名字–Copland，怎么会不引发争议。
混淆语言构架和实现的结果就是一团浆糊。
扎了一针觉得挺爽，于是四处为针头辩护。殊不知起作用的是针管中的xxx。
话是这么说, 但如果没有Obj-C, 也就不会有Cocoa. 用C/CPP是实现不出Cocoa那样的自由度的, 因为没有运行时, 也就没有运行时多态.
这是一种向下看齐运行时多态又不是Obj-C的独特特性。
语言和开发框架是没法完全分割的。看看STL的insert copy行为就知道这就是没有内存管理的语言拥有的框架。
CPP的运行时多态本质上还是编译期的, 你必须要确定基类和派生类的继承关系, 编译才能通过, 之后的多态也是体现在派生类之间的. 而Obj-C的运行时多态是真正的运行时, 也就是说你根本不需要知道某个对象究竟是什么类型, 你甚至可以调用某个对象在代码中根本不存在的方法, 编译器只会给你警告, 因为在运行期, 一切皆有可能.
没有一种语言是完美的。程序员也不奢求完美的语言。需要的是一个比Cpp简单，而又性能可靠，同时有一个优秀OS支持的语言。很多比Objecive C某些方面强的语言并不能兼顾所有三点。回到原来的话题，没有其它语言或者OS能让Apple的系统重演Copland。
请看下面这篇文章的”Smalltalk 的启示”一节.
http://blog.youxu.info/2010/02/28/why-mac-os-x-for-programmers/
Cpp有些走火入魔–剔除运行时的一切bookkeeper，又在编译时大玩花活。结果是写出一个能符合标准的Cpp编译器都很难。Cpp一直标榜no one true way。但是在上面两个方面做的比任何语言都极端a。
把火力集中于C 是一种向下看齐而已。。。为啥没见人喷Ruby呢。。。啊。。。MacRuby。:)
评论里高手如云啊，难得也没有乱喷粪的，除了那个说脑残单键鼠标的–话说用了10多年的左右键鼠标，现在真觉得单键鼠标也是一个选择，可惜windows天生不是为单键设计。
支持引用计数的，Froyo 的性能和耗电就摆在那里，他们看不见。
支持Obj-C的，MacRuby/RubyCocoa也摆在那里，他们看不见。
支持单键鼠标的，苹果自己的右键/双触操作就摆在那里，他们看不见。
他们最善于向后或者向下看寻找别人的缺陷一览众山小。我猜测本文作者想说的其实就是：苹果，你一定不要如此。
@OBJCMeansNothing 这篇文章的作者确实可能有感而发。不过他的论证过于线性类比，而技术发展的某些参数是有拐点的。就象用一个简单的向下看齐的标签是不会消弭别人的论点的。
我很好奇，上面那些大谈垃圾收集和JAVA不需要指针的到底有多少人是真正了解指针的呢？有时候我真觉得指针是个好东西，可以防止那些本质上不适合做程序员的人进入这个行业。
我觉得 JAVA 之所以那么流行是因为它够简单，简单到让一些只会组装的代码工人也以为自己是程序员，简单到让企业很少的成本就能找到人。
Java不是不需要指针，没有指针Java也无法得到对象。以为Java不需要指针的程序员和不识字的杂志编辑差不多。
王小波笔下的傻大姐能很好的缝扣子。那么本质上扣子缝的不是那么好的人使用更加“简单”的缝纫机就不能更快而且更好的作出东西？
@middleware “给别人贴标签”本身也是一种标签。贴标签不一定有问题。没有贴到符合这个标签的人或者事情上才是错。“向下看齐”这个标签不知道贴对位置没有。
@OBJCMeansNothing 不要东拉西扯了吧，同意不同意，要能容下别人的意见。
@OBJMeansNothing 是的，那也算标签，不过是个显而易见的总结。只是你的向下看齐是个不明就里的定义，这种粗糙的论证方式比原文的线性类比还粗糙。
“不明就里的定义”同样也是不明就里的定义….
为什么我要容忍逻辑上有问题的意见呢?Obj-C会容忍多释放一次引用计数器吗？：）
当年我感慨Cpp博大精深的时候是喜欢这种形式游戏的。不过与Cpp和Java奋斗多年之后终于在一个实用的平台上开发、工作、娱乐，我现在还是喜欢通过基本的常识来讨论。即使是开发10.6 only app，我也不会用GC–这是我五年内的选择。我遇到过n多内存泄露，Java这种有GC的环境带给我的麻烦更多。各种debugging工具和静态分析工具已经让很多原本被认为GC独有的优势不值一提了。
今天Android和Froyo就在那GC用的好好的。至少说过三遍了而您总是拿着五年前的CPP说事避而不谈今天的东西。“向下看齐”的标签贴在您身上一点都不冤枉。
如果你坚持说GC是自动管理而RC是手动，那就和声称简体字能提高人民文化程度差不多。虽然大陆的简体字也用地好好的，我不认为港台的繁体是向下看齐。
@OBJMeansNothing 你说我老是说cpp不说今天的技术，但是你没有明白我的论点是什么。我没有说今天没有Objective C以外的技术超过cpp，我只是说Objective C以最小的代价解决了cpp试图解决而没有解决好的技术。也许这就是你说的向下看齐吧？如果这样我喜欢这种向下看齐，这个叫minimal overhead。You should find a solution as powerful as possible, but not more powerful.
“恰到好处”或者“过犹不及”需要特别用13个英文字母来表达吗？难怪我说的中文您一直没有理解而是一直在曲解误解，原来是美国友人。
汗一个是英文单词非英文字母。
@OBJMeansNothing 个人只是比较喜欢爱因斯坦的说法借用一下。无意在国学方面冒犯。
@OBJMeansNothing 其实我是从和同事讨论知道这个句子。然后又在Art of UNIX Programming里看到。这本书替代Mac OS X，一开始我认为这只是Apple为了走出危机的权宜之计。但是这十几年OS X的发展还是紧扣UNIX文化的，而且把Apple原来的优势结合的很好。可以说我是作为一个UNIX工程师喜欢上Mac的。所以我没想太多那书里英文的翻译，只是经常摘用。
其实开发技术并非一味求新。也有固守优秀文化的一面。Copland危机是因为当年PC无法应用UNIX成果，而后Apple跟进不及的危机。所以Copland其实是守旧的危机而不是创新的危机。我觉得作者其实没有搞清历史脉络。比如，当年的OS都是monolithic，今天的OS都是replaceable模块。技术格局变了，Copland一去不返。即使Objective C真有缺陷需要改进，也并非Copland的重演。
有些个人经历确实不吐不快。我面对过很多有GC和没有Gc的平台的bug。一些在无GC平台上很容易用glue code一类工具看出来的内存泄漏，到了GC上就是要几天才能看出来的缓慢增长–因为GC的行为不是短期可预测的。一些在无GC平台上很容易fix的crash，到了GC平台上就是奇怪的行为。而无GC平台上不好fix的东西，多半即使用GC也不行。不好说GC一定没有用，可我就不能认同作者就那么有把握说没GC就是Copland。
苹果可能已经在酝酿替换 OBJC的东西了。
看来他们放出的 WWDC 视频要找时间看看。
争论已经足够了。
Time will tell
http://daringfireball.net/linked/2010/07/06/jesper-cocoa
之前在Windows Mobile上面开发，后面转IPhone开发的，中间从CPP过度到Obj-c表示没什么压力，那些表示有压力的只能说自己比较懒，在程序员的生涯中本身就是要不断学习的。另外讨论语言这种东西是没什么意义的，要我说框架才是王道，好的框架能够让你在短时间内写出优秀的应用这个才是最重要的