That was my first question too, comparing to Groovy. I think the answer is that Groovy has significant runtime requirements (notably dynamic typing and invocation) whereas Xtend appears to purely compile down to plain Java. I suspect that means that you can run it in an ordinary container without extra tooling like Groovy. But a cursory look at the docs suggests that they do have some runtime library requirements (I see a StringConcatenation class and an InputOutput class, for example)

Yes, that's right. Dave Jones has made noteworthy contributions to the kernel, so he gets a free pass to complain about a third-party driver that breaks the kernel, and he is allowed to propose workarounds to correct said breakage, even if they use snarky variable names.

Ha ha, but seriously: Android's Dalvik virtual machine does not use the Hotspot compiler, so I think it should be unaffected by this bug.

Minor nit: you mean "ellipse", not "ellipsis". An ellipsis is three dots used as punctuation like this...

But I disagree that it will look "if it might crash into us". It will be reportedly 14% larger than it's smallest appearance (http://scienceblogs.com/startswithabang/2011/03/what_the_hell_is_a_supermoon.php), or I'd guess about 7% larger than normal. Not sure if that's areal size or diameter. Most people probably won't be able to tell the difference.

I love Coverity. I love other static analysis tools too -- I'm one of the lead developers for Perl::Critic, which performs static analysis on Perl code. They are enormously valuable tools.

However, I've seen many cases where people read the issue report from the tool and fix the symptom rather than the problem. The improvement from 1 in 3333 to 1 in 4000 is fantastic, but that means 1 *Coverity issue* in 4000, not 1 *bug* in 4000 lines.

My current closed source project has a Coverity count of 2 issues in 150,000 lines of code as of today. Does that means it's less buggy than Samba? No, it's just different. We've simply removed the majority of the easiest-to-automatically-detect bugs.

Google points out that several people have explored opposite idea: LLVM emitting Parrot bytecode. So, you could compile C down to Parrot for the ultimate in interoperability and portability. :-)

I received a Perl Foundation grant in 2007 -- $2000 for about 80 hours of work. That's not a very good rate for an experienced engineer in the USA, but for me the money was not just a carrot but also a stick. I knew that failing my project would be a very public humiliation. It was work I wanted to do anyway, but I had procrastinated it in my free time. The deadline and publicity made me finish it. So, IMO it's the acceptance of the grant that's a significant source of motivation, not the completion.

If it wasn't for the money, I may have been just another open source programmer who didn't finish just another open source project.

The primary reason for the longevity of the Perl 6 development effort is shortage of volunteers. To put it harshly, people like you spend their energy complaining instead of helping.

The money is most certainly well-spent on both Perl 5 and Perl 6. I was a Perl Foundation grant recipient to work on Perl::Critic, a static analysis tool and code quality aid. My contributions are making a positive influence to help with the readability, maintainability and portability of large Perl 5 codebases. (read TFA and you'll see my name mentioned) Perl::Critic is being actively used in improving the Parrot codebase.

What have you done to help?