While the snippet you showed in your example is easily packageable, many idioms are not. Idioms share a lot in common with patterns, which are essentially mental blueprints for common approaches to recurring problems. However, many idioms and patterns also share the unfortunate trait of forming a framework for other tasks, instead of forming a task in its own right.

The seminal work in recognizing and applying patterns is Design Patterns, also known as the "Gang of Four" book referring to its four authors: Gamma, E., R. Helm, R. Johnson, and J. Vlissides.

Many apprentice programmers pick up the Gang of Four and are a bit overwhelmed with the concepts introduced at first, but generally start to recognize the appropriate patterns that already exist in application code. This is an important skill to acquire: recognizing idiomatic development in existing projects.

Many journeyman programmers pick up the Gang of Four and try to write a library of code that implements the basic interfaces of each pattern. They quickly get out of their depth, trying to implement a flexible and approachable system which makes writing applications easy, yet doesn't hinder the application from doing obvious special work on top of the basic pattern.

In my observations, so-called master programmers generally don't rely on idiom libraries or pattern classes. They rely on data structures libraries, surely, but idiom is meant to be flexible in ways that libraries can rarely deliver. For example, how do you write a Perl5 library to handle the Schwartzian Transform? Every programmer cuts and pastes this approach, or types from memory, to speed up their critical and complex sorts. But writing a library to handle the obvious alterations would be heavier than the perceived value of having such a library.

Instead, where appropriate, melt the powerful idioms into the language itself: Java absorbs assert(), and Perl 6's sort will do internal optimizations akin to the Schwartzian Transform.

There will always be inappropriate or inconveniently persistent idioms that resist packaging: unique() and slurp() come to mind. Should they be a library? Or should they be one-liners that you can type from memory?

The reason they resist packaging: how do you handle the special cases, the empty lists, the degenerate worst-case work, the nonstandard separators, the already-sorted, the deep data structures? Each time you type these idioms, these issues raise their heads and you adapt your idiomatic solutions to cover them. It's my expectation that those special cases are exactly why they haven't been absorbed into the language already.

--
[ e d @ h a l l e y . c c ]

In reply to Re: CPAN module fior common idioms? by halley
in thread CPAN module fior common idioms? by dragonchild

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.