Re^2: CPAN module fior common idioms?

[ihb]

++ for a good post.

I too wouldn't care much for a Idioms::Common module, but I sometimes would like to see libraries that performs the function the idiom does, if abstractable.

As I see it, we talk about two different idioms: functional idioms and patterns (the distiction may be a bit fuzzy). Below I will talk about functional idioms only.

I would like to bring up some of your point and elaborate a bit.

For example, how do you write a Perl5 library to handle the Schwartzian Transform? / ... / But writing a library to handle the obvious alterations would be heavier than the perceived value of having such a library.

You raise a good point, but I think you take a too black and white look and the situation. You don't have to write a library to handle any alternation. I realize that ST was just an example, but let's continue on that example. Just a plain ugly ST may do fine in many cases, and then the library version could be used (and it's easy to abstract the vanilla version). Having a library that handles one common way to do ST doesn't stop you from using your own ST.

An example of this is File::Slurp which is one of my favourite modules. It uses plain and simple routines, but often I need those plain and simple routines. When I need something more controlled I do it myself.

Another example is grep, which is a special map.

    grep BLOCK LIST
    map { do BLOCK ? $_ : () } @_ }

And we agree grep is a good addition to Perl. And like above: I need a more sophisticated grep I use map, but grep is still nice to have for all those cases where I just want a simple grep.

If grep wasn't built-in though, I still would've enjoyed having it ready through a library.

Instead, where appropriate, melt the powerful idioms into the language itself.

Indeed, and this is what Perl 6 is about, partly. But in the mean-time, I don't see any wrong in abstracting abstractable idioms into libraries. But there's also another side to it. Some idioms may be appropriate for you to melt into the language, but someone else might want another set of idioms into the language. The Perl 6 RFCs shows good examples of this. Or perhaps I'm twisting the meaning of idiom now and if something isn't overall applyable, then perhaps it isn't an idiom after all.

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?

As it turns out, slurp() is available as &File::Slurp::read_file. It's not written idiomatic, and I'm in fact not arguing with your main point. This has nothing to do with idioms, and as I said at the very top: I don't see any reason to put the idiom in a library, but the function the idiom does.

In my observations, so-called master programmers generally don't rely on idiom libraries or pattern classes.

I believe there are a couple of factors for that:

• False laziness: they can do it them selves and it doesn't take much time each time (but summed up it's a lot) whereas it'll take a while to understand and get started with the library/pattern class.
• Don't agree with the pattern: They want a different way to do the same thing, and everyone has their own idea of how to do it. Since Perl lets you do things your way, they do it their way.
• Experimental: Many pattern classes are experimental and give the feeling of proof-of-concept modules rather than something to be used in production.
• Dependancy: You don't want to depend on something experimental for your productions.

Now, if we were to write a rigid actively maintained module and managed to make it almost a part of the language (like CGI.pm is for Perl CGI programming), I think things can work out well.

Just my thoughts,
ihb

Read argumentation in its context!