LOGO-L> Re: LOGO language design - Was: predicate writing 
Author Message
 LOGO-L> Re: LOGO language design - Was: predicate writing

Hi Brian,
Please could you elaborate on a few of your points made. I lack the compiler
design knowledge to appreciate your interesting analysis of LOGO design
issues:

1) What is LAMBDA and what is a "first class procedure"?

2)What are "Dynamic" and "Lexical" scopes?

3)What is the advantage of LCSI's 3 + 4 vs. 3+4 and what is "tokenization"?

Thank you for all your valuable contributions to this list.
Regards
Ray Catzel

Quote:
-----Original Message-----

Brian Harvey
Sent: Thursday, November 11, 1999 10:28 PM

Subject: LOGO-L> Re: LOGO language design - Was: predicate writing

Here's my list of design issues:

1.  No first class procedures -- no LAMBDA.  This is a clear weakness of
Logo.
We can usually work around it because in a dynamically scoped language you
can use the text of a procedure as equivalent to the procedure itself, but
the notation gets messy.

2.  Dynamic vs. lexical scope.  I still think Logo made the right choice
here, for its purposes, but we still have arguments about it.

3.  Separate procedure namespace.  This is related to #1, but a little
different.  Basically, we pay a heavy syntactic price for being able to
use LIST and WORD as formal parameters, namely all those colons.  I'm not
sure what's the right thing.

4.  Tokenization.  I hate having to say "2 + 3" instead of "2+3" in current
LCSI products.  It's really annoying.  But the available alternatives aren't
perfect either.  Berkeley Logo really tries hard to "do the right thing"
about this, but the rules are awfully complicated if you really try to
understand them.

5.  Special forms.  We were just discussing this -- someone wanted to
duplicate in MSWLogo the behavior of PC Logo's ERASE, EDIT, etc., and you
can't, because we don't provide special forms.  There are arguments on
both sides of this one; having special forms means that absolute beginners
don't get caught on missing quotation marks, but also that you can't
easily extend the power of the language in workspace management by using
lists of procedure names as a kind of package facility, as in EDIT :MYPROCS.
---------------------------------------------------------------



---------------------------------------------------------------






Tue, 30 Apr 2002 03:00:00 GMT  
 LOGO-L> Re: LOGO language design - Was: predicate writing

Quote:

>1) What is LAMBDA and what is a "first class procedure"?

First-class data are things that can be (1) the value of a variable, (2) an
argument to a procedure, (3) the return value from a procedure, and (4) a
member of an aggregate (a list or an array).  For example, in Logo, numbers,
words, and lists (and arrays in UCBLogo/MSWLogo) are all first class.
But in Logo you can't do any of those things with procedures.  You can put
the *name* of a procedure in a list, for example, but not the procedure
itself.

LAMBDA is the Lisp operation that creates a procedure without giving it
a name.  For example, (lambda (x) (* x x)) creates a procedure that
squares a number.  UCBLogo/MSWLogo allow something similar in certain
contexts, namely as input to APPLY or to the higher-order functions
such as MAP and FILTER:
        ? show map [[x] :x * :x] [2 3 4 5]
        [4 9 16 25]

But here's something you can do in Scheme but not easily in Logo:

        > (define (make-adder num)
            (lambda (x) (+ x num)))
        > (define plus3 (make-adder 3))
        > (plus3 5)
        8

