Send to Printer

Programming

Hard data is hard, but the evidence mounts up

February 06, 2007 15:57:42 +0200 (EET)

Interesting snippet from Usenet: according to these posts by Geoff, Smalltalk churns out programs several times faster than Java:

IBM keeps function point counts on their projects. My understanding is, for a wide range of projects, ST comes out way ahead. ... ST has gotten as high as 60 FP's per 100 man hours, Lotus Notes 30, Java 15 to 20, and PL/1 5.

Having programmed in all those languages, I'd say those figures are pretty close to the mark. Smalltalk is perhaps benefitting slightly from the fact that the best programmers tend to prefer it. Maybe for the same programmer, Smalltalk would be "only" 2.5 -- 3x as fast as Java.

In the end, though, it's always a question of horses for courses. Each of those languages has its own sweet spots: application areas where it shines. Even using PL/M didn't feel bad for building mainframe firmware, because we didn't have to stretch the language outside its comfort zone. Also, there won't be figures for using Lotus Notes to build firmware, but there will certainly be Notes-like applications built in Java and probably PL/1.

As Geoff says, the figures above are for a wide range of projects. One thing I find interesting in Smalltalk is its ability to build a wide range of applications well. The libraries and other goodies accompanying Cincom VisualWorks, for instance, cover everything from 3D CAD to Web Services. When you find a new area that doesn't have a library, creating one for your own needs is easy and feels natural. Smalltalk really does seem to be the best generic programming language for building domain-specific languages.

How much does this contribute to the productivity figures? Nobody is going to convince me that using a period rather than a semicolon to end a line of code is going to make a 3x difference in productivity. Even the superb collection classes and IDE can only account for so much -- the less so as bit by bit others manage to copy them. Being a dynamic language helps in and of itself, but most of all because it seems to enable or promote the creation of DSLs -- at least it seems so, given that the three "DSL friendly" languages that always get mentioned are LISP, Smalltalk and Ruby.

For any given project, measuring the productivity of several languages is hard: you can't build the same system twice with different languages, but with the same programmers with the same level of understanding. Measuring similar projects is possible but can still be dubious: maybe one language is just good at that type of problem. It's only when you see a big difference over a wide range or projects that you can really start to think that one approach might really be shown to be better than another. I don't endorse Smalltalk because it's what I use, nor promote DSM because it's what we sell: I'm just a sceptic who has been convinced by the evidence.