With a solution this verbose, it would probably just be more concise to match entire phrases like "twenty-three" and "six hundred".

Then either the kata is boring, or the tests are lacking. It's still not the user's fault. Why do you always want to label this as "user cheating"? Your focus is entirely wrong.

Someone chooses to abuse the tests (or lack thereof), and that person is allowed or even encouraged to do so while the fault lies solely on the author because they allowed it to happen? In what backwards world does that logic make sense? The person chose to write a lazy and unimaginative solution; what sense does it make to blame the kata author for that?

Nobody has any obligations to play along with the kata author (after all, the kata author can demand you to solve 3SAT in polynomial time and then not put any tests on it). We only hold obligations to what is being tested.

And here is the core difference in philosophy. You are saying that people should be allowed to write whatever solution they want as long as it satisfies the test cases. I'm saying that a good solution to a kata is one that accurately addresses the problem that the kata outlines, and bonus points for doing it in a creative way, so one that ignores the problem entirely in favor of just hardcoding the correct results is a poor solution.

I'm not saying that people shouldn't be allowed to offer lookup-table solutions when the option exists. I'm saying that those solutions shouldn't be treated as though they good ones (or frankly even acceptable) because they are quite clearly against the entire purpose of the kata and CodeWars as a whole.

similarly, going for a smart(er) approach trying to prepare for a problem/exam, still shows ingenuity, at least.

There's nothing ingenious about swiping test answers. It's something anyone can do when presented the opportunity, and is nothing more than a replacement for actual applied knowledge and creativity, the two things kata are designed to promote.

@Voile

False. Lookup table is a valid and widely used technique to solve problems, especially if you already know the result.

There's nothing wrong with using lookup tables in your kata, as they can be very useful for lists of precalculated values (like prime numbers). The issue is when your kata consists solely of a lookup table, as you are making no attempt to solve the problem as presented and are just mining the answers from the error logs. It's a carbon-copy solution that can be used for every kata on the site (that doesn't have random tests, anyway), so it's lazy and uninventive.

Then go complain at the kata author/translator and raise an issue about the lack of random tests. Complaining at people submitting pattern-matching solutions as "cheating" is the least productive action you can take out of the situation.

That issue has already been raised (by you, as a matter of fact), so me just banging on the wall isn't being very productive either.

And random tests are mandatory nowadays anyway, so it's the kata author/translator's fault, not user's fault.

The addition of mandatory random test policy means lookup table solutions are frowned upon by CodeWars as a whole, does it not?

I agree. The solutions that resort to brute force aren't very imaginative, so I wouldn't vote them up. But they do solve the actual problem (albeit in a naive way), so I wouldn't want to vote them down either.

And your alternate description of the metaphor? It sounds like the exact same scenario presented with less negative-sounding words. It still amounts to the same thing - circumventing the problem rather than solving it (i.e. cheating).

And downvoting does fill its role in allowing the community to mark solutions as being low quality, whether that means they are bad solutions or they are solutions that aren't in the spirit of the kata. This solution falls under both categories, because A) it's not a real solution; and B) with the new inclusion of random tests, it wouldn't even work anymore anyway.

"How is that lazy"? Are you serious? This solution makes no attempt to actually solve the problem, but rather just mines the correct answers to specific test cases and forms a canned set of responses. It's the equivalent of stealing the answer set to a math test.

If you have an actual solution elsewhere, then good for you. That doesn't change my opinion of this solution.

Why? There's no performance difference between named and unnamed functions, and there's no good reason to name a function that has no purpose or relevance outside of the one place it is used.

Most performant, this solution is not. But dang if it doesn't look sexy.

You've replaced the inner map and join of the above solution with the reduce. While this will reduce the number of times the string has to effectively be referenced (albeit in a roundabout way), it loses that benefit by having to perform a hell of a lot more string concatenations. Ultimately, I imagine your solution would be (much) less performant than the above solution. (Also, you don't have a toLowerCase on the string in the third bit of the ternary, so your solution will fail if the input string has upper case letters in odd-numbered positions.)

I wish there was a downvote button. Simply mapping all known inputs to a corresponding output is a pretty lazy way to solve the kata. (Not to mention that this solution will not pass anymore due to the introduction of random tests.)

You are only as good of a programmer as your ability to understand the nature of what you are coding. This is a math-centric problem, so it's only natural for there to be a math-based solution. And the ability to translate that math into a line of code is what separates the good programmers from the great ones.

"Better" as in better for code golf, but not necessarily for production code.

I maintain that this solution, even though it is O(n) instead of O(1) like some other solutions, is still best practice. Unless it turns out the program needs the extra performance, simple and straight-forward is always preferable to obtuse and over-engineered. Don't prematurely optimize your code, people. :)

In this case, I would say that descriptive comments would be preferable to well-named auxiliary variables.

Definitely clever, but definitely not best practice. There's way too much mutation for the data to remain pure, and all that converting from number to string and back introduces a 10x minimum increase on computation time. If the source is a number, the output is a number, and all the operations assume the operands are numbers, there's no reason to convert the data to something other than a number at any stage.