The thing is, c.incr(); // counter is now at 1 doesn't mean that c.incr() should equal 1. It means that the counter (a property, a variable, wherever it is) will now be 1. Calling it again would make that same variable change to 2. Does that make sense?

If the author intended to show that c.incr() should equal the new number, they would have written a similar statement to those below it: c.incr() // 1. It's probably not the best way of writing those kinds of explanatory statements (I would have gone with c + 1 == 2 or something), but that's what was intended. Hope this helps.

So I just took this from the For Example box within the instructions:

For example:

var c = new Counter();
c.incr(); // counter is now at 1
c + 1; // 2
c > 1; // false
c > 0; // true
c == 1; // true
Math.sqrt(c); // 1

Interpreted each line as a literal unit test as follows:

var c = new Counter();
Test.assertEquals(c.incr(), 1) // counter is now at 1
Test.assertEquals(c + 1, 2); // 2
Test.assertEquals(c > 1, false); // false
Test.assertEquals(c > 0, true); // true
Test.assertEquals(c == 1, true); // true
Test.assertEquals(Math.sqrt(c), 1); // 1

yields the following results:

Expected: 1, instead got: undefined
0 Passed
1 Failed
0 Errors

Process took 49ms to complete

Changing the line as mentioned to what was outlined earlier yeilds:

Test Passed: Value == 1
Test Passed: Value == 2
Test Passed: Value == false
Test Passed: Value == true
Test Passed: Value == true
Test Passed: Value == 1
6 Passed
0 Failed
0 Errors

Process took 52ms to complete

Okay. So you just wrote a new test that isn't in the kata, or mentioned anywhere in the description. Still unsure what you're getting at.

Ok, so try running the following Unit Test:

var c = new Counter();
Test.assertEquals(c.incr(), 1) // counter is now at 1

/**
Runs in console:
Expected: 1, instead got: undefined

0 Passed
1 Failed
0 Errors

Process took 47ms to complete
*/

it doesn't return the result as 1 (as expected in the comment)

Not sure where you're talking about? I couldn't find a reference to this anywhere. Also, it does pass the tests, and so does work. At least theoretically.

It's about knowledge. And you gain knowledge by doing stuff like this kata and finding new features of the language you didn't know were there. Which amounts to having experience with it. It's all part of the same thing. Let's not get into a semantics war here... ;P

It is not about experience...just a quirk,you can google 'javascript implicit conversion' for more information.

I had no clue about the .valueOf ??? that is not intuitive definately more about experience on that one.

Good idea. I added that test.

You should add a multiple number of arguments test case, and random number of random arguments test case.

That's true, but higher-order functions are also a core principle of FP, which is why I included it as a tag.

Nice exercise. I'm no expert on functional programming, but I thought one of the main consepts was not to maintain state. So maybe remove the tag?

The previous description was actually more precise. If it's only number literals you're not allowed to use, the original code should be valid since it only uses nubmers as text in a string and not number literals.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Values,_variables,_and_literals#Integers