In UCBLogo/MSWLogo we can sort of do it, but it's harder:

        ? to make.adder :num
        > output (list [x] (list "output ":x "+ :num))
        > end
        ? define "plus3 make.adder 3
        ? print plus3 5
        8

In versions of Logo without DEFINE it's difficult-to-impossible to do this.
Even in the UCBLogo notation it's awkward compared to Scheme.

Quote:
>2)What are "Dynamic" and "Lexical" scopes?

"Scope" refers to the rules by which a language makes sense of variable
references, like :VAR in Logo.  If VAR is the name of an input to the
procedure in which the reference appears, as in
        to square :x
        output :x * :x
        end
then it's clear what variable is meant.  But what if you refer to a
variable name that isn't an input to this procedure?

Logo uses dynamic scope, which means that Logo looks for the variable
first in the current procedure, then in the procedure that *called* this
one, then in that one's caller, and so on, until finally it looks in
the global variables.

Most other languages today use lexical scope, which means that they
look first in the current procedure, then in the procedure *inside which
the current procedure was created*, and so on out to the global variables.
Not all languages allow definitions inside definitions; Logo doesn't, and
neither do C, C++, or Java.  But Scheme does (the lambda inside make-adder
above is an example of a procedure created inside another one), as does
Pascal.

It's lexical scope, in part, that makes Scheme's version of make-adder so
elegant.  When I said (define plus3 (make-adder 3)), the procedure plus3
remembers the value of NUM at the point where it's created, namely the
lambda expression inside make-adder.  So later, when we call plus3, it
doesn't matter whether the call is inside some other procedure that has
a local variable named NUM; what counts is make-adder's NUM.

In Logo, with dynamic scope, that wouldn't be true.  So I had to construct
the text of a procedure in which I put the *value of* NUM, not :NUM -- that
is, the definition of PLUS3 in the Logo version is
        to plus3 :x
        output :x + 3
        end
with an actual 3, rather than :NUM, because in Logo :NUM would look for
a variable NUM in the context in which PLUS3 is called, rather than in
the context where it was created.

There are pros and cons to each.  Most languages use lexical scope because
on balance it's probably better for large production programs.  But Logo
uses dynamic scope because on balance it's probably better for beginning
programmers.  If you want more details, see pp. 183-187 of Computer Science
Logo Style, vol. 3: Beyond Programming.  [advt. :-)]

Quote:
>3)What is the advantage of LCSI's 3 + 4 vs. 3+4 and what is "tokenization"?

"Tokenization" is the process by which a language interpreter or compiler
divides the string of characters that the user typed into a string of
meaningful chunks.  In pretty much every language, including every dialect
of Logo, a space character separates chunks.  The question is what else
separates chunks.  In most languages, including pre-LogoWriter versions
from LCSI, the arithmetic operator symbols are chunks by themselves,
whether or not surrounded by spaces, so 3+4 means the number 3, the plus
operator, and the number 4.  In Logowriter/Microworlds, 3+4 is a single
three-letter word, so if you wanted you could say
        to 3+4
        output 8
        end

The reason for the change in LCSI tokenization policy is that sometimes
you want to use those characters for something other than arithmetic.
The standard example is lists of phone numbers:
        [642-8311 555-1212 548-5504]
You want this to be a list of three words, not a list of nine words.

UCBLogo, and I think still Terrapin products, follow a more complicated
rule, trying to "do the right thing" based on the context.  So
        print 3+7
treats the + as a separate token, but
        print "3+4
doesn't, nor does
        print [3+4]
The trouble is that sometimes UCBLogo has to re-tokenize a bracketed list
that turns out to be Logo instructions, as in
        run [print 3+4]
When this is typed into UCBLogo, the stuff in brackets is treated as a
list of two words, PRINT and 3+4.  But when the list is given as input
to RUN, Logo re-tokenizes it so that the + is separated.

As usual with "do the right thing" cleverness, the actual rules are quite
complicated to explain, and every once in a while they do the wrong thing.
But I'd say at least 95% of the time what happens is what you wanted.



Fri, 03 May 2002 03:00:00 GMT  
 LOGO-L> Re: LOGO language design - Was: predicate writing
Brian, your list also clicked for me -- and one thing that really
captured me attention was your aside "for its [Logo's] purposes":

Quote:
>2.  Dynamic vs. lexical scope.  I still think Logo made the right
>choice here, for its purposes, but we still have arguments about it.

Part of the on-going design (and other) debates inside the Logo
community probably stem from different ideas about what "the purpose"
of a Logo implementation is.

