🚀 go-pugleaf

In article <15omhaINNgvr@agate.berkeley.edu> bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
>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).
>

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

I hate Lisp for the same reasons :-)  Prolog is sort of interesting, but it's
an expert system, not a programming language.  Granted prefix is better, but
I was taught in infix, so doing prefix requires extra effort.

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

Hmmm.  I don't knkow how to do that.  It's been awhile since I've done any Logo
programming, or perhaps the versions of Logo I was using don't provide for it.
I had to fake repeat loops by putting the loop body into a separate procedure
and have it return a boolean.  In any case, Logo is missing control structures
which I feel are basic enough that they should be part of the standard language
rather than requiring extra work to implement yourself.

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

I can't live without strong typing :-)  And while the list is a very useful and
flexible data structure, IT'S NOT THE ONLY ONE!!!  I hate having to kludge data
into lists for Logo and Lisp when other data structures would be much better
suited to the problem.

sum = 0
repeat
   write ("Enter a number or done:")
   readstring (s)
   if string <> "done" then
      sum = sum + stringtonum (s)
   endif
until s = "done"

StringToNum is usually provided as a library function.  If not, it's easy to
write.  It is the responsibility of strongly typed languages to provide safe
ways to get from one type to another.

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

I find it more difficult to debug dynamically scoped languages.

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

It just trades them for other hairy issues.  I like C's scoping rules.  (And
that's the ONLY thing I like about C!!!)  Variables are either global or local
to the procedure - simple.  It also encourages the good practise of passing 
things the procedure needs to it as parameters.