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.
  • Maybe something that covers neural nets, bayesian stuff, and AI.

    Maybe the cover would be a borg-ified camel? :-)

    I haven't done much Perl programming since becoming a sysadmin but I still buy the books. I think it would be an interesting companion to the Wolf. Heck, maybe they could add these to a second edition.

    Maybe they could throw PDL in there somewhere as well.

    Just throwing out crazy ideas.
    • Maybe the cover would be a borg-ified camel? :-)

      Thank you for making me laugh. I'm glad I wasn't drinking anything... :)

      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • 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'd like to see something along these lines, but specifically about managing Perl itself in the enterprise. I know there was a talk at OSCON about this a few years ago, and I've read the slides, but they didn't help me much. I think you had to be there.

      The book should cover how to maintain an enterprise version of perl, how to distribute it across an enterprise to multiple machines on multiple platforms. It should cover issues with upgrading, how to keep modules at correct versions, how often to upgrade mo
    • I that case why don't you just print out a cover and put it around some boring Java book.
      • I don't have any Java books :)
      • 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

    • 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 [] that I wrote along these lines quite a while back.


      • 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 acrobatic

        • 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.