Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • What silly complaints. for ( @foo ){ print "$_\n" } is fine but print "$_\n" for @foo; is not? The obfuscatory bit, if there is one, is Perl’s strange attractor, the $_.

    I never followed the argument that trailing control flow constructs are somehow obfuscatory. What kind of retard does someone have to be if they understand if( $foo ) { bar( $baz ) } but is totally lost as soon as it’s written bar( $baz ) if $foo? I’m not using “retard” in the name-calling sense either; I mean that I believe that someone literally has to be mentally retarded to fail to understand the notion of modifiers. Even if someone has been writing nothing but C for the last 30 years, I don’t see how it is possible for them to fail to comprehend what’s going on.

    To me, frankly, the suggestion that modifiers are obfuscatory is condescending. The thought process seems to go something like “uh, yeah, okay; I’ve never seen this, it’s weird, though I guess I get it; but what if the next guy who comes along is total retard?”

    I’ll never understand this.

    In contrast, I’ve often wished I could name my iterator variable in the modifier form of for (as well as map and grep) rather than having to use $_.

    • Clearly the mark of a great programming language (if you're not a Lisp hacker anyway) is when a complete idiot who's never programmed before could maintain your code, not that that's pretty much the anti-pattern or anything.

      (You should name your default variable $it so everyone knows it's a pronoun.)

      • The problem with renaming $_ to $it is that many of the confused people will assume you mean the acronym IT and complain angrily when the variable doesn't meet their expectations!

        Honestly, defending Perl against people whose impressions [] of it were formed either by reading someone else's crappy code, or more commonly by reading the rantings of some dingdong who did so, is a FT job.

        • My rule is pretty simple. Any so-called programmer who can use a pronoun correctly in English has no business writing code if he can't use $_ correctly in Perl. (It's okay if you have to explain the similarity; it's not immediately obvious to people.)

          • your reaction is a lot nicer than mine, which is: "It's just effing syntax!"
          • The constant stream of bugs resulting from accidental changing of $_ inside a sub call are a pretty good argument against using it when you don't have to (i.e. outside of a map or grep).
            • That's a fair point, as is the one about lexical declarations and postfix if. I was thinking about the whiny won't someone please think of non-programmers argument about readability instead of legitimate implementation bugs.

      • An entire paragraph written using “it” as the subject in every sentence isn’t very readable. There are good reasons to want to use a named iterator variable. Mind, I don’t think $_ is inherently obfuscatory and I have no qualms about using it, though I do consider each case carefully. If you’re iterating over a list returned directly from a somewhat complex expression, then a well-named iterator helps document intent. And there’s only one $_, so in those cases where need

        • An entire paragraph written using “it” as the subject in every sentence isn’t very readable.

          I agree. That also falls under my rule of "don't hire people who don't know what they're doing".

        • Postfix "if" can be quite dangerous. There's a significant bug you can hit if you write a line of code that defines a lexical variable and has a postfix if. It's very hard to spot these. Postfix "for" doesn't have any dangerous bugs like this that I'm aware of.