Re: LOGO-L>GUIs versus functions (was: input of numbers)

[George Mills <mills@softronix.com>]

Some reasons behind GUIs:

1) You can present your problem in a naturally readable manner.
   The cursor control you like so much *IS* one of the earliest
   forms of a GUI. The Mouse has replaced the Arrow keys,
   Tab and Backspace keys.

2) A GUI can carry a user through a problem with explanations,
   can force order, or be free from order, point out problem
   inputs more directly.

3) A GUI allows the control inputs to be placed near the
   resulting solution which may, and often is, in Logo
   a graphical result.

4) GUIs (Slide Bars etc.) allows a wide range of inputs to vary
   quickly. For example if you were doing something like a
   trajectory problem you could have scroll bars for the
   mass, initial force etc. rather than calling a function
   with arguments. A user can more quickly associate the behavior
   of the inputs on the result. They may even notice exponential
   behaviors, oscillations or patterns etc.

In my opinion you described a debugging/development technique
not a method of communicating with possibly a non programmer
user of the program under development. Passing arguments to
functions vs GUIs are apples and oranges.

A GUI does not prevent anyone from directly calling a function
to test its behavior. And it's very likely the user that asked
how to do the GUI work may of had the function you mention
done and now wants to add a GUI to polish it up for his
users.

Writing GUIs can be fun and does take time.
MSWLogo's methods are pretty basic and tedious to use.
But the goal was to expose young programmers to
what's involved with building a GUI. A GUI to build
GUI's would make it much more proficient. Now perhaps
if I learned GUIs at a younger age it would not take
me so long.

I agree we see little hard-core number crunching here.
But we also have to keep young students in the Logo
seat with enthusiasm for as long as possible. When students
see they can great GUIs then they become curious. If all
they see is text in and text out they get bored and
go play nintendo. It's the turtle graphics that kept
students interested with Logo (not the language). But with the
flood of GUI's, 3d graphics games etc. kids look at logo and say
wow, gee that's cool (in low mumbling voice). Number crunching
will come in time (when they get teachers like you in college)
but meanwhile they will be learning quite a bit.

This is exactly why I did 3D and 3D shading. Now they
will ask how can I do that.

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 - 30 Aug 1998 16:19:36 GMT
> >From - bh@anarres.CS.Berkeley.EDU (Brian Harvey)
> To - jcstclair@omsd
> Subject - GUIs versus functions (was: input of numbers)
> Usenet: comp.lang.logo
> ------------------
> Post Usenet mail to comp-lang-logo@ucbvax.berkeley.edu
> ------------------
> 
> Immot5@aol.com writes:
> |>now the point to this is we wish to input a coupleof numbers into a
> |>proceedure, like in
> |>      v = u + at
> |>where we need a value for u, a and t to work out v (velocity)
> |>so we need to be able to enter three numbers, click on a button, and
> |>retrieve a result
> |
> |to velocity
> |windowcreate "main "velocity [Velocity Calculator] 150 100 150 65
> |[staticcreate "velocity "equation [V=] 10 20 10 20]
> |comboboxcreate "velocity "u 20 17 20 10
> |comboboxsettext "u [U]
> |staticcreate "velocity "plus [+] 41 20 10 10
> | [... several lines omitted ...]
> |to calculate
> |make "u2 first comboboxgettext "u
> |make "a2 first comboboxgettext "a
> |make "t2 first comboboxgettext "t
> |make "product :a2 * :t2
> |make "total :product + :u2
> |staticupdate "answer (sentence [Answer =] :total)
> | [... etc. ...]
> 
> I know this is an old argument, and I know I'm in the minority on this,
> but I'm still having trouble convincing myself that this approach is
> better than the traditional Logo solution:
> 
>         to velocity :u :a :t
>         output :u + :a * :t
>         end
> 
> Here are the advantages of this version:
> 
> 1.  It focuses the learner's attention on the physics, rather than on
> side issues such as screen layout.  This applies both to the writer of
> the program and to anyone who reads or uses it.
> 
> 2.  It teaches the crucial idea of a *function*, making explicit the
> relationship between certain input values and the resulting output.
> By contrast, the fancy-gui procedures are not functions.
> 
> 3.  Because this procedure represents a function, it can be used not only
> in a direct user request, as in
> 
>         ? print velocity 0 -32 10
> 
> but also in a composition of functions, to contribute to solving a larger
> problem.  For example, let's say we want to learn what the object's position
> will be at some time T.  We can take finite sums of the VELOCITY function:
> 
>         to position :start.pos :start.vel :accel :time
>         localmake "pos :start.pos
>         for [t 0 :time 0.01] [make "pos :pos + (velocity :start.vel :accel :t)]
>         output :pos
>         end
> 
> approximating the integral of the velocity by measuring every hundredth
> of a second.  The expression in parentheses two lines from the bottom
> uses the same VELOCITY function that you use to make a direct calculation
> of a particular velocity.
> 
> ----------------
> 
> We can take this further.   Of the three arguments to VELOCITY, the first
> two are parameters that remain constant in any particular problem (given that
> we are studying motion under constant acceleration) while the third, time, is
> the one that actually varies during the problem.  The functional approach lets
> us create velocity functions for a particular situation:
> 
>         to velocity.function :start.vel :accel
>         output `[,[:start.vel] + ,[:accel] * ?]
>         end
> 
>         ? show velocity.function 200 -32
>         [200 + -32 * ?]
> 
> Then we can write a general-purpose finite integration procedure that
> works for any function:
> 
>         to integrate :func :start.x :end.x
>         localmake "result 0
>         localmake "deltax (:end.x - :start.x)/1000
>         for [x :start.x :end.x :deltax] ~
>             [make "result :result + (invoke :func :x)]
>         output :result
>         end
> 
>         to position :start.pos :start.vel :accel :time
>         output :start.pos + integrate (velocity.function :start.vel :accel) ~
>                                       0 :time
>         end
> 
> It's not that you *can't* do this sort of investigation and also draw fancy
> GUIs on the screen, but the GUI absorbs so much effort that I think it's
> less likely.  (And it'll never happen if you get in the habit of always
> writing procedures without inputs.)
> 
> P.S.  I don't mean to attack the work of the people who posed and solved
> the original question!  It's a reasonable question in its context; what
> I want to question is that context -- the whole post-Macintosh approach
> to computing.

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