Iteration over recursion?

[Nick Maclaren]

In article <449846e0$0$4793$636a55ce at news.free.fr>,
Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr> writes:
|> Sudden Disruption a écrit :
|> 
|> Because I do like recursion, and would personnally prefer tail-recursion 
|> optimisation over nice tracebacks. But I'm not in position to decide 
|> anything here.

[ See below before you jump to conclusions :-) ]

If you have ever had to unpick a really nasty problem where tail recursion
removal has destroyed all evidence of how the program got there AND the
program was written so that it plain did not work without it (memory
exhaustion), you will have cursed the concept to hell and back again.
Been there - done that :-(

|> > Recursion was just an attempt to "unify" design approach by abstracting
|> > itteration and creating a new context.  It allowed the programmer to
|> > isolate himself from the reality that he was actually iterating.  Talk
|> > about mind fuck.

As someone who was in this area when the Algol versus Fortran wars were
being fought, that is almost entirely incorrect.  Recursion plus tail
removal AS A SUBSTITUTE FOR ITERATION is what you are describing, but
that came a decade after recursion became widespread in programming
languages.

|> Recursion is the most convenient way to express some common algorithms. 
|> Too bad for you if it does some nasty things to your mind.

Agreed.  Recursion should be used when it is the right technology to
clarify the code, and not as a gimmicky, obfuscatory and often dogmatic
substitute for iteration!  There are algorithms that become almost
incomprehensible without recursion, and I have implemented a recursion
layer in both assembler AND Fortran just to enable me to write them
without going bonkers.


Regards,
Nick Maclaren.