澳门新葡亰信誉平台游戏Chris Lattner 访谈录(上)

by admin on 2020年4月5日

此外,模块稳定是 Swift 5 的第二目标。

Swift 3
的正式版已经基本完成,是时候让我们回顾一下这个版本了,从开发过程中汲取经验,并用于总结我们(Swift
社区)在这一年内所做的事。总体上来说,Swift 3 毫无疑问将是一个 amazing
的版本,我们完成了很多出色的工作。感谢所有为它付出的人。相比于立刻着手推进新计划,盘点过去、展望未来同样重要。

澳门新葡亰信誉平台游戏 1

ABI 稳定的实现原本是定在 Swift 4 ,随后宣布被推迟。Kremenek 当时表示:在
Swift 4 相关原理被修正之前,将会推迟 ABI
稳定性问题的解决,这样做能够避免 ABI 不稳定的风险。不知这回 Swift
5,能否真的实现呢?

可能的 Swift 4 第二阶段工作

如我之前所提到的,在这个点上不可能知道还有多少时间留给第二阶段,因此也不知道第二阶段能完成哪些工作。核心团队也希望比
Swift 3 更早完成 Swift 4 开发版的合流,以便在版本发布之前有更多时间修复
BUG,仔细斟酌。

也就是说,我乐观估计我们能够挑一些大家都想要的新功能来开发。为了让你对这些功能有个概念,我列了张表。请注意这并不是开发的计划或承诺,而只是列了一些大家都希望有的功能:

  • 反射:核心团队正致力于为 Swift
    添加强大的动态机制。举个例子,Swift 3
    中大致完成了数据反射的基础结构(已被用在 Xcode 的 memory debugger
    中)。我们应在这些基础结构之上,搭建一些强大的面向用户的
    API。同样,我们想要设计并实现动态方法反射的 runtime 与 API 支持。

  • 最重要的并发:Actors、异步 / 等待(async /
    await)、atomicity、内存模型(memory
    model)以及相关话题。这些是大家都想要的,因为有了它们,就可以在客户端、服务端等之上开发更多新功能。我们计划在第二阶段正式讨论这件事,但非常明确地告诉大家,新的并发模型在
    Swift 4
    发布时还无法完成。我们需要超过一年的时间来进行设计与开发,我们也希望把这件事做好做对。需要这么多时间,也是因为在开发内存所有权模型之前能更深入的理解它。

  • 泛型改进:泛型的开发计划中包含来许多激动人心的功能,能改进现有泛型系统。在提升标准库的
    ABI 稳定性时并不需要这些功能,但它们会使 Swift 的泛型更加强大易懂。

  • .swiftmodule
    的稳定性
    :在某些方面我们需要使“.swiftmodule”的二进制文件格式稳定下来(或用不同的机制替代它),允许开发第三方的二进制框架。这个工作量很大,并需要标准库
    ABI 保持稳定。

  • 新的脚本功能:包括正则表达式、多行字符串字面量等。有了这些功能,Swift
    在密集型文本处理任务及搭建 web
    等方面会更有吸引力。这些功能也有助于完善字符串模型。

  • 属性行为:这一功能承诺为现有属性模型提供强大的抽象能力。在被推迟的
    SE-0030 提案中对它有完整描述。

  • 其他功能:子模块、数值类型间的隐式转换、导入 C++ API、hygenic
    macro
    system、尾调用约定、枚举类型遍历、带类型的“thorws”、用户定义属性、抽象方法
    / 类、更好的 SIMD 支持、非 @objc
    的动态支持、支持数据并行、更高等级的类型…

  • 语法糖:我不会把它们全部列出来,但有大量零散的小提案会经常出现,特别是那些其他语言中出现过、用于解决特定问题的。这些在
    Swift 4 开发中都属于最低优先级。

好了,这是一封超长的邮件,列出了一些关于明年要做的事的想法与点子。有一点要提醒一下大家,目前
Swift 3
尚未完成。当对代码的破坏性改动(将要)完成时,需要留有一些时间来修复 Bug
并提升代码质量,这对于正式发布版很重要。

我认为如果我们马上花一些时间来讨论明年开发计划的一些基本事项,会很有帮助,然后再从概念上分解一些第一阶段的特性。只有在对它们有深入了解之后,我们才应该开始写一些提案。核心团队不希望被太多提案淹没,以至于无法跟踪它们的进展,或让我们无法专注于那些高优先级的项目中。

