【51CTO.com快譯】隨著在開源之后獲得對Linux的支持能力，Swift已經(jīng)成為跨平臺與服務(wù)器端開發(fā)人員不可忽視的一種強大編程語言選項。

就在上周，蘋果公司已經(jīng)公布一項承諾：其Swift語言如今正式轉(zhuǎn)型為開源項目。作為一款一年之前才剛剛出爐的編程語言，Swift屬于C語言家族中的組成部分，其設(shè)計目的在于實現(xiàn)通用型應(yīng)用程序開發(fā)任務(wù)。蘋果公司最初發(fā)布Swift語言之時主要針對新型桌面與移動應(yīng)用開發(fā)工作，且采用LLVM編譯器。Swift汲取了眾多現(xiàn)代語言設(shè)計方案中的思路成果，并將C語言的復(fù)雜性與深度同Python等解釋語言的易用性加以結(jié)合。除此之外，其運行速度亦非常出色，且能夠與大型數(shù)且及集合順暢對接。

Swift的開源發(fā)布版本將繼續(xù)保持自身發(fā)展，同時加入了Linux支持能力與服務(wù)器端語言功能。Swift目前已經(jīng)走上了前進的快車道：在其發(fā)布的當(dāng)年，Swift已經(jīng)升級至2.2版本，此外其同時增加了LLVM與clang編譯器等對接能力。目前Swift尚不提供Windows版本，不過微軟公司已經(jīng)在其***Visual Studio版本當(dāng)中加入了iOS與OS X應(yīng)用的Swift支持能力。

如果大家曾經(jīng)在OS X系統(tǒng)平臺上使用過Swift，就會發(fā)現(xiàn)Swift在Xcode當(dāng)中的使用方式與多年以來Objective-C開發(fā)者所熟知的開發(fā)環(huán)境非常相似，而兩種語言也能夠使用同一款編譯器。蘋果公司甚至直接將Swift描述為“剔除C元素的Objective-C”。

這是因為Swift實際上就是Objective-C的一種抽象化版本，且同樣使用底層LLVM編譯器。事實上，Swift與Objective-C相當(dāng)相似，大家甚至可以將Swift描述為一種新的、對特定關(guān)鍵性結(jié)構(gòu)進行了簡化并提升代碼可閱讀性的Objective-C語言分支。Swift立足于Objective-C的語法基礎(chǔ)，同時添加了現(xiàn)代結(jié)構(gòu)支持能力以簡化語言自身并幫助習(xí)慣于利用JavaScript或者C#進行iOS或者OS X應(yīng)用創(chuàng)建的開發(fā)人員輕松上手。這部分開發(fā)人員會從中發(fā)現(xiàn)大量自己熟知的特性，包括Swift的控制流處理機制以及函數(shù)使用方式等等。

Swift與Objective-C之間的共性簡化了應(yīng)用程序面向新語言進行更新的流程。大家可以將Swift與Objective-C代碼在同一應(yīng)用之內(nèi)進行混合與匹配，從而保證現(xiàn)有庫能夠在新應(yīng)用中進行復(fù)用。如果大家從其中一種語言轉(zhuǎn)移至另一種語言，則完全無需對有必要加以復(fù)用的代碼內(nèi)容進行重寫——除非各位刻意為之。

蘋果公司在語言設(shè)計當(dāng)中高度關(guān)注安全性保障原則，而Swift語言的一大核心特性亦在于其支持類型推斷。如此一來，盡管Swift并非強類型，但其仍然具備類型安全保障。具體來說，如果大家未能聲明某變量類型，但卻為該變量賦予某個已經(jīng)進行過聲明的值，那么Swift能夠自動推斷其聲明類型。在這種情況下，我們的代碼將更加安全——即降低了發(fā)生崩潰的風(fēng)險。Swift還利用自身內(nèi)存管理機制對指針進行訪問限制。

