I guess some definitions of "quite simple" can be applied to that code. It looks more like "clever" to me. (:

I rejected using 'grep' at all since it seems likely to me that there could be cases where there is nothing to trim from the front. Your solution (and any simple 'grep' solution) will produce nothing for that case (or else can't deal with extra, unexpected leading garbage). I also dislike solutions that I can tell will require fundamental changes in the face of simple changes to the requirements.

> it seems likely to me that there could be cases where there is nothing to trim from the front.

Well not clearly phrased in the OP but at least the way the example was coded!

But maybe that's the real bug???

Please notice the word "between" in this thread's title.

> I rejected using 'grep' at all

Maybe you mean mean "grep w/o reverse" ?

  DB<130> @list= ("a".."c","DBIC","A".."C","DANCER","a".."c") => ("a",
+ "b", "c", "DBIC", "A", "B", "C", "DANCER", "a", "b", "c")
 
  DB<131> reverse grep { not /DBIC/ .. 1   } reverse grep { not /DANCE
+R/ .. 1   } @list 
 => ("A", "B", "C")
 
  DB<132> reverse grep { not /DBIC/ .. 1   } reverse grep { not /NONSE
+NSE/ .. 1   } @list 
 => ("A", "B", "C", "DANCER", "a", "b", "c")
[download]

... or maybe not ?

Personally, I reject posting solutions for every possible interpretation of a poorly phrased question.

Human discussions are an iterative process.

Cheers Rolf

Maybe you mean mean "grep w/o reverse" ?

No, I meant "any simple 'grep' solution" (as I wrote). I don't consider what you proposed to be a "simple 'grep' solution". Perhaps it would help you see my point on that if you imagine yourself finding that code six months from now with no comments and trying to understand what was intended. Even now, having fresh knowledge of what your code is supposed to be doing, I find it fairly difficult to convince myself as to whether or not it is a correct implementation (based on "reading and understanding the code", not based on the test cases provided).

Please notice the word "between" in this thread's title.

Please notice the phrase "take rubbish away from the top and the bottom". 'No rubbish' means 'nothing to take away'. I don't find that to be ambiguous and I don't see it contradicting the simplified description of the problem in the title.

The original code was convoluted enough that I didn't spend much effort trying to understand it in detail, especially since the example data along with the explanation seemed quite clear. I don't know (and don't really care) what before() does with "no match", so I am unsure if you are pointing out that the original code acts like my code or that it acts different from my code.

If the original code removes everything in the face of there being no rubbish, then that might have been a bug due to the author not considering the possible edge case of "no rubbish". It might have been a conscious decision of the author based on an assessment that "there will always be rubbish on both ends". I find not having to rely on such an assumption to be an advantage.

It is possible that the original author considered the "no rubbish" case and wanted "no output" for that case but didn't bother to mention any of that in their query. I find that output enough at odds with "take rubbish away" (especially when given a stack trace) that I don't consider that supposed author behavior to be very likely. But, yes, it is possible.

Personally, I reject posting solutions for every possible interpretation of a poorly phrased question.

Human discussions are an iterative process.

I don't recall posting solutions for every possible interpretation of anything. Heck, I don't even find the description of the problem and desired solution "poorly phrased".

And I don't see how a reply to my reply is impossible or even difficult. The process can "iterate" from there quite simply.

I found what looked like a clear statement of a problem for which I quickly imagined a clear, simple solution. If you found the problem statement unclear, then I will not force you to reply with a solution. I'm sorry that you appear to have taken offense at what I did. Despite your protestations, it seems completely reasonable to me still.

- tye        

I guess some definitions of "quite simple" can be applied to that code.

Linear, clear, concise.

I did not mean to include yours in the set of "not simple". I wasn't paying much attention by the time I got that far.

will produce nothing for that case

I was viewing the problem as "print the stuff between the bounds", in which case it *should* print nothing for the case with no bound.

But it also shouldn't print anything for a missing trailing bound (while it does), so point made.

I rejected using 'grep' at all since it seems likely to me that there could be cases where there is nothing to trim from the front. Your solution (and any simple 'grep' solution) ...

So, you reject simple now, in favour of complicated, because of what might be the requirement in some speculative future.

Yep! That just about sums up all that is wrong with the software industry. Throwing good money after bad chasing what-if scenarios and may-be requirements instead of just taking care of the real requirements as they exist now; and dealing with future requirements -- actual future requirements -- when and if they actually arise.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

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        

FYI, looking at this a second time, I noticed that both of those solutions would handle input containing qw< DBIC::4 eval DBIC::3 > in a manner that seems to me rather clearly against the stated wish (of removing leading/trailing "rubbish" from a stack trace).

Well spotted. That is a realistic possibility for me.


- Boldra