I've been reading the Perl Advocacy list for a number of years now. A frequent holy grail has been to find that one piece of evidence or that one logical argument that can convince J. Random PHB to cease developing applications with Java, and start doing something sensible (like using Perl).
To be totally honest, there's a reason why it's a holy grail. A lot of the motivations are personal and irrational. There's nothing wrong with Java per se. It's just that Perl advocates feel the need to play David vs. Goliath, and Java poses a suitably nice Goliath to target those pebbles at. :-) Gnat has talked about this in a more positive light before: if Perl is to succeed in the large, it needs to be used to implement tools and software that people really need. No business-oriented individual is really interested in adopting the favorite language of curmudgeons, lunatics and other such folk who know the meaning of "sigil" simply because they claim to have chosen themselves to be the chosen people.
That said, there is a real reason why Perl is special, both as a language and as a community. Technical reasons include Perl's expressiveness and dynamism. Community reasons include a highly portable, cross platform, open source definition and implementation. But discussions like these are quite frankly boring. Any PHB who would be swayed by arguments like these would also be likely to buy a bridge in Brooklyn.
Nevertheless, distaste of Java is not groundless. You could cast it in terms of displeasure with Sun's role as stewards for the language. You could also point to problems with it's linguistic heritage -- an over-reliance on compile-time checking for example.
Pete McBreen has a refreshing new take on the discussion. In his book, Software Craftsmanship: The New Imperative, he has a brief passage buried in Chapter 18 on why Java is a liability (p. 160):
Software Craftsman Prefer Nonproprietary, Open Source Tools:
Choosing a programming language has always been a difficult problem. [...] I prefer to pick languages that have existed for more than ten years and/or languages that are Free Softwrae/Open Source platforms. If a languages has survived for ten years, there is probably a healthy user community that will its ongoing support or, failing that, an incentive for the creation of a viable migration path. Free Software/Open Source languages are an option because, if all else fails, the source is available, and someone else can be enticed into taking over support.Java Is Hazardous to the Health of Your Projects:
Java, which is currently the most hyped programming language, fails to make the cut under these criteria. It's too new and it's proprietary. Does that mean that it shouldn't be used? No, but it does mean that it should be used only if the planned life of the application is relatively short -- definately less than five years. As yet, Java does not have the track record for stability that other programming languages have. Although there is a lot of marketing momentum behind Java right now, until a defined and stable standard emerges, it is a high-risk option compared with standardized languages.
I should point out that McBreen's book is focusing on why there exists an impedence mismatch between software engineering (which isn't delivering on it's promise), and craft-based software development (which can be significantly more productive with projects less than 100 programmer-years of effort). The discussion I highlight above is an excellent reason to use C, Perl, Python, Ruby (etc.) in favor of Java, C++, C#, Visual Basic (etc.) on projects that are to be developed by a small team, and maintained for a prolonged period (more than a couple of webyears). Sadly, the "standardized languages" issue isn't discussed further; McBreen continues to mention Ruby (in the context of globalization), so I don't read it as a blanket approval of anything with an ISO stamp.
Taken on it's own, McBreen's observation isn't earth shattering. But his book is about craftsmanship (as the title suggests) and why craftsmen that create and perpetuate a culture of craftsmanship are more likely to build and maintain great software, compared to the other popular alternatives: large software engineering cultures that cater to teeming masses of average programmers, and programming cultures that are running in the dark, devoid of methodology.
This is one small point in the pro-craftsmanship discussion. But it's an interesting one that casts new light on Perl.
