I am the "Perl guy" in a room full of Java devs. It happens that a lot of our Perl code base was written by "barely-competent monkeys" and has only reinforced their notion that Perl is messy. These same monkeys also wrote some sloppy Java code which they attributed to their Perl mentality. Not fair.

I agree that aprticular criticism of Perl is daft, but to be fair much idiomatic Perl can be pretty obscure. There are all kinds of 'magic' default behaviours that you have to learn, and actualy that's what I assumed this post would be about from the title. Yes actualy Perl does have magic powers ($_, the polymorphing behaviour of <> in while loops, etc) but this makes it less comprehensible, not more.

I'm writing some Perl again after several years using Python and while it's interesting and fun the gotchas are getting me all over again. Come on Perl 6, we need you!

@Simon Hibbs:
"Come on Perl 6, we need you!"

No, we really don't. The problem is rather that people start using the right tools for the project (which doesn't need to mean the language. Many programming languages can IMHO provide the right tools for a single job. There are just more vital factors), but they didn't yet start to design or format their applications in the right way for the project. IMO the "one guideline for all" is a dead end as all "one $foo for all" principles. IMO, most if not all bigger ones of Perl 5's problems are social, rather than technical.

@chromatic:
"I also have yet to see a programming language that magically allows barely-competent monkeys to produce good code."

Well, if we're that far, we are one step away from compiling marketing-speak into useful bytecode :)

Lisp Scheme is the answer

Hey chromatic. :-)

Yes, that was actually my thought when I wrote that item too. There is no programming language that enforces all guidelines. I suppose I mostly meant a language where there aren't *quite* as many ways to do the exact same thing (thus lowering the probability that some of those ways will be terribly wrong ways).

-Max

@Luca,

Lisp Scheme is the answer

AMEN to that! Due to it's XML I would add XSLT to the mix as well, though with its roots planted firmly in DSSSL, one could argue them to be *very* similar in this regard.

Lisp Scheme? Lisp is not Scheme, and Scheme is not Lisp, so are you speaking about some wondrous to-be-invented language then?

Announcing the new ultimate obscure novelty language, Thcheme!

You're right that no programming language can possibly enforce things like good naming standards. However, programming *communities* can, and features of the language can drive the community.

I'd posit that a random sample of Smalltalk code will find much clearer variable naming than a similarly random sample of Erlang (trying to pick less controversial languages than the obvious Perl/Python). Is that because Smalltalk somehow enforces that? Of course not. However, the way method invocation works in Smalltalk ([obj someMethodWith: aParam andAnother: param]) encourages a certain style, while Erlang's punctuation-heavy syntax encourages short variable names.

There's also a question of how the standard library is written; most budding developers take their cues from standard or semi-standard modules. Haskell's de-facto standard "x|xs" creates a different breed of programmers than Lisp's "car/cdr".

To bring it back to Perl: the problem (to me -- a devoted Python guy) seems to be that the preponderance of "shortcuts" and single-character variable names leads directly to a culture where "small" outweighs "understandable". Seems there's a valiant effort these days to move the Perl community towards less show-offy code, but it's got to be hard to change that culture.

Originally reading the overview above and a recent entry on Slashdot had me fuming because the author appeared to be blaming the language Perl, for all of his problems. As I read the complete discussions, it finally came across that this was not a language issue but an organizational one.

One of the problems that he seemed to have was we did not have an architecture. A way that the application needed to be built. Another problem he was having had to do with the experience level of the programmers devoting time to the project. These programmers were for the most part inexperienced. A third issue was he was supporting an application that was 9 years old. After all that time some weirdness was bound to get introduced. So I can understand his problems with the the application.

These issues all point back to organization. Establishing a process for what and how things are accomplished. None of these issues can be solved by the programming language.

I do hope he learns from this and I am no longer angry about the issue ( I do love Perl), but he will get no where until he figures out how he is going to program rather than focus on what language he will use.

