Fixed

Bad testcases 'Flat Line' and 'Points of line, out of order', they are not an array of points. These need to be corrected. Otherwise a good kata.

The variable scale is described differently in the description and in the initial code window.

In the description: It will tell you how the content weight compares to the weight of the bottle by itself
In the comment on the initial code: A string comparing the weight of the bottle to its contents.

Weight of content and weight of bottle is reversed, I at least would interpret the one in the initial code wrong.

Other than that I think its a good kata.

Heard lots about Monads and thinking I should learn, the description was a nice introduction with great links too. But I can't get the Kata to work. I've been trying for a while now but can't get the "Bound functions evaluated on Something" testcases correct. Bind receives a function from a value (not a Monad) to a value (a Monad), it should return a function from a value (Monad) to a value (Monad). I've been doing some logging and it seems that the testcases expect the function passed to bind to take a number x return Just(x+1). The problem is that i can't make the function passed to bind return anything else than Nothing.

Maybe.bind = function(f){
  console.log(f(1) instanceof Nothing);
  console.log(f(Just(1)) instanceof Nothing);
  ....
}

Only logs 'true'

I probably missed something crucial here but I can't understand what the function f is or what I'm supposed to do with it.

Very nice i think this was a nice kata. I also missed the switching side bit, but that probably was because i read the description to fast. Nice with the hint in the testcase that fails if this happens,

I hope i remember this correctly.
When 6 is removed both node 5 and 7 needs to be moved (one of them replaced). In this case you need to either put a new 5 under 4 and move 7 into this new 5 or put a new 7 under 4 and move 5 into the new 7. Hence either node 5 or 7 should survive (the one that is a leaf in the new tree).

I think that print(t1.left.right.left === t2.left.right) should print false. And you should check for t1.left.right.right === t2.left.right.right (if you create a new 5 and move 7, which you're example suggests).

You are right. Did a new submission with this corrected.

Do you gain memory from having functions in the closure instead of each of the objects?

How does javascript engines actually store function instances? If there are properties attached to a function instance these obviously has to be stored somewhere. In the case above does it matter if eval and toString are bound to functions in the closure? The toString and eval functions above are semantically different for every Operator instance, but are all these stored as different entities internally in the javscript engine, seems more naturally treat the actual logic of functions as immutable and just apply these logic entities to different objects.

Secondly if the functions are placed in the outside closure as edalorzo suggested will changing, for example reduce (in edalorzos solution), change the behaviour of all Operators or will they still be bound to the original reduce, if they were created before the change?

I thought that this was a lesson in lazy evaluation. You could make this a requirement and test that operators aren't evaluated too early.

I think this solution is incorrect this would say 'aab' is an anagram of 'abb' :(

I agree I thinks it is very good that the test uses big maps, but I think it should be specified how big the largest map is. This might help people to get an understanding for complexity analysis of algorithms.