I agree that's confusing; regex syntax is very terse, and there's nothing in there to help you learn it. (In regular code, variable and function names can help you infer from context what the other constructs do.) Secondly, it's hard to reason about code that does things that aren't written. "while(<>)" assigning to "$_" for "/.../" to use is confusing. $2 and $3 coming out of nowhere are confusing.

The problem, though, is not with Perl; it's with the author's lack of knowledge of how it works. Regexes are nice once you learn them. Operating on $_ is nice once you expect that to happen. $1 and friends are quite handy.

Finally, most Perl apps don't look like this. Sure, there may be something like this hidden over in an obscure subroutine, but most Perl looks like every other language.

Here's a randomly sampling of Perl from my git repository:

http://git.jrock.us/?p=Template-Refine.git;a=blob;f=lib/Temp...

Basically, it looks like it would when written in any other language. It's not unreadable or crazy, it's just a program.

Finally, here's a more readable version of his example:

    while ( my $line = <> ){ # or "readline" if you hate <>
        while( $line =~ /<!--(?<comment_body>[^-]+)/g ){
            say $+{comment_body};
        }
    }

Even so, I supect that most readers that know both languages, even Perl fans, will agree with me.

Not true. I don't know Python, so of course I'm not going to be able to use it to write maintainable code. I do know Perl, though, and I bet I can write much better code than the author of this article.

I should note that his program doesn't actually work. It won't work across lines, and doesn't allow "-" in the comment. A full-file parser would do a correct job, and one is available from the CPAN, so it would involve less code anyway.

In Python, load lxml module and parse the content into an etree, a heirarchical data structure for XML elements.

lxml.etree will read them in and treat them as Comment or ProcessingInstruction.

You can then iterate the tree and collect the comments.

http://codespeak.net/lxml/tutorial.html

I've been working with etree for the last couple of weeks, firstly using xpaths to extract data from a HR database a customer expects my company to look up manually for 6000 people, then to create OpenDocument files. It's really easy, even if you've never done any XML programming before, and the mailinglist is very helpful too.

That said, I do prefer the 'one, right way to do it' of Python - it makes it a lot easier to pick up on someone else's code.

His snippet is perfectly idiomatic perl code and I find it easily legible. His point is that it's pretty hard to parse that without having already spent some hours with the perldocs. Fair enough.

Now I myself love Perl and code in it for a living and I think the author does in fact "get" it, it's just that he thinks Perl is a problematic language precisely because "getting it" is required to use it well. It's something he's explained a little further over here:

http://www.prescod.net/python/why.html

You may disagree with him and feel that an easier language does not a better language make (I'm not sure I'm convinced either) but complaining he hasn't read the documentation is proof that you yourself haven't grasped what he's actually talking about.

This is true of Python also. I don't "get" Python, and you can bet any Python I'd write would be crap.

In order to use a programming langauge, you actually have to learn it. Then you have to use it (to determine what you don't know), and then learn that too. Repeat.

There is no magical "I can understand it without learning" programming language. So any criticism of Perl for this reason applies to every other programming language.

I still much prefer Perl over Python and C++ over C, and I would recommend my preferences even to a beginner. The steeper learning curves are justified by the power. I disagree with his assertion that you should choose a language on the basis of how easy it is to learn. I also think his Perl vs Python debugging claim is baseless.

> The steeper learning curves are justified by the power.

What can you do in Perl that you can't do in Python?

I think you'd be hard pressed to implement something like Perl's Moose in Python. I'm not completely sure it's possible.

There's a lot of tricky stuff that's easy in Perl but requires tons of hoop jumping in Python.

Don't underestimate the utility of perl one-liners. You can't do them in Python, both because of the whitespace and because in practice Python is too verbose.

The value in doing something in a smaller amount of lines is lessened by the lessened maintainability of unreadable code.

Where do you think the effort in maintaining software goes? Typing? Or maintenance?

C, on the other hand, is frequently indecipherable because so many lines are spent doing something trivial that it's easy to lose the forest for the trees.

Here's a better rule: "Any sufficiently useful Lisp program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of standard perl and the best CPAN modules."

Which doesn't sound like something you need in Python - you'll have to be more descriptive.

Python (culture and language) value complex ideas expressed as simple code.

> insert the same bug into the X programs.

raise an eyebrow. In my experience the platform and language determine what the what the bugs will be. Said more simply: You aren't going to have the same bugs in Perl that you will in Python, and vice versa. Certainly you could, but typically you won't.

Also, the biggest problem with Perl isn't the language per se, it is the entrenched culture which is inclined to abuse of power and unclear coding, often in the name of "efficiency".

Still, Python drives me nuts daily with small things. I can't think of a language or platform that doesn't. Better yes, but not at a level to pick on Perl.

Oh, and I'm rusty but I'm pretty sure that regex is wrong.

So it should be /(.X?<!--)(..X?)-->(.X$)/ instead.

(Note I am using X as asterix because HN at the time of this writing converts asterisks to italics tags.)

But other than that the Perl is perfectly fine. And it is easily readable if you know Perl.

print $_ . "\n" foreach ((<>) =~ /<!--(..*?)-->/g);

Why is it all who moan about Perl immediately point to a regex written in perl and cry "Look! That's perl! It's unreadable!" No dumbass, that's a regex, and regex by the way, looks about the same in every language. It just so happens perl is better at regex than most other languages and perl coders aren't afraid to use it (and unfortunately many abuse it).

- uses the implicit $_ variable

- twice

- and modifies what it points to

The regex is just for dramatic effect.

The argument that Python is better beacause it is apparently more readable is lame. To me, perl just feels a lot more expressive since I grew up "thinking" in perl.

Bashing a language because you didn't read the right documentation and/or couldn't find it is just wrong.

I agree that perl can be daunting to learn and that may make it more unmaintainable though, but if you haven't made the effort don't knock the language.

Perl OO: In Perl classes are called "packages". There are no private methods or private members, everything is mutable.

Sigils: @foo is an array, %foo is a hash, but $foo can either be a string (scalar), a number, a reference to hash, a reference to an array, a reference to a function, or a reference to an object.

Built-in functions that operate on arrays (push, pop, foreach) do not accept references to arrays, unless put an @ sigil in front: pop $foo <-- WRONG! pop @$foo <-- Oh sure, OK!

Lots of special variables: $ in combination with just about any other non alpha character means something in perl. The most often abused is $_, the default variable.

Libraries and package files have to end with 1; or return some non-zero value.

So sure, plenty of quirks of to learn, but so every lanaguage.

The language is only half of it, the other half is the culture. If you write Perl that uses an obscure (and perhaps undocumented/unintentional) feature to accomplish some relatively straightforward task, other Perl programmers will worship you as a God. The language and the culture are mutually reinforcing. Ruby is going this way as well.

Python language and culture both place a premium on doing things the simplest and most explicit way you can. Over the long run, the culture makes the biggest difference.

Hmmm... Let's read the following posts and find out!