In article <[EMAIL PROTECTED]>, Bruno Desthuilliers <[EMAIL PROTECTED]> 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.
-- http://mail.python.org/mailman/listinfo/python-list
