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.

That's a long-winded way of saying yes.

That is, what you've described as your intent, matches exactly what I got from your previous post, even if you reject my potted summation of it.

I think that the middle top panel just about covers it, don't you?

---

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?

Too many words for you? Perhaps you should have just stopped at:

Nope. I rejected "somewhat simple and clever now" for "even simpler and not clever (now)"

Hint: that doesn't actually translate to "yes". In case you still have difficulty, it was in reply to "So, you reject simple now, in favour of complicated". Underlines added.

But really, it sounds more like trolling than such a fundamental failure to understand.

- tye