Now, one way to think about this is to compare your intro CS Logo Style
and your (and Matthews') "Simply Scheme." (BTW, nice job on the 2nd
editions on both. Just got around to "upgrading" after all these years.)

Anyway, there is a lot of similar material in these. (BTW, this is not
a complaint -- just using this example to illustrate a point.) Take the
topic of recursion. Many of the examples are the same -- and there is
large overlap in suggested ways of understanding the concept. Some of
the differences seem to be: assumptions about the reading level of the
reader -- and differences in the syntax of the examples.

One thing this does is raise a question about the pedagogical
relationship between Logo and Scheme. Is "the purpose" to use Logo as
an easy introduction to programming -- with the idea that eventually
those who are interested will move on to more powerful/complicated
languages (or languages that are the result of different
design/implementation choices) such as Scheme? Or is the idea that Logo
is trying to meet the criteria of "low threshold, no ceiling" -- and
therefore, to continue the recursion example above, it's just a matter
of chance and preference whether you wind up learning to program via
Logo or Scheme?

It seems to me that one would care about different things depending on
which of these seems to be "the purpose" (and, yes, of course, there
can be other alternatives).

As someone who would like to continue using Logo, maybe I want an
implemenation of Logo with the power of Scheme/Lisp (w/ CLOS).

As someone who might want a non-threating & reasonably powerful
introductory programming environment, maybe I want something that a) is
designed to make certain behaviors easier to understand (dynamic
scoping rather than lexical), b) does not "confuse me too much" (and
what qualifies as "reasonably confusing" is, I think, one of the
hottest buttons in the Logo design community), and so does not allow
certain functionality (no first class procedures), etc. Some of the
design issues that come up in *this* case seem to be related to how one
designs such a language to a) be "reasonably" powerful and easy, and b)
not make it unduly difficult to transition to a more powerful language
that operates differently (to varying degrees).

I'd be curious to hear, Brian, what kinds of difficulties you've seen
with students who came into your Scheme course knowing Logo.

k

Sent via Deja.com http://www.deja.com/
Before you buy.



Fri, 03 May 2002 03:00:00 GMT  
 LOGO-L> Re: LOGO language design - Was: predicate writing

Quote:

> One thing this does is raise a question about the pedagogical
> relationship between Logo and Scheme. Is "the purpose" to use Logo as
> an easy introduction to programming -- with the idea that eventually
> those who are interested will move on to more powerful/complicated
> languages (or languages that are the result of different
> design/implementation choices) such as Scheme? Or is the idea that Logo
> is trying to meet the criteria of "low threshold, no ceiling" -- and
> therefore, to continue the recursion example above, it's just a matter
> of chance and preference whether you wind up learning to program via
> Logo or Scheme?

A very good question.I think it is an admirable goal to try to achieve both
simultaneously. Though it is difficult. Smalltalk 72 was for kids - but by
the time Smalltalk 80 came out it had become well-suited for professionals
and not kids. Maybe they should have thought harder and they might have
succeeded in providing a tool for both. I heard Alan Kay (the leader of the
Smalltalk group) say his biggest mistake in those days was that he didn't
consider splitting the group in 2 and letting one group focus on kids and
another professionals.

There are lots of instances in other fields where kids and {*filter*}s use the
same tool - e.g. the piano. So maybe we just need to try harder.

Best,

-ken (www.toontalk.com)



Sat, 04 May 2002 03:00:00 GMT  
 LOGO-L> Re: LOGO language design - Was: predicate writing


Quote:

> There are lots of instances in other fields where kids and {*filter*}s use the
> same tool - e.g. the piano. So maybe we just need to try harder.