谢谢大家。再次提醒一下,如果大家想要更深入讨论某个话题,请重新开一个分支。

本文由 SwiftGG 翻译组翻译,已经获得作者翻译授权,最新文章请访问
http://swift.gg。

荣誉

  • 2016年被评为“创造未来的25位当世天才”
  • 2013年获得 ACM 系统设计大奖

Kremenek 在 Swift Evolution
中更新了 README.md 文件,并概述了 Swift 5 的核心内容和重点领域:

大家好呀,

音频:ACCIDENTAL TECH PODCAST 205原文:PEOPLE DON’T USE THE WEIRD
PARTS本文首发杂志链接:《iOS成长之路》- 2017夏

(文/开源中国)    

Swift 发布计划

在接下来一年里,核心团队预计会发布两个主要的版本:2017 年春发布 Swift
3.x,2017 年秋发布 Swift
4。除了主要版本之外,我们也会发布一些小的更新(如 Swift 3.0.1)来修复
Bug,或满足核心库的需求,或其他的
swift.org 的项目。

自我介绍

1. 你怎么看待自己?

我是个程序员。我喜欢写代码。我编程有很长时间了。

我在读博的时候就开始写 LLVM 了。当时 LLVM
是我的博士研究项目,我想把它做成工业界中颠覆性的产品。当时我异想天开,尝试了各种架构设计,想解决以往编译器所有的弊端
— 结果当然没有如愿。我毕业后,就希望能接着搞 LLVM
,当时只有苹果允许我入职之后继续设计并实现 LLVM
。我想都没想就加入了苹果。

澳门新葡亰信誉平台游戏 2

Swift 4 第一阶段目标

为了专注于代码与 ABI
的稳定性,核心团队对第一阶段的工作有一个初步的讨论。下面是我们对第一阶段功能排序后的结果:

  • 代码稳定性相关功能:这一部分工作量相对较小,但很重要。举个例子,我们需要类似于“-std=swift3”的编译器标志。我们也需要一个新方法来开启一些大型的功能,这些功能尚在开发,并不稳定,有了这个方法,调试会更简单。

  • 适应力(Resilience):这个功能提供了一种方式,在保证 ABI
    稳定性同时,公有 API 可以随时间改进。一个例子,我们不想让 C++
    的“fragile base class” 问题发生在 Swift
    中。更多设计与实现上的工作已经在 Swift 3
    中完成了,但仍有重要工作未完成,包括模型中用户可见的部分(例如新的属性)。

  • ABI 细节:代码生成模型中仍有大量细节需要审核与改进。这一部分与
    Swift 开发更相关,与 Swift 的演进关系不大。

  • 泛型改进需要在标准库的基础上进行:我希望条件一致性能在功能清单中处在最高位置,递归协议要求(recursive
    protocol
    requirements)与更强大的关联类型约束能处在随后的相近位置。然而,标准库的开发者们需要大量时间来解析出至关重要的部分,最终消除那些“_”协议,并正确展现标准库中的公有
    API。

  • 字符串相关改进澳门新葡亰信誉平台游戏,:字符串是 Swift
    中最重要的基本类型之一。标准库的开发者有很多点子,能改进它的编程范式而不影响到提供
    unicode-correct-by-default 范式。我们的目标是在字符串处理上比 Perl
    做得更好!

  • 内存所有权模型(Memory ownership
    model)
    :许多系统开发者,以及想要可预测及确定性的性能(如在实时音频处理中)的人们,都非常希望
    Swift 中能有一个(可选的)类似于 Cyclone / Rust 的内存所有权模型。从
    Swift 4 的目标上来说,这个功能很重要,因为它从根本上改变了
    ABI。这一模型会通知编译器“inout”事件的产生,解释底层“addressors”如何在
    ABI 中运作,影响 Swift runtime,并对类型系统及命名管理产生显著影响。

我们对上面这些功能都有了一些想法,但它们在正式成为提案之前仍有很长路要走。我期待它们会在
Swift 4 的早期成为主要讨论内容。不仅如此,由于我们还没有全部找出那些影响
ABI
稳定性的部分,可能还有其他需要增加的条件。最后,我们也可能选择其他一些对
SwiftPM 这个包管理器,或其他对 swift.org 有高价值的小功能。

