🚀 go-pugleaf

rrogers@cs.washington.edu (Richard Rogers) writes:
>I absolutely HATE programming in Logo, even for trivial programs. I think it's
>syntax is horrid, and it's lack of control structures, data types/typing, and
>(real) local variables make it very painful to use.  Very poorly suited for
>systems programming.  Even if one could write such systems appplications in
>Logo without commiting suicide, I'd hate to see them run (crawl).

This list of complaints has to be taken apart; I have different feelings
about each of them.

Syntax:  This strikes me as an interesting research question.  One of the
reasons for designing Logo in the first place was to have "Lisp without
the parentheses"; it was thought that Lisp syntax would be too weird and
too difficult for kids.  When I first saw both languages I thought that was
very reasonable.  But now that I've done a lot of programming in both Lisp
and Logo, I find it much easier to read something like
	(se (word (bl 'hail) (bf 'cry))
	    (word (word (first 'elephant) (last 'tax))
		  (word (bf 'camp) (bl (bl 'less))) ))
than the same thing without the parentheses and forced onto one long line
without the indentation to help.  Perhaps Logo syntax is like the Mac:
great for getting you through the first day, but no growth path.  I haven't
made up my mind about this.

Control structures:  I always provide myself and my students with a Logo
startup file that defines MAP, FILTER, and several other higher-order
functions, as well as more traditional control structures like FOR and WHILE.
It's easy enough to do that.  I don't see this as a big issue.

Data types:  This is one of those religious issues that we're not going to
convince each other about, but I think you're totally crazy to complain about
that.  I can't stand programming in languages with typed variables!  Just
try writing a program that reads numbers from the user one at a time, adds
them up, and stops when the user types in "done" instead of a number.

Dynamic scope:  I take it that "(real) local variables" means that you
want lexical scope.  I have mixed feelings about this.  Scheme, with true
first-class functions, gets a lot of mileage out of lexical scope because
it can have, without extra effort, local state variables and therefore an
easy implementation of object-oriented programming.  I wouldn't have Scheme
any other way.  But in Logo, lexical scope would just be a restriction.
(That is, the variables available to a given procedure under lexical scope
would be a subset of the variables available to it with dynamic scope.)
The difference is that a Logo procedure can't return another procedure
as its value -- Logo doesn't have lambda -- so it can't create closures.
And Logo gets two benefits from dynamic scope.  One is the ability to use
first-class expressions; you can write control structures like WHILE in
Logo, and the WHILE procedure can RUN an expression that was given to it
as input by its caller.  Even more important, debugging in Logo is much
easier than debugging in Scheme because you can have pause-on-error and you
get an environment with all the relevant variables accessible for inspection
at once.  In Scheme you end up having to learn some hairy non-Scheme extra
debugging language with commands like "move forward one stack frame."

In fact, dynamic scope is the main reason why I *don't* advocate forgetting
about Logo and just teaching kids Scheme.  I'd use Scheme (in fact, I *do*
use Scheme!) to teach college students computer science, but I like Logo
for younger kids because the use of dynamic scope postpones having to think
about some hairy issues.