[IAEP] Turtles All The Way Out

Fri May 20 21:07:11 EDT 2011

Actually, I said "I made up the term 'Object-oriented', and I did not have C++ 
in mind".

Cheers,

Alan

________________________________
From: "mokurai at earthtreasury.org" <mokurai at earthtreasury.org>
To: Walter Bender <walter.bender at gmail.com>
Cc: Lucian Branescu <lucian.branescu at gmail.com>; IAEP SugarLabs 
<iaep at lists.sugarlabs.org>; OLPC Devel <devel at lists.laptop.org>; John Gilmore 
<gnu at toad.com>
Sent: Fri, May 20, 2011 5:51:08 PM
Subject: Re: [IAEP] Turtles All The Way Out

On Fri, May 20, 2011 3:11 pm, Walter Bender wrote:
> On Fri, May 20, 2011 at 2:28 PM, John Gilmore <gnu at toad.com> wrote:
>
>> > Recently, I finished my dissertation on mobile development
>>  directly from mobile devices. Something like this might've been very
>>  useful, although I did target experienced developers, not beginners.

When we get to wearables with glasses-mounted full-sized display devices
and one-hand chord keyboards, absolutely. Or when soft keyboards on
multitouch tablets are totally reliable.

>> Mobile development would work great on mobile devices like the XO-1,
>> XO-1.5, XO-1.75, and perhaps even the XO-3, if only we'd teach the
>> kids a few simple paradigms like "files", "hierarchical file systems"
>> and "text editors".

See Introduction to the Command Line

http://booki.flossmanuals.net/command-line/edit/

of which I am a co-author.

I don't know where you get the idea that files, hierarchical file systems,
and text editors are simple concepts. I would be willing to discuss
introducing the Linux file system in middle school, but our issue is
programming for third-graders, or even earlier. Preschoolers can grasp the
ideas behind turtle art by acting the part of the turtle. Where would you
have them begin?

> Sugar comes with a plain-text editor (written by a 14-year-old, BTW) and
> files (and even a hierarchical file system) that has a data store as its
> primary interface. The problem with mobile development on mobile devices
> is
> not one of religion, it is about physical affordances: small screen and no
> (or inadequate) keyboard.
>
>
>> (Efforts to teach computers to compile or interpret large programs
>> that aren't written in collections of "files" are doomed to niche
>> uselessness, though it sure makes a fun research/masturbation topic.

Language, John, our discussion of child programming must be discussable
with the children, their parents, and their parents' churches and
political parties. The archive of this list is public information.

>> I spent years paid to write big programs in APL that way in the '70s --
>> those programs are all unportably dead today, and APL is a tiny niche.)

I have an ISO/ANSI standard APL that occupies 29K, thus originally giving
a 32K workspace on 8-bit computers with 64K memory. It could easily be
expanded to run with any amount of memory. Ken Iverson successfully used
IBM APL\360 to teach first-grade arithmetic on a 360 with Selectric
terminals.

I also have books on math and other subjects in APL, from arithmetic to
calculus, cryptography, and computer design.

>> These are not hard concepts.  Kids learn them daily, but not from XOs.

Kids of what age?

>> Since OLPC can't seem to be dissuaded from this fundamental error,

because it isn't one,

>> the
>> question for me is whether it can be influenced to minimize the amount
>> of learning that kids go through which is unique to this useless
>> programming model.

The point is to maximize learning in minimum time or with minimum effort.

>> There *is* usefulness in teaching kids how to
>> write tiny programs that can never scale up to useful, portable,
>> supportable programs.  But once they get the basic concepts, they
>> should be transitioned to industry best

worst, actually (Did you ever hear of the programmer who claimed to have
20 years experience in COBOL, but it turned out he had two years
experience repeated 10 times?) No industry has ever embraced best
practices.

>> practices pretty quickly,
>> writing a real "Hello World"

So Hello World in Turtle Art is unreal?

Here is a complete APL "Hello, World." program, with its output.

   'Hello, World.'
Hello, World.

and a complete Turtle Art version

Print<<TextVariable "Hello, World."

which the activity will be happy to convert to Logo.

Next you put a Python function call on a single block to print the text,
and away you go.

