Note: If the input string contains no digits, this solution will return a 0, which might be unexpected behavior. By contrast, parseInt() and unary + coercion will result in NaN.

Just for curious newbies, this approach bug-prone because it will fail without throwing an error if the first string contains a space character already.

In order for this solution to work reliably, it must use a delimiter which is guaranteed to be absent from the source strings.

This was fun to solve in JS without recursion or mutating the nodes. This kata has good potential as an opportunity to practice generators.

It seems to default to the latest, though I can't be 100% sure without starting a new account.

The pattern I've seen is that they generally keep the older versions enabled.

It would be really nice to update the Node.js version for this kata.

On further experimentation, there are definitely JS test cases which expect the output to be -0 when both the multipland and multiplier are positive numbers.

In one random test case, for example, n (the multiplicand) is 291 and the first integer in the array (the multiplier) is 0. The test is failing because it says that the result of that first multiplication is expected to be -0.

If we could expect all such cases (where the multiplicand and multiplier are both positive) to result in a negative zero for some reason, then fine: we could work around it sensibly. But not all the test cases expect negative zero in this "positive times positive" scenario.

Right now, this kata as described seems unsolvable in JavaScript. Perhaps the description needs updated if there is some implicit requirement for returning negative zero in certain conventionally-unexpected cases. But more likely, there is a bug in the test solution.

Why are we still getting -0 in the "expected" results in this kata, particularly in JavaScript?

It's not even conventionally possible to check for -0 in JavaScript using operators, Math.sign(), or the rest of the Math library, as far as I can tell. You can't even use right-shift to find that.

(I can find two ways to do it, but they are both highly obscure and one of them appears to be undocumented. I will mention them in a comment below with a spoiler tag for those interested.)

What is this I feel? That's...

That's...

Sexy?

It is worth it. But chiefly in certain self-contained and exceptional scenarios:

1. Search and search-and-replace operations in code editors, terminals, databases, and spreadsheets.
2. Code that will never need to be shared or debugged, such as one-off automation scripts or data extraction/manipulation.
3. A proven performance improvement achieved by the RegEx engine to widen a particular performance bottleneck in an app or database query.
4. Scenarios where the readability/debuggability trade-off when compared to the alternative code is a wash, such as can easily be the case in complicated spreadsheet formulas.
5. CodeWars katas. 😉

RegEx is best used in one-off scenarios, such as you might encounter when scripting a one-time automation or data extraction/alteration, or searches (and/or replaces) in code editors and terminals.

Sometimes, it is valuable in SQL queries where a performance improvement might drastically widen a bottleneck. (But hypothetical performance improvements should always be tested in nearest-to-real-world scenarios.) Spreadsheets get some value out of RegEx, too, since spreadsheet formulas can quickly become more complicated to read and debug than a RegEx anyway.

Technically, there are branches; but since RegEx is declarative, the branching is generated for you at a lower level of abstraction (the RegEx engine). It still has to perform looping and conditional operations, which is why it is possible to write extremely slow RegEx patterns.

But yes, I caution people with the following:

RegEx can radically decrease the amount of time it takes a developer to WRITE a solution,
but it will also radically increase the amount of time it takes developers to READ the solution.

If that trade-off is worth it, do it.

But it is generally not worth the significant sacrifice of readability/debuggability, unless your code will never be shared or requires a specific performance improvement achieved by the RegEx engine.