For the most part, programming constructs like these split the world into two camps:<p>- People who point out things can be done without them, who largely see them as useless due to lack of familiarity<p>- People who've used them, and see critical ways to restructure code to make it cleaner using said constructs<p>That's been the case for a lot of progress in programming. Python, and ES2015, have done a wonderful job of bringing many previously-academic (including functional) programming constructs to a broader community, together with models like reactive programming.<p>That's true of about half of the bits of progress in programming. Garbage collection was seen as garbage by C/C++ programmers ("What's the big deal with adding a free() call? Stupid lazy people."). Garbage collections wasn't useful because it omitted free() calls, but because it allowed the design of flows with many exit points (for example, different kinds of exception handling, exiting in the middle of a function, or giving up an object in a half-dozen places an hour later in code where tracking for free() requires building an ad-hoc reference counter or garbage collector).<p>The place where tail calls are a huge deal is when dealing with deep (or even infinitely deep) tree-like structures:<p><pre><code> if condition:
return red(left_child)
else:
return blue(right_child)
</code></pre>
I don't mind opt-in versus opt-out versus neither. All the reasons listed for not having them are dumb, though, and have good and easy work-arounds. The major one -- debugging -- it's basically always good enough to just have a list of functions called, without having the whole tree. A 10,000 element stack trace is no help at all. You can, for example, keep the first 20 elements of the stack trace (don't start PTCs unless the stack is of a certain depth), and then still keep a list of functions called:<p><pre><code> ipython
webapp.main
webapp.handler
render.make_tree
[PTC: render.red*91001, render.blue*10201]
webapp.callback
</code></pre>
I have literally never seen a case where having a list of 100k calls in a stack traces is at all useful for anything.
So, what happened to syntactic tail calls? I think that's what I would prefer anyway, both because it makes it more clear from a debugging standpoint, since you opt in, and because you can get a warning (or compiler/linter error if using a transpiler or linter) when your function isn't actually tail recursive.
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.<p>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) kind of lost interest."<p>But what <i>were</i> the actual issues that blocked the two proposals?<p>Edit: Ah, I'm sorry. The issues with PTC are indeed described, but STC was brought forward specifically to address those reasons. So why wasn't STC implemented then?
One advantage of syntactic tail calls is that you can give an error if you are unable to transform to a tail call.<p>Otherwise, you could have a program that seems to work file, and then you refactor and now your recursion isn’t a tail call anymore, and your stack blows up.
Worth reading why python doesn’t have it either<p><a href="http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html" rel="nofollow">http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...</a>
We should switch on time travel debugging when it’s worthwhile, and be aware of its actual costs, rather than <i>always</i> paying for stack frames because they <i>might</i> serve as an incomplete history (missing loop iterations and calls that already returned).
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.<p>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.<p>As an example of where recursion of generic trees could be applied in a UI: Look at HN threads. Even exceptionally large threads have what, a couple hundred responses? With depth of maybe a dozen? Also you typically have affordances to navigate such a tree and only see the parts of it that you want. So it becomes even more trivially small.
The few real world discussions I've had about the topic of tail calls revealed that people mostly don't know about them and are thus more "afraid of the unknown" rather than against the thing itself.
> Despite its inclusion in the 2015 language specification, PTC is currently only supported by Safari<p>Kind of related: I kept hearing about how backward Safari is, but is it really bad?<p>To me even as a web dev myself, the constant stream of new things pushed into modern browsers seem unsustainable. Saying no sometimes doesnt seem clearly bad, especially considering the fact that all browser vendors have some sort of agenda. Safari and Firefox are the only neutral ones but I'm not sure about the latter anymore.
I had the impression, the ECMAScript spec would only accept proposals "after" they were implemented by the major players.<p>How did PTC sneak into the spec?
I've seen a lot of chatter about tail calls, but I don't think I've ever seen actual examples of what they look like. Does anyone use them or is it just something for language nerds to obsess about?
I've ended up writing a number of things in an equivalent iterative way due to this... which in retrospect feels like a positive thing because I find it far clearer.
After thinking about this for a bit, the decision to avoid including this functionality is probably for the best.<p>Even though I would love for this feature to exist, I can see people unintentionally shooting themselves in the foot and not understanding why.<p>Often when you run up against call stack limitations, you actually need to reconsider the algorithm being used.<p>Trampolines can be used to bypass the call stack limitation. As an advanced technique, the majority of people having issues with a call stack problem will reconsider their solution before thinking about jumping on the trampoline.