工作经历

  • 2005年 – 2017年供职苹果,前开发部高级总监,架构师
  • 2017年开始,担任特斯拉副总裁,负责自动驾驶

前几日,Swift 语言开发项目组主管 Ted Kremenek
邮件称,Swift
4 更新工作已基本完结,将在今年晚些时候正式发布。同时,Swift 5
的开发工作即将展开,鼓励开发者提交提案。


谈管理

6. 在职业生涯中,你在 LLVM
上鞠躬尽瘁,但我们发现这几年你更多的工作是在管理上,你自己怎么看这种转变的?

我虽然做管理了,但是我依然喜欢写代码,而且我每天都写,因为我就是个极客嘛。而且,其实我很早就开始做管理的工作了。不过我一直是作为技术领导人的角色带
2 到 3 个人的,我只是在写代码方面把把关,给他们提提建议这样。

后来带的人多了,队伍也大了。我不仅管程序员,还管小组经理和其他技术领导人。虽然我一直喜欢写代码,但是管理对我来说是一个必须要去做的事。现在回过头来,我觉得干得还不错。跟大家一起工作之后我知道很多事协同工作效果更好,和同事交流你就会理解他们的想法,这样我就可以制定更好的计划路线。

其实我没感觉整个过程有什么不同。直到今天我还夜以继日、废寝忘食得写代码,我并不是坐那边动动嘴皮子,指挥别人干活的老板。我其实每个周末都在写代码,我很忙的。

Swift 5 的重中之重将是 Swift 标准库的 ABI 稳定性。在 Swift 4 中,ABI
实现稳定是“目标”,但在 Swift 5 中,ABI 稳定是“必须”。ABI
稳定性是语言成熟度的重要转折点,不能再延迟。Swift 5 将先为 Swift
标准库提供 ABI 稳定。ABI 稳定将有助于操作系统内置 Swift
标准库和运行库,兼容基于 Swift 5 及更高版本构建的应用程序。

提示:这封 email
长得吓人,其中涵盖了各方面的话题。比起直接回复,更好的选择是开一个新话题来讨论。只需在主题上标记“[Swift
4]”即可。

主要成就

  • Swift 之父,主要作者
  • LLVM 之父,主要作者
  • Clang 主要贡献者

作者:Erica
Sadun,原文链接,原文日期:2016-07-29
译者:wiilen;校对:saitjr;定稿:CMB

苹果与特斯拉

澳门新葡亰信誉平台游戏 3

11. 苹果好像一直是个封闭的公司,你们内部对于开源怎么看?

苹果其实有开源的传统。 LLVM
虽然不是始于苹果,但是最终是苹果完成并将其开源。Clang
则完完全全是生于斯开源于斯。还有其他工具,比如
LLDB,libc+,以及compiler-rt 都是如此。

所以对于 Swift 来说,开源只是时间问题。当年从 Swift 1.0 到 Swift
2.0,一切都乱七八糟。当时我们重点在开发错误处理机制,还有协议、拓展等一系列重要的功能。所以开源
Swift
1.0,并不是一个好选择,因为这些重要的东西都没有,而这些开发是当务之急。当
Swift 2.0
到来的时候,我们才有空去开源、去做社区拓展和论坛搭建。开源社区可以帮我们修复细节,我们这时候可以更多的投入在架构设计上。

12. 苹果最让你怀念的是什么?

苹果是这样一个公司,你可以选择你喜欢的东西,然后努力工作去实现它,最终你的工作会落实在产品上,影响亿万计的人。

有很多公司,你可以努力工作,但是不一定能做你喜欢的东西;你做出来东西,可能会被束之高阁;你做的产品,也许最后很幸运的发布,但是并不一定有很多人会用。在苹果,你的工作可以真正改变世界,很有成就感。

13. 你觉得到特斯拉之后,还会努力为 Swift 做出贡献吗?

特斯拉的工作非常有挑战性,这是我最开心的地方。我现在还没入职,所以也不知道我之后对
Swift 能做多少工作。也许我还会夜以继日的发 Pull
Request,也许我就周末写写 Swift 代码。我应该会从各个方面 —
无论是顶层设计还是具体代码实现,与苹果的核心团队合作,为这个语言做贡献。

