I think the basic test cases should include at least one where the expected return value is an empty vector. I got a little confused at one point and ended up treating this as a "filter" problem instead of a "takeWhile" (my fault!), but with a better local test suite, that wouldn't have happened, I think.

This is still the case today.

I just learned something! I didn't know strings were mutable in C++ (coming from Java).

It depends on the language used to solve the kata. In Python, if using the new style classes, you can define read-only attributes. For example,

@property
def progress(self):
    return self._progress

will define a read-only attribute with the name progress. A client may invoke user.progress rather than user.progress(). Java does not have read-only fields, so the test suite should have used getters instead of referencing fields. Something got lost in translation. For the Python version, tests should be added to make sure that setting the rank or the progress fails.

In my opinion, this is an 'advanced' language feauture of Python, and if the kata had provided the tests suggested above, I would have given it 3 kyu. I am solving katas in Python while learning Python, and this kata definitely taught me something I didn't already know.

Thanks :) Although now that I'm looking at it again, it could use a tiny bit of refactoring.

Your solution is a pleasure to read :)

Neat solution.

I had already downgraded this to 4kyu from 3kyu (which was definitely too high). This could maybe be a 5 kyu. Its tricky because this kata requires understanding business rules and following them, which a lot of people struggle with way more than others would think. I personally find some 7/6 kyu kata really hard just because I suck at math - but others can solve those problems in 10 seconds and find them trivial.

A big concern I have lately is that on average no one seems to think anything is harder than a 5 kyu anymore, because the community is now so large and we all think certain things are easier than others. Approving a 4 - 1kyu kata these days very rarely happens.

As for the Java translation. It seems to be offending a number of people due to the reasons @bkaes mentioned. If someone wants to fork their java solution and rewrite it the way that uses best OOP practices, I can update the kata manually with it.

Publicly accessible fields, …

That's actually a problem of the current translation process. The translator took the JS description as a hard requirement and didn't account for OOP practices.

By the way, I think Jake said that this kata wouldn't be 4kyu today. That being said, the difficulty is choosen by users during beta.

Agree, this was my first 4kyo kata and it felt simpler than other 5kyo that I solved earlier.

I've solved harder 4th and 5th kyu katas. This is the first one that made me cringe.

These were the exact same thoughts that ran through my mind as I was fleshing out the solution of this kata. Publicly accessible fields, ridiculously easy business logic, absence of advanced algorithms of any kind, a single class solution, no custom exceptions, enums or anything fancy to justify a 3kyu difficulty. The devout Java programmer in me was wincing the whole time; at least it was a short one :|

Ah, you're right. My apologies; I missed that when reading the description.

1. It's said:

you have to produce a sorted array P of the form
[ [p, sum of all ij of I for which p is a prime factor (p positive) of ij] ...]
P will be sorted by increasing order of the prime numbers.

So no need to tell the same thing about ordering once more, maybe you didn't read very well the description.:-)
2) Yes, we could use long or even ulong (C#) or even BigIntegers in C# or Java (Ruby, Python, Clojure do it without any pain), everything is possible... But it's too late for that now.
3) Yes I could have used more test cases... Maybe another day when I have time!

Anayway, lots of thanks for your feedback!

I think it could use a few more test cases. For example, I had an issue submitting because your tests expected the prime factors to be in ascending order, but I had used an unordered implementation. On that note, the description should state explicitly that the primes must be ordered.

You might also consider using longs instead of ints for a harder challenge. The algorithm to find prime factors would then need to be more efficient.

Finally, perhaps state in the description that it would be helpful to solve the PrimeFactorizer kata first, as that solution can be modified and reused in this kata. Or vice versa.