You misunderstand what's being practiced in the kata. This kata is not about performing simple math. This kata teaches how to use multiline functions in Java. If someone performs the extremely silly activity of detecting the input and manually setting the area then returning it, they'll still have used multiline functions in Java.
But also, the only people who are going to be trying to hard-code area based on the limited input sets are people who are intentionally trying to break the kata and definitely don't need the practice. It's actually easier to just do the math. I see no reason to guard against such people since, again, they still did what the kata actually cared about (multiline function programming).
For simple statements like this, it's quite pythonic to put it on one line. Even for more complicated statements with ifs and for loops and generators, it is still often pythonic to put it on one line.
It doesn't recreate the whole list. It recurses through the list until it finds the correct index, then inserts the new Node at that location. If you're referring to head.next = insert_nth(head.next, index - 1, data), that doesn't "recreate" anything, it just sets the new assignment which, in most cases, is the same as the old assignment.
If the linked list contains that many elements, then this function will fail. However, lists of that size were not part of this kata. That being said, if I wrote this again, I'd make it tail recursive, and then the list size would not be limited by the stack size.
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.
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.
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.
The specialized functions are introduced in later katas in the series.
The point of this kata is to write the given function. The point of this kata is not boolean arithmatic.
You misunderstand what's being practiced in the kata. This kata is not about performing simple math. This kata teaches how to use multiline functions in Java. If someone performs the extremely silly activity of detecting the input and manually setting the area then returning it, they'll still have used multiline functions in Java.
But also, the only people who are going to be trying to hard-code area based on the limited input sets are people who are intentionally trying to break the kata and definitely don't need the practice. It's actually easier to just do the math. I see no reason to guard against such people since, again, they still did what the kata actually cared about (multiline function programming).
For simple statements like this, it's quite pythonic to put it on one line. Even for more complicated statements with ifs and for loops and generators, it is still often pythonic to put it on one line.
YMMV in other languages.
It doesn't recreate the whole list. It recurses through the list until it finds the correct index, then inserts the new Node at that location. If you're referring to
head.next = insert_nth(head.next, index - 1, data), that doesn't "recreate" anything, it just sets the new assignment which, in most cases, is the same as the old assignment.If the linked list contains that many elements, then this function will fail. However, lists of that size were not part of this kata. That being said, if I wrote this again, I'd make it tail recursive, and then the list size would not be limited by the stack size.
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 comment is hidden because it contains spoiler information about the solution
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.
This comment is hidden because it contains spoiler information about the solution
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.
Loading more items...