I'm going to agree with duff here, something like the map with double curly braces or a scary combination of a regex and multiple if's &&'s ||'s or's and various other operators has a downside. Maybe it's fast, maybe it was fun for the programmer to invent and maybe it makes him/her happy, but it's a maintainance problem. Every time a user runs into this new idiom, they have to try to grok it, and that takes time.

Furthermore, simple statements rather than complex ones can be extended more easily to do other things -- which is usually what needs to be done from a maintainance perspective. Another problem is that the idioms that rely on niche corners of the language make porting between different versions of the language, or (more so) different languages

This goes back to the earlier meditation on "elegance", where some one posted that one-liners are more elegant, and that clear and elegant were two different things.

IMHO - first a program should be accurate and up to performance specs - then it should be easily extensible - then it should be readable - then it should be short - then it should be clever (in that order, and hopefully the top three goals are always met)

There is zero room for obscurity in my book. I find it to be rather unprofessional, and detrimental to the inclusion of Perl in non-Perl-elite circles. There is a lot of bias against Perl, and while these statements are cool, when used in excess, they are to the detriment of the language in foreign camps. Just read any of the anti-Perl bias for the Python and Ruby folks. These languages are a lot alike, and really, they percieve Perl as an evil. Think about that, next time one decides to ponder one-liners and whether clarity and brevity are one in the same. I'll say they are not.

I'll also agree with Abigail here that OO-jumping (especially Java-esque OO) over 15 subroutines and 15 files is a horrible way to do things. I'm not trying to steer people here. Simple maintainability is about transparency. Whatever is a barrier to groking the code should be removed. Sometimes this involves consolidation, sometimes expansion.

Perl elegance? It's a Zen thing. Consider the pebble.

In reply to Re: All in one by flyingmoose
in thread All in one by duff

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.