語言、技術陣營之爭始終存在,畢竟人類具有競爭天性,對於自己擁有或支持之物,總期待是正確之選擇,並尋求排行統計、名人或大師言論來加強觀點。

眾多開發者對於程式語言排行榜充滿熱衷,看著主要吃飯傢伙的語言在排行榜上升或下降,比看著股票漲跌還刺激。程式語言在世界上的排行順序?排行順序本身如何定義就是個問題,若不先確認定義,最後就只會落得語言名次上升就欣慰讚揚,下降就沮喪或不願承認的情境。

「TIOBE Programming Community Index」是目前多數開發者熟悉的程式語言排行榜,主要利用語言名稱在搜尋引擎中的查詢結果,統計語言的熱門程度,每月更新排行。程式語言名稱本身必須是Turing completeness(因而SQL、HTML、XML不在其列),且在Wikipedia擁有條目,並使用Alexa前九大搜尋引擎。TIOBE index不表示程式語言好壞,而是反映開發者討論、課程或職務資訊的網頁數量。

不過有人質疑有些語言網頁資源雖多,但其實很少被讀取;而且TIOBE index統計對於搜尋引擎排序策略很敏感,其本身網頁上亦說明因2004年四月,Google調整了他們的排序策略,因而造成Java與C++排行迅速滑落,再則不同語言會應用於不同領域,TIOBE index並沒有針對領域加以細分,僅對物件導向、程序式、函數式、邏輯、靜態與動態定型語言,作了簡單分類。

另一個「The Transparent Language Popularity Index」是SourceForge上使用開放原始碼、全自動化工具的排行指標。其統計來源基本上來自部落格、書籍銷售、維基、開放原始碼專案、職務等網路上的資訊數量,訴求特色在完全無人工干預。

除了如TIOBE index有不分類的排行之外,這項指標還將排行分為通用型、腳本語言與其它分類(包括了SQL),統計數據來源完全透明也是該排行榜之特色。該排行榜網頁下方還列出了幾個網站,各自針對不同定義對程式語言加以排行,想要多角度認識語言的排行,是個不錯的起點。

XX已死?OO取而代之?

沒有任何語言可以滿足所有使用者,或解決所有問題,語言隨著日受歡迎,累積的使用者與面對問題就越多,連帶著無法解決的問題也會越多,失望的使用者亦會增加,加上語言會因應使用者期盼加入更多功能而日漸臃腫,或因為各種政治因素而日漸失去活力,久而久之無法避免地,必然會面對的話題挑戰,就是「XX 已死」。

在各種排行榜上總是名列前茅的Java,也許是死最多次的語言。不少人想推崇另一門語言時,開頭總愛先宣判Java已死,多到有開發者聽到就會說:「Java is die hard. OK?」,甚至有人用「Java is dead」來作了一張歷史簡表〈A history of "Java is Dead"〉。

我印象中最深刻,造成不少Java開發者討論Java已死的一次,就是2005年O'Reilly出版《Beyond Java》一書,書名雖有Java字眼,然而後半部都在談Ruby on Rails,也許是因為這本書,或者是因為當年Ruby on Rails 1.0釋出,TIOBE index上Ruby份額也在2005年開始不斷爬升,也因而有了不少Java已死,Ruby將取而代之的議論。

多年過去了,Java沒有死。作為動態語言的Ruby有其彈性,但無法替代靜態語言的優點,Rails框架也無法解決所有問題。

與Java同為靜態語言的Scala,因為2008年Java One期間,James Gosling談話中提及其為JVM上另一使用語言之加持,且由於設計兼具了動態性,加上融合函數式典範,以及具有類似Rails的Lift、Play等框架,使得Scala將取代Java的言論一度上升。不過Scala語法繁多、社群風氣、工具支援等問題,終究還是沒能取代Java。

不久前,戰爭焦點轉移至動態語言王座,Ruby 1.9的釋出,一度有了Ruby將取代Python的言論。然而語言設計哲學不同、使用群不同、應用領域不同,兩者終究無法彼此取代。

語言的死亡或被取代,需要哪些條件呢?決定語言存在與否的因素,往往不是語言本身,而是語言的應用平臺,就像JavaScript因為找到了前端應用平臺而鹹魚翻身,Java最重要的資產JVM現今沒有語言可取代,Python、Ruby或PHP,也各有應用平臺。

若某語言要能取代另一語言,必須想想,前者能否取代後者長久累積的文件、社群、相應程式庫、框架、開發工具等資源,或者更實際地,是否有足夠商業手段與費用推動這些資源的產生,或者是說服客戶改用支持該語言的平臺。

物件導向是個騙局?

有人將語言戰爭的層次提高至典範戰爭,物件導向已死之討論,已不算鮮見,近來熱議的是〈Object Oriented Programming is Inherently Harmful〉這篇文章,其中舉了不少大師、語言之父、圖靈獎得主反對物件導向的支字片語,讓不少開發者討論起,風行十幾年來的物件導向,是否真的錯了?我們是否該重新追尋其他典範,像是函數式程式設計?

一直以來,雖然物件導向所宣揚的優點之一,是重用性(Reusability),但是,對使用者的易用性(Usability)或許才是真正的優點。易用性是指相對人類而言,物件概念比較貼近現實世界,較易將現實世界問題利用物件模型加以描述,也因此十幾年來物件導向相關工具不斷興起,建立現實中的各種產業,包括物件導向語言、架構師、建模工具等。

物件導向確實解決了大部份問題,但因為物件導向過於類似實體世界,因為人類的行為本來就是複雜的,物件導向衍生的問題因而複雜。

物件導向本身其實僅是解決問題的一種思考方式,問題往往是在使用者,而不是物件導向本身。就某些領域而言,使用物件導向不會是好的選擇,或者會使問題更複雜。不應該只看文章中被節錄之名人、大師的支字片語,應該看看實際他們發言的情境或前後文,大多數情況他們想表達的,是那些無視問題本質,一律採用物件導向的愚昧、謊言或騙局。

多角度瞭解語言排行與合作關係
面對語言排行,確認排行定義,才有辦法判斷名次意義。若想避免文件或相關人才難以尋得的問題,「TIOBE Programming Community Index」或「The Transparent Language Popularity Index」或許可參考,畢竟他們代表可尋得之資源數量。如果想採用最新技術,或許可以參考「Github Top Languages」,近幾年來,由於Github使用者十分活躍,這個指標反應出專案或語言實際活躍程度。

舉例來說,近來Web前端技術、框架、HTML5、Node.js等如雨後春筍發展,2012年Github Top Languages上第一名語言是JavaScript,除了語言排行之外,開發者還可在上頭瞭解各個專案被Fork、加註星號等排行順序。

就我的觀點而言,某語言被號稱已死或將被取代,反而表示該語言尚有接受挑戰之活力,如果一門語言不再有人稱其已死,或沒有人想談取代話題,反而是該語言真正步入晚年之時。

然而若構築於某語言的應用程式眾多,維護與遷移至另一語言或平臺,也絕非一朝一夕;而且語言的設計哲學不同、使用群不同、應用領域不同,隨著現在應用程式經常跨越多個技術,已很少單一語言技術構造出整個應用程式,因而語言不會是相互取代,而是走向互相合作,在最適合的領域發揮最適合功能。

語言的典範也是如此,視應用程式各個子問題的不同,必要時也應採用不同典範來解決問題。

作者簡介


Advertisement

更多 iThome相關內容