in reply to The problem of documenting complex modules.

Here is my experience with XML:

The first time I had to parse an XML file, I started out using regular expressions. A while later, I discovered this thing called CPAN, and it had XML::Parser. I stumbled along with that until I started hanging out at PerlMonks, where people were using other things like XML::LibXML. I could easily see the clear advantage of this over the lower-level XML::Parser, but I struggled mightily with the docs. I gave up on it and tried XML::Twig. Twig had its own tutorial website which walked me through the baby steps I needed to get going. It had short XML example files and equally short code examples that I could run. Because of that tutorial, I've stuck with Twig because it does everything I need. Other modules may be better, but I have confidence that I can figure out any new things I need from the Twig docs.

XML is probably in the middle as far as complexity goes. Not as trivial as List::Util, but not as complex as PDL. Whenever I answer someone's XML question here or elsewhere, I typically warn XML new-comers that any parser requires an investment in time.

My experience with PDL mirrors yours. I've given a couple half-hearted attempts at it, but I easily give up. It looks cool, but I guess I really don't need it. I see this more as a personal flaw of mine than a criticism of PDL. I agree that I wish it had an easier jump-in point, if that is even possible. Is it possible for this and other complex modules? Should there be smaller stepping-stone modules that have a reduced function set? Once you need more than the basics, there is an obvious migration path to the real deal? The internet is full of free trial software that offers reduced functionality. Before you commit the big dollars, you can give it a trial run with the freebie. I realize this isn't the most direct analogy, but it is along the same lines.

Another experience: The first time I saw Devel::Cover, I knew I wanted to use it. I struggled a little bit, but finally got it. As penance for posting a worthless reply to Devel::Cover for Dummies, I put together a quick-start for the module: Re: Devel::Cover for Dummies (quick start). PerlMonks is hardly the best place for this; it would be better as part of the module's distribution.

Some suggestions:

I agree that many CPAN modules lack sufficient documentation. My initial reaction is disappointment, until I remember the adage: You get what you pay for. CPAN is free, after all. Perhaps the author just didn't have time, or is ignorant in the ways of documentation, or just doesn't care. I do have the option of trying to improve this situation: I could contribute and upload a patch to the POD (or example code files).

  • Comment on Re: The problem of documenting complex modules.

Replies are listed 'Best First'.
Re^2: The problem of documenting complex modules.
by BrowserUk (Patriarch) on Jul 05, 2015 at 14:31 UTC
    I agree that many CPAN modules lack sufficient documentation. ... You get what you pay for. CPAN is free,

    Thanks for your response. I may come back to your points once we get a few more, but at this stage I just want to make clear, the OP isn't a complaint about the documentation of any of the existing modules on CPAN. Those I mentioned or any others.

    It is about trying to come up with ideas for what authors of new complex modules -- or those contributing new or amended documentation for existing ones -- can do to improve the situation.

    It's not enough to just provide lots of documentation -- if it was, we wouldn't be mentioning PDL which has tons.

    So, the purpose of the OP is not to complain about existing modules, but rather to brainstorm about how new modules can avoid their mistakes.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
    I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
      Your intention is clear to me, and I think it will be to others. By no means did I intend to steer the conversation in the direction of complaining about existing docs. I think my stream-of-consciousness point was that I can (and should) make the module easier to use for myself and others by contributing patches/examples.
Re^2: The problem of documenting complex modules.
by Jenda (Abbot) on Jul 06, 2015 at 21:46 UTC

    If the intro would be better as part of the module's distribution, did you submit it to the module maintainer? Programmers in general hate to write documentation so if someone does the job for them, they may be happy to accept the results.

    Jenda
    Enoch was right!
    Enjoy the last years of Rome.