Multilingualism at programmer level (Was: slate unicode support)

[Brian T. Rice]

Glenn Alexander wrote:
> On Fri, 30 Jul 2004 22:01, Lendvai Attila wrote: 
> 
>>at a certain point in the future, this issue will be much 
>>different. source will be just another object graph, and an 
>>editor will work on that object graph instead of plain text 
>>(i.e. no parsing, or in a quite different way). 
>  
> Query: So, in theory, a programmer with absolutely no English would 
> then be able to program using keywords in their own language and it 
> likely wouldn't be too hard to have an editor that auto-translates 
> other's code in a foreign language to meaningful words in whatever 
> local language, so that programmer could look into others' code even 
> if it is not in their native language???? (I imagine such a system 
> would provide comprehensible, rather than fluent translation, like 
> human language auto-translation systems, but programmatic code doesn't 
> read exactly like a natural language anyway). 

In theory, yes. In practice, we need quite a lot of work to get there.

> eg: if I call a local variable in my code 'white_dog', a Chinese 
> programmer's editor could show it as 'bai_gou' either in pinyin or 
> characters, the idea being that meaningful variable/object/function 
> names are carried through to other languages transparently. 

In principle, yes. You need code which adheres to certain patterns, 
whether by social consensus or a bit of tool constraint. For examples, 
take spell-checking plus making an "abstract lexical grammar" instead of 
a "_"/"-" separator convention, which is a trivial grammar. Or you could 
turn linguistic descriptions into identifiers using such a means, with 
"interning" applying to it just like strings to symbols.

> This, if I got the idea right, represents a VERY useful thing ffrom my 
> perspective, as my interest in Slate is its use in the primary 
> classroom, not necessarily in an English language setting. 

Sure. I can see why.

>>at that point names will be only used for humans, you could 
>>even remove all names from the code as a simple and effective 
>>ofuscation, and it would still run just like before. 
>  
> Query: So the built-in slate standard objects could be tokenised, and 
> a local language back-translates those tokens to whatever human 
> language the user wishes to program in?? 

I hope you mean the /names/ of the objects. But Attila is just saying 
that the names are irrelevant to the meaning and that (by extension) 
sets of names could be modules themselves. By keeping a very standard 
and highly-polymorphic naming convention (overloads /plus/ same 
type-semantics for all methods with the same name), the work required to 
create and maintain such modules would diminish.

> Is this sort of thing what might be possible *in the long term*? Has 
> anyone ever done something like this before? 

It's really really hard to get this right. This has been tried or at 
least attempted before, but it's really difficult, as human languages do 
not translate well, at least not without large specially-built (meaning: 
more manual work for the builders) structures. If anything, we'll just 
make it easier to reach the point where there are only the hard problems 
left. ;)

>>so I don't think we should concentrate on parsing too much, 
>>just simply avoid chinese until there's an editor mentioned 
>>above. 
>  
> Hard to avoid Chinese when I live in the midst of 1.3 billion of 
> them ;-). But, yes, if I unserstand the intent of the above, focusing 
> on the described object graph editor would definitely be the way to 
> go. 

Well, the real work will all be done by us, regularizing how we write 
programs (method names, mainly); otherwise such a graph is not even 
possible or useful. Past translation attempts failed because the 
communities largely never even consider the "naturalness" of the way 
their code is expressed (languages with much punctuation can't even 
consider it).

> Regards, 
> Glenn 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: water.vcf
Type: text/x-vcard
Size: 208 bytes
Desc: not available
Url : /archives/slate/attachments/20040731/e91dbf65/water.vcf