I was pondering the question "Why do some people think they enjoy programming in Java?" Software engineers who use Java will tell you that they revel in the expressive power of the that language, which enables their craft and creativity to flourish.

Software engineers who use Java will tell you a lot of different things because there are a lot of different software engineers and lot of different projects.

If -- as this statement implies -- there is a narrow concensus about why people think they enjoy programming in Perl, it suggests that Perl is used in a narrow application space. The real question, then, is how Java compares to Perl for the tasks to which Perl is most popular. You'd expect Java to compare unfavorably, as does Perl when compared to Java in areas where Java dominates.

And while I'm on this paragraph, I'd like to know the difference between thinking you enjoy something and actually enjoying something, please.

In Perl, we feel liberated by the fact that (for example) Perl already has an auto-sizing array type built in; we don't have to invent that wheel yet again.

Java has had an autosizing array type in the core API since the initial release. This statement has been ignorant nearly for nearly 10 years.

Perl has approximately 3.2 jillion distinct features built in. Perl programmers can "focus on the application itself", on its high-level structures and algorithms, and not worry about, for example, how to iterate over a list of heterogeneous objects.

First of all, high-level structures and algorithms can be deeply concerned over how they iterate over a list of heterogenous objects. What is the iteration order? Can we modify the list while we iterate? If these questions are not relevant, the process of iterating over a list in Java requires no further deliberation. You get the Iterator from the List and, well, iterate.

But in Java (and most other languages) the programmer needs to think no only about those higher-level issues, but also about the lower-level structures and algorithms, and to implement them -- or at least to choose the desired ones from libraries of such things.

This is a misleading generalization. Choosing the library or core API set with which to implement a function is part of the implementation process of project in any programming language, including Perl. Choosing a library does not constitute worrying "about the lower-level structures and algorithms," it frees you from thinking about it further.

This is why it takes 5 days and 1000 lines of code to write a "hello, world" CGI in Java. Or whatever.

Even if this infantile hyperbole were accurate, this statement is an example of the author's cluelessness about software engineering. "Hello World!" is not a programming benchmark, it's an instructive example. Writing "Hello World!" in a language walks a novice through some of the basic steps needed to write more useful programs in that language.

Java imposes a certain amount of bureaucracy in it code, and its annoying when you don't need it, and great when you do. Writing "Hello World!" in Java introduces you to a lot of core concepts needed to write more complex java programs. It also takes a lot more source code than "Hello World!" deserves.
Writing "Hello World!" in Perl is trivial; it's not much more work than typing "Hello World!" in fact. But how much do you learn about Perl doing it? Can you use namespaces, associative arrays, "inside-out objects" or Regular Expressions? Does the student need to know any significant number of Perl's "3.2 jillion features" at all? No.
But after suffering through writing "Hello World!" in Java, a student is prepared to do quite a few more substantial things.
As far as whether Java or Perl is a more "productive" language, I can safely say that vendors of Perl-based "Hello World!" implementations are unlikely to face competition from Java versions. Application servers, however, are a different story.

So, in many critical respects, Perl is the language of Only One Way. There is only one way to implement a sequence: an array. There is only one way to implement an associative array: a hash. ... Of course, if you really wanted to, you could do any of these things another way.

This statement is also true, without substantial modification, of Java.

For example, there is only one way to do classes in Perl. That is, there is one intrinsic way, which uses namespaces, @ISA, the special semantics of the operator, and so on. But some folks have felt this style too limiting, or not limiting enough, or too arcane, or just simply not OO enough. Thus we have the plethora of modules in the Class:: namespace, as well as basic techniques such as "inside-out objects", message-based object protocols, etc. Java, of course, gives you no choice at all about how to do OO.

This is so far from being a true statement that it seems inaccurate to call it "false." Object Orientation is not a syntax, or a language, it is a methodology. This methodology has various flavors, and these can be followed with varying degrees of pain in any language. "Java ... gives you no choice at all about how to do OO," is a testament to the author's ignorance of OO, not Java's inflexibility in that area. Java syntax supports following a certain approach to OO, but it doesn't stop you from following another.
Same as Perl.

So, while Perl goes to great lengths to permit more than one approach to any problem, there are certain questions for which Perl hands you a "no-brainer" answer on a silver platter. In these cases, we're pretty close to Only One Way.

Again, this statement could be made -- verbatim -- about Java. The author has attempted to draw some kind of distinction between Java and Perl, and instead, drawn a distinction between himself and a programmer knowledgable about Java and OOD/OOP. -Charles Forsythe

jdporter - edited: formatted quotes to distinguish them from the new text.