重访 Copland:苹果编程语言和 API 的未来(上)

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

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 终于来了。不管「未来」到达与否,开发者为了一个损坏的指针不断的遍历内存,多少是有些愚蠢的事情了。世界已经改变,苹果亦应顺势而为。