加载中

It's high time to make the switch to the more approachable, full-featured Swift for iOS and OS X app dev

Programming languages don't die easily, but development shops that cling to fading paradigms do. If you're developing apps for mobile devices and you haven't investigated Swift, take note: Swift will not only supplant Objective-C when it comes to developing apps for the Mac, iPhone, iPad, Apple Watch, and devices to come, but it will also replace C for embedded programming on Apple platforms.

Thanks to several key features, Swift has the potential to become the de-facto programming language for creating immersive, responsive, consumer-facing applications for years to come.

是时候使用易入手又全面的Swif语言为iOS和mac OS X做应用开发了。

虽然编程语言不会那么容易消逝,但坚持衰落范例的开发小组正在这么做。如果你正为移动设备开发应用程序,并且你还没有研究Swift,那么注意:当Swift涉及到Mac、iPhone、ipad、Apple Watch和未来设备的应用开发时,它不仅会排挤掉Objective-C,而且还会取代在Apple平台中做嵌入式开发的C语言。

由于几个关键特性,在未来几年,Swift有很大潜力成为创造身临其境的、响应迅速的、面向用户的应用程序的实际编程语言。

Apple appears to have big goals for Swift. It has optimized the compiler for performance and the language for development, and it alludes to Swift being "designed to scale from 'hello, world' to an entire operating system" in Swift's documentation. While Apple hasn't stated all its goals for the language yet, the launches of Xcode 6, Playgrounds, and Swift together signal Apple's intent to make app development easier and more approachable than with any other development tool chain.

Here are 10 reasons to get ahead of the game by starting to work with Swift now.

苹果公司似乎在Swift上还有更大的目标。它的编译器性能和开发语言都被优化了,苹果公司在Swift的文档中暗示Swift被设计成小能(显示)“hello,world”,大能(完成)整个操作系统。苹果公司还没把这门语言的目标说全,Xcode6,Playgrounds和Swift的推出就一起揭露苹果的意图:更简单的应用开发,更易用的开发工具链。

这是从现在起使用Swift工作,并走在比赛前列的10个原因。

1. Swift is easier to read

Objective-C suffers all the warts you'd expect from a language built on C. To differentiate keywords and types from C types, Objective-C introduced new keywords using the @ symbol. Because Swift isn't built on C, it can unify all the keywords and remove the numerous @ symbols in front of every Objective-C type or object-related keyword.

Swift drops legacy conventions. Thus, you no longer need semicolons to end lines or parenthesis to surround conditional expressions inside if/else statements. Another large change is that method calls do not nest inside each other resulting in bracket hell -- bye-bye, [[[ ]]]. Method and function calls in Swift use the industry-standard comma-separated list of parameters within parentheses. The result is a cleaner, more expressive language with a simplified syntax and grammar.

Swift code more closely resembles natural English, in addition to other modern popular programming languages. This readability makes it easier for existing programmers from JavaScript, Java, Python, C#, and C++ to adopt Swift into their tool chain -- unlike the ugly duckling that was Objective-C.

1. Swift 容易阅读

如你所能预计到的一门基于 C 构建的语言,Objective-C 身上所有的毒疣子都有。为了将关键词和类型同C的类型作区分,Objective-C 使用@符号引入了新的关键词。因为 Swift 不是基于C构建的,它同意了所有的关键词,并将 Objective-C 类型和对象相关的关键词前面大量的@符号移除了.

Swift 丢弃了遗留下来的约定。因而你不再需要行尾的分号,以及 if/else 语句中围绕条件表达式的括弧。另外一个大变化就是方法的调用不再互相嵌套成中括号的深坑 -- 再见吧,[[[ ]]]。Swift 中的方法和函数的调用使用行业内标准的在一对括弧内使用逗号分隔的参数列表。这样做的结果就是一种带有简化了句法和语法的更加干净有表现力的语言。

除了其它当代流行的编程语言之外,Swift 更像是自然的英语了。这种可读性是的其很容易能被其它来自 JavaScript,Java,Python,C#,以及 C++ 的开发者纳入到他们的工具链之中 -- 一点也不像 Objective-C 这只笨笨的黄小鸭。

2. Swift is easier to maintain

Legacy is what holds Objective-C back -- the language cannot evolve without C evolving. C requires programmers to maintain two code files in order to improve the build time and efficiency of the executable app creation, a requirement that carries over to Objective-C.

Swift drops the two-file requirement. Xcode and the LLVM compiler can figure out dependencies and perform incremental builds automatically in Swift 1.2. As a result, the repetitive task of separating the table of contents (header file) from the body (implementation file) is a thing of the past. Swift combines the Objective-C header (.h) and implementation files (.m) into a single code file (.swift).

2. Swift 更易于维护

历史遗留问题会让 Objective-C 越来越倒退 -- C 没有演进的话,这个语言也就跟着无法进行演进。C 需要程序员维护两套代码文件,以优化构建的时间以及创建可执行 app 的效率, 这种需要延续到了 Objective-C 上。

