程式語言的異同及選擇 (轉)

程式語言的異同及選擇 (轉)[@more@]

語言的異同及選擇

.9  （所有版權保留）

一、各種語言程式設計的共同點

1. 基本單位都是

絕大多數語言的基本單位都是函式。執行環境提供給我們的是函式入口，我們編時寫的主要內容也是函式。
執行時，我們編寫的程式內的函式或者直接操作的函式，或呼叫的介面內的函式，或呼叫虛擬機器的函式，或呼叫執行環境的其他函式。

2. 函式內演算法的實現差別不大

真正的價值是函式實現的演算法（這裡把功能或業務流程的實現也都算做演算法）。單就一個函式內（或幾個相關的函式）的演算法實現的程式流程（注意不是功能業務流程）來看，各種語言間的差別不是很大。

二、各種語言的不同點

1. 執行環境的函式介面不同

這一點不用多說了。詞法、語法的差別也不用說了。

2. 函式的組織方法不同

在傳統的、C、Basic、Pascal、Script等等語言中，函式是獨立的，可以以程式碼或模組檔案進行組織管理。

在的C++、、等等語言中，函式組織成類或元件，以類或元件的形式進行組織管理。

3. 函式的規劃設計方法不同

非OOP的專案中函式的規劃設計完全沒有統一，根據實際情況變化非常大。

OOP的專案中的函式規劃設計以類為基本設計單位，確定了類之後再確定函式。現在已經有很多理論與工具來支援以類為基本單位的設計。

4. 函式的積累沉澱與重複利用

程式設計師、開發團隊、公司在執行多年後，非OOP的函式積累成函式庫，OOP的函式積累成類庫或元件庫。
非OOP的函式庫內的函式可能部分依賴於OOP的函式庫，反之亦然。

5. 函式的實現的編碼、測試工作量

不管用那種語言，如果沒有特別的執行環境函式支援或類庫支援或元件支援的話，每個函式的編碼與測試工作量沒太大差別——前提是針對熟手，例如寫一個特定的排序函式，彙編與 的工作量差別不大。

但實際上針對不同的語言，執行環境提供的支援是不同的。

三、選擇程式語言時的考慮

1. 或虛擬機器的選擇

作業系統或虛擬機器的 （包括越來越多的元件）非常重要的，這是基礎，選擇時最重要的考慮因素。

的優勢在於原始碼公開。Java 的跨平臺是指跨作業系統，不是跨虛擬機器——說實話本人不知道有多少廠家實現了多少種 Java 的虛擬機器，並且它們的 API 的定義是完全相同的。

2. 程式語言的執行環境的選擇

一種程式語言可能有若干種開發、執行環境支援。打個比方，Basic 語言有 QBasic、、 等。開發、執行環境的支援也是非常重要的，它很可能提供了作業系統或虛擬機器之上的更多的函式（如），同時也規定了詞法與語法。

程式語言的執行環境的長期生命力也是很重要的。

程式語言的跨平臺只能說是在不同的作業系統的上的開發、執行環境的函式保證一樣，但不能保證作業系統的API一樣——除非不呼叫作業系統的API。

3. 文件是否詳細、是否豐富

沒有好的文件，再好的基礎 API（或類庫、元件）我們都找不見。
原始碼是指 API 應用的原始碼。沒有豐富的原始碼，再好的基礎 API（或類庫、元件）我們都不會用。
其實某種語言發展多年之後，幾乎所有的 API（或類庫、元件）的應用的原始碼都可以搜尋到，我們抄過來改一改就是了。

抄不來的是複雜演算法（包括功能或業務流程）的原始碼——抄過來我們也看不懂，更不敢簡單改一下就賣給客戶。

4. 第三方函式庫、類庫或元件庫是否豐富

在作業系統或虛擬機器的 API 之外，在開發、執行環境的 API（包括類或元件） 之外，還有多少已經寫好的函式我們可以使用。但是實際上，對第三方的 API 的學習、適應、使用的工作量很大，風險非常高，所以這一條不用太重視。

5. 語法與詞法的選擇

在考慮了上述的因素後，我的做法是最後考慮詞法與語法。原因很簡單，我懶。哪個語言的 API 多、詞法及語法簡單，我就用哪個——我說的是給老闆給客戶幹活。如果是我有一段時間突然對某一個語言或技術有了興趣而要自學一把，那另當別論。

我也見過有的人對某種語法有狂熱的愛好，就像老夫子們出口必之乎者也，我覺得也挺讓人佩服的。任何一種語言學精了用爛了都很了不起，貴在恆心。

6. 必須要會的語言

不用多說。在現在這個年代， + HTML 好像也必須學。