<br><br><div class="gmail_quote">On Fri, May 20, 2011 at 2:28 PM, John Gilmore <span dir="ltr"><<a href="mailto:gnu@toad.com">gnu@toad.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
> Recently, I finished my dissertation on mobile development<br>
directly from mobile devices. Something like this might've been very<br>
useful, although I did target experienced developers, not beginners.<br>
<br>
Mobile development would work great on mobile devices like the XO-1,<br>
XO-1.5, XO-1.75, and perhaps even the XO-3, if only we'd teach the<br>
kids a few simple paradigms like "files", "hierarchical file systems"<br>
and "text editors".<br></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
(Efforts to teach computers to compile or interpret large programs<br>
that aren't written in collections of "files" are doomed to niche<br>
uselessness, though it sure makes a fun research/masturbation topic.<br>
I spent years paid to write big programs in APL that way in the '70s --<br>
those programs are all unportably dead today, and APL is a tiny niche.)<br>
<br>
These are not hard concepts. Kids learn them daily, but not from XOs.<br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Since OLPC can't seem to be dissuaded from this fundamental error, the<br>
question for me is whether it can be influenced to minimize the amount<br>
of learning that kids go through which is unique to this useless<br>
programming model. There *is* usefulness in teaching kids how to<br>
write tiny programs that can never scale up to useful, portable,<br>
supportable programs. But once they get the basic concepts, they<br>
should be transitioned to industry best practices pretty quickly,<br>
writing a real "Hello World" and then evolving it to be more useful.<br>
<br>
Rather than getting stuck by e.g. trying to make substantial programs<br>
fit on one screen by moving tiles around visually. As in the<br>
model-view-controller paradigm, the kids need to learn that the view<br>
is not the model, but the model is a simply structured thing that<br>
lives behind the view. If you don't teach the abstract structures<br>
that the model is based on, the kids can't learn to make that<br>
separation. This is why they never learn to modify the real programs<br>
that hide behind the fluffy interfaces on their real XO computers.<br></blockquote><div><br>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. 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 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. 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.<br>
<br>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).<br><br>-walter<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
John<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Walter Bender<br>Sugar Labs<br><a href="http://www.sugarlabs.org">http://www.sugarlabs.org</a><br><br>