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

81–90 of 146 posts

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

#81

Post by saagarjha »

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…

> 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?)

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

#82

Post by greymalik »

saagarjha wrote: post #81
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…

> 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?)

I program professionally in both languages and in my experience the two are very different when it comes to functional programming. FP is viable in JavaScript, if imperfect. And as the language continues to evolve to better support that paradigm its community continues to embrace it. But Python’s choices seem to be actively antagonistic to FP. I’d like to be able to use a functional approach in Python when it makes sense but it’s too hard, too awkward, too flawed, and too against the grain of the language.

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

#83

Post by dmitriid »

munchler wrote: post #6
xg15 wrote: post #2

Reads like a sad state of affairs, but the article itself doesn't really explain whatbthe actual concerns where that caused the proposals to be put on ice. From reading, I mostly get "PTC was un-implemented and put on ice because some browser vendors had issues with it; the alternative proposal, STC, was put on ice because other browser vendors had different issues with it. Then everyone (from the browser vendor side…

[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.

This is such a weird complaint given that Erlang exists, with tail calls, and proper async, and..., and is used to create complex software

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

#84

Post by dmitriid »

nabla9 wrote: post #25
leoh wrote: post #8

Worth reading why python doesn’t have it either http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...

Also. Final Words on Tail Calls http://neopythonic.blogspot.com/2009/04/final-words-on-tail-... Outside pure functional languages, I think the best way to implement them is to have explicit tail call declaration for functions and/and tail positions and ability to disable them for debugging (or have debugger aware of them). This way you can actually use them to implement useful stuff and rely on them. You get a compil…

> Outside pure functional languages

Erlang isn't pure, and has tail calls without an explicit syntax.

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

#85

Post by saagarjha »

greymalik wrote: post #82
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?)

I program professionally in both languages and in my experience the two are very different when it comes to functional programming. FP is viable in JavaScript, if imperfect. And as the language continues to evolve to better support that paradigm its community continues to embrace it. But Python’s choices seem to be actively antagonistic to FP. I’d like to be able to use a functional approach in Python when it makes s…

I’d agree in the sense that JavaScript gives you poor out-of-the-box support but it definitely can be shaped into something pleasant. Python will make you hate yourself if you try, yes.

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

#86

Post by ajuc »

gumby wrote: post #79
jcranmer wrote: post #75

Earlier quoted context omitted.

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…

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.

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

#87

Post by whizzter »

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…

If you're writing imperative code with side-effects (or mixed-style) like much classic JS code is, the existence of foo on the call stack indicates that performSomeEffect has been run, and thus it's side-effects on our global state when we enter baz has to be accounted for.

Is it an ideal style to write code in? No. Does real code have this problem, Yes!

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

#88

Post by blagie »

saagarjha wrote: post #81
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…

> 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% is awkward, but usually possible.

JavaScript is convoluted.... but after the learning curve, it does functional as well as anything, and better than most other things it does. It certainly does functional better than OO.

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

#89

Post by blagie »

PathOfEclipse wrote: post #71
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…

On a tangent, I've always felt garbage collection, and, more importantly, safe memory management, was important because it allows you to mostly pretend that memory allocation isn't a globally side-effecting operation, as such operations are difficult to reason about. It's the same logic that leads to design choices that don't explicitly use global variables or global state. In reality, all memory allocation is still…

I disagree. My experience with codebases with programmers who program like that is that you eventually get memory leaks, some of which are near-impossible to debug or fix. You pay for that kind of thinking down-the-line.

Enabling new design patterns == good

Not thinking about what happens under the hood == bad

Catastrophes are rare, but expensive enough to cost more than thinking things through.

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

#90

Post by kreetx »

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 parent mentioned keeping a list of functions called, so a note on calling frobnicate_something isn't lost.
Post reply on HN