Productivity and programming languages

We all know that programming languages affect productivity. For example writing a word processor in Assembler is much harder than writing it in C++. If seems natural to have a table with all available programming languages with their corresponding productivity value.

The main problem is to compare these languages. A common method is counting the “lines of code” a programmer needs for a given program. But who is going to implement the same specification in hundreds of languages? So to make the test applicable we need a common concept for the comparison.

This concept is called “Function Point Analysis”. This approach was introduced by IBM for exactly this task. Here you define function points (there are a lot of rules for doing that) and measure how many function points a programmer implements per month. More information about function points: Function Point FAQ and Fundamentals of FPA.

For the productivity measurement of programming languages we count the lines of code per function point.

The languages are categorized into levels – Assembler for example has level 1 with 320 lines of code per function point. A Macro Assembler has level 1.5 with 213 lines of code per function point etc…

Here an excerpt of this list:

Assembly (Basic)1.00320
Assembly (Macro)1.50213
SMALLTALK 8015.0021

A lot of languages are special languages – like Excel with level 57. My guess is that a general purpose language is not able to go far beyond level 20.

Another table from here shows this:

Macro Assembler213
Objective – C26
Query Languages16
Spreadsheet Languages6

The values are the same or at least nearly the same for the languages (maybe they came from the same source?)

I would like to see a JavaScript, Ruby and Python included in these tables, but unfortunately I couldn’t find anything for these languages. I think JavaScript is no better than 10, Python and Ruby are together with Perl around 15, maybe Ruby has the highest level of these languages (Comments?).

The higher the language level the easier it is to read and change such a program. There is – of course – a trade off: the more code you write (for example in assembler) the more optimizations are possible. With increasing processor speed, and advanced algorithms this argument is getting more and more obsolete.

Programs must be written for people to read, and only incidentally for machines to execute.
— Abelson & Sussman, SICP, preface to the first edition