It is also worth mentioning, perhaps as a counterpoint to this most-excellent thread (that I just dropped a great many up-votes onto) ... whatever you do, be clear, and always code for the future. Chains of map/sort/grep can indeed be quite powerful, but they can also be ... or, over time, can become ... difficult to maintain. If what you are doing can alternatively be expressed using, say, one of the List::Util packages, and even when a peek under the covers of those modules reveals heavy use of map/sort/grep, consider carefully what approach is best to take. (I do not mean to suggest the answer.)
Probably for many years in the future, someone (else ... sucks that that bread-truck was in same place you were at the same time) is going to encounter that code, is going to have to accurately understand it, and is going to have to make what may well be a significant change, thanks to the ever-present Marketing Department. It will be critical for them to be able to make the right changes to your “elegant” logic, which can be very difficult. Perhaps the change that they must do will prove to be quite disruptive to your original design choice ... whereas, given a different choice on your part, it would not have been so. Carefully weigh these concerns against elegance and efficiency. You are creating logic that is “very tightly coupled.” Every step in the chain must be considered together and is co-dependent upon every other part of it. Aye, this is both a fee-chur and a curse.
Make sure that you subject this sort of logic to extensive testing, e.g. with the ubiquitous Test::More, and that you ... well ... that you do actually test it thoroughly. Precisely because these techniques do pack a lot of semantic meaning into a very small space, it becomes exceptionally easy to make an unintended error. CPAN modules already include extensive self-tests that are run at installation time. Your logic, initially, has none. Many times, a subtle application problem can be traced to an edge-case that encountered elegance. Now, the solution was obliged to be a “big and tricky” rewrite of a tightly-interconnected (but elegant!) section of code.
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:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, 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, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||