🚀 go-pugleaf

I wrote:

>>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.

And matt@volga.Berkeley.EDU (Matt Wright) writes:

>You mean, start with recursion as the essential iterative (and
>non-iterative) technique, and then teach how to do tail-recursion
>elimination when you take a compiler construction class in college.  :-)

Pretty much, but it's not enough just to deal with tail recursion.  If
people are using recursion as casually as Fortran coders use DO, then
they'll be producing lots of functions that don't convert directly
into tail recursion. Thus, they need to learn how to move the stuff
off of the stack (where it goes in recursion) and into data structures
with defined limits. A good example is, in fact, what gets taught in
some compiler classes: how to implement recursive functions for
parsing by using production rules, grammars, and such.

Most problem solving that people routinely do shouldn't require the
level of engineering required to convert recursion into interation.
You only need to do it if you're in a situation where you're worried
about reliability in the face of an uncontrolled range of potential
inputs. People writing computational expressions for spreadsheets, for
example, should do fine just with recursion and good stuff like MAP. I
always wanted to see a good spreadsheet or DBMS with a MAP function.

Rick.

p.s. to the original poster: isn't it great how much commentary the
     "maybe a silly question" produced, and at such a level?