Warning, philosophy ahead!
I alluded to this question when I asked should the Modern Perl book prefer cpanminus?. I've tried to explain my goal a couple of times in private, but I've never done so systematically, and I've never invited wide discussion.
I'm trying to figure out the right audience for the Modern Perl book in preparation for publishing this summer. My initial idea to write the book came from two places.
First, the Camel book is a decade old, and there'll never be a new edition which covers Perl 5. Despite the fact that fourteen (almost fifteen) stable releases of Perl 5 have come out since then (and at least four of them, possibly five) count as major, the canonical printed language reference is out of date and, at this point, all but abandoned.
Second, the best explanation of JavaScript I've ever encountered is JavaScript: The Good Parts. Like almost any other language, JavaScript has some good ideas, some poor implementations of good ideas, and some bizarre ideas that you shouldn't ever use. In 176 pages, Crockford explains how the language works and how its pieces fit together. Without covering everything, you can go from knowing how to dabble with it to writing good code.
Yet you're not an expert. You understand enough of the theoretical underpinnings of the language and the practical issues of using it to be productive, to use it to its advantages, and how to avoid or at least work around misfeatures.
I want to do something similar for Perl 5. I believe that understanding how to use perldoc is essential to programming Perl well, as is understanding the two forms of context and how they influence other code, as is understanding Perl's operator-oriented container-based type system.
I believe it's possible to explain how Perl 5 works in a couple of hundred pages, such that someone who's worked through a tutorial or two on setting up a Perl development environment and written something more than "Hello, world!" can understand Perl and continue to learn and to become productive. If you add in permission to experiment with small snippets of code, there are few limits as to where readers can go.
In short, I want to produce a book you can hand to someone who says "Perl? Oh, I've played around with it a bit." and tell them "Once you've read and understood this, you'll understand Perl."
I think I can do that without also bearing the burden of teaching people how to program in general. I assume that pointing interested novices to tutorials to set up Strawberry Perl and/or Padre is sufficient explanation for the basic material.
What do you think?
I think it would be a *very bad idea* to try to teach how to program in the context of MP. That's a different book.
Discuss the reasons for choosing particular approaches, by all means, and err a bit on the side of correcting your readers' misunderstanding of programming concepts when that comes up. But don't go farther than that. Provide a reference and move on to teaching me about Perl in particular.
D'A
P.S.: Since this is my first comment here, allow me to say how excited I am that someone is writing this book.
I think targeting people new(ish) to Perl but not new to programming is the right audience. As for setting up a development environment, I'd point people to an online tutorial that can be update over time. My hope for Perl 5.14 is that CPAN.pm out of the box will be (nearly) zero-config and will offer most of the convenience benefits of cpanm with none of the limitations.
I would encourage you to think about where your book would fit versus the Learning/Intermediate/Mastering Perl series on the one hand and the forthcoming edition of Effective Perl Programming on the other. I'd add that the latter (first edition) was the book that really helped me understand "idiomatic" Perl -- but at the level of syntax, not at the level of design and structure.
Where I think people could use help (me included, sometimes) is getting past TIMTOWTDI. Tell me a "good" way to do common things. Tell me about components of good design and how to connect things together. I'm not sure if that's where you're headed or if you're doing more of an updated reference guide like the Camel book was.
I think Strawberry Perl/Padre is well outside the scope of what you should cover in your book.
They're worthy topics I'm sure, but they're not just large topics, but also irrelevent to a portion of the people who your book will appeal to.
Essentially to cover them well you'd need at least a chapter, and it's a chapter of deadweight to people who don't need the information to access the rest of your book.
If you spend less than a chapter, then you're unlikely to be providing sufficient information to help the people who do need it, and so the space is doubly-wasted.
About all you can do is say "I don't really cover this topic, but here's the name of some other books and resources that do: if you don't know how to get Perl running on windows or you need an IDE, then this either isn't the book you're looking for, or it's not the only book you should be looking at."
Write your book to complement the other good resources out there and clearly guide people towards those complementary resources at the points where their needs might diverge from your chosen topic.
I am not sure if the MP you are planning is going that way but I think there would be a need for a book that introduces "Perl for programmers". I think all the introductory level books out are going the procedural way and show OOP at the end of the book or in the follow-up version of the book.
I wonder if it was possible to teach Perl by jumping in OOP (probably using Moose) very early.
I would leave the "learning how to program" books to the "Learning Foobar" kind of style - which is great, no question. Those books can focus on many details which really teach programming and not just the language you're attempting to learn.
Having read Crockford's book I'd _love_ to see something like this for Perl - showing off the best elements of the language, teaching good and maybe even great style, being really REALLY modern and pointing the way to "how to write Perl from 2010 on".
I think, it's time for a modernized OO Perl book as well - which should contain updated elements of "the OO Perl book" but also Moose and focussing on "OO from 2010 on" in the same way.
In the end, modern learning, modern OO, modern whatever Perl books are all needed anyway - plus a couple more by specific subjects. (Mashups, NLP, Web with Frameworks, GUI...)
One of the big disadvantages of Learning Perl, I think, is that it doesn't teach the reader how to program. I think a lot of the audience needs that. However, learning to program is another book, and a career of experience.
The first chapter of Effective Perl Programming, 2nd Edition is supposed to handle the "understanding Perl" bits, and the rest is just syntax. There really is only a handful of things you need to know, but most people guess and read uninformed tutorials so they come up with these complicated models of Perl.
I'm went through Pharo's (Smalltalk) interactive tutorial recently. It's quite impressive how it teaches Smalltalk and the Pharo world at the same time. That's a much smaller problem though, and benefits from being able to "do" any text that you select.