Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What happened to proper tail calls in JavaScript? (2021)

mgmarlow.com

Post reply on HN
Print view View original

91–100 of 146 posts

Re: What happened to proper tail calls in JavaScript? (2021)

#91

Post by kreetx »

ajuc wrote: post #86
gumby wrote: post #79

Earlier quoted context omitted.

A tail call is just a goto; using a special syntax for it (`for…` or `while…`) is simply syntactic sugar. Nobody complains about the lack of a stack frame in a for loop.

Goto can be anything - a function call, a loop, an if clause, exception handler. That's the whole reason we created structured programming - so we don't have to guess what it is THIS time. Tail call optimization is nice, but it has its problems. What's the downside to requiring special syntax for it? It frees the programmer reading the code from determining if it's a tail call every time.

Right, but optimizing tail calls won't lose that structure. But sure, just using goto is a slippery slope to confusion.

Re: What happened to proper tail calls in JavaScript? (2021)

#92

Post by int_19h »

blagie wrote: post #88
saagarjha wrote: post #81

Earlier quoted context omitted.

> Python, and ES2015, have done a wonderful job of bringing many previously-academic (including functional) programming constructs to a broader community This is kind of amusing to hear considering that Python seems to actively design itself around making typical functional programming constructs difficult and JavaScript has a bunch of weird quirks with how it implements things (you’ve seen the “map” joke perhaps?)

The major thing Python has done is bring major functional design patterns, like maps, reductions, everything in itertools, and made human-friendly versions and syntax for them. Right now, that covers 70% of the stuff I did in Scheme over C/C++ (weighed by volume of use, rather than by feature list). A lot of beginner programmers now use features like closures and decorators, and they're accessible. The remaining 30%…

I would argue that, as far as popularizing sequence comprehensions goes, C# (LINQ) was probably more influential than Python.

Re: What happened to proper tail calls in JavaScript? (2021)

#93

Post by blagie »

jcranmer wrote: post #75
blagie wrote: post #68

For the most part, programming constructs like these split the world into two camps: - People who point out things can be done without them, who largely see them as useless due to lack of familiarity - People who've used them, and see critical ways to restructure code to make it cleaner using said constructs That's been the case for a lot of progress in programming. Python, and ES2015, have done a wonderful job of br…

