Develop activity [was Re: [sugar] Education?]

[Andrew Clunis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This thread has gotten rather complicated, so I am going to top-post and
pepper the quoted text with some comments.

So, I've been working on Develop activity.  It will (hopefully) be the
means for writing (or changing) activities under Sugar.  It's already
built by default in sugar-jhbuild.

Right now, it resembles a pretty standard Python IDE, consisting of a
TreeView listing of packages and modules, and a module-level code
editor.  It also sports an eToys-inspired "Supplies Box" which holds new
object types the user can drag and drop onto the TreeView to create new
objects in their project.  However, I have been toying with the idea of
making it more like Squeak/eToys in that it could be more granular in
its representation of the components of a Python program.  I am in the
process of implementing a more granular representation in Develop's
underlying data model that enables it to enumerate and manipulate
sub-module constructs like classes and functions.  This will enable the
TreeView to function as a class browser, and the Supplies Box to contain
more items.

I am also open to the notion of a more Squeak-style approach where
individual methods have their own editor buffers (I would not use
floating windows, though, because neither I or any other hackers I know
work that way).

In fact, in light of Guido's work on saner reloading for Python, this
could become even more like eToys in that it could directly changes
directly into a running instance of the activity.  This is likely a gen2
or gen3 feature, though.

One thing that does bother me about hacking within a running instance of
a program is that people might get sloppy about the state of their
program; they'll be coding against state produced by their earlier code,
including buggy stuff they deleted or changed. Perhaps I misunderstand
somehow and someone can refute this?

Guido van Rossum wrote:
> On 3/9/07, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> I still think your choice of words was inappropriate
> 
> I'm new to this place. I was told that the Python/Squeak issue was
> gone. Apparently not so.
> 
>> If anything is
>> an anathema, then it's the huge body of impenetrable C code in linux,
>> the libraries, X11, gecko, gtk, cairo, and, yes, underlying Python,
>> too, and even Squeak, though to a much lesser extent. This prevents
>> opening the hood, seeing how things work, modifying it, constructing
>> new things etc. *This* is against the OLPC philosophy, which
>> explicitly encourages constructionist learning.
> 
> Sure. I am experiencing the pain myself -- I haven't even been able to
> build the sugar environment successfully. :-( And last night, as I
> demoed the XO to a group Python users, someone commented on how slow
> it was, and how his old (1995-era) handheld running on a 7MHz
> processor switched between apps instantaneously.

Out of curiosity, what's the trouble?  I've managed to get it running
quite a few times now, and I might be able to help.

> 
>> Sadly, there isn't anything comparable to Etoys in the whole open
>> source world. Actually, strike that last five words. It's not like
>> most of it couldn't be done in Python, but for whatever reason,
>> nobody does it
> 
> Unfortunately at least *some* of the people who can do it are stuck in
> the "Smalltalk is superior" rut (not just to Python, to anything).
> Witness some of the responses I got.
> 
>> I'd be happy to hear otherwise, but so far, the
>> Python community (or anybody else for that matter) to me does not
>> exactly appear enthusiastic about creating something that could
>> replace Etoys.
> 
> You weren't there at the EuroPython keynote by Alan Kay last year.
> There was great enthusiasm. And again at Ivan Krstyc's keynote at
> PyCon two weeks ago.
> 
> Of course, not everybody agrees on exactly the same technical
> priorities that should follow from the "children first" philosophy.
> People do what they can. But we must get over the notion that we
> should faithfully reproduce etoys in Python.
> 
> --Guido
> 

>> > On 3/9/07, Alan Kay <alan.kay at squeakland.org> wrote:
>> >>
>> >>  Guido knows that I've been advocating that the Python folks
>> >> should do Etoys
>> >> or a very Etoys like environment in Python (and that the rest of
>> >> the OLPC be
>> >> given an objectification and media and scripting integration that
>> >> is Etoys
>> >> like).
>> >>
>> >>  However, there are simply zillions of things left to be done
>> >> everywhere for
>> >> OLPC so the first round of SW on the XO will be more of a
>> >> gathering of
>> >> "suggestive" features and abilities (of which Etoys is just one).
>> >> That seems
>> >> fine to me.
>> >>
>> >>  Viewpoints Research (our little non-profit) doesn't have any "ego or
>> >> identity" staked around whether the children's authoring
>> >> environment is
>> >> Python based or Squeak based. I have said many times that, if the
>> >> general
>> >> integrative base of XO is to be Python, then the Etoys-like
>> >> authoring should
>> >> be based in Python also.
>> >>
>> >>  However, I will personally fight to the death to make sure that
>> >> there is a
>> >> children's authoring environment that allows even young children
>> >> to do
>> >> simulation style programming with very rich media objects.
>> >>
>> >>  For now, that is Etoys. It could be a suitable object-oriented
>> >> Logo with
>> >> media objects (this is essentially what Etoys is). It could be
>> >> some better
>> >> design (let's do one). The base could be Javascript (if
>> >> implemented on top
>> >> of an integrated environment of sufficient power), Python (ditto),
>> >> Ruby
>> >> (ditto), etc. Whatever it is, it has to be above high thresholds,
>> >> not a hack
>> >> or a gesture.
>> >>
>> >>  Besides the programming the children use to learn important ideas
>> >> in math
>> >> and science, they also need to be able to see how their own
>> >> computer world
>> >> is structured by being able to "pop the hood" on practically
>> >> everything they
>> >> use. Perhaps it is OK for high school children to see the current
>> >> code (but
>> >> I don't think so). I think there needs to be a wrapping on the
>> >> entire set of
>> >> facilities that uses the same conventions that 9 year olds do
>> >> their own
>> >> programming in. Again, if it is to be Python, then it needs to be
>> >> crafted a
>> >> bit for younger children. E.g. Etoys allows easy unlimited
>> >> parallel tasking,
>> >> and this is very important for children's programming. Etc.
>> >>
>> >>  There are many good things that can be done here. We live in a
>> >> computing
>> >> world in which there is a tremendous amount of identification
>> >> between many
>> >> programmers and the tools they use -- so strong that it resembles
>> >> religious
>> >> fervor. From my view, ALL of the system have such flaws that we
>> >> are better
>> >> off being critical of all of them and try to use the best ideas from
>> >> everywhere.
>> >>
>> >>  If "Children First!" is really the goal here, then we must spend
>> >> most of
>> >> our energies trying to make the childrens' environments more
>> >> conducive to
>> >> creative learning of powerful ideas.

I think, for gen1 at least, that Develop should focus on older children
and hackers writing Activities, and eToys should focus on providing a
learning environment for the youngest children.

That isn't necessarily ideal, but it is certainly the most realistic
target.  That doesn't mean that Develop won't learn as many lessons from
etoys as it can, and perhaps ultimately do what eToys does now for the
young kids.

>> >>
>> >>  Cheers,
>> >>
>> >>  Alan
>> >>
>> >>
>> >>  At 02:52 AM 3/9/2007, MBurns wrote:
>> >>
>> >> On 3/8/07, no body <esorcus at hotmail.com> wrote:
>> >>
>> >> >Isn't the mere presence of eToys on the XO a complete anathema to
>> >> the
>> >>  sugar philosophy?
>> >>
>> >>  As the XO is about education and etoys is the only software on
>> >> the OLPC
>> >> that
>> >>  actually has any relation to education the above is a somewhat
>> >> confusing
>> >>  statement. But maybe I misunderstood and the XO is really about
>> >> Python...
>> >>  I think the quote is referencing something else (though I may
>> >> misunderstand).
>> >>
>> >>  The eToys environment is a self-contained world of development. One
>> >>  that exists within the Sguar world of development. Programs,
>> >> projects,
>> >>  source code and objects written in that eToys world do not exist
>> >>  outside in the Sugar world. You can write a sugar Activity or an
>> >> eToys
>> >>  bundle, and, as we have seen in the gaming realm, they can often
>> >>  accomplish the same end goal.
>> >>
>> >>  Now this may or may not be an issue to people(OLPC devs, students,
>> >>  teacers), they may or may not care, but it is an interesting 'world
>> >>  inside a world' for this transparent learning machine we are
>> >>  developing.

This is an important distinction to make.  Develop has to deal with the
real world (at least within the context of the XO), whereas eToys has
the benefit of being self-contained.

>> >>
>> >>  --
>> >>  Michael Burns * Security Student
>> >>  NET * Oregon State Universit

- --
Regards,
Andrew Clunis

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF8lncALkUMXSNow8RAtVwAJ9ZIsgVc+WewtzzhWZOaLK2sbzmjgCgzQPN
yHkexEfpqB6WC8n3iz18+m4=
=BWLu
-----END PGP SIGNATURE-----