編程中的多語言夢魘

jopen 10年前發布 | 15K 次閱讀 編程

  英文原文:Our Polyglot Nightmare

  人類語言的多樣性幾十年來一直在不斷下降。隨著全球化通信和商業的興起,發言者越來越多地將精力放在那些能夠提供最經濟和最多社交機會的語言上,世界因此加速了其淘汰非流行語言的進程。這些在語言上的損失甚至引起了類似瀕危語言項目(Endangered Languages Project)這樣的機構來保護它們不至于消亡。

  在初創企業社區,這種根本的力量甚至更勝一籌,因為初創企業團隊經常要在世界各地跨時區工作。不過,編程語言作為人類語言的表親目前還沒有遭遇 同樣的命運。恰恰相反,在過去這幾年,隨著編程語言從理論走向實踐,還出現了所謂黃金時代,新的和新近流行的被初創企業和大公司使用的編程語言都大有泛濫 之勢。

  看到供程序員使用的新的編程工具總是令人興奮的,它可以潛在地提高生產力,并且可以更快地給我們提供我們想要的產品。但是,語言的多樣性對工程師隊伍來說也有不好的一面,就為了推出自己的產品,大家必須在多語言環境中工作,更別提之后還要進行維護。

  為了對我所說的有一個更好的理解,不妨設想一下,一個典型的初創企業打算為用戶提供一款應用,可以在 web 和移動界面使用。對于前端來說,開發者將至少使用 HTML、CSS 和 JavaScript 等語言,并且有可能還會使用更多的語言而這取決于所選擇的庫。對于安卓和 iPhone 的應用,開發團隊將不得不使用這兩個平臺的原生語言,它們分別是 Java 和 Objective-C(當然對于現在而言蘋果使用的是新語言 Swift)。而為了將這一切連接起來,團隊將不得不建立一個后端,這又可能涉及如 Python、Ruby 或者 Go 以及數據庫查詢語言。

  但這種分析只是一種有趣的假設。RedMonk 公司開發出了一個編程語言排名系統,上個月發布了他們最新的排名報告,該報告顯示“語言的多樣性……仍然是常態。”他們的數據表明,盡管前幾位的排名一直相對穩定,一些新的語言正變得越來越流行。

  就像 20 世紀的“大科學” 的興起讓獨自做研究的科學家變成一個研究小組,開發環境不斷增加的復雜性要求我們建立更大的工程師團隊,擁有更多的專家。這種專業化對就業市場有著重要影 響,特別是對像硅谷工程師這樣比較局限的市場。這也意味著我們將研發的工作碎片化,這有可能延緩語言庫和工具包的演變進程。而也許最不幸的是,這還會限制 獨立開發者和小型創業團隊的貢獻,因為由于人手所限,他們將很難為某些平臺進行編程開發。

  雖然還有很多問題要考慮(后面我將詳細討論這方面),但編程語言的多樣性不一定都是負面消極的。顯然代碼的用途很多元化,無論用于嵌入式系統,還是高度可靠的系統比如空中交通管制,或者為初創企業的想法打造的簡單測試環境。使用合適的工具進行工作一定能提高生產力。

  但源代碼只有兩個目的。它讓一位工程師能夠向另一位工程師解釋一個程序要做的事,同時它也讓工程師能夠決定一臺電腦如何運作。語言越是豐富多樣,第一種溝通就會越困難。

  盡管如此,主要有三個根本原因導致了編程環境的日益碎片化。首先,新的語言采用的速度有所加快。這主要是由互聯網本身所造成的,它讓開發人員能夠通過更好的教程、參考信息和代碼示例來迅速傳播新的編程語言。

  此外,像 GitHub 這樣的工具鼓勵更多的工程師參與到庫的開發中來,這讓一個新編程語言可以用比過去快得多的速度獲得可行性。企業對新編程語言的支持也是非常強大的,無論是 谷歌對 Dart 和 Go 還是蘋果對 Swift 都是如此。最后,相比過去工程師們似乎更愿意用新的編程語言。人們不禁懷疑保羅·格雷厄姆(Paul Graham)呼吁初創公司用外來編程語言找到更好的工程師的做法是否推動了人們去選擇較鮮為人知的編程語言。

  雖然更快地采用新語言保證了更強大工具的廣泛使用,但這也對工程師構成了挑戰,他們必須加速他們的教育進程以便能跟上潮流。由于多個環境中的多種編程語言分割了他們的時間,現在對一種特定語言的掌握變得更加困難。

  以蘋果的 Swift 語言為例,它很可能成為為 iOS 進行程序開發的標準語言。雖然從 Objective-C 中獲得的知識不會完全被拋棄,但每一位的 iOS 工程師都必須學習新詞匯來充分利用 Swift 的優勢。

  第二個主要的原因是出于在多個平臺上進行開發的需要。高科技產業中的開發者現在為 Web、移動設備、云計算基礎架構、多核處理器以及可穿戴設備等進行編程。這里的每一個平臺都具有獨特的性能特點和要求,這表示一種編程語言相比另一個在 效用上可能會有很大的不同。舉例來說,像 Go 和 Erlang 這樣的語言對服務器群很有用,因為在那里并發性很重要,但很可能對一個可穿戴設備來說就沒那么有價值,因為那里的處理能力可能會集中在單個芯片上。

  第三,這種平臺上的多語言性是與各種語言范式爭奪開發者的關注相匹配的。函數式編程語言,作為一種讓學者和一些發燒友好奇的語言,現在通過像 Scala 和 Haskell 這樣的編程語言得到更加廣泛的普及,而這在很大程度上是由于更多的人意識到這種語言在處理 Web 應用程序上的價值。

  鑒于這些根本原因,多語言的噩夢似乎不大可能很快消失。

  但是這樣成本也是很高的。我們面臨的挑戰不只是語言的數量正在增加,各種編程環境的組合也正變得撲朔迷離。由于公司開始使用自己的一套獨特技 術,尋找到合適的完全擁有所需技能的工程師是很困難的,而工程師們則不得不花費更多的時間來讓自己的技能具有通用性,這樣才能保持在學科的前沿。可悲的 是,創業公司很少會給新員工提供必要的資源進行培訓,相反,他們希望程序員從一開始就具有生產力。

  更廣義來說,在編程社區里,我們越來越碎片化也意味著我們正在分散我們的精力去建立已有的庫。我們的編程時間是有限的,特別是在為任何可用的語言提供基礎的開源項目上。如果我們在多個項目上的時間和精力被攤薄,那么一開始我們就可能會失去擁有多種語言的生產力優勢。

  最終,我們會發現一個集體行為的問題,而這個問題,坦率地說,不可能被解決。雖然可能沒有什么“解決方案”,創業公司仍然可以通過將資源集中到 他們所需要的語言上來避免多語言的問題。項目經理應該對將新語言引入到現有基礎架構中非常謹慎,同時也應對從現有的流行語言轉到另一個更前沿的語言更加謹 慎。有時,一點性能上的影響讓團隊中多點凝聚力是值得的。

  如果我們繼續問如何讓技術變得更具包容性,方法之一就是確保讓在行業表現良好所需要的知識盡可能得精簡。雖然掌握多種語言肯定是對當今軟件開發 人員的要求,但我們每個人都可以盡一份力,確保技能要求不會不成比例地增加,不會超過我們的工程技術人才可以提供的范圍。工程師不必成為聯合國口譯員才能 創建自己的夢想。

  圖片來自 Flickr 用戶邁克爾·科特(Michael Coté)

來自: www.techug.com
                    <span id="shareA4" class="fl">                            
                        </span>
 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!