Perl is a favorite flogging target, both of me and others, both of detractors and fans. So is Java. Both tend to become favorite flogging targets due primarily to two factors, I believe:

each has a strong, widespread, zealous body of detractors who find it unutterably bad each has a strong, tightly-knit, zealous body of fans who find it unutterably divine

As such, both end up being example languages for all sorts of points (half-baked or otherwise). Favorite characteristics for maligning them are, in Java’s case, the immense scaffolding requirements of the language and, in Perl’s case, a harsh-looking syntax. Java’s noun-oriented philosophy is its excuse for the scaffolding. The design of Perl is often justified by explanations such as Paul Graham’s comment that “Real ugliness is not harsh-looking syntax, but having to build programs out of the wrong concepts.”

One of Java’s design philosophy principles is protection for the programmer from himself. It is considered a Good Thing that Java incorporates features intended to make it difficult to shoot yourself in the foot. One of Perl’s design philosophy principles, meanwhile, is that of enabling the programmer (TIMTOWTDI and “makes easy things easy, and difficult things possible”). In the process of trying to make dangerous things difficult, Java also makes things that should be easy rather more difficult. In the process of trying to make difficult things possible, Perl (the “Swiss Army Chainsaw”) also makes it easy to saw your own leg off. There’s a distinct trade-off going on, here. On the same subject, C and C++ are compared thusly, by Bjarne Stroustrup:

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows your whole leg off.

For a better idea of how that’s relevant, feel free to substitute “Perl” for “C” and “Java” for “C++”.

Flon’s Law provides an interesting thought on this subject, as well — one quite worthy of consideration:

There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code.

So, we must ask: What is the important guiding factor toward which we should aim our efforts when designing, or simply choosing for a given project, a programming language?

The answer, I believe, is enabling the programmer to write good code. We cannot prevent him writing bad code. We cannot force him to write good code. We cannot get good code by simply making programming easy. What we must do is make writing good code* as rewarding as possible, and to hell with all other concerns.

The definition of “good code” will change from project to project, to be sure, but within general problem domains there will be definite common characteristics that will arise again and again in the language that best rewards writing good code. The definition of “writing” never changes, however, for this metric.

a note about frameworks and other peripheral tools: If you want to get something done Today, the frameworks and other peripheral tools associated with a language are likewise valuable in direct proportion to their facility for enabling your programmers to write good code, but such value cannot be usefully measured in a vacuum. It must be measured as part of the overall results of evaluating the language. In the here-and-now, your familiarity with a langage, enjoyment of working with it, and ability to expand your knowledge of it quickly are additional factors to keep in mind.

If, on the other hand, you instead wish to invest in your future, you must consider not what frameworks, IDEs, libraries, and so on exist for a given language, but what among such things will likely exist when you need them at crunch-time, at some point in the future for which you are planning. This includes measuring your ability to generate tools for that language yourself.