Swift 丢掉了对着俩文件的要求。Swift1.2 中 Xcode 和 LLVM 编译器可以自动计算出以来并执行增量构建。如此,将内容清单 (头文件) 同内容主体(实现文件)相分离。Swift 将 Objective-C 头文件(.h) 和实现文件 (.m) 合并成了一个代码文件 (.swift)。

Objective-C's two-file system imposes additional work on programmers -- and it's work that distracts programmers from the bigger picture. In Objective-C you have to manually synchronize method names and comments between files, hopefully using a standard convention, but this isn't guaranteed unless the team has rules and code reviews in place.

Xcode and the LLVM compiler can do work behind the scenes to reduce the workload on the programmer. With Swift, programmers do less bookkeeping and can spend more time creating app logic. Swift cuts out boilerplate work and improves the quality of code, comments, and features that are supported.

Objective-C 的两份文件系统存在强加给程序员的额外工作 -- 而这些工作会让程序员难免分心而不能顾全大局. 在 Objective-C 中你不得不手动去同步文件之间的方法名称和注释, 有时候要寄希望于一个约定好的标准,不过除非团队的规矩和代码审查制度到位,否则这是不会为你提供什么保障的.   

Xcode 和 LLVM 编译器可以在幕后做一些工作来减轻程序员的工作负担. 使用 Swift, 程序员可以少做些费脑力的记忆性工作,从而能在创建app逻辑的工作上面赢得更多的时间. Swift 为我们程序员裁掉了那些样板式的工作,同时对代码、注释以及所要支持的特性的质量都有所提升.

3. Swift is safer

One interesting aspect of Objective-C is the way in which pointers -- particularly nil (null) pointers -- are handled. In Objective-C, nothing happens if you try to call a method with a pointer variable that is nil (uninitialized). The expression or line of code becomes a no-operation (no-op), and while it might seem beneficial that it doesn't crash, it has been a huge source of bugs. A no-op leads to unpredictable behavior, which is the enemy of programmers trying to find and fix a random crash or stop erratic behavior.

Optional types make the possibility of a nil optional value very clear in Swift code, which means it can generate a compiler error as you write bad code. This creates a short feedback loop and allows programmers to code with intention. Problems can be fixed as code is written, which greatly reduces the amount of time and money that you will spend on fixing bugs related to pointer logic from Objective-C.

3. Swift 更加安全

Objective-C 有意思的一个方面是指针 -- 特别是 nil (null) 指针 -- 它们被处理的方式. 在Objective中-C, 如果你调用方法的是一个值为 nil (未初始化)的指针变量,什么事情都会不发生. 表达式或者一行操作变成了一项空操作(no-operation (no-op)), 而这就使得其看起来会有不会奔溃的好处, 但其实它已经变成了一个巨大的bug来源. no-op 会导致不可预测的行为, 这是程序员在尝试找出并修复某种随机的奔溃,或者要停止反常的行为时所要面对的敌人.

在Swift代码中的可选类型使得一个nil可选值的可能性变得非常的明确, 这意味它能在你写下一段糟糕的代码时会生成一个编译器错误. 这就建立了一种短程反馈的循环,可以让程序员带着目标去写代码. 问题在代码被写就时就可以被修复, 这大大节省了你要在修复有关来自 Objective-C 指针逻辑的bug时需要耗费的时间和金钱.

Traditionally, in Objective-C, if a value was returned from a method, it was the programmer's responsibility to document the behavior of the pointer variable returned (using comments and method-naming conventions). In Swift, the optional types and value types make it explicitly clear in the method definition if the value exists or if it has the potential to be optional (that is, the value may exist or it may be nil).

To provide predictable behavior Swift triggers a runtime crash if a nil optional variable is used. This crash provides consistent behavior, which eases the bug-fixing process because it forces the programmer to fix the issue right away. The Swift runtime crash will stop on the line of code where a nil optional variable has been used. This means the bug will be fixed sooner or avoided entirely in Swift code.

在 Objective-C 的传统中, 如果某个值返回自一个方法, (使用注释以及方法的命名约定来)说明指针变量被返回的行为是程序员的责任.在 Swift 中, 可选类型和值类型使得方法定义中值是否存在,或者其有可能是可选的(即值可能存在也可能为nil),这些问题都是很明确清楚的.

为了提供对行为的预测,Swift会在nil可选值被使用时触发一次运行时崩溃。 崩溃提供的就是一种一致的行为,它能减轻修复bug过程的压力,因为它会直白地强制让程序员修复好这个问题. Swift 运行时崩溃的时候会停在nil可选值被使用到的那行代码处。这就意味着bug能更早的被修复,并能在Swift代码中被完全的规避掉.

4. Swift is unified with memory management