類型安全還意味豐大家永遠不會將int傳遞至string；Swift編譯器能夠始終將此標記為錯誤。其中將有一條守護語句在某段代碼的值為nil時阻止其執(zhí)行，這就使得我們能夠確保自己的代碼遠離各類常見用戶與API錯誤的困擾（一般來講，nil往往會導(dǎo)致編譯器時間錯誤）?；蛘撸蠹乙部梢允褂胦ptionals以允許特定變量的賦值為null，而無論其實際類型為何。

編寫Swift應(yīng)用非常簡單：大家只需要著手進行即可。整個過程不需要設(shè)置任何主函數(shù)或者導(dǎo)入引用。這種方式的設(shè)計目的在于進一小提高代碼可訪問性。盡管目前舂OS X或者iOS用戶界面都是由庫負責(zé)處理，不過大家仍然可以在為其設(shè)置外觀以及使用體驗之前首先開發(fā)應(yīng)用核心。

Swift中的一大關(guān)鍵元素為蘋果所謂“面向協(xié)議編程”機制。作為接入其它語言的關(guān)鍵性途徑，協(xié)議會利用某個類特定方法，從而保證大家能夠在該協(xié)議的幫助下在任意類當(dāng)中使用已定義方法。另外，協(xié)議還允許我們對任意類進行擴展——包括核心語言元素在內(nèi)——而無需對其源代碼進行編輯。這意味著大家可以同時使用各類第三方代碼與庫。

另一大優(yōu)勢：大家可以利用一整套協(xié)議組合幫助自己的開發(fā)團隊實現(xiàn)代碼標準。協(xié)議本身也是一款極為強大的工具，我們可以將其作為開發(fā)策略中的一項關(guān)鍵性因素。

Swift最為重要的創(chuàng)新成果之一在于將Playgrounds添加至Xcode當(dāng)中。蘋果公司目前正利用Xcode與Swift將LLVM編譯器推廣到更多開發(fā)人員手中，并確保使用者能夠在IDE之內(nèi)直接查看代碼功能。Playgrounds機制允許開發(fā)人員快速嘗試代碼片段功能，從而在無需切換至IDE之外的前提下了解其是否與預(yù)期相符。大家不必對代碼進行編譯再運行其build或者調(diào)試工具；一切都能夠在代碼編寫完成后立即進行檢驗。這種方式無疑極大鼓勵了開發(fā)人員做出新鮮嘗試，并將代碼編寫變成一種更具娛樂性的體驗。

將這些特性代入其它平臺則是同樣重要的一步。編程語言需要能夠在任意平臺上供開發(fā)人員使用，從客戶端到服務(wù)器端再到云端，而一套能夠跨越全部現(xiàn)代堆棧元素的一致性語言正是這類開發(fā)場景中的核心角色。但需要強調(diào)的是，目前大家尚無法在Linux平臺上享受到Swift編譯器內(nèi)的Playgrounds功能。

不過這種功能缺失也有其道理：作為主要面向服務(wù)器應(yīng)用程序的開發(fā)環(huán)境，大家在Linux當(dāng)中可能工不需要這種快速功能可視化機制——在這里，我們只需將輸出結(jié)果導(dǎo)入控制臺即可。蘋果公司在其Linux工具組合中提供一款基于REPL的調(diào)試工具，允許大家以交互形式快速運行代碼，這樣大家就能夠利用REPL（即讀取-運算-輸出-循環(huán)）工具作為表達式評估機制。

隨著源代碼被正式公布在GitHub之上，如今任何人都能夠?qū)wift原始庫進行fork，著手代碼實驗并將成果以貢獻代碼形式pull至Swift。其中最為重要的元素要數(shù)Swift的核心庫，其承諾提供對應(yīng)選項、從而將蘋果的各類開發(fā)框架擴展至其它平臺。這意味著我們只需一次性構(gòu)建Swift代碼，即可將其交付至多種平臺，而開發(fā)人員將借此獲得微軟開源.Net之外的又一套備選方案——另外，亦允許Xamarin等跨平臺工具供應(yīng)商為更為廣泛的開發(fā)者群體提供支持。

原文標題：Why non-Apple developers should care about Swift

【51CTO.com獨家譯稿，合作站點轉(zhuǎn)載請注明出處】