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.

One more kernel lead developer rant 17 Comments More | Login | Reply /

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

  • You are just not having a good run with them people.

  • Perhaps it is supposed to be humorous. A shudder
    is the same thing as a thrill down your spine.
    • Yes, unlike Theo, this one is clearly tongue-in-cheek. However, I couldn't resist drawing the parallel.
      --
      • Randal L. Schwartz
      • Stonehenge
      • Actually I'm surprised he is allowing perl within
        arm's length of git. I get the feeling perl is
        widely regarded as (what's the right word:
        computerly? computationally?) incorrect.
        • From what I understand, Linus started git, but Junio seems to be maintaining it now, and Junio is a fair-to-middling Perl hacker. There's also a smattering of Python in Git as well. Talk about mixed up. {grin}
          --
          • Randal L. Schwartz
          • Stonehenge

  • 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

    • 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 [joelonsoftware.com] 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.
  • In Damian Conway's Perl Best Practices, this style is deprecated. The summary statement for the section titled "Other Postfix Modifiers" reads:

    Don't use postfix unless, for, while or until.

    You may more may not agree with this book here, and I have to say that there's a lot in the book that I find somewhat limiting, but one Randal Schwartz is quoted on the back jacket:

    "As a manager of a large Perl project. I'd ensure that every member of my team has a copy of Perl Best Practices on their desk, and use i

  • All I need now is Bill Gates telling me I'm an idiot, and I'll have collected the entire set!

    Last I checked, Bill Gates was never a kernel hacker, nor was he ever a kernel lead developer (whatever that's supposed to mean).

    If you're going for the tryptic, you'd be better off trying to get insulted by Bill Joy, Brian Kernighan, or possibly Dave Cutler.

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