Question

Swift能代替Objective-C吗

Answer 1

　　这是我在网上上看到的答案，复制粘贴过来和大家分享一下，因为我和很多人一样很关心Swift的出现对Mac开发的影响和对Objective-C的影响。
　　我文章的中心是，以 Apple 目前给出的各种资料来看，这语言不会替代掉ObjC，它不是下一代的ObjC。它有很多缺点，使得它不足以做大型项目。这些缺点使得，Apple 自己都没有使用它做 Mac/iOS 的 app。我不排除明年后年它有很大改进，但至少现在还没有这端倪。
　　因此，如果你会ObjC，你不需要去看它。
　　但你如果问我这语言对普通开发者重要不重要，我说重要，可以明确告诉你这一点－－它是 Apple 在 WWDC 向全世界推出的重磅语言我怎麽能说它不重要？ 它降低了入门的门槛。使得大量的 JS, Python, Ruby用户会使用 Apple 的技术为其开发程序。它的作用，和 Core Data, Interface Builder 一样，能让你快速写出一个能用的程序来。但如果你想稍做些正经事，就心有馀力不足了。所以和 Apple 自己的 Mail 也不会去用 Core Data，自己 iPhoto 不会去用 UICollectionView，稍复杂的 App 都不会去用 Interface Builder 一样，Apple 自己不会用 Swift。它只是给三五个人的小团队能迅速做出能用的程序，让大公司能快速做些 Prototype 而已。
　　====
　　有人说它相当于 C#，或是相当于 Scala 对 Java 的改进，我可以告诉大家，Swift 不是这样的语言。它更像一种让人快速做原型的 toy language。
　　要求 Apple 发布下一代 Objective-C 语言的呼声早就有了，每年写数万字 OS X 评论的 Ars Technica 两年前就写了 Apple 应该去做一个语言，Objective-C without C 并且使用更现代的功能和更短的 API，以及对自动类型推导的支持，文章见 OS X 10.8 Mountain Lion: the Ars Technica review 。
　　但 Apple 显然没有认真对待这门语言。很明显的，他们根本不想把ObjC给替换掉。并且按Apple的风格，如果他们把Swift当ObjC的未来来对待，肯定会有一到两个iOS/Mac应用使用Swift改写。（比如Apple 当年要砍 Carbon，首先做的就是把 Finder 重写了）。
　　从语言角度，Swift 有太多的缺点：
　　它的标准库太差，只有Dictionary, Array 和 String及数这几种数据结构，连个 Set 都没有。想用别的？你还是要用 ObjC 的。是的，当你用原生数据结构时，速度比ObjC快。但是那仅限于那几个。 它没有任何对异步／同步编程的支持。它没法绑定使用 Grand Central Dispatch，因此任何正经的网络应用根本无法编写。
　　它没有任何的保护机制(private, protected)，所有的 method和 variable 都是全局可见的，这显然不能满足正经工程项目的需要。
　　只能和 ObjC 互动。如果你想正经地使用C或者C++，你得写 ObjC 的 wrapper。这基本限制了你使用大量的 C/C++ 库函数。
　　没有办法 catch Objective-C 的 exception，如果一旦出了 exception，你的 App 立马就崩了。这也基本限制了你使用很多 ObjC 旧代码库。
　　Chris 在设计这门语言时，可以明显地看到他的短视。这也很正常，他是一个做编译器的，不是做语言研究的。所以这门声称支持函数式编程的语言，根本没有大多函数式语言都普遍存在的功能：
　　仅有的支持在lazy，闭包，及简单的函数语言函数（如map, filter）。这ObjC中都能做
　　没有pattern matching
　　类型推导差不多和 C++11 差不多，没有使用hindley milner
　　从上面这些特点看， Apple对其的定位仅是给对ObjC头疼的开发者降低学习曲线所推出的玩具语言。前面五条中的每一条，基本都是致命的，因此 Apple 自己的项目也不会使用。做个早期 proof of concept的 prototype 到是可以的。
　　我可以想象，实现上 Swift 是很简单的（LLVM很成熟了，写个新语言越来越简单，比如只要几步就能做个小语言： 1. Kaleidoscope: Tutorial Introduction and the Lexer），当然有可能 Apple 将来会解决这些问题使得其真正实用。但现在来看，Apple 并不希望 Swift 来替代 Objective C。