点击上方“CSDN”，选择“置顶公众号”

关键时刻，第一时间送达！

在我的软件工程师生涯中，只有为数不多的几次被一种语言的设计和理念的美丽所折服，进而从中获得灵感。比如：

• Lua：简洁，模块化，以及严格遵循清晰的设计目标。

• Objective-C / Cocoa：对C语言极其简单的面向对象扩展，在保证一致性、清晰性的同时，做到了与已有的C和C++代码最佳的互操作性。当然这归功于Cocoa和它的设计理念、目的以及推动力。

• Erlang / OTP：角色模型最强大的实现，轻量级进程的概念，以及构建分布式系统极其容易。而且由于是纯函数式编程，最大的好处就是可以随时看到所有的状态变更，用以分析并修复错误。

• Ruby (on Rails)：纯粹的面向对象，任何东西都是对象，是一门完全的面向对象脚本语言。Rails则在其上构建了漂亮的MVC抽象，而且优美地运用了Ruby语言的动态性。在所有部分中，我最仰慕的就是XML视图的Builder部分。

当然，没有一种语言或语言框架的结合体是完美的。但它们都有一个共同点：一组定义明确、经过谨慎选择的设计目标，并根据使用场景进行过精心裁剪。这些目标会指导使用者在使用语言时保持语言的优美和一致性。

然后我们来对比下Swift。

首先要问的问题是：它做到了哪一点？想想吧。并没有明确的答案。它只是想变得更好、更现代，并且成为统治未来的唯一语言。这是给所有想用Swift重写代码的人的第一个警告，从一开始，它就想成为无所不能的语言：

• 它应该适用于从应用和界面到底层系统的一切情况；

• 它应该与现存的Foundation和Cocoa有良好的互操作性，但同时应该拥有自己广泛的标准库，这导致了许多重复；

• 它同时是函数式、面向对象和面向协议语言；

• 它希望成为强类型语言，但它的类型推断却如此方便，从设计上导致简单表达式变得过于复杂难以管理，真是搬起石头砸自己的脚；

• 它是编译型的静态语言，但却强调其交互式界面和练习界面，使之看上去像是脚本语言一样。其实它不是；

• 似乎它的原动力是编译器的需求，以及与静态分析器之间需要填补的空白。然而它考虑的并不是应用开发者的实际需求：高效，易用，以及（iOS）应用开发方面的高生产力；

• 它打算在练习场和学习方面提供简单、渐进式的学习过程。同时，学习以及阅读Swift的书籍和标准库更像是在试图掌握C++，极其复杂、严厉，不平易近人。

在这之上，它还对许多Objective-C的特性做出武断的结论，而许多经验丰富的开发者们却认为这些特性是优点，而不是问题：

• 增加了编译时静态调度（compile time static dispatch），使得动态调度和消息传递（dynamic dispatch and message passing）成了二等公民，使得自省（introspection）无用武之地；

• 定义了便捷优雅的nil消息传递，结果只带来了一系列问题而已；

• 单纯地将对象的隐含选项（implicit optionality of objects）归类为bug的来源。

同时，对于目前和将来最重要的计算问题，它并没有尝试解决或提供支持。这些问题比任何它试图做好的领域都要重要：

• 并发；

• 分布式系统；

• 整体API交互的复杂度；

• 可调试性；

• 实际的应用和界面开发；

• 开发者生产力。

它总是承诺未来的成功，然而提供的仅仅是一条需要极大工作量的路。没有稳定的收入来源，许多使用Objective-C的应用仅仅能通过编译而已，不能轻易享受到设备的新特性，还有可能会被从App Store下架，只因为升级的成本太高。如果你是个独立开发者，你应该很清楚这种情况。尽管现在这种情况应该已经不存在了，但伤害却实实在在地造成了。

比这些情况更严重的是Swift与现有的苹果框架生态系统之间的紧张局势。

尽管苹果已经尽力让Cocoa/Foundation能融合进Swift，但由于Swift的设计方式和现有框架的设计模式，使得局势仍然紧张。这种紧张局势仍然没有解决，并且由于是设计上的冲突，从本质上来说不可能解决，只能减轻。旧的Cocoa基础设计模式是代理、数据源、扁平的类继承关系等，而新的设计包括集合类等，以及易用的API等。

如果你尝试过Swift与传统框架的结合，就会发现需要经常在Swift/标准库的方式、Cocoa方式和两者结合的方式间来回切换。更糟糕的是，许多概念甚至没有好的替代品，至少这一点给我造成了不可避免的精神负担。它会阻碍我的思维，使我陷入一种认知的循环，试图找出最好的表达问题的方式，或者说让Swift对我的代码满意。

雪上加霜的是，所有这些努力都无助于解决真正的问题：写一个好的、易用的应用或框架。这正是Objective-C / Cocoa花费了大量努力试图解决并提高开发者生产力的问题。

没错，Swift代码可能最终会更正确、更好。它也可能会提前警告你那些极端情况。但是其副作用就是，它会限制你写代码时的创造力。开始写代码时，我并不知道怎样才能最好地表达API，所以我会尝试不同的方式直到找到合适的，然后再继续写代码。

然而Swift总是在要求我回答我不想立即回答的问题，从而分散我的注意力。没错，暂时来看我的代码也许并不正确，但这就是我在设计阶段想要的东西。寻找概念，找到最合适的做法，然后再快速迭代。

所以我从基础设计上就十分反对Swift。在我看来，它就像是你头上的魔鬼，总是把你的注意力从问题域中拉走，强迫你完全按照正确的方式，或者说更Swift的方式来做事。同时，它对大型变更又十分不友好。有没有试过把代码从对象改回结构（Struct），或者反之？

Objective-C曾经有过，现在也有十分优美的渐进式方式，你可以先建立原型，然后通过各种工具一点点改进原型，直到找到正确的方式。你可以打开更多的警告，运行静态分析器，并朝着C或C++的方向进行优化。

Swift推出到现在已经四年了。现在吸取经验并改变方向，建立更好的Objective-C，真正地去关心平台的目标和概念，还不算晚。

在我看来，许多还没有达到的“高级的目标”甚至都不应该算作目标。想一想，Objective-C何时像Swift那样得到过苹果的这么多推动和关注？Swift最终到处都是妥协，最后一事无成。

我很希望看到这样的改变，但平心而论，这种改变基本上不可能发生。并不是说Swift的生态系统不会产生能提高生产力的东西。但是，至少对于我而言，Swift肯定不是本文开头提出的那些优美语言或语言框架组合之一。对于我来说，Swift不仅是个忧伤的结局，而且毫无必要。

那么，根据我对Swift的反对观点，下一步该怎么走呢？幸运的是还有许多路可以探索：

• Rust：一种强类型语言，其方向和目的都十分明确。一般来说我不喜欢强类型系统，但对于底层问题而言，强类型显然有它的用处。我希望获得这些好处，并多了解些底层的世界。

• Elixir / Phoenix：在我看来就像是rails和erlang。希望它们名副其实。

• 我不会完全脱离苹果的生态系统。即使它漏洞百出，Mac和iOS设备依然是最好的。但是，我不会在以后的软件工程中使用Swift，希望可以做到这一点。

原文：https://rant.monkeydom.de/posts/2018/06/10/on-my-misalignment-with-apple_s-love-affair-with-swift

作者：Dominik Wagner

译者：弯月，责编：郭芮

  征稿啦！

CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。
如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（guorui@csdn.net）。

————— 推荐阅读 —————

点击图片即可阅读