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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The section on When Not to Use Perl reminds me of my favorite Larry Wall quote: "The trick is to use Perl's strengths rather than its weaknesses."

    Other than the first one, his arguments boil down to:

    2) Don't call external shell function when internal libraries are faster.

    3) Don't mix code with HTML.

    4) Don't write obfuscated code.

    Well, Duh! Sounds like good advice in any language.
    • Well, he hasn't even _touched_ real requirements for big projects. And why would he? If it comes to libraries, stability, deployment, toolchains, etc. there's not much difference between the languages, and CPAN is and always was a big win for Perl.

      He absolutely disqualified himself with this part:

      However, I would argue that more modern Web scripting languages, such as PHP and Ruby on Rails, offer more out-of-the-box Web support and a cleaner integration into the webpage experience.

      (Highlights are mine)

      --
      Ordinary morality is for ordinary people. -- Aleister Crowley
  • For the record, our Perl app at work does a billion (australian) dollars a year.

    And we're only in a small country, so I can only assume there's places doing billions of dollars a year, not millions.
    • Ah, I should have put a time scale on it. I was thinking on the scale of a day. One application I saw had the metric that every hour of down time was a lose of a couple million dollars.
  • 2) Don't call external shell function when internal libraries are faster.

    Apparently, he hasn't heard Abigail's talk on File::Copy.

    • I haven't either. I just read the slides but missed the point. Can you summarize?
    • "Don't call external shell function when internal libraries are faster." Apparently, he hasn't heard Abigail's talk on File::Copy.

      In the case of copying files on Unix, the external shell function is faster. And more flexible. I usually only use File::Copy when I need to copy to/from filehandles.

    • Apparently you (nor I until now) had read the article either. He actually has an example of using perl to copy files using a system call versus using File::Copy, and favors the File::Copy version (though in the system() version, he also uses system('ls') to get a list of the files). (Nit: the two versions don't do the same thing...the File::Copy version filters by extension).
      • It's the preference to File::Copy that triggered my reaction. File::Copy is very limited, at the edge of being harmful. That is what Abigail points out in his talk.
        • Sorry, for some reason I was temporarily completely missing your point...got it now :-)