If one has a linked list with tens of thousands of records in Javascript, I think that's likely a problem bigger problem than this function blowing out the stack.

Though, I am disappointed to learn that most browsers haven't implemented tail recursion optimization, even though it was in the ES2015 spec nearly 10 years ago. It's such a boilerplate program optimization, I'd assumed it would have happened by now. Go Safari, I guess.

This is a kata. The point of a kata is not to create "implementations that would be used in the real world."

"That one guy"? This is the second most popular solution. 😆

*Astronaut meme* Always has been.

A lot of people seem to misunderstand the fundamental philosophy of the kata. The point of a kata is not to have production code in the answer. The point of a kata is to practice solving individual, targeted problems. Then, later when you're writing production code, you have the "muscle memory" of solving each individual problem in your katas, and can merge pieces of multiple katas into a whole production solution.

In the same way, in karate one practices katas--sequences of moves--but one would never perform a kata in a fight. One would take pieces of katas, individual moves, expertly executed from extensive practice, in response to the opponent's moves at the time.

What does that mean here? Here, there's no need to verify the arrays are the same length. That's not part of this kata, it doesn't make sense to include that in the kata, that's not an interesting, targeted problem to solve. There's no need to worry about mutating the arguments. The arguments will not be used later, they are disposed. The kata author makes us perform a null check; that was a mistake, a sign of someone who does not understand the philosophy of katas.

This kata is about comparing two arrays with a custom comparison rule. Anything outside that core, targeted problem is irrelevant.

A lot of people seem to think that adding a lot of cruft to every single kata method somehow makes the solutions better. It doesn't. It's a waste of time. You learn nothing by adding a null check or an array length check to even an intermediate kata. Cut your katas down to the bone. Solve only the interesting problems.

Naw, go the other way. If I wrote this now, it'd be a lambda. Remove all that clutter.

The question you're asking is, "What if this kata was a different kata?"

Then I would have written different code. But it's not a different kata. It's this kata. And in this kata the arrays always have an equal number of elements.

Sneaky way to ensure the response is a boolean, instead of null.

This code was written before that syntax existed.

It works on every single row.

8 years ago that was not part of the kata.

Back in the old days when many people were completing this kata, the starting code was:

def bool_to_word(bool):
    # TODO

If you edit/fork the kata and look at the "Complete Solution", you'll see the legacy of this format is still in place (it's just in a non-public location).

Most kata writers don't bother changing given variable names, since that's not part of the "problem" we're being asked to solve.

So, yeah, people are right that it shouldn't be bool, which is why someone updated the kata to change the starting code to boolean (which, IMO, is just as bad of a name, since it's still the name for a variable type, even if Python proper never uses it; it's like Hungarian Notation, except it's not just a notation, it's the whole name). But, you should keep kata updates in mind when talking about people's ancient solutions: the ground has shifted.

That's what was asked for?

"Same" means, here, that the elements in b are the elements in a squared, regardless of the order.