The implication is that the library is available in the language you are being tested in. My point is that, providing the library name in the instructions is irrelevant to the solution if it is not actually provided. Possibly a purposeful misdirect, but that is a bit much for an 8kyu.

Not sure who is marking this as "best practice", but it is certainly not.

Just because you failed to use parseInt to do the conversion directly doesn't mean it's my fault for that.

I feel like we're talking in circles. I never even implied that it was your fault. Let me try to be more clear. I didn't use parseInt because JavaScript's parseInt will not convert this "0.db9318c2259923d0" (or any other form of string or literal hex fraction) to this 0.857713 (or any other decimal fraction). JavaScript has no concept of hex fractions, so expecting a JavaScript programmer to understand the given example while omiting a vital algorithmic step makes the instruction set for the required deliverable incomplete. There is absolutely no need to explain how to do anything, just that it needs to be done.

"Hexadecimal fraction" itself is already more than enough to let you find out what that means.

I completely agree, and it would be great if the instructions even just mentioned the term "hexadecimal fraction" at literally any point.

So you're saying something is esoteric just because the language doesn't support it on the fly?

Not at all. It is esoteric because a majority of people cannot reasonably be expected to know about a functionality with such limited use case and reach.

You seem to be under the impression that my issue is with the program in some way. My issue is purely with the instructions provided for JavaScript. If you don't want to fix it, then you do you -- whatever. I was just hoping to save another JS programmer some time down the road.

If you know what decimal fraction is, you should know what a hexadecimal fraction is.

That's a pretty bold statement. I've been doing this for quite a long time and never stumbled across it. A quick survey of my entire develpment team, and not one of them were aware that hexadecimal fractions were a thing.

And there's already an example given. There are more than enough information.

The example is very unclear in regards to this specifically. For instance, there is zero disambiguation between literals and strings. As stated previously, it appears as if the 0. is simply prepended to the beginning of a hex string.

Do I really have to outright explain every step how to derive a hexadecimal fraction?

I never said you should explain how to do it, but my point was that if you are going to explicitly list out all of the other steps, then you should at least mention it as being one of the steps. It is not only an omited step, it is also very esoteric considering that the language being tested doesn't even recognize hex fractions as being valid.

The fact that you can't just take a parseInt shortcut is not an issue either

I don't understand what you mean by this? parseInt('0.db9318c2259923d0', 16) and parseInt('0x0.db9318c2259923d0', 16) both return 0, and parseInt('db9318c2259923d0', 16) returns a completely incorrect (for this excercise) decimal value. JavaScript even throws a TypeError for (0xa0.a0).toString(10) but returns a proper decimal number for (0xa0).toString(10).

All-in-all I thoroughly enjoyed this kata, so thank you for that. However, I have one major complaint. The algorithm instructions completely omit a very crucial step: converting the hex string to a fraction. As someone who had never even heard of the concept of a hexidecimal fraction, this took me a long minute to finally figure out. As neither "0.db9318c2259923d0" nor 0x0.db9318c2259923d0 are valid hex in JavaScript, it appears that the "0." is simply being prepended to the hex string, which is not at all the case. Had I not stumbled upon a StackOverflow discussion which mentioned hexidecimal fractions, I never would have been able to solve this, and been left forever wondering why parseInt was not returning the proper decimal representation.

Not sure how you are checking for equality in JavaScript, but the tests do not pass if the returned object's properties are defined in a different order than expected, even though the two are functionally equal:

Expected: '{ vowels: 1, consonants: 3 }', instead got: '{ consonants: 3, vowels: 1 }'

Description states:

You are using a library (Game.Logic in C#) that already has the functions below

But in Node: ReferenceError: Game is not defined.

Your description does not mention that multiple questions will be sent as one parameter, or how that would be formatted. I had to look through the tests to understand your true deliverables.

So, I'm not sure that the tests properly account for cases like 1001, which create technically valid substrings with leading zeros [1, 10, 100, 001, 01, 1], and end up with a count other than 2. Was this by design?

Traceback:
   in 
NameError: name 'say_hello' is not defined

Good points. Edits made, just awaiting approval.

Fixed, thanks. Never used Python3 before.

The Python translation expects function "say_hello" instead of "sayHello", as described.

Fixed tests