So, you reject simple now, in favour of complicated,

Nope. I rejected "somewhat simple and clever now" for "even simpler and not clever (now)" while also gaining "works correctly in an easily likely but not explicitly called-out situation" and also gaining "less likely to have to be completely rewritten when the requirements are 'refined'". It was a win-win-win. It wasn't even a trade-off.

And I don't see any "speculative requirements". I find "take rubbish away from the top and the bottom" to quite clearly indicate that "'no rubbish' means 'nothing to take away'". So I consider ikegami's interpretation of "'no delimiter' means 'nothing to leave behind'" to simply be incorrect.

Considering edge cases even when they aren't explicitly given in the one example provided is not a "problem". The idea of extending a rabid "you're not going to need it" to even include "edge cases will never happen" is not something I've seen before or ever expected to see. So thanks for that novelty.

Even if I couldn't imagine how I'd end up with "no garbage in front" or "no garbage behind", I'd still prefer a solution that doesn't throw away the non-garbage when "the impossible" happens. Not to the point of choosing a significantly more complicated solution, of course. Actually, considering some edge cases often leads me to a better abstraction which leads to simpler solutions and even more often to more cohesive and better factored solutions.

instead of just taking care of the real requirements as they exist now

Providing "requirements" is not an easy task. It my experience, it is never done perfectly. Very often, it is done quite badly. I think I dealt with incorrect requirements having been provided on 3 or 4 separate projects just today (at work).

So, no, I'm not likely to "just take care of the current requirements" and avoid contemplating that the requirements might be incorrect and/or incomplete (they almost always are; though I didn't have that problem with this simple request).

Even when I have the luxury of talking directly and in-person with the person whose need I am supposed to be addressing, getting reasonable requirements is still quite an art. I certainly don't go "Oh, and here is one example; so, no need to even speculate about requirements!".

Not that I just "make up" requirements and then run off to waste time implementing over-complicated solutions based on those unconfirmed speculations (as I covered in detail before), of course.

- tye        

In reply to Re^4: List::MoreUtils before, after and ... between? (all that is wrong with the software industry) by tye
in thread List::MoreUtils before, after and ... between? by Boldra

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.