Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Why is this Myth Still Pervasive? 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Just look at it:

    msg = ' spacey string ';
    msg.replace(r'^\s+', '');
    msg.replace(r'\s+$', '');

    That’s clearly orders of magnitude easier to read than the Perl version.

    • Oh wait, it has to be this:

      msg = ' spacey string ';
      msg = msg.replace(r'^\s+', '');
      msg = msg.replace(r'\s+$', '');

      Or possibly chain the methods.

      msg = ' spacey string ';
      msg = msg.replace(r'^\s+', '').replace(r'\s+$', '');

      Perl can’t hold a candle to any of that.

      • Wow ... I've seen many complaints about lack of readability, but this has to be the dumbest one (not yours, of course, the original). Just wow.

        • BTW, the "blogger" is apparently only 15, acc. to his profile. After reading the rest of his post I figured he was a dumb kid. So he is.

          Sometimes I worry that the chorus of "Perl, in a Nutshell" will damage Perl's reputation ("it's so easy to write, but it's not always easy to read"). Then I think, if only I could be so lucky!

          • As a new Perl programmer, and (I will disclaim now) having never written any PHP, I'd like to point out that no computer language has intrinsic "readability". Do you remember your first time ploughing through "Learning Perl"'s 'A Stroll Through Perl'?

            No programming language is readable until someone invents a programming language that reads like a native language. Think Pseudo-code, and THAT is readable (or at least you'll get the idea...) However, no-one has made a REAL language like that. Yet.

            I've been to
            • I agree with much of what you say, but some quibbles:

              No programming language is readable until someone invents a programming language that reads like a native language.

              I don't accept that: I am fluent in Perl. It is nearly as a native language to me. I'd say no programming language -- or any language -- is readable to a person until they, simply, learn that language.

              I've been told by a Perl programmer that adding comments to Perl is "not the done thing" and is (apparently) unconventional. However, if there are comments it's readable. If there are none, it's difficult to read without having a good understanding and some patience.

              I wonder if perhaps you misunderstood slightly. I've never heard someone say that comments are not done if they are needed; the goal, however, is to make it so that your code is self-explanatory (to someone who knows Perl, of course). If I write this:

            • No programming language is readable until someone invents a programming language that reads like a native language.

              I'm not sure that's even possible, at least for any interesting problems. It's not that interesting to discuss the abstract relative readability of programming languages; syntax is just one particular expression of the semantics of the solution to a problem. You have to understand the problem and the semantics of a problem as well, and once you start talking along those lines, you have to

            • I would suggest starting with Code Complete 2 [amazon.com] to fill in the gaps.

              After that you'll understand things like the inherent tradeoffs in commenting. It isn't as simple as "comments aren't done." And it isn't as simple as "comments make things readable." Instead it is much closer to, "comments are helpful but untrustworthy." Which is why there is a big emphasis on making your code (which can be trusted much more since errors there get noticed and fixed) read as much like comments as possible. (Much easier s
              • I do have a lot to learn, and your comments and observations about this are most welcome. I'll check out Code Complete 2 (aaah... expensing is awesome) and will soldier on with the learning.

                My original comments came from the fact I do black box testing at work, and have recently started to approach the source code. One way I find comments helpful is when they describe what the following function is supposed to do. If I just read through the function (slowly... :~) and figure it out I can see what it does. I
                • One of my favorite comments on commenting is I find the most useful comments state what remains invariant, while the code states what gets transformed. (From this post [perlmonks.org].)

                  The explicit or implicit API presented by a function should not (lightly) be changed. Therefore it is often worthwhile to comment on that. And it is always worthwhile to pick a function name that tells you what it means. However the mechanics of how the function works internally should not generally be commented.

                  That said, there isn't an

      • Perl can’t hold a candle to any of that.

        But perl6 might...
        http://xrl.us/ftqq [xrl.us]
        http://xrl.us/5obh [xrl.us]

        In Python that can be written as:
        msg = msg.strip()

        • I expected that. Of course, until I read the documentation, I don’t actually have any idea about what strip does.

          • The Python version removes spaces from both sides of the text. Just create that in a sub{} in Perl and be done with it. : )

            • I know. I’m saying that if I see msg.strip() in a random piece of Python code, and I’ve never seen the documentation of strip, then I don’t know what it does, any more than I know what the Perl code does if I’ve never read the documentation.

        • In Python that can be written as:
          msg = msg.strip()
          Hey, but that's nearly impossible to write in Perl. Let me see:

          # in-place version
          sub strip { s/^\s+//; s/\s+$//; }
          # which would be used as
          strip($msg);

          • That won’t quite work. Make it

            sub strip { $_[0] =~ s/^\s+//; $_[0] =~ s/\s+$//; }

            or maybe

            sub strip { s/^\s+//, s/\s+$// for $_[0] }
            • use strict;
              use warnings;

              my $string = " This is the test ";

              sub trim {
                      my $a = $_[0];
                      $a = join(" ", split(" ", $a));
                      return $a;
              }

              my $nstring = trim($string);

              print "$string\n";
              print "$nstring\n";

              I don't think it takes every case...but it works with the "test" string.
            • The latter version can be generalized to:

              sub strip { s/^\s+//, s/\s+$// for @_ }

              However I don't like the idea of modifying arguments in place. Functions that do that violate my expectations. Instead I'd make a copy and return the copy. Like this:

              sub strip {
                  return map strip($_), @_ unless 1 == @_;

                  my $x = shift;
                  $x =~ s/^\s+//;
                  $x =~ s/\s+$//;
                  return $x;
              }

              • The latter took me a while to read. I’m not used to recursion so casually… and it seems to me that deliberately creating opportunities to get the termination condition wrong is an unnecessary source of bugs.

                I agree though that returning a copy is better; I wrote my code that way only because was correcting the example code.

                Personally I’d write it like this:

                sub strip {
                    my @stripped = @_;
                    s/^\s+//, s/\s+$// for @stripped;
                    return @stripped;
                }

                On a

                • There is a subtle but significant difference between the two versions that shows up if someone writes my $bar = strip($foo); Your code will return 1 in that case, while mine returns $foo stripped appropriately.

                  To fix that you would need to check wantarray. Or you could return @_[0..$#_] instead.

                  Personally I have a lot of utility functions that usually accept one value, but sometimes accepts a list and returns a list. I find it annoying to add the loop and the wantarray check to each one. And I find

                  • I see the points, but I still don’t like the idiom. It has several moving parts that have to be arranged just so, and you have to read carefully to trace its self-interaction to understand what is really going on.

                    I prefer to write simpleton code. I also prefer to avoid conditionals for the same reason, so I’d use @_[0..$#_] over wantarray. All told, for a general-case idiom I’d settle on this:

                    sub foo {
                        for ( @_ = @_ ) {
                            # ...
                         

                    • I'm too dumb to remember what the difference between @_ and @_[0..$#_] is (and I'd guess others are also), so MHO is that wantarray would be preferable. I like btilly's way also, though it does make more function calls when run on a list. And on a side note, I also find the title of this thread amusing :-)
                    • A lot of this is personal taste. All solutions are ugly. Yours involves an extra level of indentation, assignment in the for loop declaration (normally a red flag), and the subtle return construct.

                      I'll note that efficiency depends on your use case. My approach is more efficient for the single argument case. Yours is more efficient for the list case. (More efficient than either of our versions is to make your return depend on a call to wantarray.)

                      Anyways there was a period where I had to write a bunch o

                    • Well, I’ve actually written a module to deal with that sort of thing [cpan.org], so…

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.