其实我一直想说,Swift
只是我在苹果工作的一小部分,我花了大量的时间在其他事情上。实际上在苹果我也就晚上或者周末有空写写
Swift
。我希望到了特斯拉之后我还能花同样的精力和时间在 Swift
上,毕竟我对这门语言统治世界充满期待。

下面是全文:

教育背景

  • 伊利诺伊大学 PHD

Swift 3 回顾

每年 Swift 的新版本都与前一年完全不同,我希望 Swift 4
能继续保留这个传统。为了每一年都有提升与进步,以下是一些对 Swift 3
的回顾与建议:

  • 开源有许多好处。见证一个充满活力的团队合作得如此之好,大家几乎彻夜为其付出,让人不可思议、充满惊喜。与这样一个才华横溢并充满热情的团队合作,实在是太棒了!

  • 开源也带来挑战。比起“闭源设计”,“开源设计”
    进度更慢且更加不可预料,我想这么说应该是公允的。然而,开源的结果明显更好,因此权衡之下开源是值得的。“感谢你们”,献给所有帮助
    Swift 发展进化的人。

  • 预估
    软件开发的进度(特别是开源项目)依然困难到近乎不可能。我们在着手开发
    Swift 3
    的时候设立了许多高目标,在后期不得不进行修整。设立一些高目标是好事,但我们需要在沟通上更努力,让其他人知道“目标”不等于“承诺”,避免误导他们。

  • 整个社区得益于在有限的主题上保持专注,因为如果有太多事项同时进行,没有人可以持续跟进所有部分。参与到前面所提的关键讨论中,对核心团队而言非常重要。在
    Swift 3
    的开发周期中,很多人在代码评审结束前都没有时间来跟进讨论,这是一个问题。

  • 确立清晰的目标是一种解脱。特别是在去年十二月到今年一月,我们大致圈出了那些适合放入
    Swift 3
    的点子,同时开启了几个项目,这些项目最后远超出我们的能力范围。在后来的版本中,我们确立了几个具体目标(比如“不再加入新计划”),使所有人能更轻松地关注重要事项。

  • 皆大欢喜是不可能的,尤其是在我们讨论优先开发哪些功能时,因为这会降低其他一些功能的优先级。这是一个无解的局面,因为我们并没有办法将所有有意思的工作都放在一个只有一年长的开发周期中。幸运的是,将来“总会有下一个版本”,每一个新版本都会加入一些重大的改进。

在上述回顾的基础上,我们来展望未来!

  • Chris Lattner 是谁?
  • Xcode 的编译器 LLVM 背后有怎样的故事?
  • Swift 诞生的前世今生,封闭的苹果为何要拥抱开源?
  • 说好的 ABI 稳定性何时能推出?

Swift 4 发布计划

从我们在 Swift 3 中获得的经验来看,我们需要挑出一些重点。对 Swift 4
来说,主要目标是从 3.0 开始要保证交付的代码的稳定性,并为标准库提供 ABI
的稳定性。因此,核心团队决定在接下来的一年中实施两个阶段的计划:

第一阶段:专注于提升代码及 ABI
稳定性,全心投入只完成这项必要的工作。这意味着如果一些功能不会从根本上改变现有语言特性的
ABI ,或是对标准库的 ABI
进行了破坏性的改动,那么现阶段都不会考虑开发它们。举个例子,泛型中的条件一致性(Conditional
conformances)是一个附加特性,但由于它会对标准库造成众多更改,我们在第一阶段就要实现它。另一方面,正则表达式不会对现有
ABI 造成影响,也不会给标准库带来大量改动,所以第一阶段不会考虑它。

第一阶段的工作非常重要(下面会详细介绍),所以春季之前我们大概一直会很忙。

第二阶段:当第一阶段功能的设计与实现工作较好得完成之后,我们将基于剩余时间,选择一些大型的功能进行开发。我乐观估计将有剩余时间,来从长长的功能列表中选几个来开发,但具体选哪几个,得看最后剩多少时间。

除了新功能之外,我们也需要重新评估那些在 Swift 3
中尚未实现的、对代码造成破坏性变动的提案。这些提案不一定会被通过,我们需要在
Swift 4 的基础上来评估它们,挨个决定如何处理。

最后,虽然与 Swift
的进步没有特别大的关系,但我想提一提质量与性能问题。核心团队想要进一步提升质量,包括修复编译器的
Bug、改进错误与警告检测功能。性能是开发中另一个需要重视的部分,包括提升编译后的代码质量,改善标准库的实现,加快编译速度等。这些工作在任何开发阶段都需要重视。

