论程式的三元素
文 / 蔡學鏞
正如同陽光、空氣、水，是生命三元素；我認為程式三元素是語言、API（Application Programming Interface）、工具。
【語言】
語言通常是中立的，和特定的平台無關（組合語言與系統語言除外）；但是，某些語言確實比較適合某些平台。以Apple平台來說，顯然Objective-C會是最好的選擇；以.NET平台來說，顯然C#會是最好的選擇。好的語言選擇可以讓你具有更多資源，和平台有更好的整合，且新版本推出的速度更快。
語言通常也和專業領域無關（當然，像VHDL這樣的語言除外），大多數語言在介紹自己時，用到「General-Purpose」（一般用途）形容自己。但不可否認的，不同語言可能會有不同的適用性，有些語言適合開發Web前端，有些適合開發Web後端，有些適合開發桌面程式。
語言通常會帶有作風（paradigm，也稱為「範式」），有些是OOP的範式、有些是FP的範式…。經過多年的融合與演變，大多數的語言至少會同時具有兩、三種範式，有些甚至會多達七、八種。語言範式越多時，程式設計師可以依據自己的需求和喜好，採用不同的範式。但範式多不見得是好事，有可能表示這個語言沒有中心思想，駕馭的難度可能更高，寫程式時犯錯的機會可能更大。
語言有高階和低階的分別，高階者比較接近人類，低階者比較接近機器。很多人誤以為越低階的語言越「難」，事實上可能不是如此。在我使用8086組合語言的時候，我就領悟到，組合語言其實相當好學，因為語言元素（指令）相當少，且變化不大，基本概念都差不多。多數人認定組合語言很「難」，其實是在於「難讀」（不容易藉由閱讀源碼得知原作者的意圖）與「難寫」（即使要表達一件簡單的事，也必須寫出很多程式碼），而非「難學」。
對於語言的選擇，除了平台、領域、範式之外，還有相當多面向需要考量，其中有一些是許多人所疏忽的，像是可讀性、可寫性、上手快慢。另外，也要考慮到API，如果你選擇的語言沒有你需要的【API】，那麼你的麻煩就大了。
【API】
API通常和特定的平台無關，但是和專業領域有關。至於那些和專業領域無關的API（例如排序、字串處理），我都把它們歸納到語言中，而傾向不認定它們是API。
大多數的API都是以函數的方式存在。OOP的API會將函數集合成類別，將類別集合成框架；FP的API會將函數集合成模組。API的單位很難認定，你可以說一個框架或模組是一個API、一個Class是一個API、或者一個函數是一個API。
我認為語言、API、工具這三者中，API是最難學的。以Java來說，package有上百個，類別有上千個，方法（函數）更是有上萬個。API牽涉到專業領域的知識，有特定的呼叫次序和參數需求。
其中最難的API通常是GUI（圖形化使用者介面）。資料庫的API可能反倒很簡單，因為許多資料庫API都只是CLI（Call-Level Interface），只負責將SQL語法送到DBMS。從某種角度來看，不只這些負責連線到資料庫的函數是API， SQL語言應該也算是資料庫API的一部份。而SQL是一種DSL（Domain Specific Language）。
這又牽涉到這幾年開始流行的一個話題 -- 以DSL形式存在的API，例如Ruby-on-Rails。由於DSL是語言，所以使用彈性自然比函數（類別、框架）大，加上語言用途特定，所以很容易學，這些都是DSL式的API受到大家的矚目的原因。而且，DSL可以讓程式碼大幅縮短，有助於減少對某些開發【工具】的依賴。
【工具】
當然，最基本的開發工具是編輯器、編譯器（或解譯器）、除錯器，但這已經是遠古時代的事情了。現代的軟體開發，用的工具越來越多。尤其是程式產生器的地位越來越重要。
現在的開發工具都很強調程式產生器，利用程式產生器提高生產力。以往只需要UltraEdit就能寫程式，不需要這些龐大的開發工具，現在卻很難辦得到，正是因為程式碼產生器的緣故。很多人即使不知道底層的作法，也可以很快地把系統做出來，可以在名片印上「資深軟體工程師」，這也是拜程式產生器之賜。
現在的軟體開發都已經走火入魔了。開發的速度提升，不是因為需要寫的程式變短，而是程式碼產生器幫我們產生出更多程式，而這些產生出來的程式，如果沒有像Visual Studio這樣的工具協助，以後會相當難以維護。
我希望語言能更精簡，且支援建立DSL，而DSL類型的API大幅度減少程式碼長度，減低我們對於某些工具的依賴。語言、API、工具不應該是三足鼎立，而應該以語言和API為主，工具為輔。
正如同陽光、空氣、水，是生命三元素；我認為程式三元素是語言、API（Application Programming Interface）、工具。
【語言】
語言通常是中立的，和特定的平台無關（組合語言與系統語言除外）；但是，某些語言確實比較適合某些平台。以Apple平台來說，顯然Objective-C會是最好的選擇；以.NET平台來說，顯然C#會是最好的選擇。好的語言選擇可以讓你具有更多資源，和平台有更好的整合，且新版本推出的速度更快。
語言通常也和專業領域無關（當然，像VHDL這樣的語言除外），大多數語言在介紹自己時，用到「General-Purpose」（一般用途）形容自己。但不可否認的，不同語言可能會有不同的適用性，有些語言適合開發Web前端，有些適合開發Web後端，有些適合開發桌面程式。
語言通常會帶有作風（paradigm，也稱為「範式」），有些是OOP的範式、有些是FP的範式…。經過多年的融合與演變，大多數的語言至少會同時具有兩、三種範式，有些甚至會多達七、八種。語言範式越多時，程式設計師可以依據自己的需求和喜好，採用不同的範式。但範式多不見得是好事，有可能表示這個語言沒有中心思想，駕馭的難度可能更高，寫程式時犯錯的機會可能更大。
語言有高階和低階的分別，高階者比較接近人類，低階者比較接近機器。很多人誤以為越低階的語言越「難」，事實上可能不是如此。在我使用8086組合語言的時候，我就領悟到，組合語言其實相當好學，因為語言元素（指令）相當少，且變化不大，基本概念都差不多。多數人認定組合語言很「難」，其實是在於「難讀」（不容易藉由閱讀源碼得知原作者的意圖）與「難寫」（即使要表達一件簡單的事，也必須寫出很多程式碼），而非「難學」。
對於語言的選擇，除了平台、領域、範式之外，還有相當多面向需要考量，其中有一些是許多人所疏忽的，像是可讀性、可寫性、上手快慢。另外，也要考慮到API，如果你選擇的語言沒有你需要的【API】，那麼你的麻煩就大了。
【API】
API通常和特定的平台無關，但是和專業領域有關。至於那些和專業領域無關的API（例如排序、字串處理），我都把它們歸納到語言中，而傾向不認定它們是API。
大多數的API都是以函數的方式存在。OOP的API會將函數集合成類別，將類別集合成框架；FP的API會將函數集合成模組。API的單位很難認定，你可以說一個框架或模組是一個API、一個Class是一個API、或者一個函數是一個API。
我認為語言、API、工具這三者中，API是最難學的。以Java來說，package有上百個，類別有上千個，方法（函數）更是有上萬個。API牽涉到專業領域的知識，有特定的呼叫次序和參數需求。
其中最難的API通常是GUI（圖形化使用者介面）。資料庫的API可能反倒很簡單，因為許多資料庫API都只是CLI（Call-Level Interface），只負責將SQL語法送到DBMS。從某種角度來看，不只這些負責連線到資料庫的函數是API， SQL語言應該也算是資料庫API的一部份。而SQL是一種DSL（Domain Specific Language）。
這又牽涉到這幾年開始流行的一個話題 -- 以DSL形式存在的API，例如Ruby-on-Rails。由於DSL是語言，所以使用彈性自然比函數（類別、框架）大，加上語言用途特定，所以很容易學，這些都是DSL式的API受到大家的矚目的原因。而且，DSL可以讓程式碼大幅縮短，有助於減少對某些開發【工具】的依賴。
【工具】
當然，最基本的開發工具是編輯器、編譯器（或解譯器）、除錯器，但這已經是遠古時代的事情了。現代的軟體開發，用的工具越來越多。尤其是程式產生器的地位越來越重要。
現在的開發工具都很強調程式產生器，利用程式產生器提高生產力。以往只需要UltraEdit就能寫程式，不需要這些龐大的開發工具，現在卻很難辦得到，正是因為程式碼產生器的緣故。很多人即使不知道底層的作法，也可以很快地把系統做出來，可以在名片印上「資深軟體工程師」，這也是拜程式產生器之賜。
現在的軟體開發都已經走火入魔了。開發的速度提升，不是因為需要寫的程式變短，而是程式碼產生器幫我們產生出更多程式，而這些產生出來的程式，如果沒有像Visual Studio這樣的工具協助，以後會相當難以維護。
我希望語言能更精簡，且支援建立DSL，而DSL類型的API大幅度減少程式碼長度，減低我們對於某些工具的依賴。語言、API、工具不應該是三足鼎立，而應該以語言和API為主，工具為輔。
