A crossroads in software development.
The article What The Perl Community Needs Is a Good Enema gives me hope things might break loose in a useful way.
I really like Perl for some sorts of problems, and the CPAN library is wonderful. I really like Java for other sorts of problems, and the amount of available stuff in the Java world is amazing. Too bad these two worlds are so isolated, as it would be even more effective if you could call Perl directly from Java (and the reverse).
In fact with enough contortions it is possible to call between Perl and Java - but I'd not use "easy", "graceful", or "elegant" to describe the result.
The Microsoft folks really do have the right notion with the "Common Language Runtime" (CLR).
The Perl folks are off inventing their own virtual machine ("Parrot"). Why invent another virtual machine? Isn't this just hubris? Why not use a JVM? At least the notion of calling between Perl and Java should end up easier.
OK, I know that Perl is open source and Java is not. Hopefully Sun will get around this hangup someday.
I know that Java bytecodes might not be ideal for Perl, though better JIT in JVM's from Sun and IBM may negate much of that theoretic difference.
Virtual machines (today) and microcoded machines (in the past mainly) have a great advantage in that you can tweak or add instructions to suit your workload. At the time I was at Burroughs they realized that while the Large Systems microcode was ideal for ALGOL, must of their customers were running mainly COBOL code. After some benchmarks they had enough information to go into and slightly re-work the microcode to greatly enhance COBOL performance.
If both parties can get past the ego issues and work together, I believe we could see slightly enhanced JVMs that do a good job with Perl code.