Swift

7. Swift
是如何诞生的?在苹果这样一个大厂,决定做出如此巨大的变革,同时还是在封闭的环境下,你是如何一步步实现的?

首先,苹果内部所有的项目都不尽相同 —
工作流程、战略规划、实施细节,到最后发布。Swift
也一样,没有可比性。因为苹果本身就是小组单兵作战模式 —
每个组负责不同的大方向,组里自己计划和工作,甚至招人都是各自招。

言归正传,契机发生在2010年了。当时好像是我们刚刚完成了 Clang 对
C++的支持。你也知道 C++ 写起来有多丑,但是做个编辑器支持 C++,完善 C++
这门语言就是另一回事了,我们当时搞了好久终于完成的时候特别有成就感。当然
Clang 远没有到达完美的地步。

我又扯远了。除了做 Clang 以外,无论是 C语言,C++,还是
Objective-C,都有一些我不是很满意的地方。所以我就想要不我们搞个新的语言来吧。新的语言要越简单越好。一开始大家都没认真,后来我跟很多同事聊了之后觉得新语言的计划可行,而且大家都很亦可赛艇。于是我们就用业余时间开始顶层设计和写代码。

现在问题来了,因为我们已经有 Objective-C
了。虽然它有几个地方很丑,比如老是用
“@”,每句结束了还要打分号,但是这些并不妨碍它是一门伟大的语言。所以,我们为什么要开发新语言,而不是把精力花在优化
Objective – C 上?

澳门新葡亰信誉平台游戏 4

原因有三。

第一,如果我们大幅优化 Objective – C,把很多 Swift
的特性加进去,这对开发者来说是灾难性的,因为他们要对原来的 APP
要进行大幅修改;

第二,Objective – C 很多特性积重难返,比如它安全性上的问题;

第三,Objective – C 是基于 C 开发的语言,所以你无论怎么优化,它必然有 C
语言自身的缺陷。

于是我们就动手做 Swift 了,它的背后有着数百人的努力: 支持 Xcode,开发

Chris Lattner 写了一篇文章:回顾 Swift 3,展望 Switf
4,以下是这篇文章的关键内容:

ABI 稳定性

14. 现在 Swift
已经到了第3个版本了。我们也知道ABI稳定性的追求一直是你们的目标,但是它也一直被各种事情拖延。你对此有什么计划吗?或者说你从拖延中学到了什么经验教训吗?

ABI 推迟有两个原因。

第一是因为 Swift 的开发进程中有很多不确定性。当 Swift
开源之时,一堆人对我们提 pull request,提各种各样的
issue。这样我们就不得不去花大量的时间去维护开源社区,而不是专心去做计划内的工作。

第二个原因是,尽管稳定的 ABI 很重要,但是对于开发者来说,稳定的 ABI
对他们来说没有明显的好处,他们更关心是语法和兼容上的稳定和优化。所以我们后来修改了计划,语法和兼容上的稳定性被定为是最先要实现的目标。这样当
Swift 3.1 或者 Swift 4.0 出来的时候,大家不用担心语言上的转化会让 Xcode
崩溃,或是需要大家整个重构 APP。Swift 3.0 主要就是实现这个目标。

澳门新葡亰信誉平台游戏 5

15. 稳定的 ABI 什么时候推出?他会赶在异步和并发模型之前吗?

Swift 现有的内存管理机制对 ABI
稳定性造成了不小的影响。有些底层逻辑还需要调整,比如 getter 和 setter
的生成以及属性的内存分配问题,苹果内部正在做这件事,这之后我们才能完成
ABI。至于并发模型啥的就跟 ABI 没有关系了。

很多人担心 Swift 4.0 的时候苹果能不能推出稳定的
ABI,因为毕竟工作量太大。ABI
的工作正在井然有序得进行,而且对于开源社区来讲推出稳定的 ABI
至关重要。Ted (Chris Lattner 之后的 Swift 领导人)有一件事说对了,现在
Swift 当务之急就是让编译器更稳定,让错误处理更方便,提高编译速度,并且将
Swift 拓展到大规模系统中。

我在想 Swift 4.0 的时候究竟能看到什么。也许没有稳定的
ABI,但是一定会有重要的新功能加入。

