您的位置:知识库 » 编程语言

苹果编程语言和 API 的未来

来源: apple4.us  发布时间: 2010-06-23 11:33  阅读: 11936 次  推荐: 0   原文链接   [收藏]  

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

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(原 iPhoneOS)的崛起令人头晕目眩。在台式机上多年不见得配置重新出现: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 终于来了。不管「未来」到达与否,开发者为了一个损坏的指针不断的遍历内存,多少是有些愚蠢的事情了。世界已经改变,苹果亦应顺势而为。

  比以往更紧迫

  哦,我知道你在想什么。你们这些 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继任者的问题仍顽固的存续着。这一回,我不再加入年份,但请放心,我仍将观守并等待。我只是希望我不是唯一的一个。

  英文原文:Copland 2010 revisited: Apple's language and API future

0
0
标签:苹果

编程语言热门文章

    编程语言最新文章

      最新新闻

        热门新闻