Swift vs. Objective-C:未来看好 Swift 的十个理由 已翻译 100%

oschina 投递于 2015/05/12 15:03 (共 22 段, 翻译完成于 05-14)
阅读 20709
收藏 93
5
加载中

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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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 人翻译此段
我来翻译

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).

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 1 人翻译此段
我来翻译

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.

已有 2 人翻译此段
我来翻译
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(56)

贺小康
贺小康

引用来自“CWhite”的评论

PHP是最好的语言

引用来自“goyem”的评论

必须是最好的
java才是。
goyem
goyem

引用来自“CWhite”的评论

PHP是最好的语言
必须是最好的
勇敢善良坚强的小海豚
勇敢善良坚强的小海豚

引用来自“kidfruit”的评论

我觉得这篇文章把swift换成c#或者java基本上不用改
确实
wujian
wujian

引用来自“CWhite”的评论

PHP是最好的语言
java才是。
x
xiaolezi
牛不牛,不是说出来的,等swift有了比OC更强大的资源环境了,在说吧...swift水很深,建议先掌握OC,有能力可以去研究swift...
d
djlycit
如果我能用oc完成所有工作,swift的优势在哪,还是要花几年时间去学习,填坑
雪人哭了
雪人哭了
eechen 评论员即将降临
chris2012
chris2012
[吐]
TuWei
TuWei
@阿唐唐 正话反话听不出来吗? 说到xcode废品,你可以试试appcode
TuWei
TuWei
@啊唐唐 正话反话听不出来吗? 说到xcode废品,你可以试试appcode
返回顶部
顶部