相較Java,Ruby在語言上有幾個特點:(1)動態型別(2)更為純粹的物件導向程式語言(3)語法上提供更多高階抽象的元素(4)提供meta-programming。

很多人提到Ruby時都會強調,用它寫下的程式碼較簡短。上述特點,其實多半有助於縮短Ruby程式碼的長度。

而Java因為是靜態型別語言,所以為了型別的宣告及處理,會要求程式設計者寫下相關的程式碼,導致內容因此變長。

另一方面,Java設計之初,為了效率的考量,將型別分為基礎型別(primitive type)及物件型別。基礎型別就是像int、float、double之類、可能在程式中頻繁被使用於計算的型別。因為型別分兩類,也因此衍生不同語法。用不同的語法操作兩類的型別,也會讓程式看起來不簡潔。

Ruby相較於Java提供更高階的抽象語言元素,這讓程式設計者可以用更高階的方式來描述同件事,而這麼一來,程式碼長度自然也有機會縮短。

前文提到所謂的「魔幻語言」和「簡約語言」的分別,就能知道Ruby和Java是如何分屬這兩派。

簡約語言「崇尚清晰直接,夠用就行,要求程式碼容易理解,寧可笨一點、累一點、多寫一點程式碼,反對出人意料的技巧,反對故弄玄虛」。這類語言其程式碼較長,一點也不讓人感到意外。

匆忙寫完程式碼,整體開發時間未必縮短
有人可能會說,某語言因為程式碼比較短,所以寫起來快,所以生產力高。若不深思,可能會有這樣的誤解。若用某程式語言寫下的程式碼較短,省去的其實是程式設計者打字的時間。但就如同前文中反覆強調的,軟體開發的生產力是由許多環節所影響著,從沒有程式碼,到你在鍵盤上逐一敲下第一個版本程式碼的期間,其實只佔所有開發時間的一小部份。你會需要測試、除錯,會面臨功能的修改調整或擴充,而這些工作在整個開發時間中所佔的比重,通常都不亞於完成第一個版本的時間。

也就說,即使你使用某個語言,可以很快寫完第一個版本的程式碼,但之後工作中必須花費過多的時間,例如,很簡短的程式碼卻暗藏許多難以察覺的bug,導致除錯工作困難及緩慢,那麼,對於縮短整體的開發時間來說,不見得有利。

整合式開發環境能提供許多協助
此外,這是從程式設計者全憑己力敲下所有程式碼的情況。事實上,在現在的開發中,許多程式設計者都會使用整合開發環境(IDE)來協助程式的開發。而大多的整合開發環境,都提供一些協助程式設計者產出程式碼的功能,例如自動補齊(autocomplete)的功能,能依據程式設計者已輸入的程式碼前後文,提供接下來可能會想輸入的選項,讓程式設計者僅需在諸多選項中選擇,即可完成程式碼的輸入,因而縮短程式碼設計者花在敲擊鍵盤以產生程式碼的時間。

所以說,或許某一份程式碼表面上看起來比較長,但是,在整合開發環境的助陣之下,或許並不需要花費太多的輸入時間。有趣的是,相較於動態型別的語言,對於靜態型別的語言,整合開發環境能夠提供給程式設計者的協助更多。因為只有當程式碼中提供了型別的資訊,整合開發環境才能據以進行分析,進而提供產生程式碼或是各種進階分析的幫助。

我們可以說,靜態程式語言或許先天上在程式碼長度上佔了劣勢,在後天上卻又可以得到整合開發環境的自動化輔助,縮短輸入程式碼所需的時間。總的來說,單從程式碼長度來論斷開發生產力,其實是過度簡化了可能的影響因素。

兩種語言在網頁應用程式開發的優勢與劣勢
Java在生產力上面臨最大的質疑,恐怕就是在Web應用程式開發上。或許是因為社群風氣的影響,大多的Web應用程式框架,都朝向高彈性、高通用性的架構方向在發展,而高彈性及高通用性通常就意謂著高複雜度,這不僅使得學習曲線過高,也造成了開發時的一些額外負擔。這並不是說這些應用程式框架無用,而是它們或許並不適合所有的開發者,尤其是一些需要輕量級開發的開發者。當你使用重量級的應用程式框架時,是很難期待會有輕量級的表現,這當然不會有太好的生產力表現。

相反的,基於Ruby語言的RoR框架,巧妙瞄準了特定應用領域的問題、提供足以滿足大多需求的方案,讓基於RoR的Web應用程式開發,可省下許多開發時間。這是RoR讓人感受到高生產力的原因。

當然,Java社群一樣有機會打造輕量化的Web應用程式框架,在特定的應用情境下,提供較目前方案更好的生產力。

相較於Java,Ruby可能會被質疑的就是它的效能問題。當然,Ruby身為直譯式語言、動態型別語言,在效能上是肯定要付出代價的。每種特性都有好壞的那一面,例如,Ruby身為直譯式語言所帶來的優勢就是毋需編譯、沒有複雜的部署程序,但是,沒有什麼好處是不需要代價的,代價當然就是執行效率。動態型別當然也有它的好處,但是,這個特性衍生出來的弱點之一,也是效率的問題。

有趣的是,Java初問世時,也時常遭受到開發者對其效率的質疑,因為Java並程式多半不是直接以原生的CPU指令執行,而是運行於原生CPU之上的虛擬機器。但時至今日,已鮮少聽到此類的質疑。

隨著各種技術的發展,原本效率差的已變好
事實上,我認為一個語言是否具備足夠的效率,是會隨著時代的演進而有不同的意思。因為一方面硬體效能總是不斷的在成長,。而另一方面,我們所開發的應用程式,其運作不完全只是單純的密集使用CPU而已,例如應用程式會需要做I/O,無論是磁碟的讀取或網路的傳輸,而這些I/O動作所需等待的時間、以及佔應用程式的比例,可能都高過於密集使用CPU於計算的部份。

過去你可能覺得效率不彰的語言,或許因為硬體的進展、編譯、直譯的技術演進,它成了具備足夠效率的語言。有些時候,我們在軟體開發遭遇到最難的問題,並不是在於我們寫的程式執行得不夠快,而是在於我們沒有辦法在目標時間內完成足夠品質的軟體。倘若一個語言在這方面的表現卓越,那麼即使它目前的效率還不夠好,也會很快的達到世人對於其效率的要求。

另一方面,愈是高度抽象化的語言,愈有機會得到更高的效率。因為它意謂著程式設計者處理的,都是高階的概念,至於低階的實作則由語言或程式庫負責。而低階的實作或程式庫通常都可以由專家負責最佳化的工作,只要把語言實作和程式庫的效能調校好,那麼程式就自然而然的變快了起來。

適用性才是關鍵
從上述的討論中不難明白,語言間的優劣好壞實在不容易比較,我覺得最有趣的現象是,撇開工作上需求及限制不談,每個程式設計者會喜歡、慣用的程式語言時常都是基於天性。很多時候,你就是喜歡具有特定特性的程式語言,並不是因為它最多人用,或是其他現實的因素。

以我來說,就是偏好靜態型別、編譯式的語言,這是天性,很難具體的解釋為什麼。不過,現在的開發工作上其實時常會涉及需要多種語言的情況,沒有最好的程式語言,只有相對適合的程式語言。能運用的程式語言愈多,就形同擁有更多可選用的工具,對於解決現實的開發需求,也就更有幫助。

 

專欄作者


熱門新聞

Advertisement