第一個Hello World範例的出現,據稱是在Brian Kernighan寫的《A Tutorial Introduction to the Language B》中,此後成為許多程式語言教學的第一個範例程式。隨著技術演進,Hello World的示範漸漸有另一種意涵,如何用最簡潔程式碼來顯示Hello World,似乎就代表了該語言的能力?

語法簡潔僅為技術能力的一個面向
就顯示Hello World來說,若是Python或Ruby,可以只寫print('Hello World'),若是Java,得寫成System.out.println("Hello World"),簡潔性上的差異一目瞭然,若每天待解決的問題都是Hello World,Java自然遜色許多。不少文件或書籍常以此論調,鼓舞其他開發者投入具有更簡潔語法的語言。

事實上,語法簡潔性常以隱藏複雜度來換取,被隱藏的複雜度會以另一種代價在某處呈現。

例如,動態語言無需宣告變數型態,在語法上得以簡化,但失去了型別檢查優點,代表程式間必須有更多慣例約束,處理執行時期錯誤的負擔更重,程式碼測試必須更為全面,輔助工具的製作較為困難,效能上也存在一定瓶頸。

某些語言允許開發者擴充語法,讓他們得到更符合問題情境的語言,然而若為求語法簡潔而大量擴充符號,為了看懂程式碼,得先瞭解擴充語法過程,若語法上過度簡化,反而造成日後維護的問題。

語法只是解決問題時考量的元素之一,現實中要解決的問題絕不只是Hello World,就算是Hello World,也可進一步放大需求來考量。

在感受語法簡潔性帶來的快感之餘,你可以嘗試更多Hello World式簡易範例的可行性,藉此挖掘出語法以外,附加在語言身上更多必須考量的要素,甚至被隱藏的複雜度。

嘗試各種Hello World的可行性
以Java為例,在執行過第一個顯示Hello World的程式後,你可以想一下,若要輸出中文「哈囉世界」可行嗎?若是Java,將字串改為中文就可以了。若程式編譯出來的HelloWorld.class是在C:\workspace中,而你要在另一路徑執行程式呢?其中一個可行的方式是:

> java -classpath C:\workspace HelloWorld

在得知如何執行以上指令的過程,你會先學習到java指令其實是啟動Java虛擬機器(JVM),也就是Java程式的作業系統,.class就是JVM的可執行檔案,而-classpath引數是在告知JVM可執行檔案的搜尋路徑。如此,更進一步瞭解Java技術,以JVM抽象化作業系統的重要事實。

若根據使用者輸入來說聲Hello呢?程式也許是:

java.io.Console console = System.console();
System.out.print("Input your name: ");
System.out.println("Hello " + console.readLine());

在寫出以上程式碼的過程中,必須接觸使用套件(package)管理類別名稱空間的概念,也許你可為HelloWorld類別加上套件名稱;而瞭解編譯與執行時必要的目錄結構,以及類別名稱全名指定後,思考到編譯出來的.class有檔案名稱衝突的問題,那麼原始碼.java也有同樣問題,從而進一步認識編譯時-sourcepath引數的存在與意義,並瞭解原始碼檔案管理,初步認識Java專案結構的基本概念。

接著可以再想一下,一個檔案可寫完的程式拆為兩個檔案如何撰寫?在目前程式中,System與Console類別是哪邊提供的?在找到rt.jar中封裝了Java標準API後,就知道Java發布或部署程式庫時會運用JAR封裝.class檔案,也許可試著將自行撰寫、編譯好的.class封裝為JAR檔案,也許在這一連串嘗試,對下達繁複指令感到厭煩之後,從而認識了各種成熟的建構工具或整合開發環境,以及相關指令與工具之間又是如何對照。

這一連串嘗試過程,主題都可以是Hello World,不用艱難目標、不用複雜語法,卻可從中認識Java語法外的幾個面向,像是抽象作業系統的JVM概念、套件式的名稱空間管理、原始碼與位元碼管理、專案結構基本概念、API的封裝與發佈、建構工具與IDE的使用。

