@patrickmeyer2598
In C, C++, and Rust, loops often compile into extremely well-optimized and vectorized assembly that is often impossible to improve upon. I'll stick with my loops.
@anlumo1
This is a dangerous video for people who didn't already know all of this. It feels like it's targeted towards new programmers, but leaves out so many important details that if somebody would follow it to the letter it would lead to unusable code.
@wlcrutch
Recursion is often far less efficient than loops. And many recursive functions will be optimized into loops by the compiler. Loops are also usually far more straight forward to read. So yeah, i’m going to stick with loops. Unless the data structure lends itself nicely to recursion, eg, Trees.
@heliumhydride
Most common languages will perform better on loops than using recursion. EDIT: Woah that's a lot of likes!
@sudoCompetence
Recursion is for specific use cases, not a drop in replacement for loops. Recursion often obfuscates the control flow of the program, makes memory management difficulty, but most importantly recursion is almost always slower than the alternative.
@Cammymoop
If you ever run into issues using recursion, try using recursion to solve them
@TheAmzngAids
I don't know why it's so difficult to just say use the right tool for the job. "I'll trade readable and safe code for performance any day of the week." What a quote. Firstly performance, safety and readability are not mutually exclusive, and what a perfect encapsulation of the difference between a developer and an engineer.
@tri99er_
This doesn't explain, why we shouldn't use loops, if the safety is guaranteed (like Rust's for loop with collections). It's not bad for performance either, since loops are often unrolled and don't overload stack like recursion. They are also much more readable usually, since recursion can be pretty tricky to grasp, even if you're familiar with concept.
@jolynele2587
haskell is the only language i trust enough with recursion, because fn programming looks like maths to me
@Jol_CodeWizard
"Never write another loop again" Newbie, do not tell me what I have to do.
@MagicGonads
One thing to note is that we have to distinguish between two kinds of 'iteration': 1. Iteration that only makes use of O(1) local variables (as extra memory) 2. Iteration that makes use of at least some O(n) data structure (as extra memory) And these correspond exactly to two kinds of 'recursion': 1. Recursion that meets the requirements of tail call optimisation (TCO) - called 'primitive recursion' 2. Recursion that has some components that do not meet said requirements - called 'non-primitive recursion' The simplest function of type '2.' is called the Ackermann function, and it's ridiculously complex This means that theoretically for most cases we do not need stacks (or queues), and we do not need stack frames. But practically it requires a great deal of thinking on the behalf of the programmer to turn something that is seemingly in type '2.' into one clearly of type '1.'. This is related to the Curry-Howard-Lambek correspondence, and further we can understand that for every problem there is a higher order function that deals with it, because we can interpret any 'container' as a 'functor'. So we can also categorise containers (data structures) corresponding to these two types: 1. Containers that can be traversed (with their correct topology/semantics) without use of a stack or queue / non-primitive recursion, e.g. arrays 2. Containers that can only be traversed (with their correct topology/semantics) with use of a stack or queue / non-primitive recursion, e.g. trees Also, 'nicer' (more 'optimisable'/'parallelisable') higher order functions correspond to containers that can be interpreted as 'monads' (monoids and semigroups) not merely functors.
@yaksher
@9:00 It's worth noting since the example of a language which uses fold instead of reduce that Rust has both fold and reduce and they are distinct operations. Reduce on an iterator if items of type T takes a single argument, a function, Fn(T, T) -> T, and evaluates to a value of type Option<T> (where it's none if the iterator is empty). Fold, on the other hand, takes two arguments: an initial value (of type U) and a function Fn(U, T) -> U, and evaluates to a value of type U. So if you have an array of integers, for example, you can reduce it to an integer, but you could fold it into, for example, a set of integers or whatever.
@ShadowKestrel
stack frames on their way to inhale all your memory rn especially in embedded
@wscamel226
1:56 - and I dont wanna watch this video anymore
@alexander53
9:44 I found this loop version version much easier to read here. You can literally read out the intent word for word "for each course in the list of course", "for each student in the course", etc. I can see some cases where map, filter, etc would be more readable however, but this may not have been the best example
@snk-js
I can say that recursion is really better when solving recursion patterns like tree operations, because it has a lot more chance to get stack overflow due to the depth of calls been too high
@grillpig3860
I still don't understand why you would use recursion instead of loops. I mean loops are the most basic and understandable thing in Programming in general imo. Also there's no need for a compiler to optimise anything that way. Try using recursion on a microcontler, it's gonna go up in flames.
@judewestburner
It doesn't matter what you do in programming there will always be a person on YouTube telling you not to do it
@branmuller
functional programmers love to talk about functional programming until its time to build scalable production apps
@matiasthiele770