Good programmers will write good code in any language. Language is just a tool and there's nothing wrong if it happens to be powerful. Perl is powerful because of all the 'shortcuts' and 'magic' variables.
Of all professions, only programmers can come up with the absurd argument that they wouldn't use a tool because it's so darn flexible and powerful !!

It might be helpful to correlate artificial languages to natural languages.

Some natural languages are better at expressing certain ideas. A language native to Alaska like Yup'ik may have many more distinct and subtle ways to referring to snow than say a language native to Vietnam like tieng Viet.

The history of the use of the language causes the language to transform to the needs of the users. Someone living in say 18th century Vietnam could have lived and died without even knowing snow exists.

Perl seems akin to English to me in that it functions like a trade language. Perl has been called a glue language many times. It can stand between two incoherent groups, adapt to their forms and pass meaningful values between the groups. Structurally, Perl has adopted "vocabulary" from other languages, dropped rigorous declination in favor of context, and has developed a rich set of idioms that convey more meaning their individual signifiers. It has adopted many different forms because it has filled the place of many different needs.

The two edge sword of trade languages, at least from my perspective, is that they are easy to learn but difficult to master. You can say iteration but not wateration--unless of course, you're a politician and you know your heart that it means an instance of watering. That's because the inherited language elements of so many parts of English come from vastly different roots.

I find Perl easy to learn to create simple systems, but difficult to learn for really complex ones. As beginner at Perl, speaking from my own monkey-hood, I quickly picked up all of the essential elements of the language. Many years later, when I look at my old Perl code I can see how I missed out on creating more complex and reusable structures because object oriented Perl is foreign element brought into the language and not a part of its original Anglo-Saxon roots, I mean, original language design.

Java, on the other hand, assumes object orientation for everything (yes, I know it's possible to write procedural Java). Java has made programming certain types of applications easier for me. I also have to say that I get sick of running to CPAN every time I want to use some facet of the language. On the other hand, I more frequently use Perl because of my particular usage needs and my personal history with programming. I finish writing a small Perl app for parsing some bit of data with say only 500 records in a matter of minutes. Writing a similar Java program could easily take an hour because of the sheer verbosity of the language.

When it comes to maintaining applications, the difficulty or ease of maintaining the application is first and foremost the responsibility of the programmer. No doubt. Bad programmers will write bad code. Obviously. What I wonder about is the more nuanced and subtle distinctions between languages given the same skill of programmer.

Having lived overseas, the many English idioms I use every day became transparent as meaningless when speaking to someone whose second language is English. Have you ever wondered what the phrase "the whole nine yards" means? There are so many apocryphal accounts it's hard to really know. Perl, like English, has a large body of idioms. I would argue that, despite Perl always being my default language and true love, that it is harder to maintain when used in a highly idiomatic and idiosyncratic fashion than other languages with less idioms or seemingly less idiosyncrasies.

When I picked up a copy of Perl Best Practices, after getting over the initial sense of dizziness brought on by the idea that such a book would even exist, I found a treasure. Here is a language guide that will help me and other Perl programmers come to some sense of agreement on the way the language should be used. This kind of guide helps good programmers write more maintable and usable code in a flexible and robust but highly idiosyncratic language.

I used to have a sign over my desk that said: "An Experienced Programmer can write FORTRAN in any language." It's the PERSON who writes good code, the language just provides tools that are either easy or not-so-easy to use.

Don't forget the old quote: "the determined Real Programmer can write Fortran programs in any language" - it's still valid!
(from "Real Programmers Don't Use Pascal", http://www.pbm.com/~lindahl/real.programmers.html)

I believe Flon's Axiom applies here: "There does not now exist, nor will there ever exist, a programming language in which it is the least bit hard to write bad code."

I was going to comment on this article, but then realized that everything I wanted to say I said in comment on your other article.

Ruby has magical powers though, just in case you wondered.

"Technically, they're APES!"