[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