Journal Degrees's Journal: Yes, Perl sucks 14
I'm an old guy (my first program was in FORTRAN on punched cards in 1979) and I learned programming the old-fashioned way. Which means that I like my source code to be obvious as hell.
Here's what makes sense to me*:
$source = "abcdef";
$pattern = '/^def/';
preg_match($pattern, $source, $destination);
print($destination);
Really, what I want is:
$source = "abcdef";
$pattern = "/^def/";
$destination = regex_match($source, $pattern);
print($destination);
How it's done in Perl:
$source = "abcdef";
$pattern = '/^def/';
$source =~
$destination = $1;
print($destination);
Why do I hate thee? Instead of letting me assign something to $destination, I have to encapsulate my regex pattern within parenthesis (because OF COURSE that's the assignment operator), and now the result will magically be assigned to variable $1 - wherever the hell $1 came from. THEN I'm allowed to assign $1 to $destination. Wonderful. And by the way, the single quotes around the regex pattern matter - you cannot put it between double quotes.
Obvious as hell, it ain't.
*Note that first snippet is working PHP code. Yes, I would have answered my own rant, except that my postfix and GroupWise boxes do have Perl on them, and do not have PHP on them.
Perl (Score:1)
I'll sign on. Perl sucks.
I would much rather write a bourne shell script than perl 99% of the time. Perl is what you get when a C programmer wants a scripting language.
Re: (Score:2)
Re: (Score:1)
Depending on what sort of wrangling, have you considered sed and awk? I've found those two to usually be up to the task. Granted report generation was perl's original purpose, or so I hear, so it might be a better tool.
Re: (Score:2)
Re: (Score:2)
I have to second FroMan's feedback. Shell scripting makes almost anything easy (and usually it can be elegant too). But some of the string wrangling does get trickier, but if you learn to deep corners either sed or awk, you get the power of string stuff too.
A friend and I always faced off, script duels if you will. He writes something in perl, I match him stride for stride. Ultimately we end up turning the challenge into converting our "task" into one line of perl or shell and almost always we succeed.
Re: (Score:2)
yes, but... (Score:2)
Yes, perl sucks, but it does it in so many different and elegant ways! I think perl is able to suck in more ways than any language I've coded (and I've coded many -- also wrote FORTRAN (and COBOL, AND PL/I) on punch cards long ago).
(for the record, I've written thousands of line of perl also, and I find it to be a fascinating language, and very useful, but it is one of the most abused languages out there, mostly because it's easy to abuse. I always cringe when asked to work on someone else's perl. More
Re: (Score:2)
Thankfully (for the rest of the world, at least) I have no intention of building enough stuff that anyone else will feel the need to maintain it. ;-)
I understand the need for Perl. I'm just frustrated going from the old style nothing-tricky-because-computers-are-already-hard-enough to the Perl paradigm of heres-a-nifty-trick.
Well... (Score:2)
Your chief issue is with this construct:
$source =~
$destination = $1;
The problem is that this:
$source =~ /($pattern)/;
Comes from a construct meant to be used like this:
if ($source =~ /($pattern)/) ...
but you can drop the result of the regex comparison (a boolean) and take advantage of the side effects (sub-expression capture) as a convenience.
=~ is supposed to be akin to the other comparison operators. It makes perfect sense in that context.
Re: (Score:2)
I did see a lot of examples similar to what you have there. Of course, I'm looking to use $destination later on in the program, and using an if statement as an extraction mechanism is completely counter-intuitive to me.
Even
if ($source =~ /($pattern)/) {$destination = $1} ;
isn't particularly readable. I suppose that the set of parenthesis for the "if" go to $0 - but the whole idea of hidden variables for results just frustrates me. What else is hidden? How is a mere mortal supposed to deduce that $1 was th
Re: (Score:2)
Oh, there is a lot hidden in Perl predefined variables [xav.com]. :)
Personally, if you intend only to capturing the results of the matches, what would make the most sense is a function returning a list of matching parts... @results = preg_match($source, $pattern) or similar. Return undef if nothing matched.
Anyway, you could always write a subroutine to emulate the behavior you like in PHP...
sub preg_match {
my $s = shift or die "Missing source\n";
Re: (Score:2)
Here it is:
sub regex_match {
my $s = shift or die "Missing source\n";
my $r = shift or die "Missing regex\n";
if ($s =~ m/$r/) {
my @results = ();
Re: (Score:2)
That was very kind of you to write that for me. Thank you.
I almost follow it all. ;-)
I don't follow what's happening with the substring extract. I see that you are iterating $c, but why it should match only $r I don't get. And the position element $-[] isn't something I recognize.
But thank you for giving me something that will help me out.
Re: (Score:2)
Anyway, the code accounts for multiple subexpression matches:
"The quick brown fox jumped over the lazy dog" =~ m/(q.+k).*(o.+r)/;
actually gives you $1 = "quick" and $2 = "over"
The magic substr actually gives you the same thing as $1, $2, $3,
#!/bin/perl
my $source = "The quick brown fox jumped over the lazy dog.";
my $regex = '(q.+k).*(o.+r)'; # omit the slashes
my @r = regex_match($source, $regex); # @r gets two elements back
print join("