You must be in quite the functional bubble (I envy you for that, though)

Actually, I've recently watched a talk by Guy Steele where he makes a case for tail call elimination being essential for object orientation: <https://www.youtube.com/watch?v=0hlBkQ5DjaY>. He demonstrates how tail call elimination enables better separation of concerns, allowing you to write code where objects don't need to "peek" into one another.

Another non-functional application of tail call elimination is finite state machines. Writing them as functions calling the next state in tail call position is very elegant, legible and efficient.

ES6 used to require tail call elimination, and it was even shipped by Safari and Chrome back in 2016.

Were it not for Firefox and Edge teams who torpedoed that feature, it would be a part of the major language of today.

Maybe it still will be.

Just Ruby...

I use Python plenty, just not in large enough doses that I have to actually make peace with it.

Lack of TCO is a JVM problem. All JVM languages are incapable for this reason. It's a very hard problem to fix apparently, I remember even asking one of the Sun JVM developers at a talk at my university and he said one of the issues was the Java security model and stack ownership IIRC. This was a long time ago though so I may be incorrect. The problem remains hard though.

Neither PyTorch nor Julia run on the JVM.

A true scotsman rolls their own callstack.

I've never seen recursive looping over a thing get turned into efficient SIMD code in any language. Starting with loops has no good reason to be better able to achieve that but for practical compilers it makes a huge difference.

Julia code might also uses a lot of in place operations which would be hard for a compiler to infer as safe.

> I've never seen recursive looping over a thing get turned into efficient SIMD code in any language. Starting with loops has no good reason to be better able to achieve that but for practical compilers it makes a huge difference.

Well, for example at the very least in Common Lisp you'll have much more joy with higher-order functions than with loops. The simple reason for that is the existence of compiler macros (http://clhs.lisp.se/Body/03_bba.htm) which can replace function compositions with arbitrary code. And it's much easier to figure out what the function composition does than to write a loop vectorizer.

Maybe loops are not fun in common lisp the? I had much fun with loops in PicoLisp.

Julia also has similar macro capabilities to common lisp.

> And it's much easier to figure out what the function composition does than to write a loop vectorizer

I probably agree but complicated loop vectorisation would probably expressed in Einstein tensor contraction notation such as Tullio.jl provides. I wonder a Fourier transform would look using function decomposition.

@tullio F[k] := S[x] * exp(-impi/8 (k-1) * x) (k ∈ axes(S,1))

Loops are a lot of fun in Common Lisp, what with LOOP (https://gigamonkeys.com/book/loop-for-black-belts.html), ITERATE (https://common-lisp.net/project/iterate/doc/Don_0027t-Loop-I...), and FOR (https://shinmera.github.io/for/). But their fundamental problem of trying to extract a "bird's eye view" of what you're actually trying to do remains here.

Maybe a new iteration construct specifically supporting parallelization would help here. Some of these things might already work quite well, for example it should not be difficult to discern from (let me use ITERATE's example)

    (iterate (for el in list)
             (finding el minimizing (length el)))

that you're computing argmin using a pure function, which should be easy to do in parallel, whereas the way you'd typically write this in C would be probably difficult for the compiler to confirm as such (it would have to look for pattern such as "if (f(current)<f(best)) { best=current; }" or something like that. (BTW have you seen another loop construct supporting argmin/argmax in another language? I haven't so far.) Whether this could be done somewhat generally and extensibly is something I have to ponder on.

And functional paradigms have a way to express looping over a thing that's much better than recursion: filter / map / reduce.

This is why I find it so annoying that CS programs seem to worship functional programming (at least MY program did!).

No, I AM going to write procedural code, and it WILL be faster than your "high IQ" 1 line recursive solution. Also funny to see how little recursion gets used in CUDA/Pytorch/GPU programming - which is what we are seeing to be more and more important over time.

Functional programming is a lot more than just recursion and there's nothing about GPUs that precludes an immutable first array based language with functional programming as core. Google Research's Dex is an example.

Speaking of functional programming and GPU's - check out Futhark :D. Very on the fringe but very interesting.

Tail calls and while loops are essentially equivalent, so why care whether a language prefers one or the other?

They're not "essentially equivalent". A while loop can't begin in one module and end in another. A tail call sequence can. Loops are not modular.

Just to be clear, are you suggesting mutual recursion across modules?

Just to be clear, I'm using the word "module" here in an extremely generic, language independent way. Basically in the sense of "things that can be compiled individually". In many languages (for example in Lisp), those are functions. A syntactic loop construct ordinarily can't even cross a function boundary.

If your language of choice features formalized modules in the Modula-2 sense, its loops most likely can't span multiple functions even within a single Modula-2-sense module, even if you wanted that (for example, in a state machine with named states as functions which tail-call each other to switch state by transferring control, or something like that).

Why is that unreasonable? I might be missing something (I have no formal CS education), but I can imagine it, e.g. a base graph datastructure library, and then two libraries dependent on the base library being used together for some graph traversal work (where callbacks are used).

It's like, why use one synonym and not the other? Sometimes it's because writing things in an immutable manner makes things clearer. Other code that can benefit are certain coroutines and generators.

> It's like, why use one synonym and not the other? Sometimes it's because writing things in an immutable manner makes things clearer.

That's true in many situations, but in this case the equivalence between the two is so straightforward that I can't see recursion gaining you any clarity. Perhaps you have a concrete example?

I can't think of a specific example but I do know that there have been times where I have chosen to write a loop as tail recursion and times where I have used mutable variables and a while loop. Why one or the other might be recursion better capturing intent, preferring immutability, efficiency or just a matter of taste.

Sometimes it makes more sense and is more flexible to package functionality as a recursive function, then mutation and variables feel like clutter. Other sometimes using recursion instead of a loop gains nothing expressively. Or sometimes structural recursion + pattern matching is the much more elegant approach in terms of communicating and capturing the essence of the algorithm.

Because if you like functional programming, then avoiding loops and imperative code is desirable. Some of us hate seeing `for` and `while` because they also imply mutation of variables. Recursion is beautiful.

it's fairly easy to just write a macro to do tailrec in julia at least; https://github.com/TakekazuKATO/TailRec.jl

if you want tail calls in Julia, there is a 3 line macro that gives it to you.

Could you point to it? Thanks

Here is one:

https://github.com/TakekazuKATO/TailRec.jl

It works by inspecting the code and rewriting a function to turn tail calls into loops.

The interesting bit is that it was very easy to write because of the strong macros in Julia.

This is eye opening. I might take a look at this in depth and try Julia again.

This repo should interest you https://github.com/TakekazuKATO/TailRec.jl

Real world code rarely uses recursion, and if it does it's the kind that doesn't allow tail call optimization.

I've been using FP strategies for around thirty years, so pardon me if I don't find confidence in your perspective.

Your case is covered by the "rarely" word in my comment.