I agree with this, in principle. The problem, though, seems to be that we
don't really have lots (or even a few) examples of cases where {*filter*}s and
kids use the same *very complex* tools. Yes, pianos have something like "low
threshold, no ceiling" -- so beginners can make sounds -- and there is an
ever-increasing range of expression and complexity that can be attained.
However, providing a neophyte with a piano is, in other ways, *nothing like*
asking them, for example, to start using Emacs as their first text editor
(slash operating system slash programming environment slash email handler
slash your-answer-here). It is just *way* too easy (and common) for
beginners -- and even intermediate users -- to hit some combination of keys
that puts them in a mode they a) don't understand, b) don't realize they are
in, and c) don't really know how to get out of except by exiting Emacs. Now,
it's possible to argue that Emacs doesn't have the ideal interface for an
environment with "low threshold, no ceiling", but I believe the general
point still holds: computational environments typically either a) design for
neophytes by leaving out modes & functionality that would be too confusing
if evoked unintentionally, or b) make all of their power available, and thus
(eventually) become environments for experts. (You may cite Squeak as a
counter-example, but it seems to me that the evidence is still out on that
one.)

It has always seemed to me that your work on ToonTalk points in a direction
that is one possible way of addressing this. Namely, looking at video games
as a model for environments that are complex, engaging, powerful and that
neophytes are often willing to take on enormous challenges to master. So
what about an "Emacs for kids": by this I mean an emacs that is
neophyte-friendly (as opposed to a dumbed-down version of emacs "for kids").
Note: I'm not literally proposing that one work on making Emacs
kid-friendly, but using this phrase as a short-hand for a complex
computational environment with low-threshold. One way that one could imagine
addressing the issue of an "Emacs for kids" is to use the video game concept
of "levels." Game players are very comfortable with the idea that when they
enter new levels, "the rules can change." Now, there are problems with the
model of levels -- not everyone wants to start the same way, or learn things
in the same order. An alternative might be something like the old text
adventures, where there are different rooms and areas. Anyway, I guess it's
easy to see that I lean in the direction of an "Emacs for kids" -- as
opposed to environments that have ceilings.

This relates also to the debate you and Brian were having (summarized on
your web site) about different models of programming. I tend to favor the
model that one learns a multitude of techniques and tools -- and learns to
recognize the appropriate situations under which to use them. So I'm more
inclined to think about how to design and environment in which someone can
use logic programming, as well as procedural programming (and one which has
SIMD, MIMD, OOP, etc. extensions), depending on which is appropriate to what
one wants to accomplish. Now, one of the (very few :-)) design issues that
didn't come up in that discussion is the difference between whether it is
*technically* hard to implement such a system -- and whether it is too
*conceptually* hard for a user if such a system exists. As you and Brian
pointed out, *implementing* a system that supports both logic and procedural
programming is a challenging design and implementation task. As *users*,
however, I do think that we, as human beings, are able to switch contexts
and operate with different models (drive on the left or the right; etc.) So,
a direction I find interesting is: provide the broadest range of tools
(conceptual and otherwise), provide good (and non-threatening) means of
transitioning between them, provide good indicators of which tools are
currently being used, and (possibly) provide some means for me as a learner
(or as a pedagog) to say "don't expose certain functionality to me" (yet).

k



Sun, 05 May 2002 03:00:00 GMT  
 LOGO-L> Re: LOGO language design - Was: predicate writing

Quote:
> One way that one could imagine
> addressing the issue of an "Emacs for kids" is to use the video game
concept
> of "levels." Game players are very comfortable with the idea that when
they
> enter new levels, "the rules can change." Now, there are problems with the
> model of levels -- not everyone wants to start the same way, or learn
things
> in the same order. An alternative might be something like the old text
> adventures, where there are different rooms and areas.

I think this is a promising direction to try but there have been attempts of
this sort with mixed results. Even Emacs has a notion of levels. Novices who
type some sophisticated command get a warning asking if they really want to
proceed (and whether they want to be bothered about this sort of thing in
the future). My understanding of Robolab for LEGO Mindstorms is that it has
several levels that are incrementally revealed. Maybe someone reading this
has some experience with it and can tell us how well this works in practice.

