Swift 讓我對蘋果深惡痛絕！

關鍵時刻，第一時間送達！

在我的軟體工程師生涯中，只有為數不多的幾次被一種語言的設計和理念的美麗所折服，進而從中獲得靈感。比如：

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

譯者：彎月，責編：郭芮

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！