[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Functional Paradigm popularity and Maths (Was: XML as a transition to s-expr)



Ok, I think I see your point.

I also think have not communicated mine particularly well.

I was saying that, to me, the very act of reading lisp code involves
seeing the expressions as lists. I suspect, that for many people, it is
not "actually" the parenthesis that are an issue but what they represent
[nested lists]. 

Where the process of mentally parsing them (when nested) is easier with
additional degrees of experience in abstract thinking of this very form.
I.e., read some lisp/scheme, it gets easier. Read it all the time, it
"seems" really easy and natural (especially with a good pretty printer).

That said, my previous comment(s) are not really relevant to the
processes by which young children might interact with, control and
educate a piece of software. In many of those environments it is the
visual-interaction-tool (UI) that becomes predominant. In
applications/environments targeted to these younger age groups they
presumably would not even see the textual language.

Which is was what I tried to allude to in a subsequent post when I
mentioned that the issue is not one of "syntactic-form" but rather the
programs exposure of the underlying language semantics [which builds a
foundation] that leads to thinking in terms of
"conversations/interaction" with "things/objects".

An idea, which I understand from this group's feedback, can presumably
be done easily in lisp/scheme; and which happens to flow naturally from
the language semantics of Smalltalk.

a) At a younger age group the interaction is through a
visual-environment that "wrappers" (and writes for you) the textual form
of the language.

b) At older age groups, the interactive IDE takes on some of this role,
but now one interacts directly with the language syntax. Where, in
Smalltalk, the concept of ubiquitous and consistent "thing/object"
semantics are directly exposed as the language.

Squeak (a popular Smalltalk dialect) itself has been shaped (and
evolved) into a construction kit for building object-and-componentized
interactive multi-media. I suspect a significant part of the effort's
goals are to turn it into an appealing "Sim-City-like-facility" for
learning and thinking about programming and perhaps stepping beyond that
to create interesting active content.

-- Dave S. [SmallScript LLC]

SmallScript for the AOS & .NET Platforms
David.Simmons@SmallScript.com | http://www.smallscript.org


> -----Original Message-----
> From: owner-ll1-discuss@ai.mit.edu
[mailto:owner-ll1-discuss@ai.mit.edu]
> On Behalf Of Dan Weinreb
> Sent: Wednesday, December 19, 2001 7:28 AM
> To: David.Simmons@smallscript.net
> Cc: tim@cs.brandeis.edu; dpb@cs.brown.edu; ll1-discuss@ai.mit.edu
> Subject: Re: Functional Paradigm popularity and Maths (Was: XML as a
> transition to s-expr)
> 
>    Date: Wed, 19 Dec 2001 04:23:06 -0800
>    From: "David Simmons" <David.Simmons@smallscript.net>
> 
>    Lisp requires one to think in terms of "lists" and "recursion".
> 
> It really can't be emphasized enough that there is no such
> requirement.  You can learn Lisp and program in Lisp and write
> compilers and Ethernet drivers and graphics packages and mail readers
> in Lisp and never use lists or recursion at all.
> 
> I have spent many years programming in each of Lisp, C++, and Java,
> and I use or don't use recursion under exactly the same circumstances
> independent of which of those languages I am programming in.
> 
> Lists are just a data structure in the library of useful data
> structures.  You use them when they're appropriate and you don't when
> they're not.
> 
> (Footnote 1: the Lisps I was using did not do tail-call elimination.
> Footnote 2: Yes, you do need to learn about lists if you want to do
> Lisp macros, but you aren't "required" to use macros, particularly if
> we're comparing with a language that doesn't have that kind of macro,
> and I don't think the little kids writing in Smalltalk are dealing in
> that kind of macro.)