ecn-pa.scott (07/21/82)
I've always wondered how people program when they work
primarily in other languages than English. Are there
other-language versions of English based programming
languages? The very few examples which I've actually
seen use the English keywords with variable names in
the second language. Something like:
if (vitesse > 10.0)
{
dommage++;
valeur--;
}
When I see something like that, I read "if vitesse greater
than ten, dommage plus plus; valeur minus minus" with everything
but the actual French pronounced in English. I heard a rumor
of a French version of BASIC, but I'd be interested to know
what people do in other languages. What about cases where
the alphabet which one programs in and that of the programmers
spoken language are different? Do you transliterate or use
English? Questions, questions...
Scott Deerwester
Purdue University (pur-ee!scott)cak (07/21/82)
I worked in Germany for a while, and it's just as you imagine. COBOL, PL/I, BAL and APL (it was an IBM shop) were all programmed with English keywords, German variable names. It was interesting, to say the least. Even more intriguing were the manuals. The latest software release was always available, but manuals in German were usually a couple of revisions behind, leading to many difficulties. I was often called upon to do on the spot technical translations from the *current* English version. Chris Kent, Purdue CS Dept.
smb (07/22/82)
Some languages present more difficulties than others. Arabic and Hebrew, for example, not only use non-Roman alphabets, but also read from right to left. This makes solutions like "English keywords, native language variable names" impractical. My understanding is that at least in Israel, everyone programs in English -- knowledge of English is required at the Technion for all students anyway, for example. But that doesn't help when you're writing a program that has to print Hebrew text, even assuming a suitable I/O device. How do you include Hebrew characters in a C string? (I heard this discussed at a conference in Jerusalem about 10 years ago. Anyone up on current techniques?) --Steve Bellovin
rama (07/22/82)
I worked for a company in India, where some work was underway to come up with Hindi and Telugu versions of FORTRAN. For the benefit of the ignorant, Hindi is the national language of India and Telugu is a regional language spoken in south India. (Not to mention that India is in Asia and not in Caribbean!!) The version which I saw in operation was a Telugu one. The compiler would accept a program written in Telugu and print the output in Telugu. Unfortunately, since there were not any peripheral manufacturer making Telugu keyboards, the English keyboard had to be faked to act as a Telugu keyboard. The output was routed through a matrix printer to print the output in Telugu. There was a pre-processor which processed the Telugu text and made on the fly translation to English text before feeding it to the standard FORTRAN compiler. I believe this process was complicated quite a bit because of the fact that FORTRAN does not have the notion of keywords. I am familiar only with the early stages of this project so am not familiar with the current status. Kishore Ramachandran rama@uwisc
rvpalliende (07/25/82)
When you program in a language other than English,
English keywords become special symbols, like APL symbols.
Ex. The following program
if( velocidad > 0.0 ) {
valor++;
suma += velocidad;
}
is read as follows:
if velocidad mayor que cero, valor mas-mas, suma mas igual velocidad.
Special characters are a problem. In Spanish you normally leave out
all accents and the tilde over the letter <enye>. ~
n
This cannot be done for the word year: an~o would become ano=anus.
That particular word is dealt in several ways:
Use French: agno
Use Portuguese: anho
Use Latin: anno.
By the way, the tilde is really a small n so, the Latin approach is
sensible to me.
Also, Spanish manuals are normally awfully translated.wagner (07/27/82)
I can answer some of the questions about computing in Israel. Most texts are in English, all the manuals are, but some handouts are in mixed Hebrew/English. Typically, the program is on the left side, reading left to right, and the comments are on the right side, reading right to left, in Hebrew. Your eyes do little reversing scan tricks to try and read it. As for final output, there are Hebrew print chains, but they are typically special mounts, and you have to reverse the string yourself. I dont think I ever knew how it printed in the program listing. I know the Technion had specially modified 3270s with a Hebrew character set. I think there was also a hardware mod to the horizontal coils to reverse their sense at the flip of a switch, allowing programs that hadnt gone to the trouble of reversing their strings to be readable. I also saw a modified version of [NW]SCRIPT (sort of like NROFF) that offered right justification as well as left justification, and programmed string-reversal. On other fronts, PLI (optimizer and checkout, not F as far as I know) has user-replacable keyword tables, so you can change the word DO to FAIT (or whatever you want). There is even a way of specifying optional embedded blanks (as in GOTO or GO TO ) I cant remember what happens to the messages, though. I think they stay in english unless you want to do major surgery, but I am not sure. I have never actually encountered anyone who used this feature. I dont even remember how we found it. Michael Wagner, UTCS
jcwinterton (07/27/82)
Many, many years ago, the U.S. Naval Electronic Research Laboratory published a book on a compiler and compiler generator system called NELIAC. This book contained the only version of a compiler which accepted ALGOL with all the keywords translated into any language you liked. There was an example in the book of the text of an entire program in Hawaiian, keywords and all. The only two translations I recall off hand were: ALOHA ::= BEGIN PAU ::= END Interesting, but when it comes to "standard" languages such as COBOL and PL/1, I believe that it is more important for keywords to be invariant across national and linguistic boundaries for the sake of portability. Variable names and labels are just arbitrary symbols and need not really be thought to have any semantic significance outside the program(s) in which they are defined. John Winterton