Hell yeah, brother. Functional programmers rise up.
Haven’t used a loop in almost a decade! It’s a nice life 😎
Hell yeah! Groovy programmer here, mapping closures over lists of objects.
As your compiler patiently turns it back into a loop.
mmyes
Unironically this. I know it’s the same assuming there’s no bugs (lol), but it’s just faster to type and easier to read, at least to me.
I always found map more confusing than loop for some reason. Especially nested.
To each their own.
Or sometimes fold them over trees of objects!
Objects? What is this OOP nonsense?
Immutable in order to protect against parallel code changing the size of the iterable?
Immutable because the only lists worth iterating over are the ones I define for myself.
Ah yes the X86 instruction set for mapping.
Everything is a conditional branch loop. Always has been.
There also isn’t a loop instruction though.
It’s a conditional branch… You make that into a loop. Branch if zero, branch if not zero, etc.
deleted by creator
I never looked into this, so I have some questions.
Isn’t the overhead of a new function every time going to slow it down? Like I know that LLVM has special instructions for Haskell-functions to reduce overhead, but there is still more overhead than with a branch, right? And if you don’t use Haskell, the overhead is pretty extensive, pushing all registers on the stack, calling new function, push buffer-overflow protection and eventual return and pop everything again. Plus all the other stuff (kinda language dependent).
I don’t understand what advantage is here, except for stuff where recursive makes sense due to being more dynamic.
They aren’t talking about using recursion instead of loops. They are talking about the map method for iterators. For each element yielded by the iterator, map applies a specified function/closure and collects the results in a new iterator (usually a list). This is a functional programming pattern that’s common in many languages including Python and Rust.
This pattern has no risk of stack overflow since each invocation of the function is completed before the next invocation. The construct does expand to some sort of loop during execution. The only possible overhead is a single function call within the loop (whereas you could have written it as the loop body). However, that won’t be a problem if the compiler can inline the function.
The fact that this is functional programming creates additional avenues to optimize the program. For example, a chain of maps (or other iterator adaptors) can be intelligently combined into a single loop. In practice, this pattern is as fast as hand written loops.