用各種Hello World知新而溫故
在學習另一種程式語言時,類似Hello World的探索過程,不僅可引導出語法層面外許多議題,更可與原本已知曉的語言交相印證。

以Ruby為例,成功顯示Hello World後,可將字串改為中文「哈囉世界」嘗試執行,不幸地,會出現invalid multibyte char (US-ASCII)錯誤(Ruby 1.9之後)。這反映出Ruby文化對字串編碼的特有認知──使用與字元集無關的(Character Set Independent,CSI)處理方式,將字串單純視為位元組序列。這其實與Ruby誕生於編碼方式紛亂的日本有關,認為語言本身對編碼的任何預設都有困擾。

無論如何,若使用非西歐字元,Ruby要你一開始就面對編碼議題。若使用UTF-8文字檔案,那麼必須在原始碼中告知直譯器:

# encoding: UTF-8
print '哈囉世界'

依使用環境不同,在繼續進行簡單的Hello World輸入、輸出時,也許還會遇到其它編碼問題(若環境不是一致地採用UTF-8),從而認識Ruby中外部編碼、內部編碼與字串編碼的存在。

若只看第一個Hello World程式,怎會認識到這些問題呢?或許此時你會反思,為什麼Java沒有這個問題?為什麼以前撰寫Java原始碼時,從沒意識到原始碼檔案的編碼問題呢?Java內部編碼又是什麼?

由於語言文化不同,會讓你回頭對原本熟悉的語言更深刻認識,從而發掘出以往沒有的思考方向。

你也許想寫個.rb檔案負責取得簡單輸入,另一個.rb檔案負責簡單輸出,兩個檔案放在不同的目錄,因此認識了-I引數與require的使用,你想到Java中的-classpath與import,但它們並不相同,也稱不上類似;進一步地,你會認識Ruby模組可以達到Java中套件的類似功能,但名稱空間管理還是有所不足;接著,你想要將目前幾個簡單的檔案封裝、發布,從而認識到RubyGem的使用,你也許回頭想想Java中JAR機制跟RubyGem有何不同,從而認識JAR檔案本身版本控管能力不足的問題,知道RubyGem與Java生態中Maven工具的相似性。

通常對於原有語言的熟悉度,會引導你寄望所接觸的另一門語言也有對應或類似特性,這會是很有趣的過程,不僅可得知另一門語言的概略架構,也讓你反思原本熟悉語言的相關議題。

不同語言解決不同面向的問題
不同語言會有不同語法,不同語法根據不同模型,也許不同模型解決的問題集合有所重疊,但是不同模型擅長解決的問題集合並不相同,甚至有其誕生時的文化背景與待解決的特定問題。

使用組合語言也能解決顯示Hello World的問題,但拿來與Python、Ruby相比並不合情合理。

靜態語言在變數型態的要求有其編譯時期檢查優點,然而語法上就沒有動態語言的簡潔。Ruby、JavaScript這類偏重物件個體性的語言,可以輕易賦予物件不同的特性,快速堆砌想建構的功能,但容易造成維護上的混亂,在必須應用在工程性為重的場合,往往得以包裹器對物件的個體性加以約束。反觀Java這類重於工程性的語言,使用類別規範所有物件行為,在重維護的場合較具優勢,但語法彈性相較上自然顯得不足。

通常在推廣或說服其他開發者投入另一門語言時,為了馬上端出牛肉給開發者眼睛為之一亮,自然不會有這一連串Hello World範例來呈現背後複雜度或架構的過程,然而身為接受資訊的開發者本身,在瞭解語法之餘,可自行嘗試各種簡易範例的可行性,挖掘出語言外概略的複雜度、文化,更可進一步瞭解到語言想要或擅於解決的問題集合。

 

作者簡介


Advertisement

更多 iThome相關內容