[danjoc]

So we start out with an attempt to build an anonymous recursive function. That's cool I suppose. But doing it in a language like javascript (or java)? It turns out that tail recursion == stack overflow. Not daunted, the plucky author decides that we can solve this particular issue by creating a closure over stack variables and put them on the heap instead!

You know, if you want to use Haskell, use Haskell. Trying to shoehorn this stuff into languages designed for loops instead of recursion just means impressionable JS developers are going to see this and rush out to implement it in some project to prove how smart they are. Then everyone suffers. The implementation is slower because it goes to heap. The memory usage explodes because it goes to heap.

Purely for illustration of a Y combinator, this is great. But there should be a big red warning somewhere on the page as a reminder of the downsides of this approach.

[braythwayt]

We actually don’t start out with an attempt to build anonymous recursion.

That is the goal of the Y Combinator in the Lambda Calculus and Combinatory Logic, but here the initial goal was to decouple an anonymous function from itself so that we could decorate it.

[danjoc]

Going out to main memory is orders of magnitude slower than hitting cache. Even a stack overflow would be preferable to debug vs an out of memory error. At least with the stack overflow, the stack trace pinpoints the problem.

Like I said, I have no problem with this article as an illustration of a ycombinator for JS devs. The problem is it does not warn them sufficiently of the very major drawbacks in using it. This is why we have Gate's law; Developers using inefficient constructs because they're neato.

[empath75]

You don't even use the y combinator in haskell. It's an academic exercise that's mostly relevant in lambda calculus.