一份6000個項目的比較結果表明：編程語言的選擇對項目進度有重大的影響。

我最近在開發者論壇上看到一個討論有關JVM語言生產力（編程效率）方面的問題，如果那些高效率的開發人員一旦離開了Java（無需處理語言的冗長），他們的編程效率會怎樣？會找到其他JVM語言來代替Java嗎？說實話，這完全是一個似是而非的要求，把簡潔轉化成生產力。簡潔和底層技術使人們有可能相信其他的技術成本——可讀性。另一個貢獻者——動態類型可以允許在運行時報錯并且會被靜態類型捕獲。一個給定語言的生產力（編程效率）是有許多因素決定的，冗長僅僅是其中之一，至于這是否是最大因素，目前還不確定。

語言生產力（編程效率）的衡量常常被視為一種藝術而不是科學工作。或許因此有人認為，它違背了精確測量這一標準并且有了失真方面的嫌疑。但是本文的作者Peter Hill帶領了一組研究人員在軟件工程上就硬件數據這一主題進行了研究。以功能點做為核心衡量單位，在項目的需求階段就開始測量功能點的數量，它對許多組件進行了測量，比如邏輯文件數量、接口文件、外部輸入、外部輸出和外部查詢。它是一種可以給35年以上軟件提供統一測量的一種方法。從本質上來講，它是基于可衡量的工件來估算功能總額的。一旦項目的功能點數量被確定，你就可以進行其他方面的衡量并且還可以與其他大致相同數量的項目進行比較。

Peter小組，ISBSG，一個非營利性的軟件研究小組，已經聚集了6000個項目，把功能點衡量的主要數據。從這些數據可以知道完成一個項目需要多少小時，然后在映射到項目所用語言上。下圖顯示了他們研究結果：

*表示經典的ASP.用于進行比較（由ISBSG提供）

這個數字是無可爭議的。在表1上也似乎表明，高級語言比低層次語言是更有生產力的。然而，這一趨勢又自相矛盾的，語言設計主要是用于商業用途- COBOL和ABAP – 與通用編程語言相比，反而會降低（效率）生產力。Hill指出，語言并不是影響這些數字的唯一因素。項目類型（你肯定不希望同一項目里面摻雜多種語言，比如C和ASP）、團隊的規模與性質也會對上面的數字起著一定的作用。

盡管我希望C++比C更具生產力并且希望Java也超過C和C++，但是C#排在這幾個語言的最后仍讓我非常吃驚，我覺得它應該更接近Java，特別是它們可以被使用在相類似的項目中。但是它排在VB的下面似乎是理所當然的。

?

Hill是一個非常謹慎的家伙，他不會提供語言上統計數據，除非他有個可借鑒的大項目。所以我猜測在我們知道如何提升腳本語言或者Java替代方案出來之前，還需等一段時間。與此同時，如果你能準確評估項目功能點，那么你就可以參照上面這張表來預測項目完成時間啦！