Swift unifies the language in a way that Objective-C never has. The support for Automatic Reference Counting (ARC) is complete across the procedural and object-oriented code paths. In Objective-C, ARC is supported within the Cocoa APIs and object-oriented code; it isn't available, however, for procedural C code and APIs like Core Graphics. This means it becomes the programmer's responsibility to handle memory management when working with the Core Graphics APIs and other low-level APIs available on iOS. The huge memory leaks that a programmer can have in Objective-C are impossible in Swift.

A programmer should not have to think about memory for every digital object he or she creates. Because ARC handles all memory management at compile time, the brainpower that would have gone toward memory management can instead be focused on core app logic and new features. Because ARC in Swift works across both procedural and object-oriented code, it requires no more mental context switches for programmers, even as they write code that touches lower-level APIs -- a problem with the current version of Objective-C.

4. Swift 的内存管理是统一化的

Swift 以一种 Objective-C 从未有过的方式进行了统一。对自动引用计数 (ARC) 的支持是在整个过程化的和面向对象的代码路径上完成的。在。Objective-C。中, ARC 在 Cocoa API 和面向对象代码中获得支持;然而它并不支持过程式的 C 语言代码和像 Core Graphics 这样的 API。这意味着在使用 Core Graphics API 以及其它 iOS 上的底层 API 时,内存管控的处理都是程序员的责任。程序员在 Objective-C 上会遇到的大量内存溢出问题在 Swift 上是不可能的。

程序员不应该为他或她创建的数字对象去考虑内存的问题。因为 ARC 在编译时就处理了所有的内存管理事务, 内存管理所有消耗的脑力现在可以被用来专注于核心的应用逻辑以及新的功能特性。因为 Swift 中的 ARC 在过程式的和面向对象的代码中都能起作用,它也就不再需要程序员进行心理上的上下文切换了, 即使是他们在编写要触及底层API的代码时也不需要 -- 这在目前版本的 Objective-C 中就是一个实实在在的问题。

Automatic and high-performance memory management is a problem that has been solved, and Apple has proven it can increase productivity. The other side effect is that both Objective-C and Swift do not suffer from a Garbage Collector running cleaning up for unused memory, like Java, Go, or C#. This is an important factor for any programming language that will be used for responsive graphics and user input, especially on a tactile device like the iPhone, Apple Watch, or iPad (where lag is frustrating and makes users perceive an app is broken).

5. Swift requires less code

Swift reduces the amount of code that is required for repetitive statements and string manipulation. In Objective-C, working with text strings is very verbose and requires many steps to combine two pieces of information. Swift adopts modern programming language features like adding two strings together with a "+" operator, which is missing in Objective-C. Support for combining characters and strings like this is fundamental for any programming language that displays text to a user on a screen.

自动和高性能的内存管理是一个已经被解决的问题,而苹果公司已经证明了这个问题的解决可以提高生产力. 另外一个副作用就是 Objective-C 和 Swift 不会像 Java,Go 或者 C# 那样遇到垃圾收集器针对没有被使用的内存运行清理作业的情况. 这对于那些将会被用于相应图形和用户输入的编程语言而言就是一个非常重要的要素, 特别是在诸如 iPhone、Apple Watch 以及 iPad 这样的(如果响应滞后就会让用户感知上以为应用是坏的)触摸屏设备上。

5. Swift 代码更少

Swift 减少了重复性语句和字符串操作所需要的代码量。在 Objective-C 中, 使用文本字符串将两块信息组合起来的操作非常繁琐。Swift 采用当代编程语言的特性,比如使用“+”操作符将两个字符串加到一起,这在 Objective-C 中是没有。像这样支持对字符和字串的组合对于任何要在屏幕上向用户展示文本的编程语言的基础设施。

The type system in Swift reduces the complexity of code statements -- as the compiler can figure out types. As an example, Objective-C requires programmers to memorize special string tokens (%s, %d, %@) and provide a comma-separated list of variables to replace each token. Swift supports string interpolation, which eliminates the need to memorize tokens and allows programmers to insert variables directly inline to a user-facing string, such as a label or button title. The type inferencing system and string interpolation mitigate a common source of crashes that are common in Objective-C.

With Objective-C, messing up the order or using the wrong string token causes the app to crash. Here, Swift again relieves you from bookkeeping work, translating into less code to write (code that is now less error prone) because of its inline support for manipulating text strings and data.

Swift中的类型系统减少了代码语句的复杂性--作为编译器可以理解的类型。比如,Objective-C要求程序员记住特殊字符标记(%s,%d,%@)并且提供了一个用逗号分隔的变量来代替每个标记。Swift支持字符串插入,这就消除了需要记住的标记和允许程序员直接插入变量到面向用户的字符串中,比如标签或者按钮的标题。这类推理系统和字符串插入减少错误来源在Objective-C中都是很常见的。

在Objective—C中,搞乱了顺序或者使用了错误字符串标记会造成app崩溃。这里,Swift再次将你从反锁的工作中解放出来,翻译成更少要编写的代码(代码现在已经不容易出错)因为它的对处理文本字符串和数据的内嵌支持。

返回顶部
顶部