Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

*::Tiny modules namespace origins

by Smonff (Beadle)
on Oct 08, 2020 at 09:18 UTC ( #11122599=perlquestion: print w/replies, xml ) Need Help??

Smonff has asked for the wisdom of the Perl Monks concerning the following question:

I am searching for a cultural or historic answer here.

What's the idea behind the *::Tiny modules namespace, like Role::Tiny, Path::Tiny or Type::Tiny? I see and use more and more of them and would like to have a better cultural understanding of their underlying origins. In the past (I only started to use Perl circa 2011), I saw a lot of the similar *::Simple namespace modules and liked them quite a lot (I like easy to use things) and wonder if there is a different meaning or intention or if this is only because most of the namespaces where already taken, so Tiny is kind of a synonym for Simple?

I am sure some respectable monk would have some clues about this. Thanks!

🌸

Replies are listed 'Best First'.
Re: ::Tiny modules namespace origins
by choroba (Archbishop) on Oct 08, 2020 at 09:39 UTC
    Please don't use ::Tiny unless it meets the ::Tiny criteria, thanks!

    Here are the rules Adam Kennedy originally defined for what ::Tiny means:

    1. The module should be implemented in "as little code as possible"
    2. The module should implement a useful subset of functionality
    3. The module should use at least 1/10th the amount of memory overhead, ideally less than 100k
    4. The module MUST have no non-core dependencies
    5. The module MUST be only one single .pm file
    6. The module should be back-compatible to at least 5.004
    7. The module should omit functionality rather than implement it incorrectly.
    8. If applicable, the module should be compatible with the larger module.

    See also the talk about Acme::Tiny by xdg.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

      Thanks! I'm glad I asked because it is much more formal than what I was thinking. Very impressive...

      🌸
      The module should use at least 1/10th the amount of memory overhead, ideally less than 100k

      Does memory overhead mean memory allocated by C libraries under the hood? Is using 50% of memory allocated "good" and 5 per cent less so, because we will have asked for too much?

Re: ::Tiny modules namespace origins
by Discipulus (Abbot) on Oct 08, 2020 at 09:37 UTC
    Hello Smonff,

    David Golden here states:

    > Adam Kennedy was annoyed that a config file loader had a huge memory footprint - Config::Tiny was born

    Infact in Config::Tiny we can read:

    > The *::Tiny family of modules is specifically intended to provide an ultralight alternative to the standard modules.

    And finally some rule found at blogs.perl.org

    Here are the rules Adam Kennedy originally defined for what ::Tiny mea +ns: 1-The module should be implemented in "as little code as possible" 2-The module should implement a useful subset of functionality 3-The module should use at least 1/10th the amount of memory overhead, + ideally less than 100k 4-The module MUST have no non-core dependencies 5-The module MUST be only one single .pm file 6-The module should be back-compatible to at least 5.004 7-The module should omit functionality rather than implement it incorr +ectly. 8-If applicable, the module should be compatible with the larger modul +e.

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

      Coming from an art background, it looks like OuLiPo for programmers to me! Very interesting...

      🌸

        Since you're interested in art and OuLiPo you might enjoy The Lighter Side of Perl Culture (Part III): Obfu - which notes that the Paris Perl Mongueurs have a long-standing interest in both OuLiPo and Perl obfu. Both BooK and stefp helped me a lot with that article and I was very grateful for their assistance. BooK was the one who pointed out the similarities between Perl obfu and OuLiPo as an art form, both being based on constraints.

      What's the reason to conform to so old version of Perl? As far as I know, these days all modern systems come with Perl 5.14+ at least. This century I've seen Perl 5.8 on board of Solaris only.
        As far as I know, these days all modern systems come with Perl 5.14+ at least.

        Not everyone has the luxury of working on modern systems.

        This century I've seen Perl 5.8 on board of Solaris only.

        5.10 wasn't even released until the end of 2007 therefore everything released before that will have used 5.8 or an even older version. RHEL5 used 5.8 and some of those boxes are still supported under ELS.

        All that said, I don't see much value in supporting (or trying to support) anything older than 5.8 for any new modules written today. The stipulation about ::Tiny was put in place years ago and time doesn't stand still. Perhaps the new steering committee could look to revise the official guidance once they are done with Perl 7.


        🦛

        In practice, most ::Tiny modules only support as far back as toolchain currently does: 5.8.1.
Re: *::Tiny modules namespace origins
by soonix (Canon) on Oct 08, 2020 at 18:36 UTC
    I think there was some discussion a while ago, that the "Simple" modules are sometimes "too simple" and inflexible if/when circumstances change. More or less, the "Simple" modules usually make "their" thing simple to use, by including boilerplate/wrapping default behaviour around a complex thing (which makes it more difficult to deviate later, when it may be necessary).

    The "Tiny" modules more or less give you only the bare necessities to build upon, which enables you to start simple and later make it just as complex as needed.

Re: *::Tiny modules namespace origins
by perlfan (Vicar) on Oct 08, 2020 at 18:19 UTC
    I think that the market of users will decide. I assume the best of intention for the module author. The proof of it's usefulness (presumably due to it's tiny footprint) is that it will get used. In the case of HTTP::Tiny, it was used so heavily that it was rolled into core. Also note, there are ::Fast, ::PP (pure Perl), and ::XS traditions as well, for example: Class::Accessor::Fast, Date::Pcalc, JSON::PP/JSON::XS.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://11122599]
Approved by Discipulus
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2020-11-30 12:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?