Excuse me. If I could find a delete button I'd press it, but I can't find one so an edit will have to do.

Your code won't work for {25,25,50,50,100}. It should return no, but yours will return yes.

One way of optimizing your time is to make something abstract only when it is expected to change. So, if the requirement changes once or twice, abstract it out. Otherwise, a simpler specific solution will save you time and reduce project complexity.

Thanks for pointing this out :)

Corrected regex compared to my previous solution, which didn't handle 6 consecutive separators correctly (now, it does).

In fact, the regex should be "(\W|\w+)+?", I just realised this by myself (too late), otherwise 6 consecutive separators in the input will be shortened to the word "4", however this is an edge case, which the test cases don't cover.

Oh, I'm a beginner programmer (working about 1 year) and I couldn't agree more on the requirements when dealing with people, you're absolutely right about it and sadly, it will never change. People in general will always change their minds whenever they can, that's why I love doing open source projects and just dealing with this annoying chattering when I have to. Don't let your hopes go down tho, there are awesome places to work and they'll minimize this kind of situations.

For me, this is a huge wtf xD
This is not grandma's average Java code ...
Nice effort dude !

I found the usage of "modern" java features rather creative for this Kata, but I find the readability took a serious smash in the face. Good job anyway !

Thanks for the honest answser, it's really appreciated. "Horrifying" is a strong word after all, sorry about that ^^" I do understand these Kata's are only exercises :) However when you say "you know your parameters and they won't change"... I dearly hope that is the case for you if you're a professionnal programmer, because where I work, the client changes his mind every 5 minutes and thinking ahead has become a second nature for me, and I can never take his word for granted on any requirement what so ever -_-"

I think you're half right. You've said things that I agree, but sometimes you just have an answer that fits your demands. You know your parameters and they won't change, but most importantly: you don't have to think about scalability on a common solution like this one.

"WAIT, are you SAYING that scalability or abstraction SOMETIMES isn't a good thing?"
Hell no, but if we would stop to think about an ideal solution for everything, we would end up stuck extra minutes/hours finding, creating or adapting a design pattern on top of a solution that is much smaller and simple.

There are a lot of higher level KATAs that need a generic or abstract code, that are full of random tests and it will break your code if the mindset is slightly distorted. My purpose here was to find the smallest and quickest solution to this KATA, I see by your answer that you aimed for a more generic solution, that's indeed better than the most solutions on this KATA, but again, that doens't make our solution - by any means - horrifying.

This solution doesn't handle this case properly : "an invalid sequence (a string with non numeric character).
Using input data "1 a" returns 0 instead of 1.

Not OOP design, but still trying to be both generic and understandable.

Add a 4th type of bill and you will have to rewrite the whole method, because the logic varies directly according to the bill value. I believe this is wrong design. Am I the only one this type of solution horrifies ?

Finally a solution which goes the generic way ! I love it ! The value-specific logic proposed in most solutions horrifies me to no end ...