Causes of stack overflow in recursive functions

Question

In this video around the 28 minute mark, Brian Harvey was asked by a student if we should always use an iterative process over a recursive process when writing programs. He said no, because

Your programs are not gonna run into space limitations. And in terms of locality of what's in memory, you have to have a lot more control than you do over the way the program is interpreted to really affect that.

Since this is not a scheme course I assumed he is talking generally here about programming languages. And when he said ""Your programs are not gonna run into space limitations.", is he disregarding stack overflows? I am confused by his answer because isn't having a stack overflow means you already ran out of space with function calls? And I don't understand anything from the "in terms of locality" part. stack overflows can happen to scheme, java and other languages. Am I correct or I'm misunderstanding his statement?

Answer 1

The video you are referring to is a Computer Science lecture. Computer Science is largely theoretical and addresses many details of computing that are not relevant in practicality. In this case, as he says towards the start of the lecture, today's computers are large and fast enough that performance is rarely an issue.

---

Memory locality is not related to StackOverflowExceptions, in any language. Actually, memory locality refers to the SRAM (static RAM), which holds a cache of adjacent data brought in whenever the bus retrieves data from memory (can be either the disk or RAM). Taking data from this cache is faster than getting it from memory, so a program will run faster if all the data it needs for several, consecutive operations is within the cache.

---

Now that's all very low-level. Behind most (if not all) modern languages, like Java, there is a compiler working to do numerous low-level optimizations. This means, first of all, that there's little you can do to optimize your code for at a low-level, especially without interfering with compiler optimizations. Secondly, (like as he says right after the segment you're referring to) unless you are a making a resource-intensive game, it is not worth your time to worry about performance (unless you have noticeable performance issues, but that's more likely an indication of other problems in the code).