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.
  • I'd like to see "Perl Enterprise Patterns" or something equally buzzword compliant lying on my desk.

    It would probably be an interesting read, but mostly I would just use it to subliminally fade the script/unreadable/toy/fringe aura Perl has in too many people's minds.
    • I that case why don't you just print out a cover and put it around some boring Java book.
      • why don't you just print out a cover and put it around some boring Java book

        It doesn't have to be that way. Here are a couple of paragraphs from my notes that I mentioned above:

          While it's certainly possible to write Perl that looks like
          Java, you're probably using Perl because it affords a different
          approach and a different philosophy to solving problems. Don't
          consign that philosophy to the scrap heap just because the
          problem is bigger.

          ---

          Be aware of the unique advantages that Perl brings. Many of the
          strictures of other methodologies exist because it is so *hard*
          to do anything with other languages. Taking a rigid, methodical
          approach is the only way to ensure, or at least encourage,
          timely, reliable results.  Perl is different. In the time it
          might take to perfect one particular version of a C++ program,
          the Perl programmer can try ten different approaches, select
          the best one, and move on.  This is the form of TMTOWTDI that
          we don't often celebrate -- that it can be used as a means to
          finding the *best* way to do it.

          ---

          Perl programmers are rightly suspicious of this sort of guide.
          Too often, it's an attempt to relegate programmers to
          diagram-reading, spec-following drones -- just another set of
          interchangeable parts.  This guide will *not* be like that, and
          should work to gently but firmly correct that line of thinking.

        Any "Perl for the Enterprise" book would have to take Perl's philosophy and culture into account, or it would go absolutely nowhere.

        --Bill