4 ms·

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, bu

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 8y ago
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.
- braythwayt 8y ago
  Well, given that the post links to two different discussion forums, I attest that it’s not my responsibility to outline every single consideration of every single technique, nor is it my responsibility to include the entire syllabus of computer science to explain the background. Instead, I outsource that to people like you. You voice your concerns here, and people can read them and make up their own minds. Speaking of making up their own minds, please explain in more detail how the trampoline’s memory consumption grows unboundedly, to the point where it could cause an out-of-memory error. That would be most interesting for the community to ponder.
  - danjoc 8y ago
    Why don't we just illustrate the problem using the code from the article? https://jsfiddle.net/q59Ljeu7/ https://jsfiddle.net/q59Ljeu7/ A loop is not just fewer LoC and easier, it is orders of magnitude faster than the ycombinator decoupled trampoline. The first alert is nearly instant. The second one takes almost a minute. My chrome dev tools are hard locked waiting for the ycombinator to finish. This is not something I would encourage JS devs to use in practice.
    - braythwayt 8y ago
      Well, refactoring isEven or exponentiation to a loop is faster. But wait, you know what's even faster? Using built-in math primitives. I wrote an entire article about refactoring tail-recursion to iteration and linked to it in TFA. I've also written a Scheme interpreter that can perform this optimization for certain functions on-the-fly. But arguing that the code is slow is missing the point by a country mile, and then some. The article is not arguing that the code is fast, or that you should always do this. I find it amazing that every time a programming technique is discussed, people want to worry about whether it belongs in production. Is there no recreational programming any more? Or is it all about shipping the next app to deliver food by electric scooter? My world would be depressingly boring if the only things I thought about were the things I use at PagerDuty every day. Now as to what I asked you about: What you said was that this implementation leaks memory in such a way that using the trampoline it trades a stack overflow for an out-of-memory error. I wish to understand that problem. Specifically, how does the decoupled trampoline leak memory?
      - danjoc 8y ago
        I already told you, I liked your article. I said it was great. You get a trophy, smart person. My gripe is a lack of disclaimer. There are plenty of people who will read it, then rush right out to duplicate it. That will bring bugs and chaos all over the javascript world. The trampoline is a bad idea in practice. I can't show you an out of memory error or lack thereof. The code in your article hard locked the dev tools which is much much worse than throwing an error. Since the trampoline is a bad idea, the solution to your stack overflow errors needs work. It follows that with no solution, then the ycombinator itself is inappropriate. It shouldn't be hard for you to admit that, being as smart as you are. All I'm asking is that you mention that more prominently in your otherwise great article.
        dentemple 8y ago
        > There are plenty of people who will read it, then rush right out to duplicate it. That will bring bugs and chaos all over the javascript world. Citation needed. I seriously doubt that there's a horde of developers who--at this very moment--are pushing Y Combinator JS apps into production all thanks to this thought exercise.

danjoc 8y ago

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.

braythwayt 8y ago
Well, given that the post links to two different discussion forums, I attest that it’s not my responsibility to outline every single consideration of every single technique, nor is it my responsibility to include the entire syllabus of computer science to explain the background. Instead, I outsource that to people like you. You voice your concerns here, and people can read them and make up their own minds. Speaking of making up their own minds, please explain in more detail how the trampoline’s memory consumption grows unboundedly, to the point where it could cause an out-of-memory error. That would be most interesting for the community to ponder.
- danjoc 8y ago
  Why don't we just illustrate the problem using the code from the article? https://jsfiddle.net/q59Ljeu7/ https://jsfiddle.net/q59Ljeu7/ A loop is not just fewer LoC and easier, it is orders of magnitude faster than the ycombinator decoupled trampoline. The first alert is nearly instant. The second one takes almost a minute. My chrome dev tools are hard locked waiting for the ycombinator to finish. This is not something I would encourage JS devs to use in practice.
  - braythwayt 8y ago
    Well, refactoring isEven or exponentiation to a loop is faster. But wait, you know what's even faster? Using built-in math primitives. I wrote an entire article about refactoring tail-recursion to iteration and linked to it in TFA. I've also written a Scheme interpreter that can perform this optimization for certain functions on-the-fly. But arguing that the code is slow is missing the point by a country mile, and then some. The article is not arguing that the code is fast, or that you should always do this. I find it amazing that every time a programming technique is discussed, people want to worry about whether it belongs in production. Is there no recreational programming any more? Or is it all about shipping the next app to deliver food by electric scooter? My world would be depressingly boring if the only things I thought about were the things I use at PagerDuty every day. Now as to what I asked you about: What you said was that this implementation leaks memory in such a way that using the trampoline it trades a stack overflow for an out-of-memory error. I wish to understand that problem. Specifically, how does the decoupled trampoline leak memory?
    - danjoc 8y ago
      I already told you, I liked your article. I said it was great. You get a trophy, smart person. My gripe is a lack of disclaimer. There are plenty of people who will read it, then rush right out to duplicate it. That will bring bugs and chaos all over the javascript world. The trampoline is a bad idea in practice. I can't show you an out of memory error or lack thereof. The code in your article hard locked the dev tools which is much much worse than throwing an error. Since the trampoline is a bad idea, the solution to your stack overflow errors needs work. It follows that with no solution, then the ycombinator itself is inappropriate. It shouldn't be hard for you to admit that, being as smart as you are. All I'm asking is that you mention that more prominently in your otherwise great article.
      - dentemple 8y ago
        > There are plenty of people who will read it, then rush right out to duplicate it. That will bring bugs and chaos all over the javascript world. Citation needed. I seriously doubt that there's a horde of developers who--at this very moment--are pushing Y Combinator JS apps into production all thanks to this thought exercise.