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? 9 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 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 said than done!)

              After you've come to understand principles like that, you'll be able to appreciate why pseudocode is not inherently more (or less) readable than a computer language, and making a computer language that reads like a native one does not suddenly make it easy to program. (The first language to try that approach was COBOL almost 50 years ago. There is a reason that modern computer languages are not marketed on the basis of being easy for your manager to read...) If you're lucky, you'll also be on your way to seeing how readability is an interaction between text and the reader, and how to use this to deliberately write code that is pitched to a specific type of reader.

              And you'll be a better programmer. In any language you try to program in.
              • 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

                  • Plus with any significant codebase, productivity strongly depends on how well you know your way around it.

                    Also very important is your knowledge of the problem domain.

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