Stop writing Perl books!*

By Steven Haryanto on July 31, 2012 11:11 PM

People should write (more) books on CPAN instead. Here are some ideas.

1) The best of CPAN. A curated list of modules, picked by the editor. I would prefer a task-oriented organization. Every mention of modules should also at least mentions its maintenance status (is it actively maintained? is the author responsive? bug queue? are bugs getting fixed?), performance characteristics, strong points, drawbacks, interface. Tasks doable by Perl's builtins and core modules can be mentioned too, although the editor should not dwell too much on those.

2) Creating and maintaining your own CPAN. minicpan, Pinto, carton?, ... Potential reader base include Perl shops and corporate users.

3) Definitive guide to Acme::. Fun things, stories behind the modules, (mostly) useless tricks employed by the modules. I want to a fun, entertaining, light read. Should be 100 pages or less. In the age of ebooks, could perhaps sell for $5-$10? I'd buy it.

4) The worst of CPAN :) A bit like #3 in spirit, but more "coding horror" style.

Any takers?

*) A.k.a.: Perl book ideas #1

9 comments

9 Comments

Gábor Szabó - גאבור סבו | July 31, 2012 11:39 PM | Reply

My plan is to the take the Perl Maven Cookbook in the direction of 1) and 2) in your list.

brian d foy | July 31, 2012 11:43 PM | Reply

People shouldn't write books on CPAN. It's mostly a waste of their time for which they'll get little reward and little exposure. Niche topics do very poorly in book form. Even if you personally would buy one of these e-books for $5, hardly anyone else would and hardly anyone would talk about it. It doesn't matter how much anyone would pay for it. It matters how many people would pay, and hardly anyone does.

Well crafted magazine-style articles and blog posts, easily available and reference-able on the internet, will get more traction. These take less time to write are easier to update, and easier to promote. The time between concept and reader engagement is much shorter.

I get far more feedback from the Items on the The Effective Perler blog than I do for the book I'm trying to promote with it.

Alberto Simões | August 1, 2012 12:13 AM | Reply

I tried that. And wrote some chapters (check http://ambs.github.com/Books/). But I do not have much time recently and therefore the project is stalled for some time. I also requested help writing it, but didn't got much interest.

I agree with brian, things change too fast to be profitable. My idea would be to have small articles (magazine-like) for the main/bigger modules that are available on CPAN. My idea would be to make it available as PDF to download, but also available on lulu.com, that makes it easier to change the document every 15 days if needed.

But then, for such a project, where chapters or sections need to change every time, I would need a lot of potential authors. For instance, Perl module authors to write their own sections. And I would only work as an editor, checking the articles size not to be excessive, and not to include hard comparisons with other modules (although they could be correct, they are not polite).

Leon Timmermans | August 1, 2012 4:16 AM | Reply

I do think it would be nice if there was a book on creating and maintaining CPAN modules, though the issue brian mentioned may be an issue.

Ben Bullock | August 1, 2012 5:46 AM | Reply

1) The best of CPAN. A curated list of modules, picked by the editor. I would prefer a task-oriented organization.

Naoki Tomita (TOMITA on CPAN) published a book in Japanese last year called "Perl CPAN Module Guide". It's "task oriented", containing 32 sections detailing the "best of" modules from CPAN for various tasks. Here is Amazon link to the book. It says that the sales rank is #249,357 in "book", #36 in "Perl books", and #2596 in "IT books". For a comparison, the Japanese translation of "Learning Perl" is #193,302, #26, and #2013 respectively.

Every mention of modules should also at least mentions its maintenance status (is it actively maintained? is the author responsive? bug queue? are bugs getting fixed?), performance characteristics, strong points, drawbacks, interface. Tasks doable by Perl's builtins and core modules can be mentioned too, although the editor should not dwell too much on those.

Do you really think anyone is going to write a book on those kinds of things? That sounds like a waste of time for everybody. If the module is not getting fixed or has poor performance or other problems, the sensible solution is not to mention it at all, especially in a book.

Nova Patch | August 1, 2012 6:28 AM | Reply

I have a copy of an outdated book titled Writing Perl Modules for CPAN on Apress, which is quickly approaching its ten year anniversary!

Steven Haryanto replied to comment from Ben Bullock | August 1, 2012 8:56 AM | Reply

Do you really think anyone is going to write a book on those kinds of things? That sounds like a waste of time for everybody. If the module is not getting fixed or has poor performance or other problems, the sensible solution is not to mention it at all, especially in a book.

But of course. No modules are perfect. Some may be featureful but a little slow, others fast but minimalistic, yet others fast+complete but the authors have moved on. Mentioning these gives perspective and could also result in orphaned modules getting adopted.

Ben Bullock replied to comment from Steven Haryanto | August 1, 2012 9:55 AM | Reply

But of course. No modules are perfect. Some may be featureful but a little slow, others fast but minimalistic, yet others fast+complete but the authors have moved on. Mentioning these gives perspective and could also result in orphaned modules getting adopted.

I doubt that such a book would have a wide audience, and it would be out of date so rapidly that it would hardly be worth publishing. Cpanratings, blogs.perl.org or a self-published web site are much more appropriate ways to comment on module problems. The huge majority of people's goal involves nothing else but getting their own job done with minimal effort, and most people who buy a book are looking for guidance about how to do that - get something done without wading through CPAN documentation. For example Naoki Tomita's book mentioned above consists of short "how tos" for each module, like Text::Xslate or Algorithm::NaiveBayes (opening the book at random pages), which get the person started without the pain of reading CPAN documentation (in a foreign language, for the intended audience). Nobody is going to buy a book which consists of discussing the lengths of bug queues of CPAN modules, and nobody is going to write such a book.

Tatsuhiko Miyagawa | August 1, 2012 11:39 AM | Reply

Acmecyclopedia, aka Acme modules perfect guide, has been published since 2009 and updated every year, sold at YAPC::Asia.

http://www.donzoko.net/cgi-bin/tdiary/20091207.html
http://f.hatena.ne.jp/kits/20111014131617

Name

Email Address

URL

Remember personal info?

Comments (You may use HTML tags for style)

About Steven Haryanto

A programmer (mostly Perl 5 nowadays). My CPAN ID: SHARYANTO. I'm sedusedan on perlmonks. My twitter is stevenharyanto (but I don't tweet much). Follow me on github: sharyanto.

More info »

Of course I still use Perl