Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: CPAN module fior common idioms?

by halley (Prior)
on Jul 23, 2004 at 14:03 UTC ( #376883=note: print w/ replies, xml ) Need Help??


in reply to CPAN module fior common idioms?

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 ]


Comment on Re: CPAN module fior common idioms?
Select or Download Code
Re^2: CPAN module fior common idioms?
by BrowserUk (Pope) on Jul 23, 2004 at 14:20 UTC

    Brilliantly stated++


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
Re^2: CPAN module fior common idioms?
by eric256 (Parson) on Jul 23, 2004 at 16:50 UTC

    I keep hearing about the tons of idioms, but i can seem to think of many. I put together a small list that i know is incomplete.

    Idioms: Tye + Juerd in id=204874 sub slurp { local( *ARGV, $/ ); @ARGV = shift; <> }; dragonchild id=376694 sub unique { my %x; grep { !$x{$_}++ } @_ } broquaint id=374287 sub in_list {return !!grep { $_ eq $_[0] } @_[ 1 .. $#_ ];}

    These represent in no way a complete list, they are just a collection of idioms I found while searching perlmonks. Could we start a list or a document that would hold perl idioms and maybe a short explanation of them? If you wanna help just add it as a reply here or should i start a meditation on the matter? Well for now reply here, I can always post a revised list to meditation for comment/correction and addition.


    ___________
    Eric Hodges
Re^2: CPAN module fior common idioms?
by Ven'Tatsu (Deacon) on Jul 23, 2004 at 20:33 UTC
    I agree with you, but you got me thinking. How about this:
    #usage: @result = st_complex sub { complex comparison }, sub { transfo +rm }, LIST sub st_complex (&&@) { my $compare = shift; my $transform = shift; map { $_->[-1] } sort $compare map { [ $transform->(), $_ ] } @_; } #usage: @result = st_simple sub { transform }, LIST #note: comparison is string wise. sub st_simple (&@) { my $transform = shift; &st_complex(sub { $a->[0] cmp $b->[0] }, $transform, @_); }
    The only shortcomings I can find are that sub NAME (&&@) won't allow you to call NAME { CODE } { CODE } LIST, only the first code block can be a bare block, and I can't thing of an effective way to combine the two into a single function like sort.

      I thought about this too, when writing my reply to Re: CPAN module fior common idioms?. But I did three distict different design choices. My sort call looks like this:

      my @foo = qw/ a3 b2 r4 s1 /; print for STsort( sub { /(\d+)$/ }, sub { $_[0][1] <=> $_[1][1] }, @foo ); __END__ s1 b2 a3 r4
      The differences are:
      • Order of the subs: I feel it's more natural to first see the transformation and then how that transformation should be sorted, as the sort sub means nothing if you haven't seen the transformation sub. An inlined ST is read backwards.
      • $_[0] instead of $a: &STsort can't, without voodoo AFAIK, in every case realize which $a and $b to use.
      • Original at index 0: I put the original value at the beginning of the array instead of at the end. I feel this is nicer when I don't know the length of the result of the transformation.

      ihb

      Read argumentation in its context!

Re^2: CPAN module fior common idioms?
by ihb (Deacon) on Jul 24, 2004 at 02:18 UTC

    ++ 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!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://376883]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (7)
As of 2014-12-28 07:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (179 votes), past polls