一份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替代方案出来之前，还需等一段时间。与此同时，如果你能准确评估项目功能点，那么你就可以参照上面这张表来预测项目完成时间啦！