>> and then evolving it to be more useful.

Precisely.

I prefer to teach not only programming but computer science concepts in
the early years. One of the great advantages of Turtle Art is that there
is no parsing step to translate from linear text with bizarre punctuation
rules to a tree structure. The children program directly in effectively
preparsed tree structures, with no "syntactic sugar", as the LISPers call
it.

Also, Walter has built stack primitives into Turtle Blocks, so we can
teach stack discipline and the rudiments of FORTH in Turtle Art. He
recently added a block to read the color at the turtle's location. I had
mentioned to him some time ago that that was the only function missing for
me to write a Turing machine in Turtle Art, using colors for cell states
and elements in the transition table. I must do that sometime.

>> Rather than getting stuck by e.g. trying to make substantial programs
>> fit on one screen by moving tiles around visually.

Strawman. Not the purpose of Turtle Blocks, and not something we would
encourage anybody to do. At that point you start writing Python
subroutines, and shortly after that you transfer completely to Python. Or
Smalltalk. And from there, you can learn the syntactic sugar of any
programming language. After learning three different clean programming
models, we have some hope that our children will appreciate what
abominations most other programming languages are.

"I invented Object-Oriented Programming, and C++ is _not_ what I had in
mind."--Alan Kay

>> As in the
>> model-view-controller paradigm, the kids need to learn that the view
>> is not the model, but the model is a simply structured thing that
>> lives behind the view.  If you don't teach the abstract structures
>> that the model is based on, the kids can't learn to make that
>> separation.  This is why they never learn to modify the real programs
>> that hide behind the fluffy interfaces on their real XO computers.

We have paths from Turtle Art to Python and Logo, and we also have all of
FORTH and Smalltalk built into XOs.

Also, I don't know of any more fundamental structure than a parse tree,
something that almost no conventional programming students ever learn
about. They only see the linear text view of their programs, and most form
incorrect models of the execution process. LISP has the best execution
model, with the eval-apply mutual recursion and the read-eval-print loop.

> I cannot speak for every Sugar developer, but the approach I have tried to
> take with Turtle Art is a bit different than you are describing.

Don't be modest, Walter, it's very different.

> The
> block-based programming environment is not meant to be a substitute for
> real tools; it is meant to be a place to get started;

to understand the real ideas behind programming without getting bogged
down in syntax;

> to learn that you can write
> and modify code; and to provide multiple motivations and launch pads for
> getting into the "real" thing. I've worked pretty hard to make the
> "structured thing" behind the view more approachable, and have provided
> multiple ways in and out: exporting your "fluffy" view into Logo that can
> be
> run in Brian Harvey's text-based Logo environment; direct, in-line
> extensions written in Python; the ability to create new blocks by
> importing
> Python; a plugin mechanism for making major interventions; and a
> refactoring
> of the underlying structures to make the code more approachable. (The
> source
> code is peppered with comments and examples of how to make modifications.)
> None of these interventions are intended to keep the kids programming in
> Turtle Art. They are all intended to get the kids started down the path of
> "real" programming. But I content that we need to engage them; let them
> discover that they can write code; and make changes; and that it is not
> something just for "others" but for everyone. When I talked about Turtles
> All the Way Down at Libre Planet two-years ago, I wasn't suggesting that
> we
> use fluffy interfaces all the way down, but that we invite modifications
> all
> the way down by providing scaffolding and encouragement. Step One is to
> give
> them the freedom to make changes; Step Two is to give them the context in
> which they can actually start doing it.

Yes, what Walter said.

>  Sure, there will always be the
> handful of kids who will jump right into Emacs and C, but most won't.
> Maybe
> we can encourage a few more to do something of substance but giving them
> some scaffolding.
>
> I am open to suggestions as to how to get more kids to move on from Turtle
> Art to ___ (insert you favorite "real" programming environment here).

> -walter
>
>
>>        John
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep

-- 
Edward Mokurai
(默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر
ج) Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos is my dwelling place, the Truth my destination.
http://wiki.sugarlabs.org/go/Replacing_Textbooks

_______________________________________________
IAEP -- It's An Education Project (not a laptop project!)
IAEP at lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/iaep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20110520/14602426/attachment.html>