Maybe the idea of levels isn't quite the right thing to borrow from video
games. Consider Super Mario Brothers - this is a rather rich world but it is
revealed in very small steps (e.g. first time you encounter a mushroom you
experiement, see how it changes things, and learn what it does to you). But
all the complexity isn't present at once - you must explore and find things
and discover what they do. And it is safe to explore - you won't break
anything. And the designers have organized things so you learn what you need
to before you can get to the next "level".

Quote:
>So I'm more
> inclined to think about how to design and environment in which someone can
> use logic programming, as well as procedural programming (and one which
has
> SIMD, MIMD, OOP, etc. extensions), depending on which is appropriate to
what
> one wants to accomplish.

I was a big proponent of multi-paradigm computer languages for about ten
years. But then I read a study from Bell Labs (this was about 12 years ago -
I can't remember the reference) which pointed out how hard it was for teams
of programmers to work together. Basically every team member had to be an
expert in all the different sub-languages since they would frequently have
to READ code from other programmers. The appeal of multi-paradigm
programming is as a WRITER of programs I can choose the tool I prefer and it
will all be nice integrated. But the cost is the expertise it requires of
readers of code.

Community is very important for programming. The ability of people to share
and help each other is critical. This is one of the strongest reasons to
strive for languages whose users span from small children to professionals -
they can all be part of the same community. Community consists of news
groups (like this one), email lists, web sites, sample programs, books,
research papers, courses, and the like. And I think the benefits of
community are stronger for simple (yet powerful) languages because more of
the material and discussions will be relevant to the majority of the
language's programmers. I think with complex languages their support
communities are more likely to splinter.

Interesting discussion.

Best,

-ken



Sun, 05 May 2002 03:00:00 GMT  
 LOGO-L> Re: LOGO language design - Was: predicate writing

Quote:


> Maybe the idea of levels isn't quite the right thing to borrow from video
> games. Consider Super Mario Brothers - this is a rather rich world but it
is
> revealed in very small steps (e.g. first time you encounter a mushroom you
> experiement, see how it changes things, and learn what it does to you).
But
> all the complexity isn't present at once - you must explore and find
things
> and discover what they do. And it is safe to explore - you won't break
> anything. And the designers have organized things so you learn what you
need
> to before you can get to the next "level".

Not sure if you talked your way around to liking levels or not :-)

