点击上方“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

译者：弯月，责编：郭芮

  征稿啦！

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

点击图片即可阅读