Isnt this a CPU optimisation thing, ie code & languages working better for some instruction sets than others?
One of the languages I've used in the past always performed best on certain AMD cpu's, but that was when we could choose what cpu the compiler was to optimise for, ie 286, 386 etc etc.
I'm also aware of backroom shenanigans going on with some languages and tools working better for some CPU's.
Tail call optimization has nothing to do with optimizing for different CPUs, it's about dropping a function's stack frame when it's evaluating its return expression and its stack frame isn't needed anymore.
In a language implementation that doesn't optimize tail calls, the stack would look like the following after the call to g:
g
f
main
In a language implementation that does optimize tail calls, the stack would look like this, because the result of f is whatever the result of g is so f is no longer needed:
g
main
If a language implementation doesn't optimize recursive tail calls, the following code will quickly overflow the stack and the program will crash:
def loop() =
do something...
loop()
In a language implementation that does optimize recursive tail calls, this code can run forever because loop's stack frame gets replaced with the stack frame of the new call to loop.
The reason people want recursive tail calls optimized out is at a much higher level than anything to do with the actual CPU instructions being used, they just want to have a way to write recursive functions without worrying about the stack overflowing.
I have never seen this referred to anything other than things like tail-call recursion, tail-call optimization, etc.
Languages like Python make implementing simple loops like:
def loop():
<whatever>
loop()
impossible.
Python will reach a maximum recursion depth and error.
Why is this important? Like I said, it makes looping very easy. For example, actors can almost be trivially implementing in languages with tail-call recursion.
It’s not in Python because like most things in Python, van Rossum doesn’t like it because <reasons>.
There’s little point in having full traces of the data doing in and out of the tail-call loop is immutable, so you only really care about the current call of the function.
Yes, the different terminology is a reflection of the entrance of so many new entrants going for what is easy in the short term, instead of learning the theory of their industry and thus learning better approaches that are not 'immediately' obvious.
This lack of learning theory in our industry, instead going for something that is 'easy to get started' explains the popularity of python and javascript, and at the same time why python and javascript are littered with problems that have already been solved, and cluttering up the field of knowledge by reinventing terminology because they never learned the original existing terms.
One of the languages I've used in the past always performed best on certain AMD cpu's, but that was when we could choose what cpu the compiler was to optimise for, ie 286, 386 etc etc.
I'm also aware of backroom shenanigans going on with some languages and tools working better for some CPU's.
This 12 year old post goes into a lot of detail https://stackoverflow.com/questions/1414911/intel-x86-assemb...