ABI 将允许未来 Swift 版本开发的应用程序和编译库可以在二进制层次上与
Swift 3.0
版本的应用程序和编译库相互调用。这样,ABI的稳定性将保证一定程度的二进制兼容性,并且第三方更容易发布二进制库。另外,ABI
将允许删除需要的 Swift 标准库和二进制文件,就像目前情况下通过Xcode创建的
iOS 和 OS X 应用程序一样。

澳门新葡亰信誉平台游戏 6LLVM.png

补充:LLVM的三层结构

  • 第一层:Clang 编译器,负责编译各种语言
  • 第二层:代码优化器,通过模块化操作优化代码,是 Bitcode
    逻辑的主要部分
  • 第三层:代码翻译器,针对不同平台和 GPU 将代码翻译成机器语言

补充:LLDB,llbc++,compile rt

  • LLDB: 一个有着 REPL 的特性和 C++ ,Python 插件的开源调试器。LLDB
    绑定在 Xcode 内部,存在于主窗口底部的控制台中;
  • libc++,libc++ ABI: 高性能 C++ 标准库实现,支持 C++ 11
  • compiler-rt:为 LLVM 和 Clang 设计的编译器扩展函数库。针对
    __fixunsdfdi 和其他目标机器上没有一个核心 IR (intermediate
    representation)
    对应的短原生指令序列时,提供高度调优过的底层代码生成支持。

ABI 是什么?

Application Binary Interface,中文名:应用二进制接口。是 APP 和
操作系统、其他应用之间的二进制接口。它包括以下细节:

  • 数据类型的大小、布局和对齐;
  • 调用约定(控制着函数的参数如何传送以及如何接受返回值),例如,是所有的参数都通过栈传递,还是部分参数通过寄存器传递;哪个寄存器用于哪个函数参数;通过栈传递的第一个函数参数是最先push到栈上还是最后;
  • 系统调用的编码和一个应用如何向操作系统进行系统调用;
  • 以及在一个完整的操作系统ABI中,目标文件的二进制格式、程序库等等。

Chris Lattner’s Homepage深入剖析 iOS 编译 Clang LLVM与调试器共舞 – LLDB
的华尔兹compiler-rt” runtime libraries应用二进制接口

  • 开源大有益处,但无法让所有人满意。

  • Swift 3 将在 2016 年秋到来。Swift 3.x 会在 2017 年春公布,Swift 4
    会在 2017 年秋发布,这其中不包括修复
    bug、提升兼容性之类的小更新(例如 3.0.1)。

  • Swift 4
    在交付时一定会保障代码的稳定性,增加容错性、ABI,优化泛型与字符串等等。

  • 语法糖的优先级最低,没有提上日程。

  • 安排进度有些困难。开发的目标并非是对交付的保证。从一开始安排计划与进度就是最主要的事。

LLVM

2. 说说 LLVM(Low Level Virtual Machine)到底是什么吧

  • 先说编译器:编译器是把程序员的代码翻译成机器可以理解的语言的工具;
  • 再谈 LLVM:一个模块化和可重用的编译器和工具链技术的集合,Clang 是
    LLVM 的子项目,是 C,C++ 和 Objective-C
    编译器,因为多模块的复用,所以提供了惊人的快速编译,比 GCC 快3倍。

3. LLVM
是一开始就作为一个完整的编译工具来使用的吗?还是有什么其他故事

LLVM 当时是为了解决一个小问题而开发的:当使用OpenGL 函数库的时候(Mac OS
10.4 和
10.5环境下),比如你要调用这个函数,glVertex3f(),编译器必须将其转化为特定的GPU可以理解的数据。但是这带来一个问题:市面上有海量的GPU,每个GPU的性能和参数也不尽相同,所要求的数据格式也不同。这时
LLVM 可以产生很小的一部分代码去解决这个问题,这是 LLVM 诞生的初衷。

4. LLVM 的 bytecode 和 Apple 现在的 bitcode 有什么不同?

这是历史遗留问题。一开始 LLVM 是开源的,所有代码在转成二进制时就叫做
bytecode — 因为 java
当年就是这么叫的。当时这一部分有很多问题:比如不能扩展,无法兼容,非常脆弱。

然后就到了 LLVM 2.0,当时我重新设计了架构,采用的就是 Bitcode 机制。LLVM
2.0 将所有代码以比特流(bit stream)而不是字节流(byte
stream)的形式来编码。这就是 bitcode 这一术语的由来。

