Re: Preferred implementation language (Re: Meeting agenda robot)

On Thu, Dec 25, 2008 at 01:38:21PM +0200, Kalle Kivimaa wrote:
> My experience in volunteer projects is to informally poll the
> potential developers for the implementation language and/or platform
> and select the one with the most widespread willingness to use/learn
> it.

This is the key point, I think. For example, there are a very large
number of Java programmers out there in the world, yes, but in my
experience a *much* smaller percentage of them are willing to
volunteer on open source programs. Java has become the "Cobol" of
computer languages --- which is not meant as a slight on the language,
but to characterize the sort of programmers that make up a very large
percentage the programming community. They are business/application
programmers, that program on a 9-5 basis, and when they are done, they
go home and they coach Little League or sit in front of a television
and veg.... they don't (as a *very* broad generalization) volunteer on
open source projects, at least not to the same extent that you will
see in the C, Perl, and Python worlds.

The other problem I see is that many Java programmers are, quite
frankly, not very good at writing programs (performant or long-term
maintainable, in my experience). And before you say that "performance
doesn't matter", I have had the misfortune to be forced to use a
proprietary mail program written in Java where it takes a full second
to delete a message, and then display the next message in the mail
folder --- on the fastest, most modern laptop I could find (and this
was *after* I stuffed it to the gills with 4GB of memory; the
performance before I did that doesn't bear thinking about.) Think
about that for a second; and think how much of disastrous usability
matter that would be. How could such a horrible performance/usability
disaster come to pass?

Because of the Java class libraries; there must be easily a dozen
levels of abstractions in the Java class libraries itself, plus
another dozen or so levels of abstractions in either J2EE or Eclipse
stack; and then if you use the Rich Client Platform (RCP) on top of
Eclipse, there's another half-dozen abstractions right there; and
that's before you get to doing anything in the application! There are
*so* many levels of abstractions between the Java application
programmer and the bare metal, that if you say words to them such as
"blowing your I-cache" or "cache line", most of them will stare
blankly at you, with a deer-in-the-headlights-look and no idea what
you are talking about. Given their language of choice, they had no
possible hope of being able to control that sort of issue, so it
ceased to exist for them.

So the critical matter is not the richness of the toolset, or the
number of programmers, or the average performance of the language ---
if you can find a talented Java programmer, who understands
performance issues and who isn't afraid to dive into the dozens of
layers of Eclipse or Java class libraries to understand why some
application class has become O(n**4) --- or heck, understands what the
big-O notation means in the first place (you can write fast,
performant code in any language, just as you can write Fortran in any
language). No, the key is which language you are most likely to find
a large pool of good, talented programmers who are willing to
volunteer for your project; not just now, but also 10-15 years from
now.

I'd suggest that the only programming languages likely to meet that
test are C, Perl, and Python, but what's important is the criteria and
understanding why that's important.

- Ted