begin  quoting Gabriel Sechan as of Fri, Jun 22, 2007 at 06:12:58PM -0500:
> >From: Andrew Lentvorski <[EMAIL PROTECTED]>
> >Gabriel Sechan wrote:
> >>If you have to get your head around it, by definition its not intuitive.
> >
> >Iteration is far from intuitive, IMO.  We are *taught* iteration far 
> >earlier.
>
> For a very large value of far earlier-  we're taught iteration in 
> childhood, because its a more real world way of looking at things.  Want to 
> wash all the dishes?  Well, wash dish 1, wash dish 2, wash dish 3, and so 
> on.  Humans seem to be hard wired to think in this way-  iterate over 
> objects.

I must be wired differently.

When I was told to "mow the yard" as a kid, I'd start by running the
mower once around the edge, and then I'd pick an arbitrary point on the
other side of the yard, and head off in that direction.

Now instead of one big area to mow, I had two small areas to mow.

So I'd do it again.

My parents informed me a couple of years ago that my approach to mowing
the yard bemused and amused the neighbors. I'd get the most interesting
patterns ('cuz I also waited until the grass (or wild onions, if it was
late summer) was good and long before mowing it). . .

Oddly enough, the concept I had the *most* difficulty grasping was the
idea of a tree -- "why is the root at the top and the leaves at the
bottom?" -- until someone finally showed me the recursive approach of
"walking the tree".

> >In addition, as I have pointed out.  "Recursion" isn't necessarily the win 
> >over iteration.  It's the existence of "foreach/map/apply/collect" in the 
> >language that is the big win.
>
> Foreach always seemed to me to be a form of iteration, not recursion.  And 

Um, that's his point, innit?

> for some reason I've never really liked map.  It might be due to me 
> associating it with perl though-  I almost always see it in perl, meaning 
> its usually written in perlese, including liberal use of $_ and other 
> cryptic variables.

I like Smalltalk's "do" message...  "aCollection do: aBlock".

% gst
st> #( 1 2 3 4 ) do: [ :x | x displayNl ]. nil. !
1
2
3
4
nil
st>

Of course, collections are pretty smart, too:

st> #( 1 2 3 4 ) reverse do: [ :x | x displayNl ]. nil. !
4
3
2
1
nil
st>

Of course, normally, you want to keep the results around, rather than
relying on side effects:

st> | a b c |
st> a := #( 1 2 3 4 ).
st> b := [ :v | v * v ].
st> c := a collect: b.
st> c printNl.
st> !
(1 4 9 16 )
Array new: 4 "<0xfac60700>"
st>

[snip]
> >IMO, it depends.  Certain algorithms lend themselves to iteration and 
> >certain algorithms lend themselves to recursion.

They're computationally equivalent, so what you can do in one you can do
in the other, given sufficient memory and time.

> >People who do "tree" algorithms iteratively often screw them up horribly.  
> >People who do multiple action "foreach" recursively often screw them up 
> >horribly.
> 
> Agreed.  I work with trees constantly in my current job (the service I 
> provide is basicly a graph data service).  When I work on hierarchial data, 
> I recurse.  When I'm given a list of nodes or edges, I iterate.  It just 
> feels more natural and easier to code in both cases.

Pick the one that seems more appropriate at the time. That's fine. :)

-- 
I still barely grasp generating functions.
Stewart Stremler

-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg

Reply via email to