The problem with tail calls destroying stack traces isn't with the recurse-for-the-tree functions. It's with code like this: function frobnicate_something(foo, bar) { let baz = antifrobnicate(foo, bar); // Hey, I'm a tail call! return exfoliate_meteor(baz); } With tail calls, you now lose the frobnicate_something stack frame and you just see a call to exfoliate_meteor, which can produce confusing results. This lost s…

The proposal to be explicit is fine, but there are alternative proposals which avoid this problem too:

- Only tail recurse once the stack is n objects deep. Having a 10,000 element stack trace isn't helpful.

- Keep a log of which functions were called, but not a full stack trace of each call. That's O(1).

I mentioned both of those in my post.

Re: What happened to proper tail calls in JavaScript? (2021)

#94

Post by dgb23 »

zeven7 wrote: post #72
dgb23 wrote: post #32

I use recursion in JS when implementing generic trees/dags. I'm not worried at all about growing the stack because I use the language for UI stuff, where the depth of the trees is quite shallow and the data is small overall. I don't really know what the utility of TCO/proper tail calls would be. You already have UX constraints that nudge to avoid having a ton of stuff on the screen. As an example of where recursion o…

> I don't really know what the utility of TCO/proper tail calls would be. You already have UX constraints that nudge to avoid having a ton of stuff on the screen. The only thing you can think of using recursion for is walking the DOM?

Not specifically walking the DOM but doing DOM/UI related stuff with JS is where I sometimes use recursion. This might also be data processing, but that data is often small and shallow enough for stack growth not not matter, because it is typically related to the UI in _some_ way.

I don't typically use JS for heavy computation of large datasets that lend themselves to recursion. The only thing I can think of that is somewhat large is data visualizations and drawing graphs interactively, but there you typically have a matrix or just a flat array.

Re: What happened to proper tail calls in JavaScript? (2021)

#95

Post by int_19h »

chriswarbo wrote: post #33
munchler wrote: post #6

Earlier quoted context omitted.

[From the article] Why are browser vendors ignoring PTC? V8 chalks it up to two main reasons: * It makes it more difficult to understand during debugging how execution arrived at a certain point since the stack contains discontinuities, and * error.stack contains less information about execution flow which may break telemetry software that collects and analyzes client-side errors.

> It makes it more difficult to understand during debugging how execution arrived at a certain point since the stack contains discontinuities That's a weird complaint, considering that stacks don't describe "how execution arrived at a certain point". In fact, stacks don't describe the past at all; rather, they describe the future of what's left to do (AKA the "continuation"). For example, consider this code: function…

Stack frames also capture locals, and those often provide a lot of information about what just happened. I've had cases before where this was instrumental to figuring out the cause of the bug, and other cases where it likely would have been if TCO hasn't wiped out that information (in C++).

Re: What happened to proper tail calls in JavaScript? (2021)

#96

Post by dgb23 »

zeven7 wrote: post #73
dgb23 wrote: post #49

Earlier quoted context omitted.

Yes, but even there it is typically used for stuff that leans towards front-end. People don't typically write databases and messaging systems in Nodejs. I wonder about specific use cases where stack allocating recursion actually becomes an issue in the JS world.

People do a lot more in JavaScript than you realize.

That's what I'm wondering about. When was the last time you blew the stack with JS and what did you try to accomplish?

Another commenter said they had problems walking a dependency graph.

Re: What happened to proper tail calls in JavaScript? (2021)

#97

Post by kreetx »

dragonwriter wrote: post #66
MrBuddyCasino wrote: post #12

Earlier quoted context omitted.

Pretty good arguments in there: - TCO only addresses recursion that can easily be replaced by a loop - loosing stack frames makes debugging harder - its not just an optimization, as soon as code depends on it to not blow the stack its a required feature for all implementations - functional languages with no side effects need recursion, everyone else really doesn't Personally, I think TCO is bad in a similar way as as…

> TCO only addresses recursion that can easily be replaced by a loop This is simply false. Specialized tail recursion optimization, which I've seen a few places, approximately does that, but generally TCO covers a lot of things that aren't easily replaceable with for loops. > its not just an optimization, as soon as code depends on it to not blow the stack its a required feature for all implementations True, though t…

As far as I understand, TCO (or PTC?) gives you "structured goto", i.e something that would be a pain to write as a loop, won't either mess up the state/scope, but still achieve that "loop speed" without stressing the stack.

Re: What happened to proper tail calls in JavaScript? (2021)

#98

Post by edoloughlin »

blagie wrote: post #68

For the most part, programming constructs like these split the world into two camps: - People who point out things can be done without them, who largely see them as useless due to lack of familiarity - People who've used them, and see critical ways to restructure code to make it cleaner using said constructs That's been the case for a lot of progress in programming. Python, and ES2015, have done a wonderful job of br…

Garbage collection was seen as garbage by C/C++ programmers ("What's the big deal with adding a free() call? Stupid lazy people.")

As a former C++ programmer working on a large code base when/before Java was introduced, garbage collection was seen as expensive and slow, but definitely not a waste of time. I would have given my right arm to be free (pun intended) from the need to manually manage my heap across threads. Adding a free() call was never not a big deal.

Re: What happened to proper tail calls in JavaScript? (2021)

#99

Post by blagie »

int_19h wrote: post #92
blagie wrote: post #88

Earlier quoted context omitted.

The major thing Python has done is bring major functional design patterns, like maps, reductions, everything in itertools, and made human-friendly versions and syntax for them. Right now, that covers 70% of the stuff I did in Scheme over C/C++ (weighed by volume of use, rather than by feature list). A lot of beginner programmers now use features like closures and decorators, and they're accessible. The remaining 30%…

I would argue that, as far as popularizing sequence comprehensions goes, C# (LINQ) was probably more influential than Python.

Hejlsberg is a genius.

Before C#, he designed Delphi, which was a pleasure to use. It made Pascal beautiful, which is not something many considered possible. Functionally, Delphi combined the ease-of-use of VisualBASIC with the power of C++, with an elegance unparalleled in any environment before.

He did Turbo Pascal. It's hard to overstate how much of a revolution that was. Compile-wait-wait-wait-run turned into run.

Now, he's doing TypeScript.

I'm not sure it's really fair to compare anyone to Hejlsberg.

"Sure, your kid won a Nobel Prize for his research, but Einstein did relativity...." "Sure, your business hit a billion dollars, but it's no Apple...."

Acknowledging brilliance elsewhere doesn't reduce my appreciation of Python. It's a good language.

Re: What happened to proper tail calls in JavaScript? (2021)

#100

Post by z3t4 »

tlb wrote: post #48
dgb23 wrote: post #32

I use recursion in JS when implementing generic trees/dags. I'm not worried at all about growing the stack because I use the language for UI stuff, where the depth of the trees is quite shallow and the data is small overall. I don't really know what the utility of TCO/proper tail calls would be. You already have UX constraints that nudge to avoid having a ton of stuff on the screen. As an example of where recursion o…

I ran out of JS stack, walking the dependency graph of a big computation. Dependency graphs can be very deep relative to their overall size. It was a big pain to rewrite with an explicit stack of to-be-visited nodes. TCO wouldn't have saved me, though. It just needs a big stack. Node defaults to just under 1 MB, which doesn't go very far.

Rewriting a recursive function into a for-loop can be mind boggling, but you often end up with more simple code.
Post reply on HN