主要的工作流程就是现将代码转成比特流,然后相应处理。处理完后再将编码传到其他地方去。

5. Bitcode 这个机制比直接传输二进制有什么好处

好处那是多了去了。首先
编译器工作起来会越来越好。因为通过Bitcode机制,它可以通过编译不同代码来存储各种优化方法,这样下次碰到类似代码,它就会自动启动相关优化机制,使得效率提升。还有个好处是
LLVM 可以让芯片的兼容性变得很好。因为 Apple
每年都在芯片上推陈出新,它们转化为二进制的规则都不尽相同,LLVM
只要每次重新编码并传输成比特流就好了。

当然 Bitcode 也不是万能的。比如它不能解决 32位的 APP
在64位机器上的兼容问题。这个问题其实应该依靠代码逻辑。

Playground,兼容调试器和编译器。我个人感到最骄傲的一点是,我们并不打算自己内部把它做到完美

我们开源、我们依靠社区,这样一门语言才能在无数开发者的实战中得到检验和改进,我想这才是
Swift 最棒的地方。

8. 你之前在优化 Objective-C 的时候,有没有想到什么地方是未来 Swift
可以用得到的?

ARC。我们其实一直都在争论是用垃圾回收机制(garbage collection)还是
ARC,后来决定了是 ARC。

另一个是模块化,我们也将这一部分的经验带到了 Swift 开发中。

其实,很多数组和字典方面的语法优化本来是计划在 Objective – C
上面的。但是后来我们开发了
Swift,于是这些改进被直接用在了新语言上,所以大家会在写 Swift
的时候觉得似曾相识,因为本来这些就是 Objective-C 的升级版本嘛。

我可以透露一个有意思的事情。我们在做 Swift 的时候,很多 iOS
开发者,包括苹果内部的工程师,都在吐槽我们这几年在 Objective – C
上毫无建树,都在说你们为什么不做这个那个。我们当然不能告诉他们我们在全力开发
Swift,而他们所要的语法功能我们都会给。

9. 苹果内部对于 Swift 的使用情况和开发是怎么看得?

Swift
团队对于开发上有明确的目标和计划,应用二进制接口的稳定性一直是我们的首要目标。很多人很喜欢我们开源的
Swift Playground。同时 iOS 系统内置的 Music App 也是 Swift
写的。其实用不用 Swift
主要是技术和开发方面的考量,苹果内部同时得兼顾稳定性和开发效率,这不是说大家喜不喜欢这个语言的问题。

Swift 刚发布的时候,内部很多组都很惊讶:我们已经有了
Objective-C,为什么还要搞新的 Swift?而且 Objective-C
本身就很不错,开发起来也很顺手。后来渐渐 Swift
成熟了,大家也爱上了这个新生儿。

内部其实对于 Swift
一个很大的顾虑在于,苹果的所有开发必须兼容32位机器,而32位的应用都采用了
Objective-C 的 runtime 机制。这就要求 Swift
团队也弄出个类似的机制,或者弄个兼容的方案,否则 Swift 无法与 AppKit
适配。

10. 开源后的 Swift 发展态势喜人,你对此有什么看法?

开源之后,Swift 发展之好让我咋舌,然而这也是问题所在。

当年我们开源了 LLVM 和 Clang,它们也发展喜人。我们的对手 AMD
们完全跟不上我们。但是跟 Swift 比起来,它们的发展也太慢了,LLVM 和 Clang
开源后完全没有 Swift 这么火。

Swift 就不同了,开源一年之后,我们就有了上百万的开发者在使用这门语言 —
我和很多有丰富开源经验的老工程师都吓了一跳,这简直了!然后我们每天收到无数的邮件和
pull
requests,要求更新这个、要求优化那个,我们的节奏完全被打乱了。我们如何规划开发?我们如何把
Swift
的开发导向一个正确的方向?这些问题随着时间的推移和经验的积累,慢慢找到了解决之道。

我现在觉得开源这个决定至关重要。一来大家会帮着优化;二来我们有个巨大的论坛,在那里大家可以畅所欲言,全世界的人都在帮着
Swift
进步,这真的很棒。我们虽然没有一开始就具体计划要开源,但是苹果内部当时都觉得
Swift 肯定有一天要开源。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图