I came across some interesting ammunition for perl advocacy written by Steve Yegge. While he isn't particularly a fan of perl (to put it mildly), he is someone who watched Java and perl programmers in action at Amazon for a number of years, and came to the obvious conclusions. It's nothing you haven't heard before, but sometimes it's useful to have it from an "outsider": Is weak typing strong enough? Update: fixed dead link. (Maybe Ted Nelson was right, eh?)

Some quotations (with many sentences ellided, check the original for the full text):

I watched the strong/weak battle play out (in various ways) in Amazon's Customer Service Applications group for years. ...

One thing I observed was that the folks who favored Perl always seemed to be able to get stuff done really, really fast, even compared to experienced Java folks. And they had their act together; it wasn't just crude hackery, as many Java programmers would like to believe. Their code was generally very well organized, and when it wasn't, they'd go in periodically and fix it. Sometimes they did quick, hacky scripts, and in fact the ability to do this proved to be mission-critical time and time again. But generally the Perl stuff worked just as well as the Java stuff. Whenever performance became an issue, they'd find clever ways to make it perform well enough. ...

So for years, we had Java and Perl development going on side by side. This was a decision made in old days, purely for expedience reasons. When we were deciding how to implement Arizona (our internal web-based application suite for CS), we had about a 50/50 split between Perl and Java programmers on the team.

During the initial development, the Perl use-cases got finished astonishingly fast. For a while, Arizona had more Perl than Java, because our Perl programmers started grabbing tasks assigned to the Java folks. Over time, the "climate" across the company pushed us to migrate everything towards Java. It was a pretty complicated situation not worth recounting here, but over a period of years, most the Perl stuff in Arizona was gradually rewritten. (I hear after I left, the climate changed again, with Java being phased out in favor of C++ and Perl, but for reasons mostly unrelated to the languages themselves.)

In any case, for several years I got to watch Perl and Java folks working side by side doing pretty much the same tasks. In some cases, they even had to implement the same logic in both languages. Yes, there were inefficiencies with our Perl-and-Java approach. However, it was the right decision at the time, and as a result, I was personally able to witness a more or less apples-to-apples, multi-year comparison of the strong-typing and weak-typing camps at work in the same production environment.

In nutshell, I was pretty impressed. I was a die-hard Java guy at the time, and even then, I could see that the Perl code was far smaller and simpler than the Java code. It didn't feel "cleaner", since Perl itself is a bit challenged in that department, but it seemed modular enough. It had a well-defined architecture, and it got the job done, year in and year out.

Our Java code (to me) seemed far more complex, even though I could read Java more easily. I think Java programmers have a tendency to overengineer things, myself included. I suppose many Java folks would have thought of our Perl code base as grossly under-engineered. But if it was really under-engineered, it seems like it should have caused more problems than it did. In practice, most of the problems in the Perl code were interoperability issues with external services (or databases, in cases where there were no services yet.) Most service owners didn't include Perl bindings for their interfaces, so our Perl folks had to do a lot of head-scratching to find workarounds.