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.

Unwritten Perl Books 4 Comments More | Login | Reply /

 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.

    • Funny you should mention this; Andy Lester and I were talking about it just a couple of days ago.

      We both want this book, for two main reasons:

      • We want a quality guide we can hand our developers and say "Build Perl applications this way."
      • We want to establish greater credibility for Perl with management, to show that "enterprise applications" can and should be built with Perl.

      In case anyone's interested, here are some notes [tmtowtdi.com] that I wrote along these lines quite a while back.

      --Bill

      • Possibly one of the biggest problems I can see with a book like that is the average Perl developer. For Java, I think you can really get away with having developers less skilled than many and still have a bit of safety. Encapsulation, type-safety and checked exceptions are examples of constraints that simply don't exist naturally in Perl, but are the safety net for the Java programmer. This also means that the Java programmer must weave that safety net rope-by-rope or he's not allowed to do his acrobatics. This "one size fits all" approach is not always the best route.

        Perl allows programmers to skip the safety-net weaving and go straight to the acrobatics, but this is dangerous. It's so much easier and quicker to do most things in Perl (reading from files is a perfect example) that many developers don't understand the ramifications of what they're doing. How many times have we looked at larger scale open-source Perl and seen people writing to files without a flocking a sentinal or or reaching straight into an object to get the data? How many times do people call external resources without checking to see if those resources exist or the calls failed? Perl programmers can get a lot more done, but I often see it done in a fragile, haphazard fashion. You simply need a better class of Perl programmer to get enterprise programming done, but there are fewer of those programmers out there and many find it tough to evaluate the quality of a Perl programmer.

        But perhaps that explains the need for the book :)

        • Having actually seen "enterprise-class" Java, I label the parent post "-1, Unnecessary Community Self-Loathing".

          Trust me, there are enough terrible and dedicated programmers in the world to jump through Java's hoops to produce absolutely hideous code.

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