[sugar] Multilingual programming

Ian Bicking ianb
Mon Mar 12 23:15:14 EDT 2007


Since there's been some talk of programming environments and whatnot, I 
thought I'd throw out some ideas about the whole English focus of most 
programming.

Anyway, I've thought a lot about how it might be possible to use other 
languages in Python code, and I can't come up with anything even 
slightly useful.  With sufficient cleverness, it might be possible to 
support other languages in isolated code, but it's so isolated that it 
requires cutting off the rest of the environment.  You can't reasonable 
translate things like dict.items, or the standard library, or the code 
that's going to be written by English speakers; and English will be the 
only common language among developers indefinitely, since there's no 
other common language to replace it, just local languages.

Still, we could create miniature environments where largely non-English 
code could be written.  It would involve lots of wrappers and custom 
libraries or wrappers and some hiding of libraries in tracebacks and 
elsewhere.  Keywords would still be left.  But the result is so 
constructed and isolated, I'm not sure if it's any better than just 
using a different language.

Something that can be localized reasonably easily is the documentation 
itself.  That could even include docstrings -- a small hack to help() 
and/or pydoc could look up translated docstrings, probably just leaving 
the original docstrings in place.  This could be useful.

Another option that came up in conversation (though I've forgotten the 
guy's name) is to use a language more suited to translation (like Logo, 
or eToys scripting) but really focus on using that as a bridge to 
English programming.  That could be done simply by offering translations 
as much as possible.  E.g., if they type in:

   para cuadrado :longitud
     repetir 4 [ad :longitud iz 90]
   fin

And they get alongside (and they could use at any time if they want):

   to cuadrado :longitud
     repeat 4 [forward :longitud left 90]
   end

This is only somewhat helpful, since the language used in Logo and eToys 
doesn't actually line up with Python.  But maybe that should be a goal; 
at least with Logo it *could* line up.  There's no repeat in Python, but 
"to" is "def", for *could* be added ("for" seems to mean lots of 
different things), it could have significant indentation, and some other 
renaming.

Anyway, just throwing out some ideas.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org


More information about the Sugar-devel mailing list