Quote:
> I was a big proponent of multi-paradigm computer languages for about ten
> years. But then I read a study from Bell Labs (this was about 12 years
ago -
> I can't remember the reference) which pointed out how hard it was for
teams
> of programmers to work together. Basically every team member had to be an
> expert in all the different sub-languages since they would frequently have
> to READ code from other programmers. The appeal of multi-paradigm
> programming is as a WRITER of programs I can choose the tool I prefer and
it
> will all be nice integrated. But the cost is the expertise it requires of
> readers of code.

Excellent point! Although ....the read/write issues continues to be a
problem, and despite many
proposals for improving the situation, the two major concrete advances, as
far as I can tell,
are related to object oriented programming (OOP) methodologies. On the one
hand, there is
re-usability, so once something works at least it gets re-used as something
"working". And second, OOP (as well as other approaches) emphasizes  *what*
the code of someone else does -- as opposed to *how* it does it (in other
words, try like hell not avoid actually having to debug the internals of how
someone did something).

The first advantage would seem to generalize to multi-paradigm languages.
The second advantage/approach would also seem like most coder's preference,
independent of the complexity of the language. Even on my (rare) best days,
I'd rather do just about anything than have to go in and
read/comprehend/debug someone else's code. And this reluctance is largely
independent of the language and the degree to which said language has
"sub-languages" -- it has mostly to do with how different people *think*,
conceptualize problems and solutions, and manifest those solutions in their
approaches to writing and organizing their code. So, although I agree with
your point that multi-paradigm languages may play into the problem of  the
shared practice of programming -- it's just not clear to me that it makes it
any more difficult than it already is. (It's also not clear to me, nor to
the programming community at large, as far as I can tell, what can be done
about this problem. It looks like it's just going to get progressively
worse.)

Quote:
> Community is very important for programming. The ability of people to
share
> and help each other is critical. This is one of the strongest reasons to
> strive for languages whose users span from small children to
professionals -
> they can all be part of the same community. Community consists of news
> groups (like this one), email lists, web sites, sample programs, books,
> research papers, courses, and the like.

Again, a very nice point. But, given your stated interest in developing
ToonTalk as an environment (similar to video games) that does not require
such support, I'm actually kind of surprised you chose to make it :-)

You may be right: keeping a language "uni-paradigm" may facilitate the
deployment and support for such language. I can easily imagine that people
who first learn programming as {*filter*}s will find it easier to learn such a
language. But will this be the case in 10+ years when the exposure to
computational ideas will presumably be much broader & consistently earlier
in life (and those people who are just starting as teachers and parents will
be much more familiar with computational ideas than has been the case in the
past)? I guess I'm concerned that if we go down this path (ie, "let's not
implement
a more complicated feature because the majority of the existing community
wouldn't
currently understand it and therefore might not support it properly"), it's
not clear when to stop.

There is always a scaffolding problem when one proposes introducing powerful
new ideas to children whose parents/teachers are not familiar with them.
People
thought Papert & Feurzig were crazy to imagine computers for kids in the
60s.
I hope that just as it was once inconceivable that children would ever
program, it will at some point seem natural for children to use more
complicated paradigms than we currently use. It is still the case that many
teachers and parent struggle valiantly with programming and computational
ideas. As a community, we could stop the evolution of languages here -- or
we can continue and assume that just as Logo was initially a hurdle for many
people, those who grow up in a world where computational ideas are common,
and in which they themselves use those ideas, will support the next
generation of
users who have more powerful and complicated tools & concepts than they had.

This is not an argument for complexity "for complexity's sake":
it's just that the computational complexity, and the conceptual coordination
of
complexity in general, is going to continue increasing both in terms of raw
scale, and in
terms of the nature of the problems. Take quantum-computing. No one really
knows the extent of the fundamental paradigmatic changes it will bring to
computation. (However, I'll bet kids can, on average, *today* wrap their
heads around qubits easier than we can (it wouldn't surprise me if there is
some video game construct that kids use every day that maps by easy analogy
to a qubit :-))) And we could spin off other, non-computational activities
that will
be aided by a mastery of complexity that programming (among other things)
affords.

Quote:
> And I think the benefits of
> community are stronger for simple (yet powerful) languages because more of
> the material and discussions will be relevant to the majority of the
> language's programmers. I think with complex languages their support
> communities are more likely to splinter.

