News:

And we're back!

Main Menu

Computer Programmers, to me!

Started by merithyn, May 13, 2013, 05:47:06 PM

Previous topic - Next topic

frunk

I use recursion when I need to.  It's definitely a case where there are good applications for it and bad, and the wisdom is knowing the difference.

Berkut

I think the issue is that there really aren't cases where one "needs to" use recursion. You go over the canonical examples in CS classes, but mostly anything you can do with recursion you can do with a iterative loop, and for real world applications, most of the time the iterative loop is going to be a lot clearer to code/debug/understand. Recursion is easy to understand if the problem is simple, but extremely difficult to understand when the problem is complex and it is someone else's solution, and since code maintainability is generally vastly more important than code elegance in almost every typical application, there is generally very little reason to use recursion outside very fundamental examples that are well understood (like sorting algorithms and such).
"If you think this has a happy ending, then you haven't been paying attention."

select * from users where clue > 0
0 rows returned

ulmont

Quote from: Berkut on May 14, 2013, 10:38:13 AM
I think the issue is that there really aren't cases where one "needs to" use recursion. You go over the canonical examples in CS classes, but mostly anything you can do with recursion you can do with a iterative loop

Not "mostly."  Anything.
http://stackoverflow.com/questions/931762/can-every-recursion-be-converted-into-iteration

DontSayBanana

Quote from: Berkut on May 14, 2013, 10:38:13 AM
most of the time the iterative loop is going to be a lot clearer to code/debug/understand. Recursion is easy to understand if the problem is simple, but extremely difficult to understand when the problem is complex and it is someone else's solution

Nail on the head.  Recursion's so unfamiliar to many developers that even ones who can eyeball what an iteration loop is doing need to manually trace recursive calls.

Also, seconded to what Ulmont said.  By definition, when you've got a stopping case, there is a finite number of iterations of repeat.  Unending loops can be a problem, but an iteration loop can generally be given a much vaguer stopping case.

Biggest problem I see with most developers shying away from recursion is that newer developers end up making way too many of their functions void-typed in strongly-typed languages.  Forcing a strict return type makes code a lot more predictable and really discourages the developer from sloppy, over-connected functions.
Experience bij!

frunk

In general I don't find recursive code difficult to understand, and I'm surprised that that's considered generally true.  Well written recursion isn't any more difficult to understand than an iterative loop.

Valmy

Quote from: frunk on May 14, 2013, 11:10:08 AM
In general I don't find recursive code difficult to understand, and I'm surprised that that's considered generally true.  Well written recursion isn't any more difficult to understand than an iterative loop.

Man it was like voodoo the first couple times.  I get it now but iterative loops were alot more intuitive.
Quote"This is a Russian warship. I propose you lay down arms and surrender to avoid bloodshed & unnecessary victims. Otherwise, you'll be bombed."

Zmiinyi defenders: "Russian warship, go fuck yourself."

Berkut

Recursion becomes difficult to debug and undertand when it is tied into complex code. Throw in persistent object refreshes, maybe some data dumps out to integration sources, even some asynchronous data manipulation and recursion can become nightmarishly difficult to debug.

And lets not even begin talk about mixing recursion with multi-threaded applications.

There is a good reason it is simply not done in most real environments. It simply is not worth it - the cost/benefit is just not there.
"If you think this has a happy ending, then you haven't been paying attention."

select * from users where clue > 0
0 rows returned

frunk

Quote from: Berkut on May 14, 2013, 11:45:13 AM
Recursion becomes difficult to debug and undertand when it is tied into complex code. Throw in persistent object refreshes, maybe some data dumps out to integration sources, even some asynchronous data manipulation and recursion can become nightmarishly difficult to debug.

And lets not even begin talk about mixing recursion with multi-threaded applications.

There is a good reason it is simply not done in most real environments. It simply is not worth it - the cost/benefit is just not there.

Those are situations where an iterative loop or recursion are going to be difficult to debug.  In both cases you have state changing outside the process and unless you can step through it (or have plenty of debug statements) you don't know what is going on exactly at each iteration/recursion.

Iormlund

Recursion has its place in the real world. It's called a functional language.

It is one of the things that makes Erlang my favorite language. Everything is done via map/fold and recursion. I've got apps thousands of lines long without a single while/for loop.  Also, concurrency follows the actor-message model, which makes it a breeze to deal with.

And no, it's not hard to read at all. Once you make the switch, it's just another way of programming.