🚀 go-pugleaf

smith@sctc.com (Rick Smith) writes:
>I suspect the "right" way to teach programming is to start with
>recursion as the essential iterative technique, and then teach
>how to convert from recursive to iterative as an engineering task.

Not to beat a dead horse, but I really think the alleged dangers of recursion
are overstated.  It may be a problem if you're programming on an 8086 that's
limited to 64K of stack space, but on any real computer, if you have a memory
problem you probably also have an even bigger problem about execution time.

To a first approximation all algorithms are either like searching or like sorting.
If your algorithm is like searching, and you're running out of stack, you're using
a linear algorithm.  If you switch to a log-N algorithm, you'll have plenty of
stack space, unless the size of your problem is very different from what most of
us face.  If your algorithm is like sorting, then you'd better be using a
divide-and-conquer method, in which case you need the stack space whether you
like it or not.  You can go to a lot of trouble to use non-recursive control
structures, but only by building your own data stack by hand, and that won't
help with the space issues.

If you describe recursively an algorithm that's really a loop, then your C
compiler will implement it iteratively.  (You *are* using gcc, aren't you?)
If not, then the technique of recursion elimination will still require a
stack, and not much is saved.

I do agree with the part of the message that says that programmers have
to be trained to learn to think recursively.  That's why colleges should
use Abelson and Sussman as their intro programming course, and high
schools should use Logo!  :-)