That first "Ideal candidate criteria": "You have general familiarity with Perl conventions and “perlish documentation practices”"; could be a mistake.

Imagine if instead of this, you had something like:

my $mce = MCE->new( max_workers => 8, chunk_size => 2000, tmp_dir => $tmp_dir, freeze => \&encode_sereal, thaw => \&decode_sereal, gather => \@a, init_relay => 0, input_data => $input_file, RS => "\n>", use_slurpio => 1, parallel_io => 1, use_threads => 1, spawn_delay => 0.035, submit_delay => 0.002, job_delay => 0.150, on_post_exit => \&on_post_exit, on_post_run => \&on_post_run, user_args => { env => 'test' }, user_begin => \&user_begin, user_func => \&user_func, user_end => \&user_end, user_error => \&user_error, user_output => \&user_output, stderr_file => 'err_file', stdout_file => 'out_file', flush_file => 1, flush_stderr => 1, flush_stdout => 1, interval => { delay => 0.007 [, max_nodes => 4, node_id => 1 ] + }, sequence => { begin => -1, end => 1 [, step => 0.1 [, format => +"%4.1f" ] ] }, bounds_only => 1, task_end => \&task_end, task_name => 'string', user_tasks => [ { ... }, { ... }, { ... },], );

And when you mousever the keys, you get a brief explanation of the parameter; mouseover the value and the default is displayed; click the key and the embedded description comments from the original above are displayed in a popup.

Suddenly, those five screens worth of dense, complicated, hard-to-read details are all available on one screen, with a clear overview and a quick way to compare/contrast/lookup the details.

Apply that thinking through from the top level of the module.

Doesn't that seem a better way to both provide and explore the details of a complex module?

Is it too late to change “perlish documentation practices” for the better?


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!

In reply to Re^2: The problem of documenting complex modules. by BrowserUk
in thread The problem of documenting complex modules. by BrowserUk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.