Not sure I buy this reasoning. The support for Logo might be stronger if it
wasn't widely perceived as "just a language for kids." As it is, I would
imagine that the programming language of choice in most schools is still
Basic (or perhaps C). And one could attribute at least part of Basic's
endurance on the fact that it has managed to reinvent itself such that
professionals continue to use it (oh, and maybe the fact that some guy in
Redmond, who once implemented it for the Altair, managed to make it the
basis of his products' application development environments :-)).

k



Sun, 05 May 2002 03:00:00 GMT  
 LOGO-L> Re: LOGO language design - Was: predicate writing

Quote:

>One thing this does is raise a question about the pedagogical
>relationship between Logo and Scheme. Is "the purpose" to use Logo as
>an easy introduction to programming -- with the idea that eventually
>those who are interested will move on to more powerful/complicated
>languages (or languages that are the result of different
>design/implementation choices) such as Scheme? Or is the idea that Logo
>is trying to meet the criteria of "low threshold, no ceiling" -- and
>therefore, to continue the recursion example above, it's just a matter
>of chance and preference whether you wind up learning to program via
>Logo or Scheme?

Well, of course different people have different purposes...  but I
wouldn't want Logo's design to revolve around _Computer Science Logo Style_!
It's more the other way around; CSLS is designed to allow someone who grew
up with turtle graphics (or some multimedia extension) to use the Logo
experience as a basis for learning some computer science.

Quote:
>I'd be curious to hear, Brian, what kinds of difficulties you've seen
>with students who came into your Scheme course knowing Logo.

I don't have much useful to say about this.  I've had many students
in the Scheme course who studied Logo in elementary school ten years
earlier, but remember few details and weren't taught much about, say,
composition of functions anyway.  So it doesn't really matter much
that they've seen Logo before.

PS.  Indeed, we wrote _Simply Scheme_ using CSLS as an intellectual
starting point.  And then the SS experience helped me with the
second edition of CSLS.



Tue, 07 May 2002 03:00:00 GMT  
 LOGO-L> Re: LOGO language design - Was: predicate writing

Quote:
> For me, learning is one of the most enjoyable experiences in life.

That was what I was thinking Andru.

I observe that if little kids and old geezers like me are not learning we
are not having much fun.  Like you said we don't enjoy eating that much and
most of the other things that most of the rest of you enjoy(like working)
the youngsters do not do yet and we oldsters do not do as much as we used
to.

So "educators" should be advised that the demand(at least at the beginning
and the end of life) is not for more efficient ways of learning but more
enjoyable/interesting ways of learning what each of us *want* to know.

What got me going was I had just returned from a Highline School District
School Board meeting in which the Board and the audience were showed a video
of a super-dooper new six week summer reading program for lousy-readers.  No
matter how the Ph.Ds in Education doctored up the video you could tell that
the children were miserably missing out on their summer vacations.  All
because of the increased pressures on the government school system to
improve their test scores each year.  I will tell you for sure that these
"educators" would force knowledge pills down the children's throats in an
instance.

But I still would like to have a grammar pill.  I have not discovered an
enjoyable way of learning grammar.

If I knew my grammar better I would be better able to explain what I am
thinking about to others.    Dale
---

---------------------------------------------------------------





Tue, 07 May 2002 03:00:00 GMT  
 LOGO-L> Re: LOGO language design - Was: predicate writing

  This seems to be a case of right brain/left brain. Symbolic processing is
largely done in the left hemisphere, while images involving sound, color,
shape, etc., happen largely in the right side. The two sides communicate at
high speed to interpret and synthesize meaning.
  But symbols (whether letters, numbers or musical notation and the
"grammars" for making sense of them, need to be learned. Sound, color,
shape, etc., are recognized at a more instinctive level.
  The good news is that the young human mind is prewired for generating
organizational grammars for meaningful use of symbols (see N. Chomsky).
This is a fundamental tenet of Papert's that has given him the zeal to
pursue Logo for so long. Try sitting a 6 year old at a computer and leading
them in designing a square. Ask them a lot of what-if questions and help
them with answers. Most kids find this natural. They are simply learning a
new way to make meaning with symbols. When their procedure commands
instantly make something visible, it is a great reinforcer for going
further. The psychological term for what Papert espouses is efficacy--sort
of a feeling of "I can do" that tends to increase with one's ability to
create symbolic meaning.
  Questions of interest and perception fit into the motivational and
semantic parts of this framework.

Quote:
>Well, I will try to explain, but I am not sure it is possible.  I agree
>that people receive all kinds of informal instruction such as watching
>others, trying things out etc.  That surely happens with musicians as
>well.  But the computer, at this stage of the game does not seem to me to
>be at all intuitive.  When my grand daughter bangs on the computer, you
>get nothing (except perhaps broken key boards or something).  Even when my
>grandson, quite a bit older, uses some of his preschool programs, he tires
>quickly of all of them because he reaches limits that are not easy to find
>ways around. Whe my grand daughter agina bangs on the piano or my guitar
>she gets sound (and broken keyboards and strings).  Guess which one she
>bangs on the most.  There is a primitive response to sound and ryhthym
>shows up very early.  Musicians learn music at birth in the sound of their
>Mother's voice and cadence of speech surrounding them. I agree it is not
>without instruction, that part of my earlier statement is probably
>extreme.
>     Computers have to be turned on.  Mastering language to interface with
>the computer requires at least an iconic recognition.  If using a typed
>language you have to develop eye, brain, hand cordination similar to
>writing which is another chanlleneg beyond music.  I know, I know, manual
>dexterity is required for some music as well, but not for pounding and
>singing which is where it starts.  And don't get me started on note
>reading.  Notes are unnecessary to music and play very little role in a
>musicians life, despite the inordinate amount of time spent learning to
>read them (which many do not) and the empahsis put on them by many music
>teachers.
>     The second part of my response is that the two activities feel
>different when I do them.  I know I am inviting someone who will claim
>that they play and program and it feels the same to them.  I told you I
>wasn't sure I could explain this.  But Playing music is just not about the
>same things as programming.  Yes, they both have a mathematical basis.  In
>fact I give lectures at the local elementary schools on the science of
>music.  But that does not mean that when I am playing or writing I am
>thinking very much about that.  In fact, I can tell you I am not.  We use
>notation and math to talk about music, not to play it.  Maybe the
>confusion is that I am talking about how we learn music, and play music,
>not about music as a subject.
>    Of course music for one person is not the same as it is for another
>and I have to assume that the same is true for programming.  I cannot
>remember when I did not pound out rythym, sing, pound on the piano, pluck
>strings, take instruments apart, blow on reeds, whittle whistles, etc.
>But I only learned to program much later (if anyone would call what I do
>programming). I just don't think computer have that same kind of ability
>to tinker and explore regardless of age, yet.
>     There is also one last consideration.  Music is explored with the
>ears.  Computing is basically a visual experience.  These area of the
>brain are located in different places, respond to different kinds of
>stimuli, and, I am sure, process information in their own unique ways.
>They "feel" different.
>    I apologize if my comment on one item, made almost tongue in cheek,
>has taken us too far from Logo.  I didn't mean any harm, honest!

>---------------------------------------------------------------




Jim Baker
Understanding begins with finding first principles.

---------------------------------------------------------------





Wed, 08 May 2002 03:00:00 GMT  
 LOGO-L> Re: LOGO language design - Was: predicate writing

Quote:
>But I still would like to have a grammar pill.  I have not discovered an
>enjoyable way of learning grammar.

What about Logo sentence generators, stuff like this:

to sentence
output (se noun.phrase verb.phrase)
end

to noun.phrase
output (se "the adjective noun)
end

to adjective
output pick [red blue green big small fat skinny loud quiet]
end

to noun
output pick [computer elephant boy girl aardvark]
end

to verb.phrase
output (se verb noun.phrase)
end

to verb
output pick [likes eats visits hates paints]
end

You can learn a fair amount about grammar by extending this to handle
more kinds of sentences -- intransitive verbs, prepositional phrases,
names, etc.

For instance, you could add [sits on] to the list of verbs.  In school
they teach that this is the intransitive verb SITS followed by a
prepositional phrase starting with preposition ON.  But you can't use
any old preposition; it has to be ON.  Maybe it makes more sense to think
of SITS ON as a two-word transitive verb.  You think about this a while,
then you go read what the experts say.



Thu, 09 May 2002 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. LOGO-L> predicate writing

2. LOGO-L> Re: LOGO language design - Was: predicate writing

3. LOGO-L> logo language

4. LOGO-L> Logo language

5. LOGO-L> Apple logo/MSW Logo

6. LOGO-L> Reseach Machines Logo (RM LOGO)

7. LOGO Design by LOGO-TOGO

8. LOGO-L> Welcome to logo-l

9. LOGO-L> Re: Dynamic scope in Logo

10. LOGO-L> INFO re SIG-LOGO

11. LOGO-L> Logo speed

12. LOGO-L> Logo foundation site

 

 
Powered by phpBB® Forum Software