[sugar] Develop activity (Oops...)

[Jameson "Chema" Quinn]

Mcfletch, I love how you've stated the ideal steps for handling native
languages. The visual stuff has me more skeptical, though:


> My idea for internationalization is as follows:
>
>     * assume a progression from graphical, to local language, to
>       subset-of-English for those who want to become proficient
> programmers
>           o provide tools that let the children put blocks together in a
>             reasonably constrained environment


I think a good visual programming language should be designed from the
ground up as such. I support giving some drag-and-drop support and visual
cues to programmers, but I doubt it will ever be beneficial to actually hide
the textual python code, as opposed to overlaying/supplementing it. (Indents
are already a powerful visual feature, anyway) For real visual programming,
we should focus on squeak and/or logo.
Visual elements that could add to python:
-Branching/looping control flow arrows in the left margin
-a menu of functions, objects, variables, and control flow objects, with
generic icons, for dragging into the program
-the ability to see where a variable was last set (all possibilities given
control flow)
I remain unsure whether any of these are worth the effort.

          o show the children what putting the blocks together does in
>             their native language


Are you implying that the visual metaphors only encompass a subset of the
Python language? This is an interesting way of simplifying our task, but it
makes the leap from visual to textual editing an irreversible one - not good
for user-friendliness.


>     * have a tool that allows for querying e.g. BabelFish to get
>       translations from/to a given language for given identifiers


Note that this tool would not need sophisticated syntactic logic, just some
basic dictionary. It could thus rely on dictionaries in the flash, which
will be present anyway.


> My preference would be that we get a few spike tests under way that show
> that a given internationalization approach will work *with the current
> Python*, also to test out AbiCollab as an editor, integration of an SCC
> system into an editor in an intuitive manner, parsing and presentation
> of Python code as visual programming operations (and visual editing to
> produce new Python code), and generally any parts of the project that
> are "research".  We can assume that this code will be thrown away and
> that we'll just use the ideas and results to write the actual IDE.


I'm starting work on a fork of IDLE which should demonstrate the translation
logic, pretty much along the lines that have already been discussed - I'll
send a message to this group when I have something workable. Most of the
guts of it should be agnostic about the underlying data, so it should be
applicable to an AbiWord-based system. One thing I worry about, though, is
undo - as multiple people are working on the same code on multiple levels of
abstraction (languages and language mappings, for instance), the simple
undo-stack metaphor starts to break down and you need something more like
version control and merges.... I wonder if anyone else has good ideas on
that score.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070807/3f0c2145/attachment.htm