外文解析：现在放弃Objective-C使用Swift的最好时机
各位亲爱的iOS与OS X应用程序开发人员，如今正是将编程阵地转移至更为亲民、功能更为全面的Swift的最佳时机。
一般而言，编程语言往往不会轻易消亡，不过由相关厂商大力推动的更新换代举措则不在此列。如果大家从事移动设备应用程序开发工作，但却还没体验过Swift，那请注意啦：Swift不仅仅是一种希望在Mac、iPhone、iPad、Apple Watch以及其它未来设备上取代Objective-C的新型编程语言，它同时也将在苹果平台上一举取代C语言对嵌入式编程的统治。
得益于自身的多项关键性特色，Swift正迅速成为我们在未来几年中创建沉浸式、响应式、面向消费者的应用程序时不容忽视的优先性编程语言选项。
苹果公司似乎为Swift制定了一项宏伟的发展目标。该语言针对编译器性能以及语言开发需求作出了诸多优化，而且苹果公司在Swift的说明文档中暗示称该语言“在设计思路上充分考虑到规模化需要，从‘你好，世界’到完整的操作系统皆可轻松应对”。尽管苹果方面目前还没有明确指出该语言的设计目标，但Xcode 6、Playgrounds再加上Swift的陆续出台标志着苹果公司希望让应用程序开发工作变得更加轻松，同时这套体系与任意其它开发工具链的对接也将变得简单便捷。
在今天的文章中，我们将立足于十大理由，了解选择Swift作为首选编程方案所带来的具体收益。
1. Swift代码更易于阅读
Objective-C几乎让大家对于一款以C为基础建立起的编程语言所抱有的一切预期及希望都落了空。为了能够将自身关键字与类型设置与C语言作出区分，Objective-C引入了@符号作为新的关键字标记。由于Swift并非以C语言为建立基础，因此其能够将所有关键字加以统一，同时取消了原本在每种Objective-C类型或者与对象相关的关键字中的@符号。
Swift彻底丢弃了其前身的大量遗留设定。因此，大家已经没必要再保证每一行代码以分号结尾，或者在if/else语句当中利用括号将条件表达式给括起来。另一大重要变更在于，Swift中的方法调用不再相互嵌套，这就让我们从可怕的中括号地狱中解脱了出来——再也不见了，[[[ ]]]。Swift中的方法与函数调用采用了业界标准化的，在圆括号内以逗号分隔参数列表的作法。结果就是，我们如今拥有了一套更为简洁、更富于表现力的编程语言，并能够享受其中更为简单的语法表达方式。
Swift的代码内容与英语这一自然语言非常接近，或者说比目前其它主流现代编程语言相比更为接近。这种可读性使原本使用JavaScript、Java、Python、C#以及C++等语言的程序员能够更轻松地将Swift纳入其工具链当中——而不像当初的丑小鸭Objective-C那么难对付。
2. Swift代码易于维护
这种继承属性正是Objective-C在发展中遭遇拖累的主要原因——如果C语言没有进化，那么Objective-C也将无法进化。C语言要求程序员同时维护两个代码文件，从而改善构建时间并提高应用程序创始的执行效果，而这一要求也被Objective-C原原本本地继承了过来。
Swift语言则消除了这种双文件要求。在Swift 1.2版本中，Xcode与LLVM编译器已经能够自动判断出关联性并执行增量构建。如此一来，将内容表（也就是头文件）从主体（也就是执行文件）中剥离出来的任务已经彻底不复存在。Swift将Objective-C的头文件（即.h文件）与执行文件（即.m文件）整合成了单一代码文件（即.swift文件）。
Objective-C的双文件系统无疑给程序员带来了额外的工作负担——而这让程序员们更难从大局角度出发完成开发任务。在Objective-C中，我们必须以手动方式在两个文件之间进行方法名及注释的同步工作，从而让二者使用同一套标准表达，但除非开发团队已经拥有现成的规则及代码审查机制、否则这一目标根本得不到保障。
Xcode以及LLVM编译器能够在幕后起效以减少程序员的实际工作量。而在Swift当中，程序员几乎用不着再为上述任务所烦恼，从而把更多精力及时间用于创建应用程序逻辑。Swift简化了样板工作、提升了代码及注释内容的质量，同时带来更多功能支持能力。
3. Swift安全性更高
Objective-C语言的一大有趣之处在于对指针——特别是nil（也就是null）指针——的处理方式。在Objective-C当中，如果大家尝试利用某个为nil（即未初始化）的指针变量调用一项方法，则不会起到任何效果。该表达式或者代码行将因此变成无操作（no-op）内容，尽管其不至于导致意外崩溃状况的出现，但却一直是应用程序中各类bug的主要根源。一条no-op往往会导致不可预知的行为，而这正是程序员们在努力寻找并修正随机崩溃或者中止意外状况时所面临的头号大敌。
可靠类型的出现让无操作值在Swift代码中的可能后果变得非常明确，这意味着一旦大家编写出糟糕的代码、其将直接引发编译器错误。Swift借此创建出一套简短的反馈循环，并允许程序员根据自己的意图进行编码。在代码编写的过程中、相关问题就能够同时得到解决，而这显然会大大降低我们在bug修复工作中所投入的时间及精力——特别是与Objective-C指针逻辑相关的bug。
从传统角度看，在Objective-C当中，如果某个值返回自某个方法，那么程序员就需要负责在文件中记录下该指针返回变量的行为（利用注释以及方法命名规则）。而在Swift中，可选类型及值类型的存在使我们能够很轻松地通过方法定义了解到该值是否存在或者其是否属于潜在的可选项（即该值可能存在或者可能为nil）。
为了提供具备可预测性的行为，如果某个nil可选变量被使用、Swift会触发一项运行时崩溃。这一崩溃会带来一致性行为，从而简化了整个bug修复过程——因为这迫使程序员需要立即对该问题进行修复。此类Swift运行时崩溃将阻止对应代码行在出现nil可选变量被使用后继续运行的状况。这意味着该bug必须尽快得到修复，或者被彻底被排除出Swift代码。
4. Swift在内存管理方面拥有统一化特性
Swift能够以Objective-C所无法达到的方式实现自身语言的高度统一。Swift对自动引用计数（即Automatic Reference Counting，简称ARC）的支持能力可以完全涵盖面向过程与面向对象的代码路径。在Objective-C当中，ARC只能够在Cocoa API以及面向对象代码内部得到支持; 除此之外，其无法作用于C代码过程以及Core Graphics等API当中。这意味着程序员在使用由iOS所提供的Core Graphics API以及其它低级API时，必须自行负责内存管理工作。有鉴于此，Swift彻底杜绝了程序员经常在Objective-C中所面临的内存大规模泄漏问题。
程序员不应该从自己所创建的每个数字化对象角度考虑内存管理工作。由于ARC能够在编译的过程中处理所有内存管理事务，因此大家的脑力应该专注于应用程序的核心逻辑以及各类新功能。由于Swift中的ARC能够跨越面向过程与面向对象的代码起效，因此其不再要求程序员把太多精力浪费在上下文切换方面——我们甚至能够直接编写出触及底层API的代码，从而一举解决Objective-C目前版本所面临的最大难题。
通过解决自动化与高性能内存管理这一难题，苹果公司用事实证明了Swift能够切实帮助程序员提高生产效率。另一项附加作用在于，Objective-C与Swift都不会受到用于清理未使用内存的垃圾收集机制（即Garbage Collector）的影响，正如Java、Go或者C#一样。这一点对于任何一种会被用于响应图形及用户输入内容的编程语言都非常重要，特别是在像iPhone、Apple Watch或者iPad这样的触控设备之上（在这些平台中，操作滞后会带来令人难以忍受的糟糕体验，并导致用户认为应用程序的运行出现了问题）。
5. Swift所需要的代码较少
Swift对于需要重复的语句以及字符串操作，Swift能够大大降低所需代码量。在Objective-C当中，处理文本字符串的过程非常繁琐，而且需要采取一系列步骤来将两组信息结合在一起。相比之下，Swift则具备多种现代编程语言特性，例如通过“+”运算符将两条字符串直接合并在一起，这种能力是Objective-C所不具备的。对于此类字符与字符串结合方式的支持能力已经成为任何一种需要在屏幕上向用户显示文本内容的编程语言的必备要素。
Swift中的类型系统能够降低代码语句的复杂程度——因为编译器能够直接识别出这些类型。举例来说，Objective-C要求程序员雇特殊的字符串标记（例如%s、%d以及%@），并提供一份由逗号分隔的变量列表来替代这些标记。Swift支持字符串插值，这就使程序员不必再死记硬背这些标记、而能够直接将变量插入到面向用户的字符串之内，例如标签或者按钮标题。相比之下，Objective-C中的类型推理系统与字符串插值则往往成为导致应用崩溃的诱因。
在Objective-C当中，弄乱字符串标记的顺序或者使用了错误的字符串标记都有可能令应用程序发生崩溃。但现在，Swift能够把程序员从这些繁琐的规定当中解放出来，并凭借着其对文本字符串及数据操作的内联支持能力保证翻译得出的代码成果更为精练（从而降低了代码出现错误的机率）。
6. Swift代码的执行速度更快
从深层角度看，舍弃C语言遗留特性让Swift在多个方面获得了巨大提升。Swift代码在性能基准测试中的出色表现也证明了，苹果公司确实一直在切实改善Swift运行应用程序逻辑时的速度水平。
根据Primate实验室——也就是高人气性能工具GeekBench的开发方——所公布的结果，Swift在去年12月采用Mandelbrot算法的计算绑定任务测试中，其性能表现已经与C++非常接近。
2015年2月，Primate实验室发现Xcode 6.3 Beta版本对Swift在GEMM算法——这是一项内存绑定型算法，面向大型数组进行连续访问——中的性能表现作出了进一步改善，其提升指标为1.4。而在最初的FFT算法当中——这是一项内存绑定型算法，面向大型数组进行随机访问——其性能提升幅度可达2.6倍。
Swift所采用的一系列最佳实践则让这种改进效果变得更为突出，其FFT算法性能测试中的性能提升幅度达8.5倍（而使用C++时其测试结果仅为Swift的1.1倍）。这样的增强效果同时也使得C++在Mandelbrot算法中仅仅获得了1.03倍于Swift的得分。
Swift语言在FFT与Mandelbrot两种算法中几乎已经能够与C++的性能水平相比肩。根据Primate实验室的说法，GEMM算法性能测试结果证明，Swift编译器无法像C++编译器那样实现代码量化——而这种量化方式正是快速提升性能表现的便捷途径，并将在下个版本中正式登陆Swift。
7.减少与开源项目之间的命名冲突
一直困扰着Objective-C代码的一大问题在于，其缺乏对于命名空间的正式支持能力，而这正是C++在解决代码文件名冲突时给出的办法。当这种名称冲突状况发生在Objective-C当中时，其会表现为一项链接错误，而且应用程序将无法正常运行。解决的办法虽然已经出现，但其却有可能引发其它潜在问题。一般而言，程序员往往会利用一段由两个或者三个字母组成的前缀来区分已经编写完成的Objective-C代码——换言之，就像是在Facebook上@了我们的代码一下。
Swift语言提供隐含的命名空间，允许不同项目之间使用同样的代码文件名称，且既不会导致build故障、亦不强制要求程序员使用NNString（即Next Step，是由乔布斯在离开苹果后创建的公司）或者CGPoint（即Core Graphics）这类命名方式。最后，Swift中的这一特性使得程序员能够进一步提高生产效率，且意味着他们无需再像使用Objective-C时那样记录大量文件名称。在Swift项目中，大家可以看到由这一影响而产生的诸如Array、Dictionary以及String等简单名称，而不再像过去那样被迫使用NSArray、NSDictionary以及NSString等Objective-C缺少命名空间所造成的畸形产物。
在Swift的帮助下，命名空间基于代码文件归属的目标所存在。这意味着程序员们能够利用命名空间标识符区分类或者值。Swift中的这项变更可谓意义重大。这极大地简化了将开源项目、框架以及库整合到自有代码中的流程。该命名空间使得不同软件厂商能够创建出同样的代码文件名称，而又无需担心在将其与开源项目整合时出现命名冲突。总而言之，现在Facebook与苹果都能够使用名为FlyingCar.swift的对象构陀侗换岬贾氯魏未砦蠡蛘build故障了。
8. Swift支持动态库
Swift当中的最大变化——但同时又没能受到足够的重视——当数从以往的静态库经历多次大版本更新（iOS 7、iOS 8以及更多后续版本）而最终迎来了动态库支持。动态库属于可执行代码片段，且能够被接入到应用程序当中。这一特性意味着，如今Swift应用程序可以随着Swift语言的不断发展随时与其最新版本相对接。
开发者需要同时提交应用程序及其对应库，而二者都利用开发证书进行了数字签名，从而确保其完整性（听起来美国安全局又能有所作为了）。这意味着Swift语言甚至能够以高于iOS的速度得到更新，而这也正是现代编程语言的一项重要要求。指向库的所有变更都能够被包含在App Store当中应用程序的最新更新包内，而且整个过程的实现可谓非常简单。
直到Swift与iOS 8面世之前，iOS系统一直无法支持动态库机制——然而在桌面端，Mac早就已经开始对动态库提供支持。动态库存在于应用程序执行文件外部，但却会在用户从App Store获取应用程序时以绑定方式被一同下载。由于这部分内容会被载入到内存当中，因此其降低了应用程序的初始大小，而且这些外部代码只会在被使用时才得到接入。
在Apple Watch平台之上，这种在移动应用程序或者嵌入式应用当中实现延后载入的能力可以提高呈现在用户使用过程中的性能表现。而这正是iOS生态系统的一大独特之处，即使用体验更为灵敏快捷。苹果公司一直专注于让应用程序在运行过程中仅仅载入所需的资产与资源，而如今经过编译的接入代码也被纳入了这一范畴。这种运行过程中即时载入的方式能够降低应用程序的初始等待时间，并保证其直到需要被显示在屏幕上时才真正被载入。
动态库支持能力的出现令Swift成为一款能够以前所未有的速度实现变更与改进的编程语言。用户不必再等等iOS的版本更新，即可即时享受到苹果在Swift当中添加的任何性能提升或者可靠性改善效果。
9. Swift Playgrounds鼓励程序员采取交互式编码方式
Swift全新引入的Playgrounds正是经验丰富的开发人员们的最大福音。Playgrounds的诞生受到了苹果公司前任员工Brett Victor的启发。Playgrounds能够帮助程序员实时测试一种新算法或者图形例程——例如包含五到二十行代码——而且无需创建出整套iPhone应用程序。
苹果公司还为Playgrounds添加了内联代码执行能力，从而帮助程序员在创建一条代码片段或者编写一种算法的同时，从开发环境处获得效果反馈。这一反馈循环能够大大提高代码的编写效率，因为从传统角度讲，程序员需要用想法的方式来估计当前代码的运行效果——而有了Playgrounds，一直皆以可视化方式进行。编程是一种迭代式过程，而其中任何可以减少或者用于补充创建流程的机制都能让程序员们更具生产效率，并把他们的精力解放出来用于处理更为重要的问题——而非专注于解决传统编译器强加给程序员的那些恼人的细节调整工作。
备注：根据我个人在教授新人程序员时的感受，Playgrounds的实际效果对于刚入门的新手而言其实不像经验丰富的老鸟们那么突出。单纯在Swift Playgrounds当中显示出某条变量的运行效果并不能帮助新人们理解这部分代码到底是需要浮点变量还是整数变量——是的，如果打算开发一款能够记住用户上一次Facebook新闻内容访问位置的应用，这种变量类型的需求将非常显著。对新手们来说，关于“为什么”的问题只能在实现运行中的iPhone应用里找到答案——而不是Playgrounds上的片段运行效果。
10. Swift代表着我们能够参与并对其产生影响的未来
Objective-C在相当长的一段时间里仍将继续存在，但其已经不会再迎来任何重大改变，而这完全是因为Swift的出台。Swift中的一部分功能可能会被迁移到Objective-C当中，但Objective-C脱胎于C语言的血统就注定了它也只能吸收这么一丁点新鲜血液。
Swift语言则给开发社区带来了一种直接的途径，允许我们每位参与者对其作出影响，并利用最终成果创建应用程序、嵌入式系统（如果苹果未来发布嵌入式框架许可并向第三方提供芯片架构授权的话）以及像Apple Watch这样的设备。
苹果公司专注于提供最出色的消费者使用体验，并正在着手构建那些真正值得认真关注的功能特性。随着Swift 1.2版本在Xcode 6.3中的发布，苹果方面已经修正了苹果bug报告所收集到的数千个已知bug。负责支持Swift发展与演进的技术团队对该语言的命运非常关注，他们期待着观察Swift如何实现更出色的支持效果、从而帮助开发社区打造出优秀的应用程序及系统成果。
Swift:更加平易近人且功能更为齐备的语言选项
前面提到的一系列变更让Swift得以凌驾于Objective-C之上，同时彻底摆脱了后者作为衍生型语言所残留的大量固症顽疾。苹果公司并不会放弃Cocoa，因为其正是创建出苹果产品特殊使用体验的核心API及代码库。相反，他们会推出功能齐全的校验机制，并使Cocoa能够轻松与其它可以支持Force Touch或者Taptic Feedback（即力度感应与力反馈）等功能的新型API实现交互。
过去的许多传统设定从设计思路上看，完全是为了保障编译器设计方案的易用性。Swift则将注意力集中在了摒弃传统编码实践当中那些容易令人神经紧张的糟粕，从而帮助应用程序开发人员更轻松地完成工作。随着现代编译器方案的不断改进，我们将能够利用更少代码表达出更多信息。
有了Swift语言，程序员们需要维护的代码文件只相当于原先的一半、不必以手动方式进行代码同步、产生标点错误的可能性也变得更低——这将保证他们将更多时间花在真正具有意义的高质量代码编写上。在Swift当中，代码现在能够实现自我记录并提供更多可选类型：编译时安全机制会返回某个值或者无值，这恰恰是异步操作、网络故障、无效用户输入内容或者数据验证错误等多发问题的根源。在Swift当中，ARC在C语言式过程代码与采用苹果Cocoa框架的面向对象代码之间得到了统一。
开发人员会发现，他们在Swift中需要编写的代码量更少，而且能够借助各类现代语言特性支持自己让代码行内容变得更为可靠。Swift自身在不断演变的同时，将始终保证苹果生态系统站在编程发展潮流的前沿，而这都要归功于iOS与Swift当中提供的动态库支持能力。与家庭自动化、设备以及社交服务相集成的开源项目、第三方SDK以及框架等都将更轻松地实现对接，而无需忍受由此带来的额外构建时间。Swift在一部分算法测试中几乎拥有可以与C++相媲美的速度表现，而最新发布的Xcode 6.3与Swift 1.2版本则标志着苹果将进一步推动这一性能优化步伐。