Live data from Hacker News

All About Recursion and Tail Calls in JavaScript

lucasfcosta.com

21–22 of 22 posts

Re: All About Recursion and Tail Calls in JavaScript

#21
post #15

What I don't understand with STCs is, how would I, as a developer, decide when to use them and when not? As program correctness is concerned, tail calls and recursive calls should behave exactly the same (except stack use), so going by correctness alone, either the choice doesn't matter at all or tail calls are preferable. So the logical thing to do would be to always use tail calls. The post goes on to list a number…

You absolutely should have knowledge of your target platform and whether it does TCO (and whether it kicks in for your code). Otherwise, you may decide to just use recursion everywhere and then your stack overflows when your N is bigger than expected. When in doubt, don't use recursion and don't expect that you get TCO.

> You absolutely should have knowledge of your target platform and whether it does TCO

If I write web apps, as far as I'm concerned, my platform is V8, Whatevermonkey, Trident and every other hypothetical​ javascript engine out there, any of which might or might not support TCO under different circumstances.

> When in doubt, don't use recursion and don't expect that you get TCO.

I think relying on TCO is always a bad idea, exactly because you can't be sure your platform supports it. But STC doesn't change that. You can't expect the platform to support tail calls because you did some magic incantations.

On the other hand, it doesn't make sense to me to forbid tail calls either. If you know your recursive code will work without TCO, it will work with TCO, too.

Re: All About Recursion and Tail Calls in JavaScript

#22
post #19

Earlier quoted context omitted.

But then you are looking at the wrong thing: You are no logger profiling/debugging Javascript but the Javascript runtime. Those tools do tell you the Javascript part, why do you say "superficial"? Example (memory profiling with heap snapshots): https://developers.google.com/web/tools/chrome-devtools/memo... Profiling functions (V8, Chrome, using the CPU Profiler): https://developers.google.com/web/tools/chrome-devtoo…

Superficial as in all I want is the two numbers to be printed out at the end. Why do I have to go look at flame charts and timelines? Boggles the mind. If you look at the documentation of what I am actually interested it is time-timeEnd or profile-profileEnd. With profile end I just don't get output on console and have to jump back and forth between these views looking at a ton of crap I am not interested in. With ti…

> With timeEnd I get the number I want but would like to see a "safe" approved way of where to place the timeend while dealing with async/promises/recursion separately and together.

Measuring asynchronous code? You are not measuring your code. Your code is only the synchronous parts, the time spent in asynchronous parts are "environmental factors". Your code doesn't run during those times, it sits in the event loop waiting for an event so that it can continue.

Post reply on HN