Because I'm too busy. The maintenance of the Shootout is simply not my daytime job, it's not something I get paid to do. I do this in my free time (when and if I have some). So if you don't see the material you sent, or you got no mail from me, be assured that I've not choosed to ignore you.

That said, I'm very happy to receive contributions, bug reports, comments and everything else (including flames :-). Just give me time, once in a while (measured in months) I try to backlog everything I've received and reply and integrate stuff.

Most of the programs were written by Doug Bagley. I've personally implemented only a few languages, and most of the times I've either followed Doug's guidelines, or simply taken the same program written in a language that I already knew of and "transliterated" in the new one.

If you feel you can write better programs than mines (always following Doug's guidelines), feel free to contribute!

Did you read carefully Doug's Scorecard page?

The main issue with scores is that many languages experiments several failures (due to portability issues, platform limits, etc.). A language gets 0 point in a test that fails, or times out. For this reason, even if CPU times seems good at a first glance, a language may get a bad overall score.

Just to make an example (this was the real Q, by the way :-), the Java score seems to be unreasonably high, given that individual scores are bad on almost every benchmark. Believe me, I'm not trying to cheat on this -- I personally don't like Java at all.

The fact is that Java gets score for every benchmark (even critical ones like Echo Client/Server and Producer/Consumer Threads), while many other languages fails on some tests. For this reason, the overall score for Java is higher than other, more "performant", languages.

I have to (reluctantly) admit that Java has showed very good portability, so the score does reflect this.

Read the section "About this test" on the corresponding benchmark page on Doug's Shootout site.