Andrew Clunis wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, Dec 19, 2006 at 08:41:12AM -0800, Alan Kay wrote:
Hi Andrew --
I guess I agree with what you say about Python and its structure, but
I was thinking much more about what the children see, not so much the
developers.
That brings up another problem. I myself was a child not so long ago,
and as I started to become interested in computer programming and
software development, it was important to me that I was "on the same
level" as all other desktop application developers (I admit that I was
a bit of a weirdo, though).
I think there might be room for two kinds of development environments;
one that is proper Python, directories, etc, and one that is more
constrained. This goes against the "same level" idea, but I don't know
if everyone will mind so much.
The idea then would be that someone (more experience) would set up the
framework of an activity. The child would edit just a few files,
ideally just one file. There might even be some constraints in how the
module could be set up -- e.g., no fancy module-level execution to make
the module hard to reload.
Here's a use case:
Writing chat bots is fun. The basic code is pretty clear -- you start
up a chat session with a user, and messages come in and responses go
out. Clearly there's more to it, but this is all the child is
interested in, and all the child needs to be interested in.
The Chat Bot Activity Factory Activity creates a new activity. There's
one file, "chatbot.py", that the child edits. It contains the basic
framework:
from chatsession import ChatSession
class Session(ChatSession):
def respond(self):
return 'Hello '+self.buddy.name
And maybe it has some other methods (maybe just no-op methods that can
be usefully extended or changed), plus some docstrings to help the child
figure out what's going on.
The child really has a lot of freedom from here. They can connect to
websites, do calculations, maybe read things from the journal, whatever.
But they don't have to think too much about what goes into making a
chat bot, and they can get very immediate results from their work.
This could actually apply to anything, really; this could be part of the
development environment as a whole. Now that I think about it, it
doesn't seem to hard. You just need a Activity Factory Activity, and
some metadata about the resulting activity to help guide children
through the first parts of development.
One example would set up a Sugar GUI activity. It would create all the
basic files, the main loop, etc. It would contain enough so that you
could start the resulting activity and see something. It would also
have some metadata telling the Develop activity where the child can
start work. The generated files can inline documentation. (In what
language? That's the kicker -- anyway, we can localize the docstrings,
even if we can't really localize the API itself)
It's also possible that other languages could be supported; e.g., Logo
through PyLogo. It doesn't give you the full power of Python (e.g., OO
stuff is hard to do through PyLogo), but it gives you a lot, and could
potentially be localized in a way that Python could not. Anyway, while
that's not an appropriate language for an entirely activity (for
instance, it's very slow), it can be appropriate for extending
appropriately constrained portions of the activity.
Of course, then there's the notion of plugins. If you write one chat
bot program, do you need to have children fork it and extend, or can
they just extend the activity directly given stable and public extension
points? So far Activities lack any notion of plugins in this style,
except perhaps through dbus (which is still too vague by itself, and
would need to be expanded upon).
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
