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

use Perl Log In

Log In

[ Create a new account ]

gnat (29)

gnat
  (email not shown publicly)

Journal of gnat (29)

Thursday June 20, 2002
05:19 PM

Advanced Perl Programming, 2ed

[ #5824 ]
What topics would you like to see in the 2nd edition of Advanced Perl Programming? Ideas that have been suggested:
  • parsing
  • GLADE GUIs
  • Inline
  • POE
  • natural language processing
  • advanced OO
  • templating
  • web frameworks
  • Parrot and Perl 6
  • Unicode

Should topics covered elsewhere like Tk, objects, and the new freaky things in Perl 5 regexps be covered?

Tell me the topics (one per chapter) you'd like to see and I will make it so!

--Nat
("hi" to the Manning and Wrox editors reading this--glad to be doing your market research for you, you lazy buggers!)

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.
  • XS (Score:2, Informative)

    'Nuff said.

    • I don't want to sound too arrogant (particularly since it was actually Tim who wrote most of the XS chapters) but there really won't be any need for anything additional to cover XS once our book [amazon.com] hits the shelves. (Look for it at TPC!)
  • Many of the topics on that list seem to be well covered elsewhere. Pick the ones that aren't. Info on advanced parsing and natural language processing is pretty sparse and scattered.
  • Definitely parsing, since it fits in well with Perl's text processing roots, and since the Parse::RecDescent part of the chapter would probably be relevant to Perl 6. I would personally like to see both P::RD and Parse::Yapp covered, since each has its place. Along similar lines, a guide to the hairy regex features would be nice. While they're not that useful most of the time (especially when using a parsing module), they can be used for some surprising things. I'm not sure if anyone but a few (alien) P
  • How about:
    • Threading - especially from 5.8 onwards it gets more interesting
    • Embedding perl, and more perlguts (everywhere :-) especially around handling complex nested data structures etc.
  • A bit contrarian (Score:3, Insightful)

    by autarch (914) on 2002.06.21 0:10 (#9841) Homepage Journal
    Do we still need an Advanced Perl book?

    First, let's look at what's in the old book and see if it needs to be updated...

    1. Data references - nah, see Effective Perl Programming

    2. Complexe data structures - ditto

    3. Typeglobs and symbol tables - sure, this could be cool.

    4. Subroutine references and closures - ok, I can buy this one too

    5. Eval - also still useful

    6. Modules - updating this would be useful

    7 & 8. OO - nah, see Conway

    9. Tie - Conway again

    10 & 11. Persistence - um, maybe, but this would largely consist of reproducing various module docs (Tangram, SPOPS, etc.). I'm not sure how much value this would provide.

    12. Socket networking - How often do you really do this. LWP has its own book. Network programming wit Perl has its own book too. POE and Stem would be interesting topics, maybe, but they probably belong in the Network programming book.

    13. RPC - eek. no way

    14-16. Tk - got its own book or three

    17. Template driven code generation - kind of interesting, I guess.

    18-20. perl internals - soon to have its own book

    So of the old stuff I'd say updating maybe 1/3-1/2 of the chapters might be useful.

    The real problem is that it all seems kind of a random assemblage of topics, and some of the topics that aren't well covered in other books probably belong as part of other books.

    So I'm not sure I see the value behind a second advanced Perl book. Back in the days when there were many fewer Perl books, it kind of made sense to have a book that covered a bunch of different, "advanced", topics. But nowadays, with so many very specialized Perl books, its hard to see the need.
    • I have seen quite a few not-so-advanced Perl people finding Advanced Perl Programming really useful for being an introduction to the more advanced topics. Cool Stuff Chunked In Bite Sizes. Beep. Chunked? SEGV!
      --

      -- ask bjoern hansen [askbjoernhansen.com], !try; do();

      • I learned socket programming in general from Advanced Perl Programming. It taught me a lot of concepts I hadn't been exposed to elsewhere, and then taught me why they should be done in Perl.

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • Let me be slightly contrary to your contrarian argument.

      I'm willing to bet that "We don't need a new book for that, it's in Conway or Effective Perl Programming" isn't going to hold much weight with ORA. Conway is Manning and EPP is Addison Wesley.

      I haven't read EPP, but the Conway book is nothing short of brilliant. So, while I'm with you from a consumer standpoint that we've got damn fine references as it is, I'm willing to bet Gnat can't go into an editorial meeting and say "Sorry guys, Manning alrea

      • Actually, I quite sure gnat _can_ say that.

        ORA would be foolish to publish a book that's likely to receive reviews consisting of "its ok but see X, Y, and Z to really learn about these topics"

        ORA needs to publish books for which there is a market. I was questioning whether or not there still is a market for a generic "advanced Perl" book.

        Remember, in the original post, gnat called this "market research". I'm part of the market, and my response will be considered by the folks at ORA, just as everyone el
        • Dave's right--we do say "there's no point doing this, someone else already did it". When we do publish on similar topics (e.g., I'm putting the finishing touches on Perl Graphics Programming, while Manning has Graphics Programming with Perl) we try to take a different approach (our book will have more depth than the Manning title).

          skyhook implied that the consumer point of view was different from the publishing point of view. Uhuh, we're a service industry baby. We can't make you buy books, so we have

          • I'll agree with all of that (And what Dave said as well.) My comments derived more from my own consumer practices than by an overriding knowledge of the book industry.

            I personally look to ORA as the gold standard by which we should critique other computer book publishers. Up until last march, I worked for an arm of the Pearson Group, so QUE, SAMS, AW, Prentice Hall, Cisco Press, and New Riders were all "Family Members", and their books crossed my desk all the time. (Even though I was a 'Make the server go

            • Thank you for those kind word. We love you, too! :-) To be completely honest, we've done stinkers before, and there are good books from SAMS (e.g., the mod_perl Developers Cookbook, which should have been an O'Reilly book :-)

              And hey, if Damian wants to write a book about the history of Ladies Footwear, ORA will outbid Manning for it! "Admiring Women's Shoes: The Definitive Guide" coming up.

              --Nat

              • The Cookbook is not one I've read yet, my experience has mostly been with the "Teach Yourself" series.

                I can see it now. "Exegesis 9: From Spiked heels to the Orthopedic Wedgie". I'd buy it.

    • So of the old stuff I'd say updating maybe 1/3-1/2 of the chapters might be useful.

      I'm not talking about updating chapters, I'm talking about replacing the chapters. The idea is that there are topics that we can't justify an entire book on, but which are interesting and useful nonetheless.

      Many of the topics in the first edition have grown into their own books. I don't think this means that each topic we're considering should be its own book right away. It's much safer for the publisher (and more eco

      • Maybe I wasn't clear. I was suggesting that at least of the old chapters would be worth updating and including in an advanced Perl book.

        For example, the chapter on modules, updated to talk about EU::MM, Module::Build, and maybe also ExtUtils::AutoInstall and others, while pretty much dropping the AutoLoader and SelfLoader stuff, could be worth doing.

        Same goes for typeglobs and symbol tables, which still aren't well-covered in other books, that I know.

        I'm just not sure that there are _enough_ such topics
  • Threads, and one or more types of remote procedure call type stuff: SOAP, XML::RPC, or something. I'd like to see Perl put Java to shame for some of the stuff I had to do for Distributed Systems (The Class Formerly Known as Operating Systems II) this Spring.

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • by cwest (1514) on 2002.06.21 8:22 (#9852) Homepage Journal
    It's somewhat difficult to think of things that haven't been covered well in other books. And when I do think of things (below), I know I'm no expert on the topics but I bet they could be a book all their own.
    • AI
    • Event Programming, Event Loops (there's more than POE).
    • Applications with thin clients (heavy servers with documented APIs and mulitple access points).
    --
    Casey West
  • > Should topics covered elsewhere like Tk, objects,
    > and the new freaky things in Perl 5 regexps be
    > covered?

    To some extent, I'd think that *everything* in the book
    will probably be covered elsewhere. My hope is that this
    book will take a few of those items and cover them in
    some depth... more depth than the man pages, but less
    depth than if it had its own book.

    For example, if you're talking about funky regex shit,
    then probably more detail than the perlre talks about
    extended regexen, but less detail
  • It's been a while, but I seem to recall loving the first half of APP, but hating the later half. The various topics were based around specifics that just weren't applicable to anything I did. "Here's how to do sockets, except you shouldn't do this because it blocks...so here's another way you also shouldn't do it. Here's an RPC that next to no one uses. Here's how to write a Perl/Tk program that doesn't separate data from presentation so you can't port it to other display options."

    Actually, I'd love so
  • I would definitely suggest POE and threads as not being sufficiently covered currently and probably advanced enough. Problably something about PerlIO even though that's not necessarily complex.

    I would also throw in a chapter on XML processing that goes father than Perl & XML does, but that may be because I'm a bit biased towards XML ;)

    --

    -- Robin Berjon [berjon.com]

    • To take the themes of the parent post:

      "Programming Perl" (3rd) covers 5.6, right? Ideally, as well as whatever else Advanced would cover, I'd like to see detailed stuff on the new features of 5.8 (like the threads, PerlIO and anything else).
      --
        ---ict / Spoon