jjohn has come across an interesting post on slashdot comparing Perl to Java from an ex-Java-hacker's POV. He's chimed in with some observations where Perl needs to improve vis-a-vis Java, and where some of Java's supposed strenghs are really straw men.
Both are interesting reading. Both tackle the issue of "elegance" in a programming language. Both come to the conclusion that the surface syntax (e.g. all of the line noise, sigils, and the preponderance braces in Perl) may or may not be elegant, but the ease with which Perl-as-a-platform helps you solve problems is really elegant. (Is this really a surprise? :-) It's also a non-obvious elegance, at least when looking at golf swings, obfuscated Perl, or random bits of Perl code.
I honestly think that this is a new pro-Perl advocacy argument. I've heard Perl advocates try to battle the "your syntax is ugly" bear before, and the arguments just aren't really compelling. This [new] one is. It also chimes in with some of the noises I've been hearing from the Scheme community recently, thanks to fallout from LL1.
We've also been telling ourselves that write-once-run-anywhere is a promise that Java has failed to deliver, yet one that Perl has always delivered. It sounds more belivable coming from a Java hacker (er, ex-Java hacker).
Another topic that comes close to being discussed with these two posts, but never gets mentioned, is the mindset a Perl programmer brings to a problem vs. the mindset that a Java (or Python, C++, ...) programmer brings to a problem. Perl is language for Getting Stuff Done(tm) by any means necessary (regexes, system calls, OOP, closures, etc.). The result is that you can replace a large crufty class for parsing data with a simple one-line regex that is actually quite descriptive. (No news here.) The alternative is the big, heavy object decompositions that come from the heavy object-oriented languages which favor the castles-made-of-air approach to design and implementation. (First, create a class hierarchy that takes up an entire wall of your cubicle in 12-point type, then write some code, then figure out that the class decomposition isn't quite right....; no news here).
This difference leads to an interesting secondary effect. The Perl mindset can lead to solutions with less code (generally speaking; that is not to say that there aren't 250 KLOC monsters lurking out there), while the Java (et. al.) approach may be "conceptually elegant" at the syntax level and the object design level, but that solution leads to a lot more code a lot more quickly. And more code equals more bugs, more complexity, etc. Of course, Perl is no silver bullet, but it is does seem to encourage better programming practices.
