[sugar] Develop activity (Oops...)

[Andrew L. Clunis]

Ack, I hit the "Send" button as the "Save Draft" button!  Sorry
about that, guys. :(

Here is the rest of what I meant to say:

Greetings all,

A group of us are interested in getting to work on Develop activity.

Here's what, as I understand it, people are working on:

- code internationalisation.  Jameson and myself have been discussing
  various means of achieving this lofty goal, see below;
- version control (so kids can modify others' activities without
  worrying about maintaining different copies of code, and providing
  them with a means of sharing and merging any changes, etc.);
- visual editing.  Mike Fletcher has been looking into Logo and
  Smalltalk-like visual editing for python development.  Guido
  has been looking into class reloading which would permit people to
  modify the code in a running program, a necessary feature for visual
  development;

The current Develop source tree sitting on dev.laptop.org is now quite
out of date and no longer runs.  I personally considered it a spike
solution, a demonstration of what a simple version of Develop could look
like.  I'm not even sure we'll reuse any code from that version.

Here, although it is somewhat out of date, is the wiki page for Develop:

http://wiki.laptop.org/go/Develop

Regarding code i18n, I filed a bug on the OLPC track several months ago
concerning docstring translation:

http://dev.laptop.org/ticket/1075

However, recently Jameson and I came to the conclusion that not only are
docstring translations necessary, but so are identifier translations.
Jameson and myself have been discussing several alternative methods:

Method I:
The programmer writes a python file in whatever language they want. They
set this language in some sort of "base language" directive in the file,
and then add translations for the identifiers to a matching '.pyt' (a
gettext-like table, perhaps?) file.

Method II:
... is the same as Method I, except that the base language is always
English.  The code is presented to the user for editing in the language
of their choice using these the human language equivalents from the .pyt
file (and the .pyt files of any imported modules).  In order to preserve
the reversible 1-1 nature of the translation step localized words which
clash with English keywords or localized words from other libraries are
given an alphanumeric prefix to distinguish them.  Although this
approach is perhaps not quite as "utopian" as Method I, it has several
pragmatic benefits: more translators will be available with English
serving as a lowest common denominator (more people know Arabic and
English and Portuguese and English than know both Arabic and
Portuguese); with a common base language, exchange of code will also be
easier in the international community.

On top of that, there remains the question as to how and where to
implement this logic.  Should it be a separate tool/library (possibly
troublesome, because Python's dynamism means that the only thing that
truly understands scope is the interpreter at runtime), or something
inside the interpreter (harder to implement/maintain/get accepted into
upstream)?

This is such a drastic change, with potentially extensive consequences,
that its development should involve the Python community.  It should
clearly begin life as a PEP.

I suggest that we have a live discusson on either IRC, a teleconference
(I imagine that the folks at 1CC would be able to arrange a
teleconference for us), or Skype (ew), and see where it takes us. There
are a lot of really awesome ideas floating around, but I think we need
to make this a coherent effort.  When are people available?

The first step would be decide what Develop should be (at least for
Gen1), and write our acceptance tests.

Happy hacking!

-- 
Regards,
Andrew Clunis