Advanced Perl Programming, 2ed

gnat on 2002-06-20T22:19:33

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!)


XS

Theory on 2002-06-20T23:48:16

'Nuff said.

Re:XS

Simon on 2002-06-21T11:49:53

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 hits the shelves. (Look for it at TPC!)

Re:XS

Theory on 2002-06-21T17:13:39

Oh, cool. I didn't know about this book. Thanks, Simon!

Whatever isn't well covered elsewhere

dws on 2002-06-21T01:40:03

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.

um...

educated_foo on 2002-06-21T01:47:39

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) Perl golfers truly uses them to their full extent -- I sure don't.

Inline would be useful, but any "advanced" use of Inline::C seems to demand some familiarity with XS. Also, now that threading has settled down in 5.8, it could make a good chapter, particularly since most people familiar with threads will probably be used to different models (i.e. explicit-only data sharing is uncommon).

As for the rest: OO-Perl's been beaten to death elsewhere -- "see Conway" would probably cover it. There are probably too many specific application areas (web, POE, GUI), and no principled way to decide which to include (should PDL be on the list as well?).

/s

Some maybes

pxharding on 2002-06-21T02:51:01

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

autarch on 2002-06-21T05:10:29

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.

Re:A bit contrarian

ask on 2002-06-21T09:16:51

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!

Re:A bit contrarian

jdavidb on 2002-06-21T13:22:11

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.

Re:A bit contrarian

ct on 2002-06-21T11:04:49

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 already covered that." :)

Re:A bit contrarian

autarch on 2002-06-21T14:49:42

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 else's will.

Re:A bit contrarian

gnat on 2002-06-21T16:20:20

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 to do books that you want.

If you do have ideas for books you want and will pay money for, I will be glad to hear them via email or in person at YAPC :-)

--Nat

Re:A bit contrarian

ct on 2002-06-23T23:42:23

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' guy, not involved in anything publishing related.)

Only New Riders makes a book worth reading, let alone buying, in my experience. I've never read a book by, say, QUE or Sams that I found useful.

I have enjoyed books by Manning, but I always chalked that one up to Damian, rather than the publisher. I'd read a book by Damian on the history of Ladies Footwear.

And I've got to admit, I am happy with my XSL book by Wrox (The Kay XSL Bible, as it were.) But in all those cases I think "How the heck did ORA not publish this first?"

Given the choice of an ORA book on Perl Graphics and a Manning book on the same subject, I'd choose the ORA book without reading a single word. ORA books tend to have a more concise, clear and readable style that make for a much more useful book. And yes, I realize that gnat is an ORA editor, so, no, this isn't sucking up. It's a fact.

So, I do think that an updated Advanced Perl would be useful, despite coverage of the material elsewhere.

Re:A bit contrarian

gnat on 2002-06-24T16:28:49

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

Re:A bit contrarian

ct on 2002-06-24T19:19:19

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.

Re:A bit contrarian

gnat on 2002-06-21T16:08:56

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 economical for readers!) to have one book of advanced topics than a dozen books, one per topic.

--Nat

Re:A bit contrarian

autarch on 2002-06-21T17:19:24

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 to fill a whole book (which is why I was feeling contrarian).

Threading and distributed processing

jdavidb on 2002-06-21T05:40:30

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.

Advanced Smorgasbord

cwest on 2002-06-21T13:22:29

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

two more cents

wickline on 2002-06-21T13:31:00

> 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 than MRE2ndEd. (Of
course I'm assuming that JF is going to go into a great
amount of detail on extended regex syntax in perl since
so many PCRE implementations use that syntax these days.)

So, "yes" those topics should be covered, but mostly
because I don't think you can avoid covering things that
are addressed elsewhere. However, I don't think that any
attempt should be made to try to cover too many topics. I
know that I won't buy a collection of man pages.

...but I'm sure you've already considered that :)

> the topics (one per chapter) you'd like to see

parsing

source filtering

more internals info
    especially as would help one learn to make
    productive use of B::Generate, B::Utils and
    the like.

maybe some parrot / perl6 architecture stuff
    sounds like much of it is nailed down at
    this point and I'm guessing that *that*
    is going to be where the interesting
    "advanced perl" stuff is happening in the
    future. I'd avoid talking about perl6
    syntax (not stable, not advanced), but
    architecture and parrot could be good.

Those are the things that come to my mind. I'm sure
I'd enjoy reading some things that didn't come to my
mind too :)

-matt

Nothing too narrow

swiftone on 2002-06-21T13:34:43

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 something that covered some of the "typical" advanced perl usages. Such as, "How to use all these Parsing modules that appear to rely on global variables" or "How to write a program in the back end, (chatbot, solitaire, whatever) so that different front-ends could be applied" (IRC/IM/ whatever, PerlTk/GTK/Curses/whatever) or "Here's how to use an XML file as a DATA file rather than transforming to HTML (all the intro XML pieces I've found transform, and the advanced ones assume you know how to extract your data in a durable format).

Misc suggestions

darobin on 2002-06-21T14:31:39

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 ;)

Re:Misc suggestions

koschei on 2002-06-22T06:46:49

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