Help me write the outline for my next book. This is your big chance to decide what goes into a Perl book that you'll buy.
Since we finished Intermediate Perl, I've been working on a proposal for the next book, tentatively called Mastering Perl, which will be the next in progression from Perl newbie and full practitioner.
I'm going to run the process much like Mark Jason Dominus did for Higher Order Perl. Instead of locking myself in a coffee-shop for six months then showing you the result, everyone can take part at all stages. I don't have more than the page and a mailing list at the moment, but I am working on the book and will add things as I get them going.
I was going to get a lot of work done until the holidays got in the way, but at least I have the Mastering Perl page where you can read the current draft proposal in all its still-being-revised glory and shame. For those of you who don't know what happens at this point in a book'e life, you'll also find a link to O'Reilly's "So You Want to Write a Book" that explains the work that goes into convincing the more business-minded people that not only is your idea a good one, but that enough people will buy it.
Re:Effective Perl Programming ...
brian_d_foy on 2006-01-03T17:45:43
Good idea... I'll have to look at its table of contents when I get home.
It used to be online, but I think Joseph let that slip away. I was able to grab parts of it off archive.org though. Does anyone have the rest? I'd like to see about hosting it if Joseph will allow it.
I like most of your outline, especially the performance chapter, but the chapter about TIE, AUTOLOAD, source filters, symbol tables, and type globs looks like the script of a horror movie to me. These are things that I expect mature coders to understand and almost totally avoid. I suppose they have to learn them somewhere though. I do like the part about error handling. Many perl coders I meet don't have much knowledge about this.
If I were going to look for a training manual for people I would like to hire, it would emphasize learning the tools (i.e. debugger, profiler, benchmarks, perltidy, testing modules), and learning some of the more difficult but useful things in perl, like some of the regex extensions (negative look-behind, etc.), pack, sprintf, splice, grep, and when to use index or other string functions instead of a regex. This might make it too long, or have too much overlap with Effective Perl though.
The other thing I expect from someone who has "mastered" Perl is a solid knowledge of CPAN. Everyone says you can't talk about this in a book because CPAN changes, but showing some basics (DBI, a templating module, a config module, etc.) should be possible. Maybe it's tricky to do this without turning the book into a long example app, which is probably not what you want, but some pointers would be good.
Re:what constitutes mastery?
brian_d_foy on 2006-01-03T17:53:06
I'm not sure what constitutes mastery, and it's something that I have to define. However, getting through the book won't make anyone a Perl master. I want to teach how to master Perl, meaning that once they've gone through the book they should be able to answer their own questions. That's a hard thing to show in the outline because it comes in bits and pieces in all of the other topics.
I also avoid subjects covered much better in other books (so maybe I should have a chapter on other books). Perl Best Practices, Advanced Perl Programming, Programming the Perl DBI, and Perl Testing: A Developer's Notebook cover those things in much much depth.
The new editions of Learning Perl and Intermediate Perl cover CPAN. I insisted on it because the change in beginner Perl has shifted in that direction. Almost every beginner I teach immediately has a module in mind for a script they need to write. Indeed, CPAN might be driving people to Perl (even if relunctantly).
The proposal is very far from finished, so your comments are really helpful. Thanks:) Re:what constitutes mastery?
perrin on 2006-01-03T18:02:09
Although pretty unusual, I think a chapter on other books sounds like a great idea. The one on Code Complete is certainly useful.
Second, a chapter showing off a couple of styles of interaction with another language would be invaluable. Perl is often touted as glue, but it's not always obvious how best to bind to some other program. Should you talk through a pipe? Generate and compile code? Write XS or Inline::* code to interface directly with the other interpreter? If so, which one is in charge, and how do you handle passing data back and forth? This chapter could either be based on one of the existing Inline modules (e.g. Inline::Octave), or build something simple from scratch.
Anyways, while there's no way I'm part of O'Reilly's target market, these are at least things I think would be valuable to those who are.
For the Other Books section, good, you have Damian's PBP @ORAof course. You should add Friedl's Mastering Regular Expressions @ORA; is a 3rd edition planned or needed of that?
Draft Proposal comments:
More Mastery: For specific additional contents, unless you want to have a 4th book after Mastering, the things that I don't remember being adequately covered elsehwhere, or have on my personal growth list
Educated_foo's comment about Perl's ancestry being recaptiulated is a good one -- to really master Perl-fu, one must grok the inner awk-ness, and why sed+awk+sh+csh+fgrep+egrep was a mess. Understanding what portions of man(1) and man(3) are embedded in Perl helps too. For that matter, to grok Unix in fullness, one needed to understand the difference between the papertape-as-universal-io of Unix and the punched-card-as-universal-io of the Mainframe and friends. (That the history of Open Source didn't start with Java, didn't even start with Emacs, but was inherited from early academic and IT mainframes and was resurrected by Emacs may not help; why bnews and rn mattered once may not matter either.)
