Follow Slashdot stories on Twitter


Forgot your password?
User Journal

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);

Really, what I want is:

$source = "abcdef";
$pattern = "/^def/";
$destination = regex_match($source, $pattern);

How it's done in Perl:

$source = "abcdef";
$pattern = '/^def/';
$source =~ /($pattern)/;
$destination = $1;

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.

This discussion has been archived. No new comments can be posted.

Yes, Perl sucks

Comments Filter:
  • by FroMan ( 111520 )

    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.

    • by Degrees ( 220395 )
      I've done a little shell scripting. It was easier than Perl. This particular thing I'm working on needed some fancier string wrangling, which is why I went to Perl. Sigh.
      • by FroMan ( 111520 )

        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.

        • by Degrees ( 220395 )
          Way back when, I was going to pursue sed and awk, but had heard that perl was both those plus the control structures you get with shell scripting. For work, I do need to be able to extract things from log files, so perl does look to be an appropriate tool for me to learn. But I may be better off using a couple simpler good tools than a complex tool that's so frustrating to get started.
      • by yagu ( 721525 ) *

        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.

        • by Degrees ( 220395 )
          One of my co-workers has the Wicked Cool Shell Scripts book, and I was able to use it to build some scripts for cron jobs - different options based on date and such. I didn't see where I could read a file and extract (and then use) only the interesting data with it. It's probably there, I just haven't looked into it deep enough. I've been doing this kind of stuff for years with WinBatch - but that's a Windows-only solution. Now that we're about 35% Linux servers and 45% Windows servers (and moving the 20
  • 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

    • by Degrees ( 220395 )

      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.

  • Your chief issue is with this construct:

    $source =~ /($pattern)/;
    $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.

    • by Degrees ( 220395 )

      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.


      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

      • Oh, there is a lot hidden in Perl predefined variables []. :)

        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";

        • Ahh, I see you actually wanted what I said makes the most sense.

          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 = ();
          • by Degrees ( 220395 )

            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.

            • You're welcome. I like puzzles. :)

              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, ... where $c = 1, 2, 3, ...


              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("

Perfection is acheived only on the point of collapse. - C. N. Parkinson