Is Perl Difficult?(prescod.net)
prescod.net
Is Perl Difficult?
http://www.prescod.net/perl/whynot.html
10 comments
As you mention, RegExps are the wrong way to handle markup.
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.
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.
There are Perl packages to do the same - XML::TreeBuilder and HTML::TreeBuilder come to mind. I'm sure for most cases they would both work just fine and it's really just a matter of preference.
I agree - wasn't trying to use that as an an illustration of superiority of Python, but just show how the data should be properly parsed, not treated like unstructured data.
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.
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.
[deleted]
> He shows a piece of code that uses a regular expression over implicitly-defined variables.
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.
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.
It might be 'perfectly idiomatic' but jrockway's code is much more typical of what a Perl programmer who wished to communicate clear ideas would write.
So there's a bunch of Perl lovers kneejerkingly responding to this post that the author doesn't "get" it.
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.
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.
because "getting it" is required to use it well
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.
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.
All he really says is that complex languages are harder to learn than simple ones. No kidding. His specific points are valid, except I'm not sure what's wrong with references in Perl.
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.
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.
> I still much prefer Perl over Python
> The steeper learning curves are justified by the power.
What can you do in Perl that you can't do in Python?
> The steeper learning curves are justified by the power.
What can you do in Perl that you can't do in Python?
Symbol table manipulation, source filters, run-time method generation via AUTOLOAD, proper closures, taint checking, lexical pragmas...
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.
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.
> 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?
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?
Where is this unreadable perl? I can't find it. I have no problem reading perl by all kinds of people.
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.
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.
Generally ~kingkongrevenge. Many ways to do things means people who know enough to be competent at writing a language still have trouble reading code created by others due to unnecessary style differences.
On the other hand it might be going too far to suggest a corollary of Greenspun's 10th Rule for Perl, tempting as it may be.
Nonsensical. Perl has most of the lispish features of lisp. There is no re-implementation.
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."
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."
That's also nonsensical though. I think most useful Lisp programs will probably run faster in Lisp. Trying to fake defmacro alone in Perl will be probably be a waste of time and ultimately result in following the original Greenspun rule.
Moose "takes the tedium out of writing object-oriented Perl."
Which doesn't sound like something you need in Python - you'll have to be more descriptive.
Which doesn't sound like something you need in Python - you'll have to be more descriptive.
Perl is not hard to learn because it is "powerful" but because it is gratuitously obscure. Perl culture and the language itself rewards those who use arcane features to accomplish straightforward tasks. Words like "wizard", "magic", "incantation" are slung about willy-nilly, even in the "official " documentation.
Python (culture and language) value complex ideas expressed as simple code.
Python (culture and language) value complex ideas expressed as simple code.
I left Perl a long time ago and lately have been using Python almost exclusively. That said, statements like this:
> 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.
> 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.
I think you are right about there being an error. I didn't try running the code but it looks like it would match everything inside the html comment braces, but incorrectly stop at any occurrence of '-' instead of stopping matching only at '-->' which I assume is what is actually desired there.
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.
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.
I think this version would be clearer though:
print $_ . "\n" foreach ((<>) =~ /<!--(..*?)-->/g);
print $_ . "\n" foreach ((<>) =~ /<!--(..*?)-->/g);
[deleted]
sigh
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).
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).
He's not. Read the example again. He's pointing to code that:
- uses the implicit $_ variable
- twice
- and modifies what it points to
The regex is just for dramatic effect.
- uses the implicit $_ variable
- twice
- and modifies what it points to
The regex is just for dramatic effect.
He didn't point out that directly but I do agree that $_ is overused among perl coders.
I don't think so. As long as there are no issues of nested scopes you should use $_ plenty.
So, whoever wrote this clearly did not read the right perl documentation, everything the author talks about is VERY well explained in the perl man pages which are pretty much a source of gold.
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.
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.
As I understand it, author tries to demonstrate that Perl is so-called "difficult to learn", and because of that, is not a good choice. OMG!! Something is bad, because it is difficult to learn?!?! For some reason I can't explain, I feel sad about that article.
Perl isn't difficult, it's just quirky:
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.
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.
Yeah. So is VIM. So is emacs. So is driving an F1 race car or flying a fighter jet. Development isn't supposed to be easy to learn - but it is supposed to be efficient once you are proficient at it. And that is exactly what Perl is.
Every time I look at Perl code I always go away pissed of for one of two reasons. A) The person that wrote the code did something super hackish and non-sesical which I attribute to the low quality of the language itself. B) I look at things like %, $ and @ and wonder why the hell I have to tell it what the variable type is. And don't even get me started on things like "Chomp" who's behavior changes depending on the value of some cryptic global variable $_\ @%#@#@^$&$*#%&@!
The person that wrote the code did something super hackish and non-sesical which I attribute to the low quality of the language itself.
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.
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.
As I read this article, I couldn't help but think of the earlier submission on improving writing style: http://news.ycombinator.com/item?id=239147
Is this article flame bait?
Hmmm... Let's read the following posts and find out!
Hmmm... Let's read the following posts and find out!
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:
One more thing; from the article:
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.