Re: LOGO-L> QUESTION ON CONDITIONAL OUTPUTS

[George Mills <mills@softronix.com>]

jstclair@omsd.cerf.fred.org wrote:
> 
> Please reply to bh@anarres.CS.Berkeley.EDU (Brian Harvey)  or
> logo-l@gsn.org   NOT   logo-list@gsn.org  or  me.
> 
>                         -John-
> --Message below re-posted by <jstclair@omsd.cerf.fred.org>
> Date - 21 Apr 1998 19:08:17 GMT
> >From - bh@anarres.CS.Berkeley.EDU (Brian Harvey)
> To - jcstclair@omsd
> Usenet: comp.lang.logo
> ------------------
> Post Usenet mail to comp-lang-logo@ucbvax.berkeley.edu
> ------------------
> 
> George Mills <mills@softronix.com> writes:
> >It always concerns me that folks feel fewer lines of code
> >is better. Avoiding sub expressions to clarify code
> >is NO advantage.
> 
> I don't think "fewer lines of code" is quite the issue.
> For me, the expression
>         (first :list1)+(first :list2)
> makes the meaning of the program clearer than
>         :a1 + :a2
> where I have to look back to find out what those variables have to do
> with the procedure's inputs.

This is trivial example and in either case it really does not matter.
But when sub expressions get more complex it is much easier
and less bug prone to break them out and assign them appropriate names.

For example if an equation used the distance between 2 points
sqrt(:x*:x+:y*:y) it would read much easier if it was assigned to
a variable called :distance rather than buried in the formula
within another complex formula.

If I eliminated every unnecessary intermediate variable when doing
the 3D enhancements I would of lost my mind. Naming sub expressions
is very powerful and useful. Like I said the ADDLISTS example, either
argument would be weak. I was just pointing that this bias in Logo
to minimizing MAKE and the number lines is not good and in the ADDLISTS
example provide no benefit.

This is quite similar to the math teachers argument "show your
work". So that the teacher can follow it and help correct where
the student went wrong. Sometimes when programming the teacher
(person reviewing the work to find a mistake) is yourself !!!

> 
> Having said that, I certainly wouldn't want anyone to feel that
> it's Bad or Wrong to use a different style!
> 
> >I also intentionally kept as much of his original
> >code in tact so he could more easily see the primary
> >difference.
> 
> And I agree with this, too -- in my own response to the original
> message, I wrote a minimally-changed version and *then* said
> "by the way, you don't really need those MAKEs" because I think
> that's also worth learning.
> 
> >I also think someone should tackle understanding list
> >manipulation (primarily a lesson in recursion) before
> >moving into high level list manipulation functions
> >such as MAP and friends. Excluding the turtle graphics
> >recursive list processing is the HEART of Logo.
> 
> I'm not sure I agree about this.  Recursion and higher order
> functions are two powerful techniques, both really important,
> both hard for beginners, and for similar reasons: they push
> people's understanding of what a function is, although in
> different ways.  My own experience is that for simple problems
> (such as this one, adding two vectors) the solution using
> higher order functions is an easier first step than the
> recursive solution, but I know that other teachers' experience
> goes the other way.
> 
> Recursion is a more general technique, so I don't envision any
> possibility that someone would learn to use higher order functions
> *instead* of recursion.  But MAP is awfully convenient, in a lot
> of situations!

I understand your point and agree MAP is very cool and worthwhile
to learn. I'm just saying recursion is a much more valuable a tool and
should have priority over MAP. We may have to agree to disagree on this
one. It won't be the first nor the last time I'm sure :-)

-- 
===============================================================
George Mills
email: mills@softronix.com
http://www.softronix.com
The www page contains some very powerful educational software.
Our single most important investment is our kids.
---------------------------------------------------------------
Please post messages to the Logo forum to logo-l@gsn.org.  Mail
questions about the list administration to logofdn@gsn.org.  To
unsubscribe send    unsubscribe logo-l    to majordomo@gsn.org.