Channels ▼
RSS

Design

The Comparative Productivity of Programming Languages


A meme that I read frequently, especially in developer forums on JVM languages, is how much more productive developers are once they move on from Java, due to no longer having to deal with the language's verbosity. I've seen this precise claim made in forums for Groovy and Scala, and would surely find it in forums for all the other JVM languages that claim to improve on Java. I've never bought the argument. To me, it's the kind of specious claim that concision translates into productivity. Concision and the underlying technology that makes it possible often implies other trade-offs that have costs — not the least of which is readability. Another contributor, dynamic typing, can allow runtime errors to occur that would be caught with static typing. I could go on — the bottom line is that there are lots of factors that determine the productivity of a given language, and verbosity is just one of them. I'm not even sure it's one of the major ones.

The problem is that measuring productivity is invariably viewed as more of an art than scientific work. It has a kind of fuzzy aspect to it that defies accurate measurement. Or so one would think. But my co-author on this editorial, Peter Hill, leads a group of researchers in software engineering who do in fact have hard data on the topic. The key unit of measure is a function point, which is a measurable amount of functionality that can be determined during the requirements phase of a program. It measures many components such as the number of logical files, interface files, external inputs, external outputs, and external queries. It is an approach has provided consistent sizing of software projects for more than 35 years. Essentially, it measures the gross amount of functionality based on measurable artifacts. Once a project's size in function points is determined, then you can measure many other aspects and compare them with other projects known to be of roughly the same size.

Peter's group, ISBSG, a non-profit software research group, has gathered data on 6,000 projects, using functional size as the key sizing measure. From this data, they can see how many hours it took to take each project to completion and how those hours mapped to languages, on projects that were primarily written in one language. Table 1 shows what his research turned up.

Table 1: Development hours per function point of software, ranked by principal programming language.

Language Hours Per Function Point
ASP* 06.1
Visual Basic 08.5
Java 10.6
SQL 10.8
C++ 12.4
C 13.0
C# 15.5
PL/1 14.2
COBOL 16.8
ABAP 19.9

*refers to classic ASP. Included for comparison purposes.
(Courtesy of ISBSG.)

The numbers are remarkably noncontroversial. They seem to suggest that higher-level languages are generally more productive than lower-level languages. However, in contradiction to this trend, languages designed primarily for business purposes — COBOL and ABAP — actually reduce productivity when compared with general-purpose programming languages. Hill is quick to point out that language is not the only factor affecting these numbers. The kinds of projects (you would not expect much cross-over between projects in C and ASP), the size and nature of the teams, and many other factors all contribute.

Nonetheless, while I would expect C to be less productive than C++ and both languages to be less productive than Java, I am surprised by the comparatively low showing of C#. I would have estimated it to be closer to Java in terms of productivity, especially since I think it would be used in similar kinds of projects. Its placement below VB, though, seems predictable.

Hill is a cautious fellow, and he won't provide stats on languages until he has a large base of projects to draw from. So, I suspect it will be quite a while before we know how much lift scripting languages or the Java alternatives actually provide. In the meantime, though, if you can estimate the number of function points in your upcoming projects correctly, this table can help you forecast an accurate timeline for project completion.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy

Update: Explained inclusion of ASP.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video