Re: LOGO-L> Re: Computer Language for Kids ?

[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 - 11 Jul 1997 16:10:55 GMT
> >From - bh@anarres.CS.Berkeley.EDU (Brian Harvey)
> To - jcstclair@omsd
> Subject - Re: LOGO-L> Re: Computer Language for Kids ?
> Usenet: comp.lang.logo
> ------------------
> Post Usenet mail to comp-lang-logo@ucbvax.berkeley.edu
> ------------------
> 
> George Mills <mills@softronix.com> writes:
> >> 1.  Dynamically growing data structures (i.e., lists as opposed to arrays)
> >> as the primary aggregation method.
> >[...] But if you mean dynamically
> >growing data C/C++/Pascal have little problems with it.
> >Keep in mind what languages are used to write the Compilers and
> >Interpreters in !!!
> >
> >And again lists are available in any pointer based language they
> >just not the primary aggregation method. But like all the other
> >features there is a tradeoff in performance that some are willing to
> >pay and others are not.
> 
> Any programming language can do anything -- they are all Turing-equivalent.
> In CSLS I have a Pascal compiler written in Logo, and in many ways it's
> easier to write a compiler in Logo than in C.
>

But it would be too slow a compiler to be practical.

> 
> But the point is about the programming style that a language encourages.
> That's why I said "primary method"!  The great thing about lists, for a
> learner, is that you can't have overrun errors, like the ones that keep
> crashing systems written in C.
> 

That's the price we must pay to be efficient and the reasons for
all the strictness to help avoid these problems.

>
> As for efficiency, it depends what you're trying to do.  If you want to
> traverse the data in order, there really is little difference between
> lists and arrays.  If you want to jump around in the data, as in Quicksort,
> then arrays are faster.  If you want to insert in the middle, though,
> then lists are faster.
> 
> >Some feel that manipulation of a program as data is very dangerous.
> 
> What I meant here isn't clobbering the text of a program.  I mean the
> ability to create new procedures on the fly.  Here is a simple
> example from Scheme:
> 

I know what you meant and what you describe below is considered
dangerous by some. It's also incredibly powerful.

> (define (make-adder num)
>   (lambda (x) (+ x num))
> 
> This is a procedure whose return value is a procedure.  We can now say
> 
> (define plus4 (make-adder 4))
> 
> and then we can do things like
> 
> (plus4 5)
> 
> and get 9 as the answer.  It's a little tougher in Logo, because
> procedures aren't exactly first-class data.  You have to say
> 
> to make.adder :name :num
> define :name (list [x] (se [output :x +] :num))
> end
> 
> ? make.adder "plus4 4
> ? print plus4 5
> 9
> 
> But in C/Pascal/etc you can't do it at all.
>

In theory you can do it C/Pascal, but it's designed to not allow it.

> 
> > His game was great, but it requires a Pentium 133
> >to run reasonably. He wants to try to sell it but he will have to
> >rewrite it in C/C++ because Visual Basic is too slow. [...]
> >Because he chose the "Fast/Easy" path of the interpreted langauge
> >he's in big trouble.
> 
> It's worth noting that out in the real world, real programmers use Lisp
> as a "prototyping language."  That is, they first implement their
> program in Lisp, to do all the debugging and the design tweaking.
> Then, at the *end* of the development process, they rewrite it in C.
>

I agree this is done now and then but it is MUCH more common to
use Visual Basic for prototyping language than lisp today. Because the
user interface tends to take up 90% of the work and Visual Basic does
do user interfaces rather quickly.

Does anyone know of Lisp currently being used for prototyping in a
commerical environment? I had seen it once in my 20 years. And that
one usage was not a prototype but final code on an internal tool.

I admit just because I have not seen it much does not mean it's
being used a lot. But again visit the news groups and notice the
volume of messages.

> 
> It's also worth noting that there are Lisp compilers that produce
> executable programs that are as fast as, say, Java programs running
> on the Java virtual machine.  That's fast enough to satisfy many
> real-world users, even though it's not as fast as the best compiled
> C code.

Visual Basic is probably in this performance realm and often does
not cut it. I suspect that the money and energy will go into Java
to make it faster and easier.

Note that just about any program that has any reasonable lifetime
and which the user has to wait more than a couple seconds might
as well run as fast as it possibly can.

Please, don't get me wrong, I love Lisp and Logo and I wish I
knew Scheme and wish it was more accepted in practice. But it
just isn't and I've just given some of the reasons that are
commonly known as to why.

Keep in mind that working in other languages can be just as much
fun and exciting by working with the hand you are dealt and making
the best of it.

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